Nostr Web Client

1. The `e` tag doesn't offer a URL property as per spec.

Which leads to 2

2. To figure out which URLs in `.content` must be verified by NIP-94 hash, the client will need to download all e-tags to filter the potential 1063s, then get their `url` tag. After that, the client must replace all 1063 URLs in `.content` with the appropriate `nostr:nevent` tag in the text before displaying in the screen which will then render the Quoted event as any other event as usual.

Sounds like a terrible workaround to not implement Quoted NIP-94s to me.

3. If we do that to 1063 events, do we need to do that with all other quoted events that are not kind 1?

fiatjaf 2y ago

1. It can be a different tag, specific for NIP-94.

2. This new tag specific for NIP-94 can reference URLs that are inside .content verbatim or in other special ways, since it is custom.

3. No, if the events are not "special" and you're only interested in having most clients display their .content and .author, then you don't need special treatment. But if you want clients to do special things with them that need special code to be written, then what is the issue with adding a new special tag?

Reply to this note

Please Login to reply.

Discussion

Vitor Pamplona 2y ago

I don't have an issue with adding a custom tag. I just don't understand why to add bloat when there is no need to.

But if everyone is ok with.. then.. bloat it is.

I certainly prefer to keep kind 1 clean with simple NIP 27 uris for every tipe of event. But looks like no one cares about that these days.

NIP 95 won't offer an option for a tag (there is no URL) so... I really don't think custom tags are a good design pattern. People will have to deal with other events sooner or later.