Remove recommendation to map emoji reactions to like/dislike#1486
Remove recommendation to map emoji reactions to like/dislike#1486alexgleason merged 5 commits intonostr-protocol:masterfrom
Conversation
vitorpamplona
left a comment
There was a problem hiding this comment.
The content warning emoji is not an application state and will stay.
|
I have used negative-sentiment emojis in jest multiple times. I would hate for them to be interpreted as downvotes. +1 |
25.md
Outdated
|
|
||
| The reaction event MAY include a `k` tag with the stringified kind number of the reacted event as its value. | ||
| The reaction event SHOULD include a `k` tag with the stringified kind number of the reacted event as | ||
| its value, and a `c` tag with the reaction's `content` so that reactions can be indexed and filtered. |
There was a problem hiding this comment.
I think having c as a sentiment category with values [+, -, 0] for positive, negative and neutral is more useful than simply copying the content.
There was a problem hiding this comment.
Where does this mapping come from? If from the client, it doesn't solve anything about assuming user intention. If from the user, then it adds UX friction. If your users want to explain their emojis, that's fine, I just don't think that would be widely adopted.
41078bb to
cc3449c
Compare
|
I went ahead and removed the |
See the discussion here
Emojis are a high-fidelity medium of expression subject to a significant amount of interpretation, while +/- reactions are a low-fidelity medium of expression subject to much less interpretation. The two are semantically incompatible ways of reacting to content, and should not be conflated.
Previously, the NIP included a recommendation to interpret emojis as likes/dislikes, but this put a burden on receiving clients to map every possible emoji to a binary sentiment. This is not only a huge mapping, it's also impossible because the same emoji reaction can be used in different contexts to mean different things.
Additionally, some clients created emoji reactions on their users' behalf to indicate certain application states, such as a failed zap or a content warning. These concepts should instead be represented as first-class things within the protocol.
This PR also adds a recommendation to add a
ctag so that reaction content can be indexed. This will allow clients that only support like/dislike or a subset of emojis to fetch only relevant events.