← Back to context

Comment by danpalmer

4 days ago

The answer to big platforms enshittifying is not to move to smaller versions of the same thing. This didn't work for GitHub -> Codeberg/Sourcehut, it didn't work for Twitter -> Mastodon. Because the problem is not necessarily the size, it's the power. Codeberg is exerting power beyond what it should and users have little recourse and get caught up in the issues, some Mastodon servers are fine but there have been plenty of admins who had the power go to their heads or had fallings out with other parts of the network, and again it's the users who get caught up in it.

The answer is building systems that prevent that power trip from ever happening. This is why Bluesky is a better answer to Twitter than Mastodon – the company has its faults, but the approach is a fundamental step forward that Mastodon did not take. The same thing is true of things like Tangled for a software forge. It's no surprise that both of these are based on ATProto, although I'm not saying ATProto is the only option here.

> it didn't work for Twitter -> Mastodon

you mean Twitter -> Bluesky?

Mastodon seems to work as intended

  • No this is my point, Mastodon doesn't solve this problem in the general case. The shift to Mastodon did not solve the problem of social network admins with too much power, because of the lock-in to instances. Most instances are fine, but there have been many that have caused their users a lot of difficulty, and users fundamentally don't own their data.

    The way most users use Bluesky is no different, but the protocol is different, and it is possible to not fall afoul of these issues – data is portable, you can choose your moderation, UI, algorithms, etc, all separately rather than being forced to take a whole package and lose control.

    See Blacksky for a completely separate stack, governed separately, that is still fully compatible. That's not possible with Mastodon or even ActivityPub.

How does Bluesky or ATProto prevent that power trip?

  • I'm not going to do the protocol justice in an HN comment, but a core goal is to separate the entities that control the data, the entities that run the network, and the entities that control the interfaces (and recommendation algos etc).

    If your Mastodon admin goes rogue, you a) have to get your data out of their hands, and b) have to rebuild your Mastodon presence in a new location, all your connections, history, etc are gone. That's exactly the same problem that Twitter users faced.

    On ATProto, you can self-host your data while still making use of Bluesky/etc, in a way that you can't do with Mastodon or even email. You can choose who your UI comes from and just switch UI and keep everything, you can switch who your moderators are and keep everything else, etc.

    Check out Blacksky, they're doing amazing work running a whole separate ATProto system that is fully compatible with, and actually the same social network as Bluesky. You can transparently migrate, at a protocol level, something Mastodon/ActivityPub doesn't attempt to tackle.

    • My understanding of ATProto is that it essentially means an open database. As a consequence anybody can write an alternative interfaces for any data.

      The argument is that with ActivityPub does not care about that aspect. With Mastodon, the database is under the control of whoever owns the server.

      The rebuilding part is rather similar, but exporting the data is trivial with ATProto but depends on the admin with ActivityPub.

    • But if you are going to self-host, then you can also self-host a Mastodon server and never have to migrate anywhere; wouldn't that achieve the same effect?

      2 replies →