3 ms·

Is there an email spec that actually hashes posts, and allows new emails to just refer to the hash it is responding to, and the thread hash-graph. And perhaps a

by Chris2048 7y ago

Is there an email spec that actually hashes posts, and allows new emails to just refer to the hash it is responding to, and the thread hash-graph. And perhaps as some metadata, some former posts w/ hashes.

vidarh 7y ago
Message-ID, In-Reply-To and References headers provides this. Hashing a post is a hard problem, because an MTA can change the encoding of the message in all kinds of ways, so you'd first need to specify a canonical form for the message. But it's also unnecessary if you can trust the sending mail server to add a Message-ID field that is unique (which it can do however it wants to, and then ensure global uniqueness by appending its hostname; note that a client needs to take a bit of care because of course a broken server may not enforce uniqueness). A harder to solve problem is that it takes very few broken mail clients participating in a thread before it causes a mess.
- Chris2048 7y ago
  The thing about a hash though, is any client could create the hash, or verify it. You could even have consensus ala blockchain type thing. I guess if we use message-id, then a signed message from the mailserver with the message id would do. But signed messages still usually contain a hash of the thing they sign, no?
  - vidarh 7y ago
    You could rely on DKIM signatures for that, potentially. But lots of systems don't generate DKIM signatures. All systems generate message id's. Using message-id's for threading has literally worked for decades when the clients supports the relevant headers. It's not the message-id that is the problem, but lack of support for the headers carrying them.
jcranmer 7y ago
Message-ID, In-Reply-To, and References are the standard way of doing this for anything using a .eml-like format (this includes both email and Usenet). Message-IDs are supposed to be unique according to the specification. In practice, you can get non-uniqueness if a message is reinjected into the mail system (say you send a message to a mailing list: both the original message you wrote, and the slightly-rewritten message sent out will use the same Message-ID). It works well enough that the way every mail client actually groups messages into threads... is to use these headers. So not only is there already an email spec, everybody already supports that spec.
- JdeBP 7y ago
  That's not really true, otherwise I never would have had to come up with the GNKSOA-MUA. * http://jdebp.uk./Proposals/gnksoa-mua.html#ProperThreading http://jdebp.uk./Proposals/gnksoa-mua.html#ProperThreading
  - jcranmer 7y ago
    The emphasis you should read in the GNKSOA is on the word "only", which is to say, the priority is not to implement References/In-Reply-To threading, but to not implement Subject-based threading.

vidarh 7y ago

Message-ID, In-Reply-To and References headers provides this. Hashing a post is a hard problem, because an MTA can change the encoding of the message in all kinds of ways, so you'd first need to specify a canonical form for the message. But it's also unnecessary if you can trust the sending mail server to add a Message-ID field that is unique (which it can do however it wants to, and then ensure global uniqueness by appending its hostname; note that a client needs to take a bit of care because of course a broken server may not enforce uniqueness). A harder to solve problem is that it takes very few broken mail clients participating in a thread before it causes a mess.

Chris2048 7y ago
The thing about a hash though, is any client could create the hash, or verify it. You could even have consensus ala blockchain type thing. I guess if we use message-id, then a signed message from the mailserver with the message id would do. But signed messages still usually contain a hash of the thing they sign, no?
- vidarh 7y ago
  You could rely on DKIM signatures for that, potentially. But lots of systems don't generate DKIM signatures. All systems generate message id's. Using message-id's for threading has literally worked for decades when the clients supports the relevant headers. It's not the message-id that is the problem, but lack of support for the headers carrying them.

jcranmer 7y ago

Message-ID, In-Reply-To, and References are the standard way of doing this for anything using a .eml-like format (this includes both email and Usenet). Message-IDs are supposed to be unique according to the specification. In practice, you can get non-uniqueness if a message is reinjected into the mail system (say you send a message to a mailing list: both the original message you wrote, and the slightly-rewritten message sent out will use the same Message-ID). It works well enough that the way every mail client actually groups messages into threads... is to use these headers. So not only is there already an email spec, everybody already supports that spec.

JdeBP 7y ago
That's not really true, otherwise I never would have had to come up with the GNKSOA-MUA. * http://jdebp.uk./Proposals/gnksoa-mua.html#ProperThreading http://jdebp.uk./Proposals/gnksoa-mua.html#ProperThreading
- jcranmer 7y ago
  The emphasis you should read in the GNKSOA is on the word "only", which is to say, the priority is not to implement References/In-Reply-To threading, but to not implement Subject-based threading.