I have thought about federated social media for some time and a pain point I see people running into is their home server closing down and having to make new accounts elsewhere, losing access to data such as their saved items, their comments, their subscriptions etc.
I get the feeling this kind of breaks the decentralized spirit of the platforms because people get tired of this and likely tend toward the larger instances because they are “safe” and don’t appear to be going anywhere any time soon.
I think it would be interesting if user objects were abstracted from “permanent” home servers. While this of course goes against part of the spirit as well in that a home server is a kind of place where you get to experience a local, smaller community - I think it would be interesting if there were a federated platform which functioned as follows.
-
Instance owners set a number of user accounts they want to host, and a threshold of the amount of data they want to store. You continue to leave in their control the ability to restrict sign-ups etc as normal.
-
When a user account is created, a default home server is suggested or assigned to them based on the decentralized network health - it would be optimal to assign new users to smaller home servers that have room for users to better how decentralized the platform is - the algorithm responsible for this would take into account the number of available slots for users instances have, how much storage they have remaining for user data, and how many users there are on the instance total (how to handle this in regards to if that server is defederated/defederates with other servers is not something I have a reasonable solution to at this time).
-
When a platform instance decides to close down, the user accounts are distributed equally to the remaining instances that make up the platform in a migration, again, accounting for the platforms decentralization health. Optimally the user would receive a notification of the change, receiving a suggestion for a new server, but would be otherwise unaffected.
-
Make it optional for a user to change on which instance their account data gets hosted - if they do not like the home server they were initially assigned, allow them to queue a migration of their account and data. Some users would do this but I suspect many would not see a need to, which would in theory better the health. In either instance, it would make it easier to manage.
I understand instances being intended to be topic based, but I really think it would be interesting to have a platform where the scope of the instance ends at hosting and performing this “load balancing”, and the topics are controlled purely by the federated communities.
By abstracting the user account data in this way or something similar, I think it would be overall better for the health of the decentralization and it would also remove one of the larger pain points experienced by new users.
Of course there would be a lot more to consider in building such a system. You would need pseudo-usernames which are actually GUID’s or some such on the back end in case an account with the same name already exists on the server accepting migration. You would need to propagate the accounts instance host to previous comments and posts etc the users have made that have been federated to other servers to try to avoid link rot.
Nonetheless, I just wanted to throw the concept out there to see if there is such a thing, or if there are any other clear pitfalls or problems with a hypothetical platform like this.
This is the one thing I really think Fediverse needs. I shouldn’t have to have a separate identity for each of Lemmy/Mastodon/Pixelfed/Mbin/Piefed/blahblahblah. In theory, ATproto has the PDS which holds your identity and posts and you can host independent from the rest of the platform. In practice, shenanigans on Bluesky over the last few days are showing that even with Blacksky, they are still centrally dependent on the main instance. There’s been quite a few Bsky users picking up on Mastodon, either new accounts or reviving old ones.