Reactions to events which kind is not 1

[mattn]

Damus or some of Nostr clients send kind-6 for repost kind-30023 long form content. And the clients for the content author will display a notice for this kind-6.
If the client follow the link in the notification, you will see that the ID is not kind-1, but kind-30023. And client would try to display long form content even though kind-6 does not strictly support kind-30023. (At least docs says kind-6 only suppotr kind-1)
Now, we have a behavior that depends on the client's behavior. If the client expects only kind-1 for kind-6, it have to restrict itself to kind-1 when getting events reposted by kind-6. If client accept both 1 and 30023, client have to display the content correctly.

@fiatjaf @jb55 Do you think that this is a bug of specification? Or client's behavior?

At least Nostter does not correctly display long form content when kind 6 points to an unexpected kind (30023). (This is intended, author says, and the clients which display 30023 via kind-6 have a problem)

I think we have to add small fix to doc (NIP-18) one of two fixes is applied.

(1) All of clients should not display non kind-1 event reposted via kind 6
(2) All of clients should display the events if the client support the kind.

cc @SnowCait

[jb55]

at least docs says kind-6 only suppotr kind-1.

I don't think this is a strongly held position in the spec. Its likely clients are going to use reactions for all types of notes, its up to your client if you want to display them for everything. You can in theory react to a reaction, etc. There will be clients that display this recursively and it will be hilarious.

[mattn]

@jb55 So do you mean NIP-18 should add comments about other kinds?

https://github.com/nostr-protocol/nips/blob/master/18.md

Since kind 6 reposts are reserved for kind 1 contents, we use kind 16 as a "generic repost", that can include any kind of event inside other than kind 1.
kind 16 reposts SHOULD contain a k tag with the stringified kind number of the reposted event as its value.

[jb55]

On Mon, Jul 08, 2024 at 08:08:18AM GMT, mattn wrote: @jb55 So do you mean NIP-18 should add comments about other kinds?

yes probably

[mikedilger]

Kind 6 should only repost kind 1. If a client wants to repost any other kind (such as 30023) it should be kind 16 with a k-tag that says 30023. Then if you can't display 30023, your client can avoid fetching those by fetching kind 16 events with only specified k tags that it does support.

At least that is what NIP-18 explains pretty clearly at the bottom.

My client could be doing it wrong because I don't recall it being like this way back when this part of gossip was coded. I'll take a look. nah gossip had it right.

[mikedilger]

But in general developers are free to do whatever they want in their client when they encounter an undefined situation. So if a client sees a kind-6 wrapping a kind-30023, they can ignore it, or they can display it, it is up to the client developer.

However, it does create a kind of perverse incentive for clients to display it so as to please their users, which just supports the bad behavior and makes correct clients look broken. But there ain't nothing we can do about that.

[mattn]

@mikedilger We can add coments in NIP-18 that we should not wrap anything other than kind-1 in kind-6. As long as we don't do that, clients that behave correctly will be judged buggy, and clients that kindly display 30023 while performing a specification inconsistency will be evaluated by users as if they are behaving correctly. I do not believe this is a good spec.

[mikedilger]

Those comments are already in there multiple times:

A repost is a kind 6 event that is used to signal to followers that a kind 1 text note is worth reading.

That already means it wraps a kind 1 only, but then we have this

Since kind 6 reposts are reserved for kind 1 contents, we use kind 16 as a "generic repost", that can include any kind of event inside other than kind 1.

The spec is fine. Clients that wrap things other than kind-1 inside of kind-6 are already not compliant.

But if you want to add even more wording I'm not going to stand in the way.

[mattn]

Yes, I want to add "MUST NOT" in the spec.