Description
(This is just a draft. CC @towerofnix @PullJosh @hedgehog1029 for opinions)
Reactions are entirely OPTIONAL for implementations - servers MUST respond with a NO
error on all endpoints if reactions are disabled or not supported.
-
New reactToMessages permission, default
true
for_users
(see Specify default permissions for '_everyone' and '_users' #3) -
GET /api/messages/:id/reactions
Responds with a list of reactions to the message under { reactions }
. If there are none, return { reactions: [] }
. If reactions are not supported or otherwise disabled, respond with a 'NO' error.
eg.
{
reactions: [
{ emote: ':nonfree:', userIDs: [ userID ] },
{ emote: '👌', userIDs: [ userID, userID ] }
]
}
- POST /api/messages/:id/reactions
emote
in body, string
requires reactToMessages
permission
Reacts to a message with emote
, which may be an existing emote :shortcode:
or a valid unicode emoji character (we need to specify the exact codepoints for this).
- DELETE /api/messages/:id/reactions/:emote
emote
in body, string - see above for restrictions
requires a session user
Retracts a previous reaction of emote
by the requesting user. Error if there is no existing reaction by the requesting user, or just return {}
anyway.
-
If an emote is deleted, servers SHOULD remove all reactions of it.
-
Two new events:
Event name | Data | Emit when |
---|---|---|
message/react | { messageID, emote, userID } |
Someone reacts to a message (POST ) |
message/unreact | " | Someone unreacts (DELETE ) |
We should wait until 1.0.0 is stable etc. before adding this to spec - I'd say 1.1.0
would be a good contender as this isn't breaking.