Mastodon: Add end-to-end encryption API
github.com
Mastodon: Add end-to-end encryption API
1–10 of 188 posts
Re: Mastodon: Add end-to-end encryption API
#2> specifically the Olm implementation developed by Matrix -- but it should be roughly the same as libsignal
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.)
Perhaps this could be done in an official testing fork, and merged back in when actual cryptographers are more confident about it?
The idea of shipping this in the standard Mastodon release cycle is terrifying, and I really hope they don't intend to do that.
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).
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, and a message cryptosystem simply to support e2e DMs. That's (dangerous) madness.
Re: Mastodon: Add end-to-end encryption API
#3> specifically the Olm implementation developed by Matrix -- but it should be roughly the same as libsignal 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.) Perhap…
agreed. on random side note, heck there is still no way to delete cached headers, leaving instance storage unbound unless you manually take care of it
Re: Mastodon: Add end-to-end encryption API
#4Could it be why mstdn.jp is shutting down? Official reason is lack of resource to handle anticipated legal requests but that sounded weird.
Re: Mastodon: Add end-to-end encryption API
#5> specifically the Olm implementation developed by Matrix -- but it should be roughly the same as libsignal 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.) Perhap…
At the heart of the issue in the complexity of these protocols is that we want to both broadcast widely and address someone specifically. This is a quandary intrinsic to discussion forums, chat rooms and social media.
And the default is to mash both of them together and make it public. Unsurprisingly, it's a source of toxicity and needs intensive moderation, because a broadcasted address is mostly employed in a narrative sense, with the person at the other end reduced to a character in the story. A timeline creates a space, but in a shared timeline, whether it's a Twitter hashtag or a comments section on a small blog, the space is made by spamming your narrative more often.
With a decentralized, privacy-enabled solution like ActivityPub, there are many tools to reshape the extent of the narrative so that you always own your own space, but the tools themselves are quite complex and pressure our engineering and UX capabilities.
And yet - broadcast by itself is not hard, if done in pull-orientation like RSS. And secure messaging is challenging but mostly solved. I have some unfinished thoughts that perhaps simpler is possible by changing the system's orientation further, because I don't think the current designs are quite it.
Re: Mastodon: Add end-to-end encryption API
#6> specifically the Olm implementation developed by Matrix -- but it should be roughly the same as libsignal 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.) Perhap…
Have you actually looked at the PR? It's not large and there is very little that actually needs to be done on the server-side. The heavy lifting is offloaded to the client, which will probably further offload its heavy lifting with one of the well-known crypto libraries.
Re: Mastodon: Add end-to-end encryption API
#7They should be using Noise along with it.
Re: Mastodon: Add end-to-end encryption API
#8Pleroma does what mastodon't
Re: Mastodon: Add end-to-end encryption API
#9Pleroma does what mastodon't
Last I checked Pleroma doesn't even have moderation tools, let alone message franking.
Re: Mastodon: Add end-to-end encryption API
#10> specifically the Olm implementation developed by Matrix -- but it should be roughly the same as libsignal 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.) Perhap…
Have you actually looked at the PR? It's not large and there is very little that actually needs to be done on the server-side. The heavy lifting is offloaded to the client, which will probably further offload its heavy lifting with one of the well-known crypto libraries.
An import 500 modules in the process.