NIP-22 - Generic Comment #1233

arthurfranca · 2024-05-12T15:54:19Z

Please read here

vitorpamplona · 2024-05-12T16:09:22Z

+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 · 2024-05-13T18:19:38Z

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

22.md

dluvian · 2024-05-14T09:25:01Z

22.md

+
+Examples:
+
+- `["o", "i:<event-pubkey>:<event-id>", "<relay-url, optional>"]`


Why is <event-pubkey> needed?

With pubkey, clients can get the right NIP-65 relay list. The referenced event most likely can be found at one of these relays.

So it is an indirect relay hint.

Also decided to add kind to the reference. It is useful to let client know if it supports the referenced event before downloading it.

Co-authored-by: dluvian <133484344+dluvian@users.noreply.github.com>

mikedilger · 2024-05-15T23:13:07Z

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

vitorpamplona · 2024-05-15T23:57:09Z

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

But is it better or worse?

dluvian · 2024-05-16T10:06:12Z

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 · 2024-05-16T15:23:26Z

@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.

Semisol · 2024-05-16T16:20:30Z

22.md

+
+```js
+{
+  w: 1111,


My wwwwwww key is getting stuck

Semisol · 2024-05-16T16:20:52Z

22.md

+For example, when commenting on a `kind:30023`, the `k` tag is set to "30023".
+When replying to another `kind:1111`, the `k` tag is set to "1111".
+If commenting on an `https://abc.com/articles/1` article the `k` tag is set to "https://abc.com" (its domain).
+The `k` tag is useful to fetch top-level comments about events of specific kinds (or domains), for example,


what if you want to fetch top level comments for some kinds, including replies?

You mean like coracle that shows not only root/OP posts and top-level replies but also any-level replies in the feed?
A K tag with the OP kind would do it instead of using the lowercase one. I will add it.

I feel like top level replies have no real use case.

I consider them high signal and great to include to the feed as they carry the start of the conversation as context. Very similar to quotes.

In contrast, reply of reply of reply tend to get off-topic and carry an incomplete context.

I can't think of any use cases for filtering by K and k tags. Maybe it's a similar discussion to #815?

Yes, like generic reposts too. When we pick one event kind to be a generic thing, clients need a way to ask relays for just things related to a specific kind. Ex: reposts of 30023 to show on a blog's first page as "recommended articles".

Without k, client would have to download all generic stuff, check individually what are they referencing and discard those that reference events the client doesn't support/want.

I quote @fiatjaf comment in #815.

I see that reposts would cause such trouble, but reactions shouldn't as you only load them after loading the target event.

K is useful if you have a reply feed, like Damus and Amethyst do. Frankly, I don't think the reply feed is that useful but so many people use it that it's kind of a requirement for kind1 feeds these days.

And the reply feed only exists because kind1 clients couldn't download just the root threads from follows. So it was a way to justify not wasting bandwidth of the replies without showing to users.

Ah, I see! I hadn't thought of a reply feed. Thanks Vitor.

mikedilger · 2024-05-16T19:49:20Z

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 · 2024-05-16T19:51:52Z

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 · 2024-05-16T19:56:49Z

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 · 2024-05-16T21:47:20Z

@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 · 2024-05-16T22:15:57Z

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 · 2024-05-17T04:28:31Z

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 · 2024-05-17T12:19:31Z

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 · 2024-05-17T12:36:51Z

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 · 2024-05-17T15:02:46Z

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 · 2024-05-17T15:16:35Z

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 · 2024-05-17T15:31:15Z

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

Semisol · 2024-05-17T18:55:29Z

22.md

+**It must have a `k` tag** pointing to the kind of the subject being commented on.
+Its value has a prefix: `"n:"` for nostr subjects and other prefixes (listed in a section ahead)
+for things that aren't nostr events.
+
+For example, when commenting on a `kind:30023`, the `k` tag is set to "n:30023".
+When replying to another `kind:1111`, the `k` tag is set to "n:1111".
+
+The `k` tag is useful to fetch top-level comments about events of specific types, for example,
+by filtering with `{ "#k": ["n:30023"], "kinds": [1111] }`.


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?

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.

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.

@Semisol #523, #683

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.

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 · 2024-05-18T15:04:20Z

I think this is probably a good idea.

fiatjaf · 2024-05-18T15:06:45Z

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 · 2024-05-23T20:46:14Z

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

arthurfranca mentioned this pull request May 12, 2024

Moves Kind:1 definition to NIP-10 #1076

Open

arthurfranca force-pushed the comment branch 2 times, most recently from 15fb2e6 to 6a40f31 Compare May 12, 2024 15:59

Add generic comment

75b02b3

arthurfranca force-pushed the comment branch from 6a40f31 to 75b02b3 Compare May 12, 2024 16:01

Add convention on relay selection

bccd745

arthurfranca marked this pull request as ready for review May 13, 2024 18:19

Remove kind:1 mention

1c34174

dluvian reviewed May 14, 2024

View reviewed changes

arthurfranca and others added 2 commits May 15, 2024 18:13

Add kind to i reference

61addbd

Update 22.md

a52b483

Co-authored-by: dluvian <133484344+dluvian@users.noreply.github.com>

arthurfranca force-pushed the comment branch from c5a1890 to a52b483 Compare May 15, 2024 21:23

arthurfranca mentioned this pull request May 16, 2024

NIP-35: Torrents #1175

Merged

Semisol requested changes May 16, 2024

View reviewed changes

Add K tag

a6a71cd

Add prefixes to help when parsing values

6af79cb

Add other prefixes

278601d

Semisol requested changes May 17, 2024

View reviewed changes

Make o and r tags variadic

194d1d7


		Examples:

		- `["o", "i:<event-pubkey>:<event-id>", "<relay-url, optional>"]`

NIP-22 - Generic Comment #1233

Are you sure you want to change the base?

NIP-22 - Generic Comment #1233

Conversation

arthurfranca commented May 12, 2024

vitorpamplona commented May 12, 2024 • edited

arthurfranca commented May 13, 2024

dluvian left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikedilger commented May 15, 2024

vitorpamplona commented May 15, 2024

dluvian commented May 16, 2024

staab commented May 16, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikedilger commented May 16, 2024 • edited

mikedilger commented May 16, 2024

vitorpamplona commented May 16, 2024

arthurfranca commented May 16, 2024

mikedilger commented May 16, 2024

dluvian commented May 17, 2024

vitorpamplona commented May 17, 2024 • edited

vitorpamplona commented May 17, 2024

arthurfranca commented May 17, 2024

vitorpamplona commented May 17, 2024

arthurfranca commented May 17, 2024

Choose a reason for hiding this comment

arthurfranca May 17, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fiatjaf commented May 18, 2024

fiatjaf commented May 18, 2024 • edited

vitorpamplona commented May 23, 2024

vitorpamplona commented May 12, 2024 •

edited

mikedilger commented May 16, 2024 •

edited

vitorpamplona commented May 17, 2024 •

edited

arthurfranca May 17, 2024 •

edited

fiatjaf commented May 18, 2024 •

edited