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.
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 don’t think it is more complicated than, e.g a VPS provider or a SaaS platform and a customer that wants to have run a server online or a managed application.
Of course non-technical users will probably just go for one of the “generic” existing servers, much like most people are fine with using Gmail or outlook addresses. But for those that want to have their own identity, it seems pretty straightforward.
I don’t think it is more complicated than, e.g a VPS provider or a SaaS platform and a customer that wants to have run a server online or a managed application.
That’s a very reasonable comparison, but to me the more relevant comparison is that of creating a commercial social media account or standard fediverse account today. This is much less accessible to users than that process, and also much more demanding on server admins.
I’d certainly be overjoyed to learn that I’m wrong and for this to revolutionize account mobility. But I don’t see volunteer server admins lining up to facilitate DNS delegation for fun or users lining up to pay VPS prices for commercial hosting of their own social media domain. The bar for simplicity and usability for me is quite a lot higher than I see this sort of approach evolving to provide.
Well, I’m firmly in the camp that believes we’ll need to professionalize hosting in the fediverse, and one of the reasons that I am looking into takahe is because it would be nice to have a way to scale my managed hosting offering, possibly being able to make it cheaper for people who do not want a full-blown instance but would like to have their own domain.
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.
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 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.
Add comment