Use ID instead of username in ActivityPub API #10556

New Issue

GiteaMirror · 2025-11-02T09:11:12-06:00

GiteaMirror commented

2025-11-02 09:11:12 -06:00

Originally created by @trwnh on GitHub (Mar 29, 2023).

Feature Description

In #19133 a basic ActivityPub API was added to the router, allowing lookup of an actor document and POSTing to inbox. However, the API as present in Swagger currently depends on the username, which means that username changes are not possible without causing breakages in federation. This should be fixed before federation is ready. Further rationale is included in https://github.com/go-gitea/gitea/pull/19133#discussion_r1050995161 and quoted below for convenience:

You can avoid having to issue a Move if you just don't use the username in any ids. Move should be reserved for moving to different domains, not changing usernames. It's completely unnecessary and completely avoidable for local username changes. I heavily recommend using something like snowflake, hash, uuid, etc instead of plain usernames. You want the ActivityPub id to be as stable as possible and ideally never change.

Screenshots

Relevant code:

3e8db31a5b/routers/api/v1/activitypub/person.go (L20-L36)

I believe this should be ctx.ContextUser.ID or something similar.

Originally created by @trwnh on GitHub (Mar 29, 2023). ### Feature Description In #19133 a basic ActivityPub API was added to the router, allowing lookup of an actor document and POSTing to inbox. However, the API as present in Swagger currently depends on the username, which means that username changes are not possible without causing breakages in federation. This should be fixed before federation is ready. Further rationale is included in https://github.com/go-gitea/gitea/pull/19133#discussion_r1050995161 and quoted below for convenience: > You can avoid having to issue a Move if you just don't use the username in any ids. Move should be reserved for moving to different domains, not changing usernames. It's completely unnecessary and completely avoidable for local username changes. I heavily recommend using something like snowflake, hash, uuid, etc instead of plain usernames. You want the ActivityPub id to be as stable as possible and ideally never change. ### Screenshots Relevant code: https://github.com/go-gitea/gitea/blob/3e8db31a5b5a7be731b19da4bd666b0ddc35bd31/routers/api/v1/activitypub/person.go#L20-L36 I believe this should be `ctx.ContextUser.ID` or something similar.

GiteaMirror added the type/proposal label 2025-11-02 09:11:12 -06:00

GiteaMirror closed this issue

2025-11-02 09:11:13 -06:00

GiteaMirror commented

2025-11-02 09:11:14 -06:00

@lunny commented on GitHub (Mar 30, 2023):

~~But wouldn't the id be changed in a different system?~~

@lunny commented on GitHub (Mar 30, 2023): ~~But wouldn't the id be changed in a different system?~~

GiteaMirror commented

2025-11-02 09:11:14 -06:00

@trwnh commented on GitHub (Mar 30, 2023):

No, the ActivityPub id is an HTTPS URI that should remain constant. For example, if we have something like https://example.com/userid then the username is free to change without breaking the id. But if we make the id something like https://example.com/username then a change from username to different_username will be seen as a completely different actor. All old comments, repos, etc. will no longer be linked, and all followers will have to be migrated to the "new" account.

@trwnh commented on GitHub (Mar 30, 2023): No, the ActivityPub `id` is an HTTPS URI that should remain constant. For example, if we have something like `https://example.com/userid` then the username is free to change without breaking the `id`. But if we make the `id` something like `https://example.com/username` then a change from `username` to `different_username` will be seen as a completely different actor. All old comments, repos, etc. will no longer be linked, and all followers will have to be migrated to the "new" account.

GiteaMirror commented

2025-11-02 09:11:14 -06:00

@ghost commented on GitHub (Mar 30, 2023):

@trwnh Thanks for the reminder. I'll implement this soon in forgejo-federation.

@ghost commented on GitHub (Mar 30, 2023): @trwnh Thanks for the reminder. I'll implement this soon in `forgejo-federation`.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#10556