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.
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.
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.
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.