FEP-c0e0: Emoji reactions

Standards Fediverse Enhancement Proposals
1

FEP describing ActivityPub emoji reactions.

1 Like
2

I’m not sure this really provides anything worthwhile over the existing mechanisms… points below

  • why the new IRI? if not using a Like activity then it seems fine to continue using the litepub IRI instead.
  • how are EmojiReact activities meant to be tracked? there isn’t a special collection for them, as with likes collection on objects. this seems like something worth pursuing.
  • if it’s similar to a Like and has standard properties of a Like, then why is it not a Like?

and more generally:

  • what are the semantics of an EmojiReact exactly? would it be perhaps more sensible to think about a generic React activity and a reactions collection? or is a “reaction” really a type of response and therefore would fit better using replies and inReplyTo? there’s a lot of things that are kind of open to further examination and interpretation, and this FEP right now feels like it’s mostly just trying to synthesize what gets done currently by some implementers, whereas i think it would instead benefit from further development of the ideas.
1 Like
5

(Sorry for the misposts. I’m surprised that SocialHub/Discourse’s “anonymous mode” feature lets you post replies as the “anonymous” user…)

Fedibird has fedibird:emojiReactions collections (https://fedibird.com/@noellabo/108784399220088240; well, you were mentioned in this post too), but they seem to be implemented as collections of Like activities that have content, instead of EmojiReact activities (which Fedibird supports as well).

Perhaps, one could argue that the semantics of the standard Like activity shouldn’t be restricted to “reactions”, though I think the existing practice of using it as “reactions” is just fine.

1 Like
6

The intention was to document existing practices. This FEP is based on my experience of analyzing Pleroma and Misskey implementations and supporting emoji reactions in my project.

http://litepub.social/ns returns 404 Not Found. Is that not a problem for JSON-LD consumers? If it’s not, I can change the recommended type to http://litepub.social/ns#EmojiReact.

This is a good idea.

I prefer EmojiReact over Like / Dislike because emoji reaction can be negative or neutral. When Like is used, negative reactions are interpreted by non-supporting services as “likes” / “favorites”.

Yes, React would be even better, but it will be not compatible with existing implementations. I think this FEP can recommend reactions collection though.

AFAIK Hubzilla and Streams use replies instead of EmojiReact. This approach has the benefit of being backward compatible with many other services, and combined with reply controls it enables moderation of reactions (@tesaguri talked about this problem in fediverse-ideas: #52 - Publicly-accessible custom emoji collections - fediverse/fediverse-ideas - Codeberg.org).

I’ll have a look at their implementation and describe it in the FEP.

7

the thing that i’m mostly unsure about is what the semantic differences are. a “reaction” and a “response” are very close to each other, and a Like can be considered to be a sort of positive reaction:

Indicates that the actor likes, recommends or endorses the object.

taking a different but related path: consider how we would federate a Dislike activity and potentially store such activities in a dislikes collection. that seems to be semantically justifiable. but once you start to add content to the activity, you start having to consider whether the best fit is a Like/Dislike/Create.object.inReplyTo (or a new dedicated React/EmojiReact type)

i understand that the UX end goal is to enable the “emoji reactions” feature as used in software like Misskey or Discord, but it’s also important to consider the semantics here at a protocol level so as to avoid unnecessary duplication or ambiguity. looking at what the indieweb does, for example:

  • reactions - IndieWeb
    • reactions refer to the subset of responses/interactions with a post that are quicker, more impulsive, but still a conscious act, typically a simple UI gesture without writing any content
  • responses - IndieWeb (redirects from “interactions” to “responses”)
    • responses or interactions in the context of the indieweb, refer to all the different ways and things people explicitly do to and with others’s posts, from written replies to quick likes, in other words responses = replies + reactions.

so basically there’s a divide between contentful and contentless interactions, and “emoji reactions” kind of ride the line between the two (since they do contain content, but a very small amount of it)

reacji - IndieWeb says this:

Markup a reacji response post as follows: Post a reply where the content is a single emoji character. Thus u-in-reply-to is required. Note: if there is HTML in the content property, it may mess with emoji detection, so you should use p-content, rather than e-content for reacji reply posts.

so that looks like another precedent for using the replies collection and generally following what Hubzilla/Streams does here. but there is definitely still some consideration for having the “positive reaction” type of reacji be expressed as Like with content. of course, there’s also no real reason to “limit” this to just emoji – one can imagine a Like with content that provides further details on why you like the thing.

after considering all this, i think that having a neutral React with a corresponding special collection for reactions might actually end up making sense and having justification. so as usual there’s like three different ways of doing it…

in summary:

  • we could have likes / dislikes / reactions as three separate collections for positive / negative / neutral reactions.
  • reactions can have optional content, not necessarily just an emoji
  • emoji reactions specifically can also just be a reply-post with a single emoji in content; this should probably be mentioned as an option
8

I found an emoji reaction generated by Hubzilla, it’s a Note with inReplyTo, content and tag. It doesn’t have additional properties that can be used to tell a reaction from a regular reply (maybe there is another way? cc @Mario).

9

I really like the idea of supporting emoji reactions, I’m glad this is brought up.

I definitely don’t think emoji reactions are the same as Like/Dislike. It should be a separate thing. You could definitely imagine a user wanting to both Like (or Dislike) something and react with an emoji in addition, which would be weird if you were to treat emoji reactions as likes (would you send two Likes, one for the “like” and one for the “reaction”? What if you dislike and react, would that be a “Like reaction” and a “Dislike”? That seems super weird).

I would caution against trying to treat “Reactions” the same as “Replies”. My feeling is that these are semantically distinct. A reply is a piece of content of its own. A reply can be replied to and reacted to in itself; one should indeed be able to put an emoji reaction on a reply to another post. That makes sense in my mind. But it definitely feels weird to be able to react to someone else’s reaction. That would be like if you could Like someone’s Like (is that a thing? I feel like it shouldn’t be).

I feel that reactions are more passive than a reply in itself and doesn’t constitute a piece of content on its own, therefore it shouldn’t be considered a reply. I feel like all the stuff in the replies collection should be replies and should be something that you could reply or react to again (and someone could reply or react to a reply to a reply, but nobody could react or reply to your reaction).

Honestly if I were to do it over again, I would have started with emoji reactions and not have Like and Dislike at all. Like and Dislike could have been modelled via :+1: and :-1:.

2 Likes
10

The draft has been updated: https://codeberg.org/fediverse/fep/pulls/381/files

  • Added “History” section mentioning Misskey and Pleroma.
  • Changed recommended type to http://litepub.social/ns#EmojiReact.
  • Like with content is also allowed.

I agree, this shouldn’t be possible. I think it would be better to focus on activity-based reactions in this FEP.

11

I don’t like this part:

Emoji reaction can also be represented as a Like activity. This variant of emoji reaction will processed by non-supporting implementations as a regular “like”, and when that is preferable, implementers MAY use Like type instead of EmojiReact type.

This would mean that non-supporting implementations would interpret a Like with a content of :-1:, :rage: or :sob: (or other “negative” emojis) as a “like” or “upvote” or something along those lines, when in fact the semantic meaning is basically the opposite.

I feel like not processing such a “Like” is much better than processing it as a Like. If I react with :-1: to something, I’d much rather it be interpreted as “nothing” than as a “like” or “upvote”.

12

I agree, but there might be cases where such behavior is desirable, so I added this text. The main recommendation of this FEP is still EmojiReact, which is ignored by non-supporting implementations.

13

In what cases though? You’d need some way to decide when an emoji indicates a “like” and then use “Like” when that is the case and “EmojiReact” when not. But deciding on such a list is non-trivial (is :sunflower: a “Like”, for instance?), would need constant updating as Unicode adds more emojis and different implementations may not agree on what emojis are positive or negative (custom emojis also makes this complex).

I feel like this only makes the proposal more complicated for basically no gain.

Besides, if an implementation feels that a certain emoji reaction constitutes a “Like”, they can just send a separate “Like” activity in addition to the EmojiReact.

14

Implementers are not required to generate Like activity, they can use it whenever they want or not use it at all (RFC-2119 MAY).
The strong requirement (MUST) only applies to processing of incoming activities. Misskey already uses Like for reactions, maybe some other services too.

15

It makes sense to send a Dislike that has content where the content is a single emoji. Whether you send a Like, Dislike, or React depends on the disposition of your reaction – positive, negative, or neutral.

You can do this.

16

But that is already allowed - implementers can already choose to send both a Like activity and an EmojiReact activity for the reaction. Example: A user clicks “React” and chooses :+1:. The underlying server implementation will send an EmojiReact with :+1: and it also additionally sends a separate Like activity. This is always allowed - there is no need to muddle the waters between EmojiReact and Like by merging them into one activity. Thus this addition to the proposal adds nothing but complexity.

I don’t think the current practice of some implementations should necessarily dictate how you should do things in general. Current practice may not be the best way to model things. If EmojiReact had been a separate thing from Like at the time that Misskey implemented their emoji reactions, maybe they would have used EmojiReact and not Like. They can change it if this proposal gets adopted.

This comes back to what I said before - you’d need implementations to somehow decide whether an emoji is positive, neutral or negative and they might disagree and this list of positive/negative/neutral emojis will get out of date and all those problems.

Think about this practically. A user reacts to a post by clicking a reaction button and choosing an emoji. If we muddle the waters between likes, dislikes and emoji reactions, it is then up to the underlying server to decide whether to use a “Like”, “Dislike” or “EmojiReact”. This is not a trivial judgement to make! First of all it’s hard to decide that for a single emoji, but more importantly, the judgement can also be wrong or ambiguous based on context - for instance, :crazy_face: could mean that I found something funny (positive) or maybe I find it crazy or ludicrous (negative). In these standards, I don’t think we should recommend, endorse or even support implementations trying to interpret this human context at all. Interpreting that context seems impossible.

You cannot deduce what the user meant. All the server can hope to do is transmit the emoji reaction on its own, without trying to add additional meaning to it as a “positive” or “negative” reaction. Implementations should not skew or alter what users mean when sending activities. This feels akin to an implementation inserting “/s” at the end of the content when it (perhaps wrongly) detects a sarcastic comment. In theory you could do that but I don’t think any standard should recommend, encourage or even mention such a practice.

That is unfortunate. In any case, I feel it should be a separate thing. Replies, reactions, likes and dislikes are all semantically separate things and we shouldn’t muddle them or encourage software to try to tell the difference. You also said previously

emoji reactions specifically can also just be a reply-post with a single emoji in content

I think this also muddles reactions and replies. Replying with a comment or chat message containing :+1: is not the same as reacting to a post or another chat message with :+1:. It is similar perhaps, but the semantics are not quite the same and users would be surprised to find them being treated equivalently. Besides the semantic difference, there may for instance also be permission differences (you may be allowed to react to a post but not reply to it, or you may be allowed to react in a chat room but not chat in it). Besides, if this proposal would consider them separate as I would recommend, implementations can still choose to interpret them as the same. That is up to each implementation, though I wouldn’t personally do it.

In general, I would encourage keeping things as separate as possible. Principles such as KISS and single responsibility applies.

17

I hadn’t got time to go through all comments, so sorry for possible duplicates. As far as I understood, this “Emoji Reactions” is reaction via some picture instead by Unicode characters like the existing implementations. This has got the disadvantage for missing accessibility for people using screenreaders.

Also I think that these reactions should be treated the same as “like”, “dislike” and the existing implementations and not as comments, since displaying them as comments would lead to a situation where you could miss a comment between tons of comments only displaying these pictures. But displaying them alongside the other activities could be an optical challenge due the display size. By now we display these reactions that way:
grafik
Most of the emoji images would simply look ugly, when resized so small.

1 Like
18

The proposal supports both unicode emojis and custom emojis.

Please see my comment above on treating reactions the same as likes/dislikes. Though the picture you showed suggests that they are treated as a separate thing from likes, dislikes and comments, which is exactly what I propose (perhaps you don’t meant they should be treated “the same” as like and dislike, but “treated the same” as in considered its own thing, just as Like and Dislike, just as I said above? Sorry, your wording is a bit ambiguous).

Though I agree with the second part of your sentence, they should definitely not be the same as comments.

19

Why? The implementation doesn’t decide this – the user decides this. It’s OK if a user sends a React with :+1: or Like with :poop: as long as they intended to do that. If you wanted to simplify this in UI, then you would first ask the user if they want to send a Like, Dislike, or React, and then they get the option to add some (optional) content, which may be a single emoji. Or it might be something else. For example, the following is valid:

actor: <a>
type: Like
object: <o>
to: <o.attributedTo>
content: "Thank you for posting this!"

This obviously doesn’t map onto the high-level feature of an “emoji react”, but it is something that could be done nonetheless. It’s important to not confuse the point, which is that this content might be a single emoji instead:

actor: <a>
type: Like
object: <o>
to: <o.attributedTo>
content: "🎉"

And of course, it could be authored as a Note.inReplyTo instead:

actor: <a>
type: Create
object:
  type: Note
  content: "🎉"
  inReplyTo: <o>
to: <o.attributedTo>

Now, the challenge is trying to force any/all possible representations onto a singular “emoji react” feature. The consumer gets to interpret these activities in the manner that they decide. So your software could detect when a Like contains a single emoji, and not only will it increment the like counter (adding the Like to the <o.likes> collection), but it can also show that emoji underneath the object. Or it could show it in-thread as a post, but have the emoji be larger than the normal text size (as is done in some chat apps or IRC clients).

Really, the challenge is almost entirely for a consumer wishing to display “emoji reactions”. Consumers must pull this information from subsets of different collections – for example, by filtering the replies and likes collections for any item whose content is a single emoji. Producers don’t really have a way of optimizing for this use-case, unless they want to publish a separate purpose-fit collection like emojiReactions, and selectively Add pre-filtered activities or objects to this collection. What the producer and consumer ideally ought to agree upon is not which emoji have which disposition, but rather which activities (or objects) qualify for inclusion.

Would you not say that there is overlap? A reaction is a reply with minimal or no content. Likes and dislikes are types of reactions. They’re not as separable as you’d like. Software shouldn’t be telling the difference so much as users should be telling the software what the difference is.

Users would be surprised by a lot of things, to be fair. It might seem like these are not the same thing to some random observer, but it might seem like they are the same thing to some other random observer. Semantically, one is generic (Create) and the other is specific (Like). Side-effect wise at the protocol level, do you necessarily want everyone to share the same concept of “emoji reactions”? Maybe, maybe not. Right now, the side effects would differ only in whether the resulting activity triggers an Add to the replies or an Add to the likes. The former is not really specified, and the latter is specified as automatically happening in ActivityPub.

So, again: “what is the behavior we’re trying to describe at the protocol level, and how does it map to the user experience?” – is an inverse question of “what is the user experience we want to enable, and how can we make the protocol fit this?” – and I’m not personally convinced (yet?) that an “emoji reaction” is something that should be reified at the protocol level as this separate unique thing. I remain similarly unconvinced about “quote posts”, which likewise have semantic confusion when trying to encode them at a protocol level (as opposed to replicating a certain UX feature). This is why I am raising and exploring the possibilities of e.g. a neutral React vs. a dedicated EmojiReact, or whether we can express the same thing via likes or replies, and so on. If we decide that they should be reified, then we also have the option of multi-typing and/or using polymorphism, for example:

type: [Like, EmojiReact]
object: <o>
content: "🎉"

or

type: Create
object:
  type: [Note, EmojiReact]
  content: "🎉"
  inReplyTo: <o>  # this could get weird bc EmojiReact feels more like an activity and would need `actor` and `object`

But first, we need to clearly define the semantics of an EmojiReact. Something that could help here is to think deeply about why a Like activity even exists at all, instead of some other similar thing like replying with :+1:. The answer probably lies in wanting to track it separately via the likes collection, and in wanting some level of automation or discrimination around this. So if we apply similar logic to “emoji reactions”, then we could arrive at the following synthesis:

  • an EmojiReact activity
  • an emojiReactions collection
  • upon receiving an EmojiReact activity, you SHOULD Add it to the emojiReactions collection

which starts to look pretty close to a mish-mash of what Fedibird/Litepub defined… though this still depends on having a consistent semantic definition of what exactly an EmojiReact is, and what its purpose is (i.e. having the side effects of being Added to the emojiReactions collection)

20

Misskey and Pleroma implemented emoji reactions roughly at the same time. I think the use of Like is deliberate: Implement Pleroma-style EmojiReactions instead of overloading Likes · Issue #5425 · misskey-dev/misskey · GitHub

This is really up to developer. Either your reaction is ignored (EmojiReact) or it is processed as “like”. Check this thread where @tesaguri argued in favor of Like : tesaguri 🦀🦝: "FEP-c0e0: Emoji reactions - ActivityPub - SocialH…" - Fedibird

21

I have never ever seen an emoji reaction feature on any social media platform that, subsequent to reacting with an emoji, asks you to choose whether that emoji reaction was positive, negative or neutral. That sounds extremely cumbersome for something fast and quick like an emoji reaction. It’s also just confusing - the user meant to react with that emoji, why are they asked to specify whether it’s positive, neutral or negative?

Part of my point here is that interpreting these activities and deciding how to handle them becomes a lot easier and simpler if we do not muddle the different activities together. If Likes and Dislikes are separate from EmojiReacts, then it becomes a lot simpler for an implementation to decide how to interpret each kind of activity. Rather than having to handle all manner of edge cases of what a Like can contain, EmojiReact being a separate thing enables a more explicit use of the feature. It’s kind of akin to dynamic vs static typing.

This is exactly why I think it should be a separate thing from replies, likes and dislikes. It makes all this filtering unnecessary and reduces the complexity of handling emoji reactions a lot.

I agree that Likes and Dislikes are a type of reaction - as I mentioned above, were I to do it over, I would have modelled Likes and Dislikes as an emoji reaction of :+1: and :-1:, although you could maybe argue that likes and dislikes are so ubiquitous in social media that they warrant their own activity type. Either way is fine I think.

But a reply and reaction are not the same I would say. A reply is a piece of content on its own. A reply is an invitation for a conversation with another reply. It is an active thing. The IRL equivalent would be talking or replying to someone with speech.

I see emoji reactions as an attempt to be the equivalent of IRL body language and facial expressions and other kinds of “passive communication” or whatever you want to call that. These things are obviously all under the category of human communication, but I think they are distinct enough to warrant their own activity type.

I don’t think we should dismiss that - users and their expectations and desires should be at the heart of how we design the social internet.

This is a good reason to make them semantically distinct. If we make them the same, the ones that think they are not the same will have a hard time telling them apart. The ones that think they are the same can easily consider two separate activities to be the same type. The opposite is much harder.

I think the latter question is the much more suitable approach here. To me, the user experience we want to enable in this case is the common emoji reactions you see on most common social media platforms these days. Mostly these are treated separately from likes/dislikes (or there is no like or dislike at all) or at least separate from replies. I have never seen a social media platform that treats a comment of :+1: the same as a :+1: reaction.

I think it should. Many, many social media platforms have emoji reactions. I think emojis compensate for a lot of the ways we cannot communicate in text.

I totally agree, and therefore it is much simpler for the developer to decide how to handle it if they are separate things.

As for that mastodon thread you linked, I don’t like this reasoning:

[regarding the problem of negative reactions being interpreted as likes] I think the use of reactions for such a negative purpose should be discouraged in the first place.

I feel that this is a value judgement that a neutral and universal protocol like ActivityPub should not make. I already find it annoying that there is a “likes” collection but no “dislikes” collection - why is that? The protocol should not be making these judgements about whether it is good or encouraged to like or dislike things. That is up to the users and the individual implementation.

22

We are currently treating emoji reaction in a similar way than likes and dislikes. I hoped that my screenshot clarifies this.
For optical purposes and especially for accessibility reasons I guess that I would solely implement the processing of Unicode based reaction, but would drop all incoming picture reactions.