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.

Reply to this note

Please Login to reply.

Discussion

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.