Re: [ietf-822] Fwd: New Version Notification for draft-crocker-inreply-react-03.txt

[cketti <[e-mail]>]

On 23.10.20 17:32, Dave Crocker wrote:
>>> Not conflating reply text with a summary reaction makes a lot of things
>>> easier for clients and users.
>
> It's not obvious to me that this is true. (In fact, I suspect it
> isn't.)  So feel free to provide a comparison between the two
> approaches, in terms of affects on clients and users.

Let's just take the filter example. It's quite easy to write one that
checks for the existence of a certain header field (I don't care much if
it's "In-Reply-React" or "Content-Disposition: Reaction" in the
outermost header).

It's quite another thing to write one for:

> check for a part with a "reaction" content-disposition at either the
outermost level or as part of a multipart at the outermost level.


>> 3. Clients would most likely want to hide reaction messages
>
> Why?

Maybe you're the type of person who prefers this:

Original message

3 👍  1 👎  1 🤔

User A reacted with 👍
User B reacted with 👍
User C reacted with 👎
User C: I don't like this because…
User D reacted with 👍 🤔

There's nothing wrong with that and (minus the summary) it's more or
less what you get with clients that don't support reactions.


However, I prefer a UI where reactions are summarized and displayed on
the original message. Who reacted how can still be displayed as a popup
or in an additional screen. But I don't want to see that information by
default. Seeing this is how popular social media/chat sites do things
I'm guessing I'm not alone in wanting this.

Original message

3 👍  1 👎  1 🤔

User C: I don't like this because…


This is the main reason why I believe recognizing reaction messages
should be as easy as possible. Combining reactions and comments in one
message adds complexity without any meaningful advantage I can see.