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.
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.
Not really. Most centralized services are accessible via multiple domains, e.g. for different countries. This would just disable one of them, but users could still use another to log into their accounts. For the Fediverse it “disables” an entire instance, cuts it off from federation and locks out users.
Lets not put a positive spin on a situation that exposes a weakness of the current system. The federation protocol needs to be able to handle these things gracefully, like propagating domain changes and migrating accounts between instances!
I’m now wondering what happens if the Mali government (or someone else) begins using those domains with their own lemmy instance, potentially with malicious content.
Would the instances they’ve federated with begin ingesting and serving that content automatically? Or would that be blocked due to key mismatch?
Afaik it is all connected to the domain name, so they could definitely start to impersonate any .ml instance. Other instances could detect that the signing key for federation messages changed, but that’s about it. Their admins would probably have to block/defederate them manually.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: [email protected]
A community to talk about the Fediverse and all it’s related services using ActivityPub (Mastodon, Lemmy, KBin, etc).
If you wanted to get help with moderating your own community then head over to [email protected]!
Rules
Posts must be on topic.
Be respectful of others.
Cite the sources used for graphs and other statistics.
Not really. Most centralized services are accessible via multiple domains, e.g. for different countries. This would just disable one of them, but users could still use another to log into their accounts. For the Fediverse it “disables” an entire instance, cuts it off from federation and locks out users.
Lets not put a positive spin on a situation that exposes a weakness of the current system. The federation protocol needs to be able to handle these things gracefully, like propagating domain changes and migrating accounts between instances!
I’m now wondering what happens if the Mali government (or someone else) begins using those domains with their own lemmy instance, potentially with malicious content.
Would the instances they’ve federated with begin ingesting and serving that content automatically? Or would that be blocked due to key mismatch?
Afaik it is all connected to the domain name, so they could definitely start to impersonate any .ml instance. Other instances could detect that the signing key for federation messages changed, but that’s about it. Their admins would probably have to block/defederate them manually.
I think they need the private key for the https certificate to do that