Remove recommendation to map emoji reactions to like/dislike #1486
+10
−13
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Sep 10, 2024
|
I have used negative-sentiment emojis in jest multiple times. I would hate for them to be interpreted as downvotes. +1 |
dluvian
reviewed
Sep 19, 2024
| @@ -33,7 +28,8 @@ The last `p` tag MUST be the `pubkey` of the event being reacted to. | |||
|
|
|||
| The `a` tag MUST contain the coordinates (`kind:pubkey:d-tag`) of the replaceable being reacted to. | |||
|
|
|||
| 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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.