Starting your own instance doesn’t solve the problem of big communities being reliant on the one specific instance they are hosted on to not go down or rogue.

I imagine it like friend requests between communities: [email protected], [email protected] and [email protected] could send each other friend requests and merge into one federated meta-community about x. Then if one instance goes down the other two are still there to keep the meta-community alive, and if one goes rogue the others can just unfriend and keep going without it.

The nice thing about manual federation is that the communities don’t have to have exactly the same name, and the mods can keep malicious or troll communities out. And ofc you could still have client-side control if you want to, e.g. add or remove a community just for you locally, or create your own local meta-community.

The database, storage and network are usually the bottlenecks in these kinds of websites, not the programming language. It might add a few ms of latency, but the big lags come from congestion or bad db queries.

What comment?

I’ve literally never seen anyone say this except FediPacters as a strawman.

I’ve seen that quite a few times already, mostly in the form of “it’s stupid to preemptively defederate, we can always defederate later”.

A domain takedown was never able to shut a server down, not even with centralized servers. Most big services are accessible via multiple domains of different countries, and this would just disable one of them. But for the Fediverse that means that they also “disabled” an entire instance with all its users.

This actually shows us that relying on domains can be a problem for the Fediverse! Imo we need to upgrade the federation protocol to be able to handle these things, like propagating a domain change or migrating accounts to other instances.

That’s why picking the right instances is important, to make sure it’s not some random person in their basement. Read the about pages of the instances, see what they publish about their operations. The people behind the .world instances regularly blog about what they are doing, spending and earning for example. Some are even run by non-profits. I personally feel much better with those kinds of people running a service I rely on, instead of a company that talks to me only through their marketing department and first and foremost wants to maximize profits.

But that’s also exactly my point. You should be able to transfer your account to another instance, so you’re not stuck if the one you picked turns out to be bad or has to be shut down.

Fix is on the way: https://github.com/dessalines/jerboa/issues/1021

Remember that this is how every service you sign up for works. What’s special about Fediverse services is that they synchronize posts between the instances, other than that they work like any other website or app.

Remove yes but not transition it to a new instance

I don’t see how this is worse than completely removing or taking over your account.

If it’s easy to migrate an account then it would be possible for an admin of a rogue instance or even just a rogue admin of a perfectly fine instance to take your account.

This is the case right now. Admins of your instance have full control over your account. They can remove it or lock you out at any point if they want to.

The author of this blog post just realized that things posted publicly on the internet are indeed public, and that Ctrl+C and Ctrl+V exist.

This is not some special property of the Fediverse, it’s how the internet has always worked. If you post something publicly (say on your personal blog) then others can see it, make copies and redistribute them, even if you later decide to delete the original content. Companies like Google build massive indexes of everything posted by anyone ever, and there is nothing you can do about it if you want your content to be publicly accessible. If you share something with just a group of people, and someone decides to make it public, then it’s public. Nothing new about that.

The GDPR works in exactly the same way in the Fediverse as with the existing services right now. If you want something deleted you have to send a notice to every service that has your content. In reality you’ll just send it to the X biggest services, because they represent 99% of the users that could potentially see that content, and that’s usually enough. You can do the same with the X most popular Fediverse instances. Even better, we might be able to create a standardized and automated process for it, because they all run the same set of Fediverse apps using ActivityPub after all.

Afaik DMs work just like unencrypted (so regular!) emails. If you send your company secrets to [email protected] then you’re probably screwed, same thing with @[email protected].

The more the merrier for the Fediverse

In principal yes, but not at any cost!

Keep in mind that the Fediverse is also a distributed governance model, and it can be seriously harmed if one bad actor gets too much leverage. Meta’s business model is to control as much of the users and content as possible, which runs counter to the idea of the Fediverse. They want to use it to bootstrap their new app, but they’ll try to superseed it as soon as they have enough leverage to do so.

I think being able to migrate your identity from one instance to another is a core requirement to fulfilling the promises of federation. The idea is to be able to freely leave a bad instance, but all you can do now is completely start over on a new instance, losing all your posts and followers. That’s way worse, and not how it should be imo. No big instance has gone rogue yet afaik, but as soon as one does this will be a major issue!

To really accomplish that we would have to create a mechanism for a user to own their own identity, e.g. in form of some sort of secret key file. This would introduce a huge number of usability issues though! Handling key files is really hard, so that’s probably not an option in the near future.

What we definitely should add is some sort of instance single-sign-on, so you can log into another instance by having your original instance authorize the login attempt. This should then allow the new instance to use your original account (for subs and posts), and also migrate that account to the new instance (update handle on all your posts, migrate your followers, …). This would be a bit worse than owning your identity, because your original instance could just refuse to authorize any SSO attempts, but it would still be a big improvement imo.

Maybe we can also just combine the two, so instance SSO and being able to download an identity key as backup.

I think the most confusing bit is that there are multiple versions of the same “subreddit”, so communities with the same name on different instances. Right now its especially annoying, because we don’t know yet which of them will become the most popular. We need some way to combine those communities into one, preferably on the instance level so users mostly only see one entry per topic.