Reaction client tag #289
Reaction client tag #289
Conversation
|
|
||
| The react tag is sent by a client with the client-only prefix `+`. The value has no restrictions. | ||
|
|
||
| +draft/react=<reaction> |
There was a problem hiding this comment.
Shouldn't this be limited to the Unicode Miscellaneous Symbols and Pictographs block?
There was a problem hiding this comment.
Well, I deliberately wanted to allow stuff like lol or :) orヾ(@°▽°@)ノ
|
👎 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) |
|
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. |
|
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 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. |
|
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 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. |
|
@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. |
|
|
||
| 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 |
|
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. |
|
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? |
|
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. |
|
Why would it need to be a channel mode rather than a client preference? |
|
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.) |
|
Yup, fair enough. This is probably already covered by the "Moderation considerations" section in the currently published message tags draft.
|
|
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. |
|
@dijit client software needs to opt in to display any output, so you're safe! |
|
@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. |
|
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. |
I only see three choices for users:
|
|
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. |
Sending "any text" would be going against the spirit of the spec and would be counter productive for a client to do. Non issue.
So, stagnation? |
True, indeed. I think Weechat has that feature too. |
|
The toggleable options in a reaction supporting client would probably be:
Could be per channel or global toggles. |
|
@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 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. |
|
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 |
|
@Zarthus maybe you can implement a client patch that takes |
|
It is useless to have a new line for every message, I'd much prefer the UI
to show it at the message like github does.
Based on how popular it is to do this, it's not unreasonable to think
people would enjoy such a feature.
…On 12 Jan 2017 09:58, "Jan Harasym" ***@***.***> wrote:
@Zarthus <https://github.com/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?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#289 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADfaeKO8jpLh3Xprz2Rr9Qgi-RWmZA0qks5rRes0gaJpZM4LSPIE>
.
|
|
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? |
|
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?
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. |
|
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. |
|
I don't think ^ will end with the introduction of reactions - people don't like to take their hands off the keyboard |
|
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. |
|
I'm seeing some potential UX issues without any regulation of reactions.
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:
I could see a couple potential ways of dealing with this:
|
|
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. |
|
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. |
|
This is no longer blocked. I'll merge it later this week barring any further issues. |
+draft/react=👍Depends on
#287and#288Source of inspiration:
https://slackhq.com/722-ways-to-say-i-got-your-message-e69a4d7da8e4#.fmzgegc5z
My UI implementation in IRCCloud: