* should notmuch handle or generate message responses (RFC 9078) (or, "why can't i 👍 an e-mail message?") @ 2021-08-05 21:36 Daniel Kahn Gillmor 2021-08-06 7:35 ` Ralph Seichter 2021-08-09 20:06 ` Tomi Ollila 0 siblings, 2 replies; 6+ messages in thread From: Daniel Kahn Gillmor @ 2021-08-05 21:36 UTC (permalink / raw) To: Notmuch Mail [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: should notmuch handle or generate message responses (RFC 9078) (or, "why can't i 👍 an e-mail message?") 2021-08-05 21:36 should notmuch handle or generate message responses (RFC 9078) (or, "why can't i 👍 an e-mail message?") Daniel Kahn Gillmor @ 2021-08-06 7:35 ` Ralph Seichter 2021-08-06 9:34 ` Reto 2021-08-09 18:32 ` Daniel Kahn Gillmor 2021-08-09 20:06 ` Tomi Ollila 1 sibling, 2 replies; 6+ messages in thread From: Ralph Seichter @ 2021-08-06 7:35 UTC (permalink / raw) To: notmuch * 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: should notmuch handle or generate message responses (RFC 9078) (or, "why can't i 👍 an e-mail message?") 2021-08-06 7:35 ` Ralph Seichter @ 2021-08-06 9:34 ` Reto 2021-08-09 18:32 ` Daniel Kahn Gillmor 1 sibling, 0 replies; 6+ messages in thread From: Reto @ 2021-08-06 9:34 UTC (permalink / raw) To: notmuch 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: should notmuch handle or generate message responses (RFC 9078) (or, "why can't i 👍 an e-mail message?") 2021-08-06 7:35 ` Ralph Seichter 2021-08-06 9:34 ` Reto @ 2021-08-09 18:32 ` Daniel Kahn Gillmor 2021-08-10 16:59 ` Ralph Seichter 1 sibling, 1 reply; 6+ messages in thread From: Daniel Kahn Gillmor @ 2021-08-09 18:32 UTC (permalink / raw) To: notmuch [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: should notmuch handle or generate message responses (RFC 9078) (or, "why can't i 👍 an e-mail message?") 2021-08-09 18:32 ` Daniel Kahn Gillmor @ 2021-08-10 16:59 ` Ralph Seichter 0 siblings, 0 replies; 6+ messages in thread From: Ralph Seichter @ 2021-08-10 16:59 UTC (permalink / raw) To: notmuch * 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: should notmuch handle or generate message responses (RFC 9078) (or, "why can't i 👍 an e-mail message?") 2021-08-05 21:36 should notmuch handle or generate message responses (RFC 9078) (or, "why can't i 👍 an e-mail message?") Daniel Kahn Gillmor 2021-08-06 7:35 ` Ralph Seichter @ 2021-08-09 20:06 ` Tomi Ollila 1 sibling, 0 replies; 6+ messages in thread From: Tomi Ollila @ 2021-08-09 20:06 UTC (permalink / raw) To: Daniel Kahn Gillmor, Notmuch Mail 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-08-10 16:59 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-08-05 21:36 should notmuch handle or generate message responses (RFC 9078) (or, "why can't i 👍 an e-mail message?") Daniel Kahn Gillmor 2021-08-06 7:35 ` Ralph Seichter 2021-08-06 9:34 ` Reto 2021-08-09 18:32 ` Daniel Kahn Gillmor 2021-08-10 16:59 ` Ralph Seichter 2021-08-09 20:06 ` Tomi Ollila
Code repositories for project(s) associated with this public inbox https://yhetil.org/notmuch.git/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).