FIP: Emoji reactions

[davidfurlong]

Would love to be able to respond to casts with any emoji.
Emojis can be used as primitives for voting as well as reacting to content

The alternative is to respond with a cast with the emoji, which makes it easy for any client to render but that might have other downsides around counting to cast storage limits or using up more storage in the protocol

[danromero]

I'm generally in favor of increasing expressiveness of reactions, but will leave a few open ended questions:

1. What happens when people use emojis that have negative connotations as an abuse vector? Or someone gets mobbed by a bunch of trolls?

2. Is the expectation clients render all of the reactions, a la Slack (which could get very noisy), or can they aggregate? In the case of aggregation, what's the default visible? Do variations of a base emoji aggregate?
   

3. Does the author of a cast have the ability to limit the response set, e.g. I specify 👍 or 👎 as the only allowed reactions?

4. Do you allow for custom emojis a la Slack as part of this? e.g. a Farcaster arch

Note: this likely confusing today, so to be clear: with Warpcast today, our gm, ga, gn and Nouns noggles are just cosmetic easter eggs on the overall like reaction and don't propagate across clients

[davidfurlong]

These are great questions that hopefully the community can help figure out.
I'll do my best to give my perspective here

1. I think this attack vector already exists in a slightly less accessible form via replies. I expect clients will have troll defense mechanisms such as moderating which emojis they show reactions of by default and which notifications to trigger
2. Good question - I suspect there will be much fewer long tail reactions relative to the most common reactions since those are the least work for people to click. I suspect clients will have different strategies here, but most will limit the number of shown emoji reactions
3. Interesting idea, not sure. For bots or polling or event rsvps I think clients should detect types of casts and adjust interfaces accordingly
4. Could be interesting - is your idea custom emojis from a set a list set by the protocol, or allowing any user to use any tiny image as a reaction?

[iwyatt]

I'm generally in favor of increasing expressiveness of reactions, but will leave a few open ended questions:

1. What happens when people use emojis that have negative connotations as an abuse vector? Or someone gets mobbed by a bunch of trolls?
2. Is the expectation clients render all of the reactions, a la Slack (which could get very noisy), or can they aggregate? In the case of aggregation, what's the default visible? Do variations of a base emoji aggregate?
   
3. Does the author of a cast have the ability to limit the response set, e.g. I specify 👍 or 👎 as the only allowed reactions?
4. Do you allow for custom emojis a la Slack as part of this? e.g. a Farcaster arch

Note: this likely confusing today, so to be clear: with Warpcast today, our gm, ga, gn and Nouns noggles are just cosmetic easter eggs on the overall like reaction and don't propagate across clients

I really like this feature idea and think this is a good differentiator for the product.

My own answers to your questions:

1. enable emoji reactions only for mutual follows, non-mutuals can only respond with the standard 'like' or 'comment'
2. Yes, all clients should be able to, or at least at a minimum, indicate that a post has content that may not be rendered. Clients that DO display the emojis should display the top (x) reactions, where (x) is left up to the client to decide (probably based on available screen real estate).
3. no (unless there is a future feature request to do so for some reason)
4. no (unless there is a future feature request to do so for some reason)

[TimDaub]

I think all of those concerns are only addressable on the app level and not protocol, right?

[varunsrin]

In factor extending the reaction type to be more flexible, but as dan pointed out there is probably a significant amount of work to think through. Most notably:

1. How many degrees of freedom are allowed? (e.g. if you say one emoji, how is that enforced? emoji are very complex and can be combined together to create more emoji. more details here.)

2. How do we expect clients to support this in user interfaces? Is everyone onboard with this direction?

3. What are the implications to storage?

4. How do we implement this in a backwards compatible way with existing reactions?

@davidfurlong if you're thinking about making a draft and implementing, we'd be happy to support with feedback and reviews. if not, i don't think we have resources to pick this up right now, given the other 3 FIP's and mainnet launch.

[codewithmilo]

I was at Slack when we launched reactions, and in my time there did a bit of work on them and emojis in general!

Short story: managing emojis has so many edges; more than I think is worth the protocol itself investing in. But, I think we could push clients to use certain conventions that might give us 90% of what we want.

(Will use past tense because this could've changed from 2021 when I left)
The way we did rxns was by having a row per user+emoji+msg combo, so to @varunsrin point it was a lot more data. If we're discussing elsewhere about capping hub messages from follows or casts, these will absolutely blow the lid off.

But the tricky bits come with how clients handle the emojis themselves: different OSes have different emojis, and so clients need to have up-to-date libraries of them per OS and be able to handle any diffs in how they're rendered cross-platform.

For custom emojis, this gets even trickier, since someone needs to store all those images, and if it isn't the protocol then clients all need to agree to a shared resource for it so they can be rendered on all of them. If users are allowed to upload, that needs to be moderated, and everyone has to agree how to handle custom emojis that are deleted, or how to handle naming them.

All in all, I think the clients should implement something to handle it and the protocol should not, because no matter what it's a ton of work for clients and that coordination will be pretty difficult. E.g. when new emoji sets are released, the protocol needs to update to include new emojis and clients need to update to render them, and that has to be timed avoid question boxes all over. (Sometimes it took like a year or more to upgrade slack emojis sets, to get the timing right for all the teams to do this dance at once)

But I love reactions and I think they should exist. So! A possible alternative! Clients can consider a cast with only a single emoji as a "reaction", and display it as such. In their UI it could also be presented as if it were reacting. But under the hood, it would just be a lone emoji cast. A bit hacky but it solves almost all the problems...except for custom emojis.

I think that could be handled in the protocol in a different way, but as I'm writing this on my phone and it's 1am I feel like I should pause and make sure what I've already said and what is in my head actually make sense. So for now, these are my thoughts. Thank you for your consideration, xoxo

[davidfurlong]

Happy to sideline this as it seems to be quite involved and probably is not a priority at this point.

[michaelhly]

An implementation for default shared emojis:

• We do not implement them as reactions
• We create a new message type called EmojiMessage
• Store 50 EmojiMessages in hubs with LRU eviction rules and no expiration
• Some sort of validation is needed to ensure the text field on the proto contains an emoji and is available in Emoji Version 15.0
• Scalar quantity of an EmojiMessage applied to a cast is determined by its set of countable messages as described in this FIP where:
  • the cast is the primary_target of the countable messages
  • the emoji is the secondary_target of the countable messages
  • counting operator of the countable messages is always ADD
  • value of the countable messages is always 1

[michaelhly]

Clients can do whatever they want with custom emojis (see Discord)

[sanchitram1]

What about custom defined emojis á la twitch or slack? Are those maintained Emoji Version 15?

[michaelhly]

No

[varunsrin]

another option is to just make them a custom reaction type and they share the same rules for the reaction set. this has the benefits of minimizing the amount of code added.

my only hesitation here is that rendering emoji correctly is a pain, and some clients might just choose not to render this and focus on the likes instead. but maybe that's OK.

[varunsrin]

closing due to inactivity