Federated user and repo migrations #9

New Issue

xy · 2022-07-22T15:41:39Z

xy commented

2022-07-22 15:41:39 +00:00

A commonly-requested feature for AP software is to be able to easily switch instances. Although user migrations are not in the AP spec, we can reuse Mastodon's approach of using a Move activity along with setting alsoKnownAs on the target and original actors.

See forgefed@codeberg.org/forgefed#149 for more details. We will also need to submit a PR to ForgeFed documenting this usage of Move.

For repository migrations, we can reuse the existing code and also send out the Move activity and set alsoKnownAs on both actors. We also have to copy over the stars and list of forks. Gitea instances should have a background job to periodically fetch the actors for remote repos, and update them if a migration occurred.

For user migrations, we can now use the repository migration code. Simply go through every repo that the user owns, and migrate it using the process above. The background job should also periodically fetch the actors of remote users and update them as needed. Organization migrations work the exact same as user migrations.

As usual, for both user and repository migrations, Gitea should redirect you to the new location when you try to access the old location.

Also, we need to have a configurable cooldown period in which a username cannot be claimed. One week should be long enough for all the other instances in federation to detect and process a migration.

A commonly-requested feature for AP software is to be able to easily switch instances. Although user migrations are not in the AP spec, we can reuse Mastodon's approach of using a `Move` activity along with setting `alsoKnownAs` on the target and original actors. See [forgefed@codeberg.org/forgefed#149](https://codeberg.org/ForgeFed/ForgeFed/issues/149) for more details. We will also need to submit a PR to ForgeFed documenting this usage of `Move`. For repository migrations, we can reuse the existing code and also send out the `Move` activity and set `alsoKnownAs` on both actors. We also have to copy over the stars and list of forks. Gitea instances should have a background job to periodically fetch the actors for remote repos, and update them if a migration occurred. For user migrations, we can now use the repository migration code. Simply go through every repo that the user owns, and migrate it using the process above. The background job should also periodically fetch the actors of remote users and update them as needed. Organization migrations work the exact same as user migrations. As usual, for both user and repository migrations, Gitea should redirect you to the new location when you try to access the old location. Also, we need to have a configurable cooldown period in which a username cannot be claimed. One week should be long enough for all the other instances in federation to detect and process a migration.

xy changed title from ~~Federated user and repomigrations~~ to Federated user and repo migrations

2022-07-22 15:41:48 +00:00

xy referenced this issue

2022-07-22 15:47:51 +00:00

Gitea federation task list #3

This repo is archived. You cannot comment on issues.

No Label

No Milestone

No project

No Assignees

1 Participants

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: xy/gitea#9