NIP-73 - Generic Comment

[arthurfranca]

Please read here

[vitorpamplona]

+1.

Thread roots and replies should always be different kinds. This "Comment" kind could be for replies only. The thread root is usually the main content kind in each NIP.

Then it would be similar to reactions. They can react to anything but they never start anything by themselves.

I also think we should migrate Kind 1 to use this kind as reply in the future. Kind 1 should be for root posts only.

[arthurfranca]

I also think we should migrate Kind 1 to use this kind as reply in the future. Kind 1 should be for root posts only.

It would be great if clients start posting kind:1111s along with kind:1 replies when publishing new replies.

[dluvian]

+1
We should deprecate nip10 root and reply markers and refer to this nip, so people are aware that kind 1 shouldn't be used for replies

I also think we should migrate Kind 1 to use this kind as reply in the future. Kind 1 should be for root posts only.

100% agree. Kind 1 being root and reply is extremely inefficient

[mikedilger]

Juggernauts, mavericks, all of you. This is a seriously breaking change breaking tons of existing software.

[vitorpamplona]

Juggernauts, mavericks, all of you. This is a seriously breaking change breaking tons of existing software.

But is it better or worse?

[dluvian]

This is a seriously breaking change breaking tons of existing software.

Strong words for something that existing clients can just completely ignore. If devs feel like their clients don't show enough content they can opt-in to querying this kind, like they do with every other event kind.

We also have to be realistic. Kind 1 sucks because it is overloaded. There have been multiple PRs that address this issue. At some point client devs will just use a different kind for replies, because it's easier to work with and is more bandwidth efficient, which is an important point since the majority of potential nostr users will use mobile clients that have bandwidth constraints.
Having these replies standardized in this repo does not matter, but would be preferable. If the overlords here disagree with a sensible proposal clients will just define their own standards like jb55 did.

[staab]

@dluvian the the bar for adding something to the nips repo has never been "will the overlords allow it", but "do two clients implement it". So if you can point to two clients that have added this, we can merge it. But it's also fine to have the conversation here and debate whether it's a good idea. I'm against it until we have a system for managing breaking changes. I think there are things we can do, but let's solve that before we break the experience in all existing clients.

[mikedilger]

I made a mistake. This it isn't what I initially thought. Reading it again after a good nights sleep and I understand better what this is.

If you need to comment on a patch, or on a bid, or on a relay list, this event makes it possible.

My initial read was that all kind-1 replies would be replaced with these comments, and only kind-1 thread roots would remain kind-1, which is why I made the previous comment. But that's not the case.

EDIT: And I got that impression from comments earlier in this thread, which were I'd say "aspirational" and not reflecting the NIP as it is proposed.

[mikedilger]

But please explain why kind-1 notes cannot already be used to do this, and how a new kind improves things. I fail to see how it improves things versus kind-1.

[vitorpamplona]

But please explain why kind-1 notes cannot already be used to do this, and how a new kind improves things. I fail to see how it improves things versus kind-1.

It is currently impossible to make a filter that only brings kind1 root posts. You have to download all new posts and replies and then filter the replies out. It's extremely wasteful.

[arthurfranca]

@mikedilger kind:1 could in theory retrofit into a generic comment. One caveat is that to download root posts only, we'de have to convince existing clients to add something hacky like an empty k tag to be able to filter by { #k: [""], kinds: [1] } (and set k=referenced-event-kind for non-root ones). Separating comments from root posts felt more appropriate than the empty string.

Also, this thread you are in is a good example of the current situation: diverse apps are indiscriminately using kind:1 to comment on things that twitter-like clients don't recognize. Kind:1 clients currently have no way to opt-out.

If we do nothing, more and more bogus events will get downloaded only to be discarded right away. A bandwidth waste to wsay the least.

[mikedilger]

I agree root posts being of a different kind would be better. But it seems like a change that is too late to make.

I'm adding it to mikedilger/nostr-next#31

[dluvian]

But it seems like a change that is too late to make.

But why? Not improving the protocol in fear of a migration process feels wrong. Especially since nostr is still relatively small, we should just bite the bullet if it's worth it.

Consider that right now we can't:

• Query only roots
• Query only replies without setting ids
• Lazy load a thread starting from the root (because of nip10 root e-tags)
• Know if a reply is to another kind 1 or some other event

[vitorpamplona]

Talking about the specifics here, I am failing to see how the new role-based tag structures (o and r) are an improvement over NIP-10 markers. The parser of the first value is wild. If we keep adding other types to it (hashtag, geolocation roots?), the parser itself could become an issue.

Is this,

• ["o", "i:<event-kind>:<event-pubkey>:<event-id>", "<relay-url, optional>"]
• ["o", "a:<event-kind>:<event-pubkey>:<d-tag, optional>", "<relay-url, optional>"]
• ["o", "https://abc.com/articles/1/"]
• ["r", "i:<event-kind>:<event-pubkey>:<event-id>", "<relay-url, optional>"]
• ["r", "a:<event-kind>:<event-pubkey>:<d-tag, optional>", "<relay-url, optional>"]
• ["r", "https://abc.com/articles/1/"]

better than this?

• ["e", "<event-id>", "<relay-url, optional>", "root"]
• ["a", "<event-kind>:<event-pubkey>:<d-tag, optional>", "<relay-url, optional>", "root"]
• ["r", "https://abc.com/articles/1/", "root"]
• ["e", "<event-id>", "<relay-url, optional>", "reply"]
• ["a", "<event-kind>:<event-pubkey>:<d-tag, optional>", "<relay-url, optional>", "reply"]
• ["r", "https://abc.com/articles/1/", "reply"]

o and r tags feel worse because now we have a little evolving (do we need versions for this?) algorithm to parse the first value. Historically the algorithm has been defined by each tag and because it had a fixed scope, it didn't need to change over time. Putting the marker as the first tag means that you have to evolve the algo to support any new owners and reply structures that might arise.

[vitorpamplona]

Maybe what's missing is the clarification of the "schema" in value 1. We could specify the chars before the first : define a schema for the rest of the value.

• ["o", "i:<event-kind>:<event-pubkey>:<event-id>", "<relay-url, optional>"]
• ["o", "a:<event-kind>:<event-pubkey>:<d-tag, optional>", "<relay-url, optional>"]
• ["o", "r:https://abc.com/articles/1/"]
• ["o", "t:<hashtag>"]
• ["o", "g:<geohash>"]

Parse the schema first and then send the rest of the value to the appropriate decoder if you support that.

Do the same structure for replies.

Then over time these letters can be expanded to words to represent more objects that can be root or reply.

[arthurfranca]

failing to see how the new role-based tag structures (o and r) are an improvement over NIP-10 markers

As you know, relays won't filter by marker. That's why the marker meaning became the indexable tag. "root" became "o", "reply" became "r" (mention became "q" - "The q tag ensures quote reposts are not pulled and included as replies in threads"). There's further explantion in the NIP at the threads section (there are two "This tag is useful to...")

We could specify the chars before the first : define a schema for the rest of the value

I'm not sure about t: and g:. It is unusual treating the hashtag as the subject (OP) considering this can already be achived by picking kind:1 and adding one t tag.

r: prefix is a good idea, good to have prefixes if we need to extend them (though I think "i:", "a:" for nostr - also "s:" for event sets - and "r:" for all old web things would cover everything).
People could add r tag too (like t and g), but twitter-like clients would be polluted by kind:1's used as blog comments, followers don't expect to see random blog comments of their follows.

[vitorpamplona]

I'm not sure about t: and g:. It is unusual treating the hashtag as the subject (OP) considering this can already be achived by picking kind:1 and adding one t tag.

The hashtag root comment will only show in UIs that follow the hashtag itself. Meaning, you can post into #bitcoin without notifying your followers on the regular kind 1 feed. Only people following #bitcoin would see your post. That is a great new feature to boost the use of hashtag-exclusive content.

Same for geolocation as in #1170

r: prefix is a good idea

I think these prefixes that define how the rest of the value is encoded are required.

[arthurfranca]

Makes total sense. Some time ago before this PR I also thought of location-based public chats.

[Semisol]

I do not see the point of trying to get top level replies only, and we should just keep a tag that specifies the top level note's kind.

Could we not implement non-existence filters and check for the existence for r for this arguably nonexistent use case if we really need to?

[arthurfranca]

Unfortunatelly, non-existence filters are a dream that will never come true, according to previous 3 or so discussions about it on this repo.

On the lowercase k tag, check previous response. Can also see it being used to hook up on { "#k": ["#:t"] } filter to check for trending hashtags, cause the uppercase version would bring many more events. More on the hashtag use case for context.

[Semisol]

Unfortunatelly, non-existence filters are a dream that will never come true, according to previous 3 or so discussions about it on this repo.

Which ones?

They can happen without much performance penalty.

[arthurfranca]

@Semisol #523, #683

[Semisol]

I honestly wouldn't dismiss it based off of those opinions. You don't actually need a tag exists/doesn't exist index, as 99.99% of tag nonexistence queries come attached with other indexable fields (kind, other tags, author).

I will make a PR soon.

[arthurfranca]

I believe @mikedilger said the same thing at #683.

The caveat is relay may end up returning less events than the requested (even if there were more on DB) - of course considering client didn't request with a bizarre limit like {limit: 10000} to start with.

Clients would lose the ability of figuring out if there are more events to fetch depending on the number of returned events. Like, if client wants chunks of 5 events, it requests 6. If relay returns 6, client knows it should ask for more.

[fiatjaf]

I think this is probably a good idea.

[fiatjaf]

But please explain why kind-1 notes cannot already be used to do this, and how a new kind improves things. I fail to see how it improves things versus kind-1.

@mikedilger multiple NIPs have already been defining special kinds for contextual replies because people are very wary of using kind 1 -- as they should be, because kind 1 will show up in all microblogging clients without any context.

So having a single generic comment kind solves that.

Or we could create dozens of different comment kinds, all with the same format, but using a kind number for each situation.

I think there are pros and cons on both sides.

[vitorpamplona]

@pablof7z should we use this kind to reply Wikifreedia posts? :)

[arthurfranca]

Agree it is better now. Anything else?

[fiatjaf]

Looks pretty good to me now, @staab @pablof7z please take a look since you were unhappy.

[staab]

This is quite nice now. I do want to re-iterate that support for NIP-10 replies can never really be dropped, but this is a big enough improvement to have two ways of doing things. I'd be ok with seeing incremental adoption of this new kind, but I hope people take care not to break old clients that don't yet support it, especially with the microblogging use case.

[staab]

Relay hint?

[arthurfranca]

Added

[alexgleason]

Don't merge this without renumbering the file. It currently overwrites an existing NIP.

[pablof7z]

I will implement this; I hope kind:1-centric clients REQ for this kind; my fear with going off kind-1 is that the other stuff, which is one of the important things that make nostr special, can get it's discoverability greatly reduced (the "Is this Lana del Rey?" case)

Let's see how this goes.

[vitorpamplona]

And dont merge without 2+ clients using this in production

[fiatjaf]

It currently overwrites an existing NIP.

That is the goal.

[MerryOscar]

@fiatjaf @arthurfranca @staab if we replace NIP-73 and remove the i tags - that will break all of the existing queries we have and the interoperability between Fountain / Wavlake / others that are already relying on them.

Also if NIP-73 disappears - how are clients supposed to reference external content ids in non-kind-1111 events? Generic comments are not the only thing where this is useful. A simple example is a long form article that wants to reference these ids but there are many more.

I think you're correct that it doesn't matter if we remove the i prefix for this kind because there will never be collisions - but we still need a way to add the external content ids to other event kinds.

Wouldn't it be better to keep this Generic Comment as a new NIP and just have a note that the NIP-73 external content ids can be used in the s / S tags without the i prefix?

[Czino]

And dont merge without 2+ clients using this in production

I published a plugin to the Chrome webstore making use of this new NIP: https://chromewebstore.google.com/detail/sitechattr/oailcfmjgnkmpieilanaidbpgbjklafc

[fiatjaf]

@MerryOscar how have you been using the i references? My understanding from the previous comments was that you were onboard with this NIP and was going to adopt it. Isn't that not the case? And as far as I know Fountain was the only app using the i stuff, so it should be easy and good for everybody if we get rid of that and adopt a single way of referencing external content that is what this NIP describes.

Also nothing prevents using the schemes defined here in other events, NIP-73 continues to hold the table of the canonical way of referencing external content.

[MerryOscar]

@fiatjaf I'm definitely onboard with this NIP and we plan to switch the podcast comments in Fountain from kind 1 to this kind 1111.

My concern / frustration with replacing NIP-73 and the i tag entirely is that:

• there are already a large number of events that use these tags which are being queried and indexed
• there are already many clients using these tags in production (Fountain, Wavlake, Fanfares, DTAN) along with other podcasting apps which are actively looking at them
• it's very useful to to add these external content ids to other event kinds (long form articles, live events, zaps, other things that haven't been invented yet)

By overwriting NIP-73 it breaks all of the above.

---

adopt a single way of referencing external content that is what this NIP describes

that is not what this nip describes or was intended to describe - it describes a way to leave a generic comment that may or may not include a reference to an external content id

---

What's the downside to keeping the NIP-73 i tags for external content ids - but for this kind using the s tag?

From my perspective the s tag is different because it might be referencing an external content id or might be referencing a hashtag / geo reference etc.

[MerryOscar]

Also - if people think it's beneficial to overwrite NIP-73 with this NIP - why not use i rather than s and then at least there is backwards compatibility and it won't break everything?

Having said that I still think it's useful to have the i tag in a separate NIP because there will likely be other new kinds that are not comments but also work in the same way in terms of referencing external things.

[fiatjaf]

I'm happy with using the i tag instead of s. Is there a problem with that, @arthurfranca? Just a letter change, right?

I think a table in NIP-73 can serve other kinds that aren't comments too if they are referencing external events. We could have a different NIP, but then this one will have to reference that such that the references have the same format, and then I feel it's just more completely for the readers and more work for the nippers. Maybe we can do a single NIP for now and migrate the table of definitions later if necessary?

[pablof7z]

+1 on using i instead of s if people are already using that.

This schema should be used for any external reference for root + parents of any event kind, not just kind:1111

[MerryOscar]

I still think they should be separate NIPs because it makes things much clearer where to look for the documentation - but at least if the i tags are the same then nothing will break.

• referencing external content ids --> NIP-73 External Content IDs
• commenting on things --> NIP-22 Generic Comment
• other new NIPs that may or may not reference external content ids --> NIP-XX ...

Another example is the Audio Track NIP which already references NIP-73 and has partial support.

[MerryOscar]

I've created a PR to expand the existing NIP-73 with the full list of ids and also included the k tag for representing the id kind without the value - #1508

My preference would be to keep the existing NIP-73 separate from the Generic Comment NIP - but if everyone else thinks they should be combined then that's fine too.

I guess either way the actual structure of the kind 1111 Generic Comment has now been agreed. I'll start building this into Fountain for podcast comments and I'll follow up when it's implemented.

---

One other thing - if we are going to combine them there are some missing pieces from the original NIP-73 that would be deleted with the current draft of this PR:

book isbns without hyphens:

Book ISBNs MUST be referenced without hyphens as many book search APIs return the ISBNs without hyphens. Removing hypens from ISBNs is trivial, whereas adding the hyphens back in is non-trivial requiring a library.

movie isans without the version part:

Movie ISANs SHOULD be referenced without the version part as the versions / edits of movies are not relevant. More info on ISAN parts here - https://support.isan.org/hc/en-us/articles/360002783131-Records-relations-and-hierarchies-in-the-ISAN-Registry

podcast:publisher:guid

[staab]

My preference would be to keep the existing NIP-73 separate from the Generic Comment NIP

I agree with Oscar, these should be separate NIPs.

[arthurfranca]

I'm ok either way. Someone please decide and inform me.

[vitorpamplona]

PR #1508 moves the table and aligns the identifiers with this. We can delete it from here and just point to NIP-73.