Mastodon: Add end-to-end encryption API
> <i>specifically the Olm implementation developed by Matrix -- but it should be roughly the same as libsignal</i><p>I'm all for "many eyes make bugs shallow", but this is somewhat-widely deployed software, and I have approximately 0% confidence (based on my previous experiences with Mastodon releases and code quality) that this will be strong and safe for its first public release.  (Happy to be proven wrong, mind you.)<p>Perhaps this could be done in an official testing fork, and merged back in when actual cryptographers are more confident about it?<p>The idea of shipping this in the standard Mastodon release cycle is terrifying, and I <i>really</i> hope they don't intend to do that.<p>Ultimately, from a design perspective, I'd much rather see ActivityPub implementations support good profile deep linking to existing (read: safe) messengers rather than trying to graft e2e onto a federated messaging protocol that happens to support DMs-do one thing and do it well, and all that. (Also: backwards-compatibility downgrade attacks, anyone?)  We all know how well previous attempts at e2e encryption of federated protocols went (spoiler: they didn't).<p>The modern day version of Zawinski's Law of Software Envelopment seems to be that apps will always attempt to expand until they can send and receive DMs.  The consequence of this should not be that every app bundles key generation, key encipherment, key backup, secure key distribution, federated key authentication, <i>and a message cryptosystem</i> simply to support e2e DMs.  That's (dangerous) madness.