Skip to content

Message reactions #4

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions