NIP-22 - Likes and Dislikes (Not replacing NIP-25 anymore)

[arthurfranca]

Read here

kind:7/17 events from NIP-25 have many problems cause the NIP was conceived when nostr was too young.

[fiatjaf]

Does anyone have any statistics about how much of Nostr storage and traffic is reactions compared to what is kind:1 content? If we're doing reactions v2 then maybe we should think about that and come up with a way for clients to display what they want to display this while not having to download a gigaton of events just to count them locally.

[barrydeen]

I have a relay that archives every kind:1 note and it grows by about 200mb a day with most of the network's notes, including all spam.

I have another relay that archives most note kinds in a subset of 50,000 npubs and filters most spam, and it grows by about 2gb per day

so at a MINIMUM it's about 10:1 storage of non-kind:1 but probably more like 15-20:1 accounting for spam

[staab]

NACK, I don't see any reason to make a backwards-incompatible change. This can be fixed by putting the content in an indexable tag, and recommending k tags if desired. See #1486

[eskema]

reactions have no problems at all, they are however been misused by clients IMO. reactions are one of the most efficient nostr events as they have minimal footprint, they are a very basic nostr event, they aren't more expensive than a kind:1 note with the same content. if nostr events are not efficient, then nostr shouldn't be used for anything... if they account for a lot, then it's because users like to use it as a feature.

[barrydeen]

relay operators will force our hand on this, we aren't gonna store all of these reaction notes forever, especially if nostr grows.

[eskema]

relay operators will force our hand on this, we aren't gonna store all of these reaction notes forever, especially if nostr grows.

i have no problems with this at all, relays choose what content goes on their hardware. reactions can be discarded on a weekly basis and nostr will be fine

[alexgleason]

Does anyone have any statistics about how much of Nostr storage and traffic is reactions compared to what is kind:1 content?

@fiatjaf On all of my relays, kind 1 is the top submitted event kind, followed by kind 3 and then kind 7.

(I think this graph is being skewed by spam a little bit right now, but this fact has always been true that kind 1s are the top event on Nostr)

EDIT: One more thing, I took a 12GB jsonl dump from my relay and filtered by kind 1 and kind 7 to get this graph of disk space usage:

[kehiy]

also, based on the provided discussion, i can't get what the actual issue with kind 7 is? is there any summary like list about these issues?

[arthurfranca]

also, based on the provided discussion, i can't get what the actual issue with kind 7 is? is there any summary like list about these issues?

• It is a regular event: ~if client or relay don't do it right, an user may "like" 100 times the same event~ Multiple reactions are lighter to store if using replaceable events;
• It started as just '+' or '-' content. But no way to filter or count by just one of them relay-side;
• When emojis were added, there was no way anymore to tell if the reaction was a positive or negative one;
• Cause of some of the above reasons that makes counting likes/dislikes separately difficult, most clients tally everything as "likes". Downside is disliked content wrongly get surfaced/recommended by positive engagement that is in fact negative.

[arthurfranca]

come up with a way for clients to display what they want to display this while not having to download a gigaton of events just to count them locally

Added info on how to count

[arthurfranca]

@staab I don't see any reason to make a backwards-incompatible change @eskema i have no problems with this at all, relays choose what content goes on their hardware. reactions can be discarded on a weekly basis and nostr will be fine

Old reactions will most likely be discarded sooner or later, probably long before the referenced events. Because of that, upgrading the spec doesn't seem disastrous. The like count of some events will be 0, so what?

I don't see any reason

reasons

[kehiy]

also, based on the provided discussion, i can't get what the actual issue with kind 7 is? is there any summary like list about these issues?

• It is a regular event: if client or relay don't do it right, an user may "like" 100 times the same event;
• It started as just '+' or '-' content. But no way to filter by just one of them relay-side;
• When emojis were added, there was no way anymore to tell if the reaction was a positive or negative one;
• Cause of some of the above reasons that makes counting likes/dislikes separately difficult, most clients tally everything as "likes". Downside is disliked content wrongly get surfaced/recommended by positive engagement that is in fact negative.

@arthurfranca relays can keep only one kind 7 from a person pointing to a specific event. we can add a tag to kind 7 to indicate whether it's positive to negative. i think with these 2 we can keep the current thing and fix the issues.

also with reaction v2 we limit the option to support stuff like telegram and discord multiple reactions. probably. kind7 is more dynamic.

[mikedilger]

efficiency: reactions are horrible. To send 1 character, the overhead of an entire event must be sent. That is less than 1% efficient. But I don't recommend any changes in this area, just an observation.

meaning: I agree with @staab and I recommend his PR which I already +1-ed. #1486. Emojis carry more meaning than "upvote/downvote" and nebulous meaning is in fact sometimes very useful. An emoji reaction is not an upvote nor a downvote, the world isn't black and white. Also, I would hate the UX of trying to make it so. Yes, it is confusing to have upvote/downvote and separately have emojis too, but it is what it is.

count: Didn't that NIP almost get pulled because nobody uses it? If popular relays are doing COUNT, I would be interested to know that.

addressable: I like that they are parameterized replaceable so that you can only have one. I presume clients are only allowing one per pubkey already, but this is better. But not enough to break compatibility.

[staab]

count: Didn't that NIP almost get pulled because nobody uses it?

I thought that was the case but merging that change ended up being pretty polarizing: https://github.com/nostr-protocol/nips/pull/842. I still think it should be killed but it is what it is.

[kehiy]

i agree with @mikedilger.

@mikedilger, about addressable part, consider that we can apply these on current kind7. that's what probably we are going to do as relay.

[mikedilger]

@mikedilger, about addressable part, consider that we can apply these on current kind7. that's what probably we are going to do as relay.

It would work. It would be an ugly special-case. I don't think we should put that in a NIP though because it cannot be required relay behavior, so clients can't depend on it even if it were suggested. But if relays want to save space, they can do it.

[AsaiToshiya]

I agree with @staab and @mikedilger. I recommend #1486 too.

• It is a regular event: if client or relay don't do it right, an user may "like" 100 times the same event;

It is just spam, and that can be said to all regular events.

[vitorpamplona]

It's not spam. Many users send multiple reactions and expect all those reactions to be visible to the receiver (I asked them directly about this). The reactions together send a message. Many social media clients allow multiple reactions and they just assume it is also true for Nostr.

[AsaiToshiya]

Yes, I understand that use case and support it. What I want to say is very many reactions from one user are spam, and the same can be said for other regular events, so that is no reason to make the reactions addressable.

[mikedilger]

It is just spam, and that can be said to all regular events.

Yes I agree it is a vector for spam. But we can't get rid of all regular events, so solving spam by making all events replaceable is a dead end. More vectors does not mean more total spam, as long as there are any vectors, the quantity of spam will be no different.

Since it breaks the existing clients, I say NACK.

[arthurfranca]

Yes multiple reactions can be useful, specially for live events or videos (reacting at specific second). Added support for it.

I propose we keep kind:7 for reactions without explicit sentiment, like #1486 wants. Then this NIP could be for clients that care for likes and/or dislikes, this way this kind of thing won't be a problem.

[pablof7z]

cNACK.

We already have a reactions NIP, we don't need six different ways of doing the same thing with slightly different methods (they won't be, they'll coalesce to have the same meaning). This is protocol bloat.

[arthurfranca]

@pablof7z thing is protocol bloat argument doesn't address these issues

[vitorpamplona]

We are coming full circle. This spec just became a poll spec with random emoji associations.

I find this proposal very confusing.

1. Why replaceables?
2. Why emojis?
3. Why custom emojis?
4. Why mixing the two.
5. Why neutral reactions if you want like/dislike?
6. You can't REQ by re. So, why not use just kind:7 where you also can't filter by .content?

[pablof7z]

@pablof7z thing is protocol bloat argument doesn't address these issues

Those are non-issues; this central-planner approach to "fix" non-issues creates actual real issues and makes extra work for the people actually building stuff on nostr.

Again. cNACK.

[kehiy]

i agree with @pablof7z here:

We already have a reactions NIP, we don't need six different ways of doing the same thing with slightly different methods (they won't be, they'll coalesce to have the same meaning). This is protocol bloat.

cnack.

[arthurfranca]

1. Why replaceables? R.: Lighter to store
2. Why emojis? R.: Why not? Emojis are great to describe a feeling succinctly
3. Why custom emojis? R.: Why not? See above
4. Why mixing the two. R.: They could be different tags.
5. Why neutral reactions if you want like/dislike? R.: If #1486 gets merged this section should point to NIP-25 . Better just remove the section, yes.
6. You can't REQ by re. So, why not use just kind:7 where you also can't filter by .content? R.: Imo it is important to be able to count how many positive and how many negative reactions there are in a cheap and fast way (on relay side with NIP-45). Counting individual emojis relay side with NIP-45 is bad cause there are so many different emojis to add to the tag filter. It would also potentially create many DB indexes for multiple reactions.

[kehiy]

@arthurfranca

1. if the issue is storage, the relay can put a limit. 1 reaction per post. 10 reactions per post. pow for more. publication fee for more. anything they want.

2. three things:

3. as discussed above, we can categorize reactions and feelings to - and +. it is something more complex.

4. "COUNT" message type is an unstable and not well-adopted thing...

5. if some services need to relay on - and + they can make a limited supported set of reactions and count based on them. there is a lots of ways to do that.

[vitorpamplona]

Why replaceables? R.: Lighter to store

Majority of the kind7s we have today are NOT spam. So, I'd like to see how much space this actually saves.

how many negative reactions there are in a cheap and fast way (on relay side with NIP-45)

That's why this became a poll spec with fixed voting options. You are trying to tally votes. And you want every user to map their emojis to a give vote. This is all too complicated.

Plus, you must also remove muted/reported authors from that count. Different users might see different counts.

[erskingardner]

Hard Nack.

[staab]

Still NACK

[arthurfranca]

Hard Nack.

lol, the mysterious nack with leading "c" was funny too.

Ok this doesn't need to be merged, this is just a draft looking for exactly this: feedback and new ideas.

...if some services need to relay on - and + they can make a limited supported set of reactions and count based on them. there is a lots of ways to do that. ...2. Why emojis?

I still don't think that NIP-25 can perform well for things like reddit upvote/downvote. Maybe the best should really be separating emoji reactions from simple -/+ instead of overloading the event.

Though it would touch a wider user base across more clients if using something like this PR was possible, I mean a spec that worked in a way that the UX for reacting positively or negatively with emojis could remain simple.