I'm in favor of specialization and not showing stuff that doesn't matter for a particular client.
For example: I don't want to see every single comment that someone adds to a "Google Doc" in my social feed, even though it might be a nostr event.
What do you think of the idea discussed at the beginning of https://www.youtube.com/watch?v=kk1x0Bjtes8 about creating a new short text tag that can be added to any weird new event kinds so clients that don't support these kinds can render that as a fallback?
Discussion
nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft, please fight this guy.
I completely agree with Gigi in that we need to be able to filter those kind of events. But I would like to have the option to see them in my clients if I want to. Only trouble is currently you need to retrieve the root event to know what it’s kind was.
I think the problem is that some people want to make comments on a music directory using kind 1, so these comments will naturally appear in their feed -- and we'll have the problem of how to display their references.
Gigi is saying we shouldn't use kind 1 to comment on songs.
I don't agree with that;
I think if generic clients had a way to parse "unknown events" in a way that makes sense of them, the experience can be perfect.
Think about a picture; someone shares one as a kind 1. People comment on it. A discussion ensues. You want to be able to see what your follow list is discussing around that picture.
A song, a list, a highlight, an item for sell, anything is the same thing; if done publicly, it should be done in a kind 1. That's the cool thing about nostr; data flows unencumbered, not siloed.
What we need is a way for clients to be able to render and discover handlers for unhandled kinds.
Zapstr track events include in the content a kind-1-compatible payload (song name, and a link to the bech32)
The content of a zapstr track can be rendered without any special consideration and it would make sense to a user, safely ignoring all the metadata
So could the "special tag" be just the content?
Maybe it would still make sense to additionally define a 5th parameter to "e" tags for the root event where the replies carry the root kind. So [ "e", "
I think that’s a valid point. otherwise everything could just be kind 1 with application-specific tags.