Changing the domain of an existing instance

It occurs to me that once an instance is federating, and especially if follow relationships are established, that renaming an instance (e.g. changing domain names, etc.) is not advisable.

Are there any established best practices, or am I destined to lose all of my followers?

Perhaps maybe as:Move for every actor, though that requires that both source and destination instances be live.

3 Likes

Probably the latter, as this is a Hard Problem. I think the “state of the art” is to have a long-lived domain name which redirects to the current location — see also the PURL concept. Bluesky/ATProto gets around this by having a centralized nameserver, the “placeholder server” that assigns and resolves did:placeholder DIDs. Essentially you will need some stable authority for naming things.

1 Like

@julian FEP-ef61 makes everything domain-independent, including posts.

as:Move will only move followers, but it can work when source is offline too (FEP-7628 pull mode).

@julian FEP-ef61 makes everything domain-independent, including posts.

as:Move will only move followers, but it can work when source is offline too (FEP-7628 pull mode).

@silverpill@mitra.social will have to read through, thanks!

Hoping this doesn't mean I have to refactor my entire note id mechanism to support!

Step in the right direction though.

1 Like

@julian For FEP-ef61 you will likely need to refactor much more than ID generation. This can be done (@mikedev and I did it), and might even be worth the effort, because this FEP not only solves the problem you've described, but also takes ActivityPub to the whole new level.

@julian For FEP-ef61 you will likely need to refactor much more than ID generation. This can be done (@mikedev and I did it), and might even be worth the effort, because this FEP not only solves the problem you've described, but also takes ActivityPub to the whole new level.