solution proposal to the domain-change problem (FMHY situation)

[tekakutli]

Requirements

• Is this a feature request? For questions or discussions use https://lemmy.ml/c/lemmy_support
• Did you check to see if this issue already exists?
• Is this only a feature request? Do not put multiple feature requests in one issue.
• Is this a backend issue? Use the lemmy-ui repo for UI / frontend issues.

Is your proposal related to a problem?

the problem is being dependent on domain-register shenanigans

Describe the solution you'd like.

using an overlay-network like yggdrasil to peer

for instance-instance communication, using their addresses as domain names, may be a quick fix without having to change the paradigm (while remaining compatible with the normal way)

so that the accounts are associated with that Yggdrasil address, instead of a domain
plus, once inside such a system, no need to migrate accounts anymore, ever
never dependent on a domain again

Describe alternatives you've considered.

I like the yggdrasil approach above other meshnets

Additional context

Hypothetical roadmap:
they have IRC,forums, torrents running on top Yggdrasil, my understanding is that the software(lemmy) would need NO changes
bundling yggdrasil with the lemmy container would be all that is required for a new lemmy instance to spawn on top of it's mesh-net and experiment with it

and if it works then figure out a way for instances to migrate the accounts

[asimons04]

I can see several problems with this:

Yggdrasil requires IPv6 to function. Docker is the primary way Lemmy is distributed/deployed and disables IPv6 by default, but there are a couple of ways to enable it either globally on or a per-container basis. That's not the problem, though.

If Yggdrasil is bundled into the Lemmy container, and IPv6 support is enabled, then that is going to cause problems when hosting from an IPv4-only connection (not uncommon, sadly) If a remote Lemmy instance resolves to both an A and AAAA record, connecting the resolved public IPv6 address will fail on an IPv4 only internet connection. This would break existing federation or cause intermittent issues at the least (I've seen this happen when enabling IPv6 for other projects in Docker on my IPv4-only WAN connection). The instance admin would have to setup an IPv6 tunnel such as with Hurricane Electric to avoid this.

The other problem I can see is that the Yggdrasil identifiers would replace the domain used in the actor ID; this is basically the crux of your solution. That would break federation with other ActivityPub platforms like Kbin, Mastadon, et al that aren't using Yggdrasil (assuming this change was incorporated into Lemmy).

Because of the way actor IDs are defined in ActivitiyPub, you can't operate both on a regular domain and Yggdrasil; they'd be two different accounts: [email protected] and bob@{Yggdrasil-identifier}.

It's an interesting idea, but I just don't see how it's a practical solution unless you were wanting to run an isolated / separate Fediverse that only exists on Yggdrasil. The same problem with federation exists and is mentioned in the official docs for running as a Tor hidden service

For ActivityPub, the W3C expects the domain to be stable, and I do not think it's an unreasonable expectation. What happened with the .ml domain shouldn't be surprising, and admins should definitely be more careful with their selections.

A more practical solution, IMO, would be to work on adding the ability to transfer communities/accounts to new instances. This would cover multiple scenarios, including losing control of a domain. A mechanism like this would also be required in your proposal, so why not just focus on this part?

[trymeouteh]

If a instance goes down for awhile due to domain seizure or hosting was cut off but the instance does go back online and did not lose any of its data and has a different domain name, I think there needs to be a way to update the other instances domain name.

You can still access FMHY communities and posts from other instances that federate with the FMHY instance even though FMHY instance is down. Once FMHY instance gets back online under what I will assume will be lemmy.fmhy.net, all the other instances like lemmy.world will need to change the domain name of the FMHY instance on their end somehow.

[nullish-cat]

Hey there, admin on the FMHY instance. We just ended up making a new instance on lemmy.fmhy.net like what @trymeouteh mentioned. We're not officially up since we're taking the opportunity to fix the image problems we've been having and transferring to a better server, but other than that, we're operational.

I think the best course of action is the adoption of a proper migration process. (And to be honest, this is already mentioned by @asimons04 and I didn't notice until I wrote the whole paragraph whoops sorry lol.) Right now we have a script to migrate posts, which basically just fetches posts from lemmy.world and copies them to the new instance. It's primitive but at least functional. What could be possible is importing an old database and copying data over to the new one. I'm not knowledgeable on the specifics of ActivityPub, but if it's just copying all the posts and communities over to new ones, assuming we limit it to local activity, it should function like brand new. At the very least, this should 100% be possible for user data.

In case practicability is needed, this is already asked for in #2018 and #3729. This would also make #506 and #3040 unnecessary for lost instances. I also would not trust lemmy.ml or any other instances on .ml to be lasting much longer.

Also, now that I mentioned it, I should at least comment on it. Domains being taken away or changed is uncommon but certainly possible. This is especially true for use cases like FMHY and a way to change hostname still has some merit. Entire TLDs exploding over night is not common.

[AppleSheeple]

Using a Mesh net would be overkill anyway, no?

A name system problem only requires a name system solution, à la GNS!

[Nutomic]

We are not going to switch to a different protocol, thats completely out of scope.