FEP-a427: Server Domain Move
ActivityPub Protocol
9
Posts
4
Posters
0
Views
-
This FEP defines a best-effort protocol for migrating an entire ActivityPub server from one domain to another when the operator controls both domains and can keep the old domain online.
Appreciate any feedback, thanks!
-
This FEP defines a best-effort protocol for migrating an entire ActivityPub server from one domain to another when the operator controls both domains and can keep the old domain online.
Appreciate any feedback, thanks!
The mapping rules outlined seem good in theory, but are not expressive enough in practice.
There are three migration paths when migrating to a new domain:
- Keep software + db
- Domain changes, no path changes
- Keep software + db, change subfolder (e.g.
/to/forum)- All routes change, prefix rule applies
- Migrate software
- All routes change, none of the available rules are expressive enough
It's possible that one could change software, migrate data, and all identifiers remain the same.
Realistically this never happens.
Realistically what happens is a reverse proxy mapping is put into place so requests to the old path under the new domain redirect to the new URL. In this scenario, there is no regular expression that will fully capture this.
e.g.
/t/274884/some-topic-slugto/topic/274880/some-topic-slug - Keep software + db
-
Thanks, this breakdown makes sense.
I agree that changing software while preserving everything is a much more complicated scenario. Once the software changes, routes and identifiers usually change in ways that cannot be captured cleanly by simple mapping rules. This spec is not trying to solve that problem.
The first two cases likely cover 95 percent of real migrations. Keeping the same software and database, with either no path change or just a prefix change, is predictable and rule based. That seems like the right scope for what we are building here.
I can clarify in the spec that full software migrations are out of scope.
-
This FEP defines a best-effort protocol for migrating an entire ActivityPub server from one domain to another when the operator controls both domains and can keep the old domain online.
Appreciate any feedback, thanks!
Have you looked into the migration spec that @jonny@neuromatch.social put together a couple months back?
It was regarding content migrations between servers, but one could adopt the same for switching domains (although I think Jonny's is scoped to the user level, not at the instance level like yours)
-
No, I have not seen it. I was actually trying to find an existing spec before starting this one. Is it one of the FEPs?
-
@julian
This one: https://codeberg.org/fediverse/fep/src/branch/main/fep/1580/fep-1580.mdThis was basically exactly what I had in mind actually, it would work equally well for whole instance moves (whether the source instance is still active or not). Using redirects from the old domain for objects is not really feasible for a bunch of reasons that come into play in core cases in which a domain migration would be necessary. Being able to migrate arbitrary objects resolves actor, instance, and object moves with a single mechanism. Predetermining IDs would be incompatible many AP implementations with and constrain the form IDs take. Re: the privacy note at the bottom, you don't need to publish actor lists either if you put the move object on the actor - the instance only needs to know the actors that the instance already knows about
After drafting and discussing for awhile I came to the conclusion that migrations sort of have to be driven by the target instance, with the source instance's role just being issuing a signed migration object so the implementation can be as simple as possible for the source and it can be retired as quickly as possible. most of the time migrations are forced by some duress at the source, and also are likely to involve an old/out of date instances. Maintaining mappings from the source instance is fragile and inevitably prone to hijacking.
-
@julian
This one: https://codeberg.org/fediverse/fep/src/branch/main/fep/1580/fep-1580.mdThis was basically exactly what I had in mind actually, it would work equally well for whole instance moves (whether the source instance is still active or not). Using redirects from the old domain for objects is not really feasible for a bunch of reasons that come into play in core cases in which a domain migration would be necessary. Being able to migrate arbitrary objects resolves actor, instance, and object moves with a single mechanism. Predetermining IDs would be incompatible many AP implementations with and constrain the form IDs take. Re: the privacy note at the bottom, you don't need to publish actor lists either if you put the move object on the actor - the instance only needs to know the actors that the instance already knows about
After drafting and discussing for awhile I came to the conclusion that migrations sort of have to be driven by the target instance, with the source instance's role just being issuing a signed migration object so the implementation can be as simple as possible for the source and it can be retired as quickly as possible. most of the time migrations are forced by some duress at the source, and also are likely to involve an old/out of date instances. Maintaining mappings from the source instance is fragile and inevitably prone to hijacking.
@julian
Its also a bit of a political question: who should be in charge? I tend to favor decentering instances in favor of empowering actors. So yes instances exist and need to change domains, but imo that would be best served by decoupling actors from instances and thereby domain changes, so an instance changing domains works just as well as an actor moving domains. -
No, I have not seen it. I was actually trying to find an existing spec before starting this one. Is it one of the FEPs?
See my reply in another thread:
https://socialhub.activitypub.rocks/t/fep-7628-move-actor/3583/33
-
No, I have not seen it. I was actually trying to find an existing spec before starting this one. Is it one of the FEPs?
Ugh, Discourse is not receiving the whole thread. Please take a look at @jonny@neuromatch.social's replies on ActivityPub.Space
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
Ugh, Discourse is not receiving the whole thread. Please take a look at @jonny@neuromatch.social's replies on ActivityPub.Space
-
See my reply in another thread:
https://socialhub.activitypub.rocks/t/fep-7628-move-actor/3583/33
-
@julian
Its also a bit of a political question: who should be in charge? I tend to favor decentering instances in favor of empowering actors. So yes instances exist and need to change domains, but imo that would be best served by decoupling actors from instances and thereby domain changes, so an instance changing domains works just as well as an actor moving domains.
-
@julian
This one: https://codeberg.org/fediverse/fep/src/branch/main/fep/1580/fep-1580.mdThis was basically exactly what I had in mind actually, it would work equally well for whole instance moves (whether the source instance is still active or not). Using redirects from the old domain for objects is not really feasible for a bunch of reasons that come into play in core cases in which a domain migration would be necessary. Being able to migrate arbitrary objects resolves actor, instance, and object moves with a single mechanism. Predetermining IDs would be incompatible many AP implementations with and constrain the form IDs take. Re: the privacy note at the bottom, you don't need to publish actor lists either if you put the move object on the actor - the instance only needs to know the actors that the instance already knows about
After drafting and discussing for awhile I came to the conclusion that migrations sort of have to be driven by the target instance, with the source instance's role just being issuing a signed migration object so the implementation can be as simple as possible for the source and it can be retired as quickly as possible. most of the time migrations are forced by some duress at the source, and also are likely to involve an old/out of date instances. Maintaining mappings from the source instance is fragile and inevitably prone to hijacking.
-
No, I have not seen it. I was actually trying to find an existing spec before starting this one. Is it one of the FEPs?
-
Have you looked into the migration spec that @jonny@neuromatch.social put together a couple months back?
It was regarding content migrations between servers, but one could adopt the same for switching domains (although I think Jonny's is scoped to the user level, not at the instance level like yours)
-
Thanks, this breakdown makes sense.
I agree that changing software while preserving everything is a much more complicated scenario. Once the software changes, routes and identifiers usually change in ways that cannot be captured cleanly by simple mapping rules. This spec is not trying to solve that problem.
The first two cases likely cover 95 percent of real migrations. Keeping the same software and database, with either no path change or just a prefix change, is predictable and rule based. That seems like the right scope for what we are building here.
I can clarify in the spec that full software migrations are out of scope.
-
The mapping rules outlined seem good in theory, but are not expressive enough in practice.
There are three migration paths when migrating to a new domain:
Keep software + db Domain changes, no path changes Keep software + db, change subfolder (e.g. / to /forum) All routes change, prefix rule applies Migrate software All routes change, none of the available rules are expressive enoughIt's possible that one could change software, migrate data, and all identifiers remain the same.
Realistically this never happens.
Realistically what happens is a reverse proxy mapping is put into place so requests to the old path under the new domain redirect to the new URL. In this scenario, there is no regular expression that will fully capture this.
e.g. /t/274884/some-topic-slug to /topic/274880/some-topic-slug
