This is actually something that I’ve been thinking about Lemmy too. Now Lemmy.World is a good instance, but if I ever need to move, I’ll lose a lot, and that’s not what Lemmy and the Fediverse as a whole should stand for. We need to allow users to migrate to another instance as a whole. Not just the name, but the messages, posts, replies, everything should be repointed to the new user.
Of course, this brings new and interesting attack vectors on instances for DSoS and for users data. Identity theft would be a real bitch.
Erin is great. I recommend following them on mastodon if you in there.
Really glad they wrote this piece. I migrated once and it really is disruptive despite how much of it works and is possible. As Erin highlights, there’s a lot that accumulates with your account on social media, especially mastodon where things designed to be more personal.
Generally, these issues highlight how much the fediverse lacks in terms of making things better for users. Arguably, the fediverse doesn’t care about users at all, it cares about servers/instances, and us users are literally just numbers.
And, as Erin says, there’s a kinglong road of prototyping from here onwards. With BlueSky, provided it can work, it seems the general lesson would be to create architectures that aren’t flat like the fediverse (where all instances are more or less the same) and instead have multiple roles and services that interact. We might all, for example, run our accounts out of effectively single-user instances, but then connect to communities hosted on dedicated servers and then use separate again search engines and moderstors and feed aggregators etc with maybe something like DNS can help keep everything together.
This is a big part on why I think self hosting is the way to go with federated platforms. At least I probably shouldn’t ever have an issue with the admins/moderators at lemmy.teuto.icu. Being able to just point the domain name somewhere else should make migrating as simple as spinning up a new container too.
I’m looking into Takahe and it seems that it’s getting very close to solve this. With takahe, you can use the same instance to serve multiple domains. So you could signup to a Takahe instance and bring your own identity. If you are not happy with the server, you just move to a different service and get your domain to point to the new server.
Hmmm. Interesting. Not sure I follow how serving multiple domains gets you a mobile/nomadic identity?
Are you saying that multiple single-user instances can be run out of a single takahe server?
Are you saying that multiple single-user instances can be run out of a single takahe server?
Yeah, but they don’t even have to be “single-user”. You can set up a domain with multiple identities.
If you are not happy with the server, you just move to a different service and get your domain to point to the new server.
I’m just learning about takahe now, but it very much looks like domains are the remit of server admins, not users. Setting up a domain appears to require admin-privileges on the computer running takahe, not something that an individual user or non-admin group of users can do. So it seems to me that takahe doesn’t facilitate users controlling domains and improving mobility of domains between different servers controlled by different admins, but rather appears to be a tool for a given admin-team to segment their users and move them around among the group of servers they control.
I could very much be missing something here, this doesn’t seem to be a scalable approach to server mobility or a way to extricate yourself from an admin team you’re in conflict with.
Setting up a domain appears to require admin-privileges on the computer running takahe
A takahe admin can not take the identity hostage. An admin can add any domain, but if that domain does not respond to the webfinger query pointing to the actual underlying domain, it will never matter. So at the end of the day what matter is how that domain responds to a webfinger query.
Fair enough. The level of close coordination required between takahe server admins and domain owners seems to make domain migration at-scale somewhere between very expensive and simply prohibitive relative to self-service account sign up though. And I’m not sure I see a clear path to resolving that issue, though it’s certainly an interesting project even if it can’t deliver domain mobility at scale.
I vibe with the daydreaming part. Here’s hoping that day dream becomes a reality.
