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", "
