Reaction client tag #289

Open
wants to merge 3 commits into
from

Projects

None yet

10 participants

@jwheare
Member
jwheare commented Dec 20, 2016 edited

+draft/react=๐Ÿ‘

Depends on #287 and #288

Source of inspiration:
https://slackhq.com/722-ways-to-say-i-got-your-message-e69a4d7da8e4#.fmzgegc5z

My UI implementation in IRCCloud:

Image

+
+The react tag is sent by a client with the client-only prefix `+`. The value has no restrictions.
+
+ +draft/react=<reaction>
@SaberUK
SaberUK Dec 21, 2016 edited Contributor

Shouldn't this be limited to the Unicode Miscellaneous Symbols and Pictographs block?

@jwheare
jwheare Dec 21, 2016 Member

Well, I deliberately wanted to allow stuff like lol or :) orใƒพ(@ยฐโ–ฝยฐ@)ใƒŽ

@MaxLeiter

๐Ÿ‘Ž because if you don't have it enabled or it's not implemented you could miss out on context of ongoing discussion. (I also just don't think it contributes to a conversation at all, and its a feature I -hate- in Slack, but that's an opinion)

@DanielOaks
Member

Just as a counterpoint, I see reactions as a non-necessary nicety. Some clients can make good use of them (particularly the newer graphical clients coming out today), and I think having it available puts IRC on a more level playing field with the 'competitors'.

That said, I don't see them as necessary. As such, I'd be fine if clients miss them or don't implement/show them. Nice to have and add some additional info for those clients that can use it, but I don't think the possible lost context is enough of an issue to avoid having the feature.

@MuffinMedic
MuffinMedic commented Dec 21, 2016 edited

How are reaction "counts" handled to ensure that all users / clients display the same & correct reaction numbers?

The simplest solution would be that this is done client side - the client receives a draft/react=<reaction> for a specific draft/msgid and tracks/displays how many of each reaction count has been received for that message ID. This introduces inconsistencies in counts though across users - users who join midway through the chat either (1) start their counts from that point forward and they are no longer the same across users or (2) they ignore the emojis for messages they didn't receive. The first presents upfront issues, while the second option can become problematic when chanhistory or buffer playbacks are added in.

The alternative is to have the reaction counts tracked server side by the IRCD and sent to the client on connect, and then either send an updated count when a new reaction occurs or have the client increment this itself client side. Both of these could, in theory work, but should not be the responsibility of the server - the client-tag implementation should be 100% client side with no server-side handling.

Either way, it seems that ensuring that if a certain message receives, for example, 15 "likes" and 22 "thumbs up" that every user / client has these correct numbers.

@DanielOaks
Member

I see those inconsistencies as no big issue. I see reactions like this as ephemeral and temporary so I'd be fine with clients that connect partway through not getting everything, and them not persisting with chanhistory and similar.

If clients/bouncers want to save and replay them / display them after restarting that's fine, but I don't think they're enough of an issue to worry about that in-depth to be honest.

@jwheare
Member
jwheare commented Dec 21, 2016

@MuffinMedic the way I do this in IRCCloud is just a client side string match. Client tags are intended not to require server intervention by design (of course servers are free to intervene for e.g. moderation if they choose).

The spec specifically mentions that there might be cases where reactions aren't displayed. Imo it's an acceptable limitation.

client-tags/react.md
+
+Software implementing this work-in-progress specification MUST NOT use the
+unprefixed `+react` tag name. Instead, implementations SHOULD use the
+`+draft/react` capability name to be interoperable with other software
@DanielOaks
DanielOaks Dec 21, 2016 Member

capability name -> tag name

@MuffinMedic

The limitation, I feel, will ultimately cause more confusion to users than it will benefit as a feature. The intended use case is, as stated, a system of inline reaction "emojis," fun and enjoyable. The actual use cases, in my experience, have been quite different.

The inspiration for the idea, Slack, I think is a perfect example. In my experience, reactions are often put to other (less ideal) uses, such as checkmarks or thumbs up for "vote yes" and an X or thumbs down for "vote no," where accurate counts become more important. Adding in this feature to IRC without the consistency would go against what people already expect and are familiar with, leading to frustration.

I think it's a good idea that ultimately comes down to a disparity between it's intended uses and the actual uses in effect.

@jwheare
Member
jwheare commented Dec 28, 2016

Not sure I follow your reasoning given the situation you described. Users who join partway through a chat won't see the initial message anyway, so it's not clear what's lost in this situation that isn't already lost with people not seeing messages before they've joined a channel. chanhistory is irrelevant, since reactions are PRIVMSGs and will be persisted by default. All it does is move the effective join time back a little.

Your objection smells a lot like vetoing a 99% solution because it's not a 100% solution, and the missing 1% is due to accepted limitations of IRC that are outside the scope of the proposal. Should we deprecate the use of PRIVMSG entirely because people don't see them before they join?

@Zarthus
Zarthus commented Dec 28, 2016 edited

While it's out of the scope of this PR, I do hope ircds will start supplying a channel mode to block reactions.

For the rest, it looks good to me.

@jwheare
Member
jwheare commented Dec 28, 2016

Why would it need to be a channel mode rather than a client preference?

@Zarthus
Zarthus commented Dec 28, 2016

The same reason as MaxLeiter suggested, some people think it makes them "lose out" on conversation. I'd rather the message was rejected than not shown in some cases.

In addition, I thought it might become a venue for abuse but that'll need some stress testing on other clients to see how well they perform. CTCP, message, and DCC spam is already common (although +q, +b and +m handle that already, so one could say "it's already a channel mode" as well.)

@jwheare
Member
jwheare commented Dec 28, 2016

Yup, fair enough. This is probably already covered by the "Moderation considerations" section in the currently published message tags draft.

Moderation tools available to channel and network operators typically operate on message text and sender information only. To avoid abusive content being sent in client-only tags, servers, services and management bot implementations may wish to enable moderation features that act on tag content as well.

@jwheare jwheare added this to the Roadmap milestone Jan 7, 2017
@dijit
dijit commented Jan 11, 2017

Seems strangely odd to tack this on to IRC when it was never what IRC was about. Text communication is the bread and butter of the IRC protocol. Additionally all line based clients are going to have to be rewritten (or you get some fugly output like the irc bridge to slack has.)

So I consider this needless complexity and am not in support of it.

@jwheare
Member
jwheare commented Jan 11, 2017

@dijit client software needs to opt in to display any output, so you're safe!

@ProgVal
Contributor
ProgVal commented Jan 11, 2017

@jwheare But from what I understand of discussions in the working group, it is still in debate whether hiding this information will be harmful to the reader.

@jwheare
Member
jwheare commented Jan 11, 2017 edited

Here's why I'm personally opposed to sending the reaction in the message body for existing clients:

It keeps the value visible but strips it of any reply-to context and makes it spill into the backlog, disrupting other conversations that might be happening. That could be a massive problem for larger channels. There also would be no way to disable it for people who don't want to see it in legacy clients.

Data without context is more often noise, rather than information.

Keeping the reaction in a tag allows clients to opt into the functionality if their users want it. This, in my opinion, is much more in line with the ircv3 approach to backwards compatible enhancements.

Yes, I acknowledge that this may result in new behaviour that people using some clients might miss out on. Sometimes that's inevitable when you introduce new features. Backwards compatible doesn't always mean perpetual backwards parity.

It's important that we consider the trade offs and we absolutely should discuss them here. My view is that the specs we publish should be about escaping the stagnation IRC has become famous for, by enabling new features and providing a clear path to their adoption, while respecting existing conventions and implementations.

Enabling a wall of context-less emoji to spew into a channel doesn't seem very respectful to me.


Having said all that, the specification doesn't currently forbid clients from duplicating the reaction in the message body, and I wrote a less opinionated discussion of the trade offs in the "Client implementation considerations" section. I think encouraging clients to let their users decide is probably the only way to resolve this.

@ProgVal
Contributor
ProgVal commented Jan 11, 2017

I think encouraging clients to let their users decide is probably the only way to resolve this.

I only see three choices for users:

  • showing the reaction as a context-less message: bad, as you showed it
  • not seeing the reaction (which may be any text with no restriction): bad
  • radically changing their UI: I don't like modern UIs, so I can only see it as bad
@dequis
Contributor
dequis commented Jan 11, 2017

Practically speaking, what clients are not capable of implementing this in their UI without a "rewrite" or a "radical change"? I mean, I've been thinking this isn't a big deal because even irssi has a way to add lines in the middle of the text buffer, but I may be wrong to take irssi as the baseline.

@jwheare
Member
jwheare commented Jan 11, 2017
  • not seeing the reaction (which may be any text with no restriction): bad

Sending "any text" would be going against the spirit of the spec and would be counter productive for a client to do. Non issue.

  • radically changing their UI: I don't like modern UIs, so I can only see it as bad

So, stagnation?

@ProgVal
Contributor
ProgVal commented Jan 11, 2017 edited

I mean, I've been thinking this isn't a big deal because even irssi has a way to add lines in the middle of the text buffer

True, indeed. I think Weechat has that feature too.

@jwheare
Member
jwheare commented Jan 11, 2017

The toggleable options in a reaction supporting client would probably be:

  • Show inline reactions (probably on by default)
  • Allow legacy clients to see reactions you send as standard messages (probably off by default)

Could be per channel or global toggles.

@dijit
dijit commented Jan 12, 2017 edited

@ProgVal "having a way" to rewrite a buffer is cool and everything but the logic is definitely more complex. I much prefer line based messaging and the current code for hexchat(and variations), Textual, Palaver, Weechat all assume line-by line input in a fire & forget fashion to their buffers.

Which is great, you don't rereference memory, just spit it to a buffer. Having it "optional" is, in my opinion, an introduction to the fragmentation that plagued XMPP. XMPP if you remember had support for everything, absolutely everything could be tacked on to the protocol, and the results were incompatibilities everywhere and most XMPP providers were then unable to federate or improve.

@jwheare You're referencing "modern" clients. Do you mean IRCCloud? IRCCloud can do "magic" in JS, but many of us choose IRC because it's light, an easy protocol to wrap things around, easy to understand.

Emojis are just the lowest denominator of conversation, they convey less meaning than words and if you're having a real IRC conversation there's no time to see a reaction.. and how do you show them? hide them up in the back buffer? Alert people to their presence. You can claim this is a problem for the IRC Client producers but you're the one writing the spec, you provide the vision.

I might be the only one here but I am vehemently opposed to "optional" information being available to me, that's not what IRC is in my opinion, I don't "go back in time" either. IRC as a protocol is write once and it's immutable. The context of a conversation changing hours after it has occurred, is frightening.

@Zarthus
Zarthus commented Jan 12, 2017

@dijit

To respond to the last paragraph, I don't believe reactions don't change context of a conversation at all. They're just a bit of useless surrounding flavour to a message (that I personally envision) would mostly be used for liking/disliking a message and showing support (much like github's current system). While it allows for rather broad reactions of any type (which I don't entirely agree with), none of them are particularily context changing.

The amount of people currently using ^ as a sole character in a message to show agreement is one of the small things that annoy me in IRC, and I think reactions would solve that. (it is also slightly error prone, but usually easy to see what was meant.), the same applies to other emoji

@dijit
dijit commented Jan 12, 2017

@Zarthus maybe you can implement a client patch that takes ^/+1 and shows a like? You even stated it was 'useless' so why have it in the protocol?

@Zarthus
Zarthus commented Jan 12, 2017
@dijit
dijit commented Jan 12, 2017 edited

If it's your client, you can remove the newline and add it to the previous message, you can even grab the highlight and tag the last message of that user.

If you want slack features, use slack. I've never seen anyone actually use this feature as anything more than a gimmick and I use slack professionally. (9 slacks, 500 people in each on average, active 9 hours a day).

Obviously that's anecdatum; but do you have differing experiences?

@dequis
Contributor
dequis commented Jan 12, 2017

You may not like this feature in the average traditional irc network, but remember some of us are not using the irc protocol to implement traditional irc servers. For all I care, traditional irc servers may never support or allow this. Doesn't matter to me, and it's their choice anyway.

Gateways to more featureful services exist, and those need to have standard ways to transmit all the information within the protocol.

Also, "I think it's a gimmick" or "it feels like it's not in the spirit of what i personally believe irc should be" are not technical reasons, can we not?

and the results were incompatibilities everywhere and most XMPP providers were then unable to federate or improve

Getting sorta offtopic but as someone who has dealt with XMPP significantly, it sounds like you're making this up. I can't imagine any ways in which a XEP could result in stopping servers from federating or improving. The vast majority are discoverable, completely optional, with specified fallbacks. More often than not it's specified as just another tag outside of the body that clients just ignore. What you're saying is misrepresenting extensibility in general and smells like FUD.

@dijit
dijit commented Jan 13, 2017

A friend of mine noticed this topic and gave me an example of the feature in action.

You're right that we're thinking of different use-cases, in my slack we have hundreds of people and constant communication (just like big IRC networks, including the one I run). But for smaller IRC networks/channels it can make sense, the full range is wayyyyyy too much, but a trimmed down list could be useful.

@Zarthus Zarthus referenced this pull request in ircv3/ircv3-ideas Jan 13, 2017
Open

Denote the target audience for certain specifications. #7

@MaxLeiter

I don't think ^ will end with the introduction of reactions - people don't like to take their hands off the keyboard

@Zarthus
Zarthus commented Jan 26, 2017 edited

I don't think anyone thought it would end ^s, that's an unrealistic expectation. The intention is just to offer a better way to do something similar.

This is totally doable without use of the mouse, too.

@LFP6
LFP6 commented Feb 13, 2017

I'm seeing some potential UX issues without any regulation of reactions.

  • Could there be some provision for having server-centralized reactions, ie so that a given server would provide a set of possible reactions, and you can only choose from those? This gets a little difficult in terms of the line between what's within the protocol and what isn't, but it could make a lot of sense for a given community to specify valid reactions for the sake of consistency.
  • What about reactions which are not text/Unicode? I'm imagining things like Slack's custom reactions. I believe Discord also has their own custom reactions that they provide. Could there be reactions as (image) URLs? Server regulation here would be particularly useful. But what if multiple clients all want to support a non-Unicode emoji, but display them with their own "styles"? Does the :emote: need to be standardized?
  • Do reaction types need to be (more) defined in order to display properly? I can think of the following possibilities:
    • Text (I assume the "lol" example falls into this example)
    • Emoticons
    • Emoji
    • (Image) URLs
    • Shorthand like :emoji:

Next thought, I'm going to go back to the start of the topic here and voice my opinion on reaction counts. After discussion in #ircv3, I can think of these situations that could be potentially problematic:

  • User comes in part way through, and the client is required to track reactions in case the user decides to scroll back in history and find the original message: Doable, but annoying since the reactions need to be kept around until something can be done with them, if ever
  • Searching allows a user to jump back to the context surrounding a post, per #292 (comment). Ditto the previous point.
  • User leaves and returns, with additional reactions added between when they left and joined (where history is kept on the client): At this point, it's not just missing context, it's wrong context. I agree with @MuffinMedic that at this point, client users will be complaining about a bug, and it makes potential usage as a voting feature pretty much worthless.
  • User leaves and returns, with no additional reactions added between when they left and joined (where history is kept on the client): This mean changing history storage formats so that reactions are stored with the message (or so reactions are stored period, if they wouldn't be for some reason), and/or the entire history needs to be "played back" so that reactions can be set (seems terribly inefficient to me, especially if a user decides to keep some tens of thousands of lines of history, which I'm sure someone does). Probably a nonissue, but something to be considered.

I could see a couple potential ways of dealing with this:

  • Extend chathistory (batch)/search to provide reaction counts along with replayed messages - Solves 1 and 2 pretty nicely in my opinion
  • Request prior reactions via CHATHISTORY or search (ircv3/ircv3-ideas#9) "filter" - solves 3 and the relatively edge case of 4, some form of rate limiting would probably be needed
    • Time period when reactions were posted (ie, when you were away)
    • Message IDs or time frame(s) of message being reacted to (ie, the messages that you have locally)
@jwheare
Member
jwheare commented Feb 14, 2017 edited

The main reason for not trying to standardise everything up front is that doing so too early stagnates the potential to do all the things you mentioned, and then go beyond it. And also assumes that we can predict how clients and users are going to adopt reactions.

New emoji are coming out all the time. The move to combining emoji like the family and skin tone stuff makes it even harder to define how to verify and validate what an emoji is. If we come up with rules for that now, they could be obsolete with the next Unicode release.

This is already a partially solved problem with the "standard" :emoji: shorthand codes. Originally they were defined at http://emoji-cheat-sheet.com, which lists a lot of projects at the top, but it's out of date. Now there are projects like https://github.com/github/gemoji and https://github.com/iamcal/emoji-data that track and update the list. Expanding them to handle new emoji is an ongoing process with each new release. Trying to insert an IRCv3 standardisation step in there won't be productive.

One way custom reactions could work is the same way they work on Slack. Each one has a shorthand text. So clients that want to support them can convert text reaction keywords to images, by using whichever mapping they choose or, of by providing a way for users to define and share mappings. Private groups can define their own mappings. Popular ones could then be bundled into clients.

This is also similar to how emotes work in Twitch. They have built in, subscriber, partner sets, which they control in their web client (and other clients can get mappings from their API) but there are community sets like BTTV and FrankerFaceZ that are popular too.

The great thing is clients that don't support the mapping still get a meaningful keyword. It's not perfect, but folks survive. Or they put pressure on client devs to support them.

Which is all to say that how this happens goes beyond the protocol scope defined here and gets more into client implementation territory. We should focus on providing primitive mechanisms and let clients work to expand them into something richer. If the landscape settles on some more solid conventions we can look at rolling them back into a spec here, but it's far too early to worry about that now. Consider it, sure, but let's try not to hinder experimentation at this stage.

@jwheare
Member
jwheare commented Feb 14, 2017

Re: reaction counts. I think you've now established that if it's a real world problem, it's an issue to be solved outside of this spec. Either in the CHATHISTORY spec, or in a new mechanism for servers to track and validate counts, or somewhere else. As I see it, the issue isn't so onerous or intractable that it makes the basic client spec as defined here worthless. And I don't think any revisions to this mechanism would be required to support any solution that builds upon it and is defined elsewhere.

@LFP6 LFP6 referenced this pull request in ircv3/ircv3-ideas Feb 19, 2017
Open

Add ability to edit and delete messages #10

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