should notmuch handle or generate message responses (RFC 9078) (or, "why can't i 👍 an e-mail message?")

should notmuch handle or generate message responses (RFC 9078) (or, "why can't i 👍 an e-mail message?")

[Daniel Kahn Gillmor]

[-- Attachment #1.1: Type: text/plain, Size: 1832 bytes --]

Hi notmuch folks--

RFC 9078 is an experimental draft "Reaction: Indicating Summary Reaction
to a Message":

https://www.rfc-editor.org/rfc/rfc9078.html

In short form, this lets you "thumbs up" an e-mail message without
sending a longer reply.

Basically, it formalizes a way to respond to an e-mail with a single
emoji sequence [0] by sending a message using the following headers:

 - In-Reply-To: <some-message-id@example.com>
 - Content-Type: text/plain; charset=utf-8
 - Content-Disposition: reaction


[0] https://www.unicode.org/reports/tr51/#def_emoji_sequence Note that
    "emoji sequence" is *not* just "a series of emoji characters", but
    rather it is a sequence of codepoints that is typically expected to
    render as a single emoji, for example a raised hand with dark skin
    tone is U+270B RAISED HAND followed by U+1F3FF EMOJI MODIFIER
    FITZPATRICK TYPE-6


Currently in Notmuch these responses would be rendered as simple, short
one-line text replies.

Some questions for notmuch to consider:

 0) Should a message that conforms to this standard be treated
    differently by notmuch than any other message?  If the answer is
    "nope" then the rest of the questions don't make sense :P

 1) does the database need any modification to store/report these things
    as distinct responses?

 2) should "notmuch new" treat the message differently upon ingestion?

 3) should message threading information count the list of messages in
    the thread differently depending on how many messages are
    "response" messages?

 4) How should a notmuch frontend decide when to clear the "unread" flag
    from such a response message?

 5) Should notmuch frontends facilitate creation of this kind of
    response?

 6) how should a frontend render the summaries of these responses?

Interesting times,

 --dkg

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: should notmuch handle or generate message responses (RFC 9078) (or, "why can't i 👍 an e-mail message?")

[Ralph Seichter]

* Daniel Kahn Gillmor:

> https://www.rfc-editor.org/rfc/rfc9078.html
>
> In short form, this lets you "thumbs up" an e-mail message without
> sending a longer reply.

Oh my... Are "+1" replies not sufficient anymore for some people, or is
this a means of allowing the authors to claim having created an RFC, no
matter how useless it is? ;-)

I believe that implementing this feature would be a waste of your
talents, but that is of course for you to decide.

-Ralph

Re: should notmuch handle or generate message responses (RFC 9078) (or, "why can't i 👍 an e-mail message?")

[Reto]

On Fri, Aug 06, 2021 at 09:35:52AM +0200, Ralph Seichter wrote:
> I believe that implementing this feature would be a waste of your
> talents, but that is of course for you to decide.

+1 :P

Re: should notmuch handle or generate message responses (RFC 9078) (or, "why can't i 👍 an e-mail message?")

[Daniel Kahn Gillmor]

[-- Attachment #1.1: Type: text/plain, Size: 3659 bytes --]

On Fri 2021-08-06 09:35:52 +0200, Ralph Seichter wrote:
> Oh my... Are "+1" replies not sufficient anymore for some people, or is
> this a means of allowing the authors to claim having created an RFC, no
> matter how useless it is? ;-)

fwiw, i think this is a little bit ridiculous too. ☺

But in addition to being an e-mail user, i also use instant messaging
platforms.  The targeted emoji feedback feature offered by platforms
like Signal Private Messenger is a real boon to making the conversation
flow -- especially in a fast-moving group discussion.  By contrast,
e-mail threads with a ton of "+1"s, are hard to read, daunting even to
approach (does anyone like opening a thread with a dozen unread messages
in it?), and are especially problematic when it's unclear which
message a given "+1" is approving of.

If we want e-mail to be able to offer a similar cadence and experience
-- if we want a decentralized, federated e-mail system to be able to
*compete* with messaging services, I think we do need to think about
these affordances.

Put another way:

 - for years, e-mail "experts" (including myself, not infrequently) have
   lamented patterns like "+1" or "metoo" threads, top-posting of
   trivial replies with huge quoted/attributed texts blindly
   re-re-re-transmitted, and other "netiquette violations" that do
   really legitimately have negative side effects for other participants
   in the thread.

   But users who generate messages falling into these patterns aren't
   "doing e-mail wrong," they're trying to express themselves, and
   they're relying on the tooling that most MUAs offer, clumsy as they
   may be.

   If we really want to minimize the negative side effects, we need to
   think about how to help people express themselves over e-mail, and
   make it easy/convenient/enjoyable to do so.  Otherwise, e-mail will
   be relegated further and further into an awkward communications
   backwater, used only in certain work environments, and maybe feared
   or loathed by its users. :/

I'll also be clear: i don't like the weakening of public discourse to
single-glyph responses to potentially-thoughtful messages (i also don't
like 280-character limits, fwiw).  But i do use them sometimes, and
sometimes they're appropriate and the most light-weight way to
communicate what's necessary to communicate.  I'd rather have them
available to me in e-mail.

To my mind, there are some interesting wrinkles that come up in trying
to apply the affordance to e-mail, specifically in this way.  for
example, if Alice sends Message-ID: X to Bob and Carol, and Bob sends
Message-ID: Y that is In-Reply-To: X to Alice and Carol and is
Content-Disposition: reaction (following RFC 9078), what would it mean
if Carol sends Message-ID: Z that is In-Reply-To: Y (whether
Content-Disposition: reaction or otherwise)?

Cryptographically, they're also interesting: as formulated, these
responses *cannot* be generated or interpreted responsibly with any of
the current cryptographic e-mail standards that don't ensure that e-mail
headers are protected the same as the message body.  To fix this, we'd
need to invest more work in projects like
https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/.

I don't have a lot of bandwidth to work on this myself right now, but if
someone wanted to take a stab at figuring out these issues for notmuch,
i would definitely be supportive.

RFC 9078 is marked as experimental.  notmuch development could offer a
chance to contribute data to that experiment, if anyone is of a mind to
do the work.

      --dkg

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: should notmuch handle or generate message responses (RFC 9078) (or, "why can't i 👍 an e-mail message?")

[Tomi Ollila]

On Thu, Aug 05 2021, Daniel Kahn Gillmor wrote:

> Hi notmuch folks--
>
> RFC 9078 is an experimental draft "Reaction: Indicating Summary Reaction
> to a Message":
>
> https://www.rfc-editor.org/rfc/rfc9078.html
>
> In short form, this lets you "thumbs up" an e-mail message without
> sending a longer reply.
>
> Basically, it formalizes a way to respond to an e-mail with a single
> emoji sequence [0] by sending a message using the following headers:
>
>  - In-Reply-To: <some-message-id@example.com>
>  - Content-Type: text/plain; charset=utf-8
>  - Content-Disposition: reaction
>
>
> [0] https://www.unicode.org/reports/tr51/#def_emoji_sequence Note that
>     "emoji sequence" is *not* just "a series of emoji characters", but
>     rather it is a sequence of codepoints that is typically expected to
>     render as a single emoji, for example a raised hand with dark skin
>     tone is U+270B RAISED HAND followed by U+1F3FF EMOJI MODIFIER
>     FITZPATRICK TYPE-6
>
>
> Currently in Notmuch these responses would be rendered as simple, short
> one-line text replies.
>
> Some questions for notmuch to consider:
>
>  0) Should a message that conforms to this standard be treated
>     differently by notmuch than any other message?  If the answer is
>     "nope" then the rest of the questions don't make sense :P
>
>  1) does the database need any modification to store/report these things
>     as distinct responses?
>
>  2) should "notmuch new" treat the message differently upon ingestion?
>
>  3) should message threading information count the list of messages in
>     the thread differently depending on how many messages are
>     "response" messages?
>
>  4) How should a notmuch frontend decide when to clear the "unread" flag
>     from such a response message?
>
>  5) Should notmuch frontends facilitate creation of this kind of
>     response?
>
>  6) how should a frontend render the summaries of these responses?

I'd wait for "standards track" ;D (or de-facto usage it that takes too long...)

Tomi

>
> Interesting times,
>
>  --dkg

Re: should notmuch handle or generate message responses (RFC 9078) (or, "why can't i 👍 an e-mail message?")

[Ralph Seichter]

* Daniel Kahn Gillmor:

> If we want e-mail to be able to offer a similar cadence and experience
> -- if we want a decentralized, federated e-mail system to be able to
> *compete* with messaging services, I think we do need to think about
> these affordances.

And who says that we want to (or should) compete with messaging
services? I rarely use instant messaging services, and when I cannot
avoid it, I see a lot of rubbish. I could easily do without 90% of all
IMs received without feeling the least bit sad about it. ;-)

This is a rather philosophical subject, but I see email as a tool for
passing on meaningful information. A "thumbs up" response is of very
little use to me personally.

-Ralph