Skip to content

Message reactions #4

Open
Open
@bates64

Description

@bates64

(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.

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions