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?
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.
It's weird that you think like that. Kinda makes me want to agree with you. Maybe I am missing something and my suggestion is way off here.
On the other hand it looks like you are not getting my points at all, so it's hard to evaluate. I do think my suggestion is better and that it adds _less_ bloat though, but maybe there will be a better idea tomorrow or next week of how to do this that will prove wrong, it's very hard to say.
By bloat I mean having to spec and maintain custom tags. Code wise, custom tags are worse (more processing needs, more special cases), but not by a lot. I prefer to work with simple e tags if possible to keep the event graph as intact as we can. All these extra named fields each event kind creates do add complexity to the composability of nostr.
Maybe I am taking a long term view while everyone else is thinking short term.
Or maybe it's just me. Either way I am happy to code what pleases everyone. What I coded was just my best way to do it.
Thread collapsed
Thread collapsed
Thread collapsed
