I don't want my replies to git project issues showing up in my social feed... ?
Discussion
Well, I want them showing up in my notifications and that's the only kind most apps will display.
that is not a good excuse. using kind 1 just because all apps support them just forces social apps to have to keep filtering out different kinds of replies
I already had enough issues in noStrudel dealing with kind 1 replying to long form posts. now they are going to reply to everything? and im going to have to filter them out just to show the timeline?
It sounds like the way forward will be for new feature specs to explicitly define their comment types. Kind 1 or kind 1111 could be used as a baseline, with additional requirements added to support the needs of the intended feature.
The potential pitfall is that clients would have to reimplement basic comment support multiple different times for different feature sets, but I don't think that's necessarily such a problem. Nostr apps don't need a "global" feed that sucks up everything, nor does every client need to support most NIPs. Make more single-use clients.
agreed, although "reimplement basic comment support" isn't really accurate. in the case of noStrudel I have generic comment thread components and I simple switch the kind depending on what they are commenting on
Yeah, but that's already enough work to make most client devs totally freak out.
The problem is that there's no notification app, so the Twitter clones are the closest thing we have and everything that doesn't show up there doesn't get a response, because people can't go to 5 different apps, every day, to see if someone responded to something.
Like, if I go to GitWorkshop.dev and write an issue, neither of you nor anyone else responds. I have to tag someone on a Twitter clone or reply to the issue with a Kind 01 note tagging them. Then it shows up in their notifications and I have a chance.
Like, someone will go to an OtherStuff app, write a comment, close it, open Primal or whatever, and then replying to them in the OtherStuff is useless. It's now dead to them.
We have threads in app silos, just like with legacy systems.
Then use Communities
I thought this was an elegant solution, but it's sort of just stalled.
https://github.com/nostr-protocol/nips/pull/1076#issuecomment-1987002929
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.
it only just dawned on you today how much of a dumpster fire is nostr client devs quality of work?
i guess not surprising considering yours is pretty much top shelf