An update:
- fmhy.ml is gone, due to the ongoing fiasco with mali government taking all their .ml domains back
- As such, lemmy.fmhy.ml is also gone, we are currently exploring ways to refederate (or somehow restart federation entirely) without breaking anything substantial
- We have backups, so don’t worry about data loss (you can view them on other instances anyway)
Currently, we have fmhy.net and are exploring options to somehow migrate, thank you for your patience.
Re-federation is probably possible. BUT! You’re going to always have problems with older content. Case in point my federation error messages is at 2300. About half are failed requests on fmhy.ml.
So for re-federation what’s needed:
1: Remote instances should unsubscribe all users from any fmhy groups. They’re dead now. They can only announce that and hope they do. I reckon when their errors start ramping up (as I saw yesterday) they will be looking into why. Probably to help de-federate from the old URL
2: The fmhy instance should unsubscribe all users from all remote groups but keep a note of the groups while identifying as fmhy.ml. Then once on a configuration for the new domain re-subscribe to each one. The first step should hopefully stop them trying (and failing) to federate new events to the old URL. The second step should trigger federation with the new one.
3: They could be able to keep the DB. But I am not sure in what places the old domain might be stored in the DB and what would need fixing there. Also not sure if they’d need to regenerate keys. Not sure if they’ll see the key was attached to the old domain and refuse to talk to the instance.
Now what’s going to be a problem? Well ALL the existing content out there has references to users on the old domain. It’s VERY hard to fix that. Like every instance would need to fix their database. Not worth it. But, whenever someone likes/unlikes or comments or whatever a post made from fmhy.ml then there’s a good chance a remote instance will queue up a retrieval of:
1: User info about the poster/commentor/liker
2: Missing comments/posts for a like/comment event
And those will fail and error log. I don’t think there’s a way around that aside from editing the whole database on every instance. Again, IMO not worth it.
Would be a nice federation feature if, provided you could identify with the correct private key, announce a domain change which would automatically trigger the above in federated instances, or at the very least some kind of internal redirect for outgoing messages.
If I’m running lemmy.world, I wouldn’t unsubscribe my people. I’d wait for that instance to move to a new domain and just find/replace in the database.
Not every instance needs to migrate fmhy. Some can just leave that stuff broken. If the biggest half dozen instances migrate manually, fmhy would be able to keep most of their subscribers.
I do wonder how often instances will keep looking for fmhy without intervention. Seems like tooling to migrate or discontinue an instance wouldn’t be too difficult to build. At least it wouldn’t if they didn’t have a million other things on their plate.
We could use a few less third party clients and more work on Lemmy itself. Unless you’re going to bring over your userbase like RiF and Apollo can.
Yes, although you might need to fudge keys if they’re properly enforced. Looking at kbin I can see requests are at least signed with the private key. Not sure if the public key is stored somewhere in database, or is pulled from the instance using DNS as a security guarantor (I guess) every time.
I don’t have any subscriptions to them, but I have those 1000+ errors just from posts their users were involved in.
Afaik mastodon has a way for instances to migrate to a new domain, but the old domain must be up during the migration process. Lemmy on the other hand don’t even have any domain migration procedure yet. People will probably go nuts about this on their GitHub issues portal.
Possibly. I think mastadon has been around a bit longer though? Not sure why the old domain must be up. Unless they don’t store public keys of known instances and they rely on DNS for the security.
e.g. Instance A signs a request, Instance B queries Instance A via DNS lookup (as is normal) and checks public key confirms signature and allows it.
I got curious so I start digging into how mastodon do it. It’s more like a hack, really. Mastodon uses WebFinger to resolve user account, so when you change domain, you can leave the old domain up so your federated servers can still resolve your users and realized the domain has been changed and update their federation data. But it turns out you can’t exactly retire the old domain either because it’s still tied to user account internally. So if you lose control of your old domain, you’re probably as screwed as fmhy.ml.
Yeah, which is why I think storing remote user and instance public keys might be better. Then that can be used to authenticate the migration request (it’d probably need to be an extension to the activitypub standard).
The biggest problem I see is that an instance doesn’t know about all the instances that have data pointing to them. So how does it communicate the changes to everyone? The mastadon way is probably the sensible way to do it, despite not supporting the loss of control of domain scenario.