-
Notifications
You must be signed in to change notification settings - Fork 0
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
truefor_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.