Change wording to imply that reactions can target any event

[nikolat]

• Define "generic reactions" (kind 17) in the same way as "generic reposts" (kind 16)
  • Kind 16 generic reposts #610
• Any clients reacting only to kind 1 events will not need additional support, and clients reacting to events other than kind 1 events will be able to handle the kind they want.

I am developing a client for Public Chat (NIP-28) that can react to kind 42 events.
However, it is causing troubles for other clients that only handle kind 1 events.
In addition, I only want to handle reactions to kind 42 events.
So I want to use generic reactions containing the k tag.

[fiatjaf]

Why is it causing trouble to clients that only handle kind 1?
I see that reposts would cause such trouble, but reactions shouldn't as you only load them after loading the target event.

[nikolat]

Rabbit assumes only kind 1 and does not correctly display reactions of kind 42.

[jb55]

This makes no sense. reactions can work on any note, not just kind 1

[nikolat]

How about adding the k tag to kind 7 events?
It is useful to filter reactions to events of a particular kind.

[AsaiToshiya]

This makes no sense. reactions can work on any note, not just kind 1

nips/25.md

Line 10 in 21c6c12

A reaction is a `kind 7` note that is used to react to other notes.

I think that "note" is not clear. Should be use "event" instead.

[jb55]

On Tue, Oct 10, 2023 at 11:27:19PM -0700, Asai Toshiya wrote: > This makes no sense. reactions can work on any note, not just kind 1 https://github.com/nostr-protocol/nips/blob/21c6c12c524cb71f18e068c9bcf223cda0214b5f/25.md?plain=1#L10 I think that "note" is not clear. Should be use "event" instead.

These terms are interchangeable, although these days I prefer notes to mean the actual json, and events to be things like ["EVENT", note]

[fiatjaf]

Rabbit assumes only kind 1 and does not correctly display reactions of kind 42.

I think it's better to fix Rabbit in this case.
Is Rabbit loading reactions without context and then looking for the context?

[nikolat]

Rabbit assumes only kind 1 and does not correctly display reactions of kind 42.

I think it's better to fix Rabbit in this case. Is Rabbit loading reactions without context and then looking for the context?

Rabbit shows who the reaction is from but not the target kind 42 event content.
The author of Rabbit was concerned that NIP-25 says notes instead of events.

[fiatjaf]

Makes sense. Let's edit the text to say events.

[nikolat]

May I use the k tag in kind 7 events?

[fiatjaf]

You are free to use the k tag, but I don't like the idea. I think it creates unnecessary burden for relays and I don't see a strong use case for it.

[nikolat]

I have to look for a few reactions to kind 42 events among the many reactions to kind 1 events.
I creates unnecessary burden for relays.
But you are right, this is very useless for many clients handle kind 1 events.

[vitorpamplona]

ACK for the optional use of the k tag.

NACK for creating another reaction event.

[staab]

NACK all, k tag will not get sufficient adoption to make it useful, so you'll only ever get a subset of events anyhow.

[syusui-s]

Thank you for creating this PR. I'm okay if it is optional.

There are possible several use-cases (but I'm not going to implement as for now, and I'm not confident with this is useful):

• For chat clients (and, other kind-specialized clients like 30023)
  • Users want to see reactions only for chat, excluding other kinds.
  • It's possible to do filtering on client but it not efficient.
  • { "kinds": [7], "#k": [42], "#p": "<my hex public key>" }
• Finding popular channels
  • Client and special server-side app for chat can find popular channels by filtering events.
  • { "kinds": [7], "#k": [42], "since": "<previous execution>", "until": "<now>" }
• Ignoring unrelated reactions
  • kind:1 client might want to ignore reactions for other kinds.