I thought this was an elegant solution, but it's sort of just stalled.
https://github.com/nostr-protocol/nips/pull/1076#issuecomment-1987002929
Discussion
I like this one.
I's still a fan of using kind+1 for replies but I think I'm in the minority. Still NIP-22 is a better solution than kind 1s
anything to stop using kind 1 😀
Kind 1 with a k Tag or a generic comment kind are both "final implementations" (you rebuild it once and you're done). Seems neater than plan Kind 1s, at least.
even kind 1 with a "k" tag wouldn't fix the issue of social clients having to filter out every reply just to show a timeline
a generic comment kind would be a clean solution since it would not show up in the social timeline and would allow clients to show just the replies
however NIP-22 might need to include "p" tags for notifications
I'd argue a generic comment kind would be well-served by AsciiDoc support, as it opens up more rich text options and makes the kind 1111 events appealing in a broader range of use cases.
I think this is cleaner than NIP-22
after reading though NIP-22 again im not really a fan of the meta-tags that it has in the "o" and "r" tags for a few reasons
- The first index of the "o" or "r" tag uses a ":" to separate the values then the following indexes use spaces?
- The "o" and "r" tags have no way of indexing pubkeys. so we wouldn't be able to pull all comments that reply to a pubkey
- Why do we need to reply to URLs, topics or geohashes? cant we just reply to events that represent those things?
IMHO a generic comment kind:1111 + NIP-10 + a "k" tag would be the most elegant solution
They've lost me, in the technicalities, I'm afraid. This is a discussion more for nostr:npub1wqfzz2p880wq0tumuae9lfwyhs8uz35xd0kr34zrvrwyh3kvrzuskcqsyn I think.
I just like the idea of not using Kind 01, but also not losing the "general comment" flow or recreating the same type of event with 29170 different event kinds.
who is going to create the events that represent those things?
commenting on highlight events are similar to replying to URLs
kind 1 with "g" geohash tags or another similar location event would work for commenting on locations
I'm not sure about topics though since that sounds kind of vague
what I am saying is that there could be multiple events representing a URL
I think the point is that there is actually no need for an event to represent a URL, since the kind 1111 events can point to entities that are not Nostr events.
It makes a lot of sense to me, all it needs is a good client to wrangle those into a worthwhile user experience.
The tagging suggestions in the NIP-22 proposal are a bit of a mess. I, for one, am not a fan of the significant uppercase 'K' tag. There's a lot riding on a minor distinction, there.
When you need a table to explain all the different tag value combinations, the tagging system is too complex.
Yeah, I was like, TL;DR.