The technological problems are not the hard problems in this space. The hard problems are social problems.
I'm not a Mastodon user, but this is haunting. Just like shady data brokers, political shadow companies and "the feds" are running VPN nodes, subreddits etc, this architecture is practically designed for malicious actors. It wouldn't surprise me if it's already being used this way on other nodes.
To be clear, in 2005 this would have been great, tech is moving fast so one has to remain humble when critizising architectural decisions. Nevertheless, today we can't trust private data in hands of benevolent (and often de-facto anonymous) volunteer actors, if we want scale and security in the decentralized (or even federated) world.
We have had enormous progress in applied cryptography, both in social apps (Signal, Matrix) and defi (some successes, many failures to learn from). We should have the expectation for private data that the operator cannot read it. Doesn't mean that all data on a social app must be private, but DMs and invite only "groups" should be.
Currently, the typical website with per-node password auth doesn't satisfy these constraints, since credential harvesting is trivial. It's very difficult to build E2EE web apps and even if, users have no habit of keeping secrets on-device. The client itself needs to be vetted and accessed securely. Perhaps Matrix is best positioned in this space.
(Please correct me if I got any details wrong)
> We should have the expectation for private data that the operator cannot read it
That's called heterogenous encryption, and it's the technological equivalent of Mythril. End-to-end encryption doesn't stop the operator from decrypting your data. In fact, pretty much everyone has to, since raw encrypted TLS data can't just get slotted into your OneDrive/iCloud account. These operators literally need to read your data to operate on it. I genuinely don't know how you would engineer a more secure architecture here.
If you want to talk about architectures designed for malicious actors, you probably shouldn't start with distributed systems. Monolithic, profit-driven corporations like Twitter are much easier to tempt with salacious "data brokers, political shadow companies and "the feds""
It's literally the opposite. E2EE means only the participating parties can decrypt the messages.
> In fact, pretty much everyone has to, since raw encrypted TLS data can't just get slotted into your OneDrive/iCloud account.
TLS is not designed for e2ee, it's designed to protect traffic in the client server model. This is referred to as in-transit encryption. SSL got traction mostly due to e-commerce.
> I genuinely don't know how you would engineer a more secure architecture here.
Prior to computers, people pre-shared their symmetric secret keys only with those they trusted, precisely to make their messages secure from spies, couriers etc. This is e2ee.
You are right that "you have to trust our almighty server" is commonplace, but they absolutely do not have to. In 1991 came PGP which let you have e2ee over email (even if your peer is offline). Signal, Matrix etc use more advanced protocols to provide even more security and useful features. Even whatsapp and telegram have e2ee in most ways, although they have been criticized for not satisfying all criteria.
Fully homomorphic encryption is also possible to operate _on encrypted data_ albeit computationally impractical still for a couple years.
Having publicly readable posts is core to the whole idea, just like Twitter.
Note: there are some interesting forks like Hometown[1] that have interesting privacy variants. The big feature I'm envious of in Hometown is the ability to send a message _just_ to people on your server that will never leave it. BUT overall mastodon is 100% about publicly readable information (like Twitter). If someone isn't comfortable with that they shouldn't use Mastodon.
This is something that perplexed me when Mastodon and Diaspora and others appeared: why would you want to recreate/mimic the toxicity of FB and Twitter ? The resharing, the upvotes, etc. If social networks all have the seeds of their defaults, why clone it ?
The other parts are true, but the "manipulation of timelines" is just a question of time because it's useful if you follow lots of people. As long as it remains opt-in and a setting it's a good thing. I'm planning an ActivityPub implementation for myself and "manipulation of timelines" is one of the features I want to add the most for my own use.
Point being that deviating from a strictly chronological timeline isn't the problem. Doing so in a non-transparent way the user has little control over is.
But overall it's easy to iterate on this, and you can try things on your own instance or your own "corner" of likeminded instances while still be able to interoperate on most things.