Most people have yet to understand what was done yesterday. Verifiable third-party content is as key to Nostr as the basic event signature.
#[0]
Discussion
Can you give us the most important parts and why they’re important? (Unless you’re busy)
There is no point in signing for posts that include image urls if the image itself can be changed later.
Same for any other reference to a static content.
I’ve been thinking this is important for translations too. Third-party translation services (like ours) could be modified in transit or by the client. Right now there’s no event associated with it and no way to know if it’s been modified.
#[6] have you thought about this?
You should sign translations as separate nostr events.
Which event type should we use? Anyone already doing this where I can read about it?
You can create a NIP for translation services. Pick an NIP, define the tags for languages used (so clients can search for the language of the user) and simply watch for kind 1s and post the new kinds with the appropriate translations.
Before translations, we should start adding tags for the language the post was authored in (on mobile, I guess you can query for the keyboard and auto complete language setting?)
Like [ “LCID”, “en-us” ]
I am not sure we can trust that info. Amethyst wouldn't know which language the author is using.
@tyiu pointed out there’s this NIP 12 addition to add a post source language but hasn’t been ratified yet?
If this NIP-12 addition got ratified and clients started following it, then maybe. But it’s still all optional. So may be unlikely? https://github.com/nostr-protocol/nips/pull/182
Doesn’t this just end with every kind 1 event having a translation in tons of languages? This is absurd bloat at the relay level. Perhaps a custom special purpose relay (more like a translation cache) could support this but I wouldn’t expect normal relays to do so.
Agreed. I don’t understand why this is necessary.
But this doesn’t prohibit us from having verified translations right?
Our translation service could publish a public key and send over a translation string along with a hash? Then client or even user can do the verification to see if the translator service actually signed it and the translation isn’t modified?
Yes, but I think that can remain an implementation detail. Don’t think it needs to be part of the Nostr protocol. In fact, the problem described here seems like a small corner case and very theoretical, and the proposed solution seems a bit over engineered comparatively. Any request can be man-in-the-middled. There isn’t really anything specific to translations. HTTPS solves some of this I think.
Makes sense !
Not only do have translations into many languages, even for 1 language you can have multiple translations based on which AI model is used for the translation. Even more bloat.
确实很关键进步，因为之前只能确保文字部分有签名验证无误，但通过URL外部引入图或视频等是无法验证其变动的。
而通过这个 #kind1063 的资源包装中转，可以记录下引入Nostr时的指纹信息，一旦有变动会有提醒。进而确保整个Nostr图文信息，在必要下可去验证与发出时相同，不会轻易变动或变动可知，增加可信度。
可以视为整个 #Nostr 协议的一次重大升级更新。从只信文字，到可以信图片和视频等多媒体了。
lightning:cndx@btcdv.com 🐇ᥬ[🐕]᭄🌿
Ceci 👇
#[0]
🤙
#[2]