New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for "Reactions" #80

horazont opened this Issue Mar 12, 2018 · 5 comments


None yet
4 participants

horazont commented Mar 12, 2018

What are reactions?

Like on different social networking platforms. Reactions are short replies to messages which can neatly be attached to them. Usually in the form of emoji. Similar reactions are aggregated in the view. Example:

11:03:23 <jonasw> I want to implement reactions in JabberCat.
   3 👍    2 👏    1 😮    [React]


  • Allow any emoji as reaction, plus some assorted things like "+1", "-1" (or maybe we can get away with thumbs-up and thumbs-down?)
  • Allow reaction to any message with ID (and not sent by ourselves)
  • Use References or Message Attachments (we’ll have to see which one works best)
  • Aggregate reactions using the same emoji
  • Put reaction in non-body child of <message/> for easy handling.

Open questions

  • Compatibility with other clients. Would most likely be confusing to users on clients not supporting the protocol, especially when reacting to old messages. Maybe default to (in the <body/> of the reaction):

    sender-name [timestamp]
    "> " first-line-of-reacted-to-message

    (Thanks, @ge0rg. This brings us XEP-0393 compat and hugification.)

    That would give other users context. sender-nickname would be elided in one-on-one conversations.

    (This is also what some people are already doing.)

    This may look rather confusing on clients which support Message Attaching, but I guess those are rare anyways.

  • Filtering of inbound reactions. Do we want to restrict/normalize the reactions used?

  • How to handle corrections to reacted-to messages? -> Corrections have different IDs compared to the original message, so the reactions attach to the individual versions.

  • Fitzpatrick modifiers; Aggregate or show separately? If aggregate, show unmodified version or most-voted-for version? (I tend to unmodified since the "unrealistic skin tone" is probably least controversial)

  • Allow multiple reactions with the different (or same) emoji from the same source?

  • Attribution in anonymous MUCs. The most sane way is probably to fade out reactions by anonymous users which left.

  • Which exact wire-format to use.

    • References: refers to the body and may apply to only a subset of the referencing message. This is not so great: it creates ambiguity because the whole message is in fact a reaction.
    • Message Attaching: Dead-simple, does exactly what we need.

    In both cases we’ll want a custom element: <reaction xmlns="…">reaction-emoji</reaction>.

  • Retract a reaction. Possibly easiest way is to emit a Correction which completely blanks the message.

@horazont horazont added this to the v0.2.0 milestone Mar 12, 2018


This comment has been minimized.

ge0rg commented Mar 12, 2018

Suggestion for legacy-quoting:

nickname [timestamp]:
> (first line of) message

This is the quote format used by yaxim, and it has some useful properties:

  • starts with the nickname
  • uses XEP-0393 quotations
  • emoji is alone on the line and can be hugified by yaxim and Conversations

This comment has been minimized.

SeveFP commented Mar 12, 2018

Allow reaction to any message with ID (and not sent by ourselves)

Regarding this one, I know to some people it may sound weird to be able to react to something you said.
But I just wanted to note that Slack (the messaging application/service) allows the sender of the message to add reactions to it. And I've seen people adding reactions to their messages once in a while.
I'm not saying JabberCat should follow this behaviour, but I would consider allowing senders to react to their messages.

Edit: Even on GitHub I can 😸


This comment has been minimized.


horazont commented Mar 12, 2018

@SeveFP Thanks for that; I’m not strong on that restriction, so let’s just remove it if other platforms handle that similarly.


This comment has been minimized.


Zash commented Mar 12, 2018

You could potentially use the User Mood (XEP-0107) format.


This comment has been minimized.


horazont commented Mar 12, 2018

@Zash There won’t be a 1:1 or even 1:n mapping for user-mood -> emoji. Defining the mapping and keeping it up-to-date with new Unicode releases seems like a tedious task with little gain.

Do you think there would be gain in defining this to use XEP-0107, defaulting to <undefined/> and say that clients MAY use more specific classifiers than undefined? What would the advantage be? What to do if someone uses a smiling emoji with serious mood (from the XEP: "serious -- Without humor or expression of happiness; grave in manner or disposition; earnest; thoughtful; solemn.")?

I only see this adding ambiguity. Also when it comes to aggregating equal reactions.

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