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

[Daniel Kahn Gillmor <dkg@fifthhorseman.net>]

[-- 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 --]