yeah, idk if you could count this as a success when by his own admission there's so much user data essentially sited on one single point of failure/compromise.

> The technological problems are not the hard problems in this space. The hard problems are social problems.

This is something that perplexed me when Mastodon and Diaspora and others appear: 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 ?

Coming up with "non-toxic" social media is extremely difficult and probably not something programmers can solve.

Social media inevitably becomes a reflection of the users, and humans all have a thread of toxicity running through them.

Mastodon and other Fediverse microblogging platforms aren't trying to recreate these abusive systems. They don't show boost/favourite counts, don't offer paid promotion or adverts, don't have the manipulation of the timelines or the other abusive dark patterns used to keep people hooked on the toxic pipes. I feel that being able to show appreciation for a post, or send it to the people who are interested in you, are both important ways to interact and can be implemented without the unhealthy byproducts of the corporate social media orgs.

It does show boost/favourite counts once you open a toot, and just like on Twitter you can also click to see the list of people who have boosted/favourited

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.

I also believe character limits is a problem and that it ultimately leads to polarization.

That too is easily modified. Mastodon hardcodes the value a few places, or at least used to. Pleroma has config settings to separately enforce a local limit on how much you're allowed to write, and a hard limit above which it will drop remote posts. Problem is the latter - any instances which increases the post length too much will need to consider that they'll effectively make federation unreliable for their users because most other instances will have a hard limit above which they'll drop or truncate posts.

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.

Thanks.

> Users have put their trust in me with their data. Choosing a new admin would require a massive amount of trust, since they’d have access to over a half decade of user data. Not just data from my local users, but from users they have interacted with.

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)

If this is a concern of yours, don't migrate your account. All instance admins play the role of Twitter CEO on Mastodon, which means (much like Amazon, Apple, Google, Facebook, Microsoft, Netflix, et. al) they can access all data you've trusted them with. The point of Mastodon is that it broke down these data silos, and give people more sane ownership models for social media. Your privacy concern is valid, but Mastodon doesn't advertise itself as a private protocol. A glorified microblogging platform doesn't really have a whole lot of data to leak besides maybe your DMs.

> 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""

to build on that, a mastodon instance's "federated" feed is the feed of stuff that everyone on the server is receiving.

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.

[1]: https://github.com/hometown-fork/hometown

You might be misunderstanding E2EE. In double ratchet system, not even the operator or host can decrypt DMs.

Fully homomorphic encryption is also possible to operate _on encrypted data_ albeit computationally impractical still for a couple years.

> End-to-end encryption doesn't stop the operator from decrypting your data.

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.