Is Object's `id` immutable?

ActivityPub
1

Hello there,
I’m a Mastodon instance administrator who is interested in server migration (between domains, or even between different AP implementations).

What will happen if the instance serves at one id on its URL with another id on the response?

For example:
(Re)fetch:

GET https://old_domain/old/id HTTP/1.1

Returns: (by proxy or by HTTP 30x redirection)

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "https://new_domain/new/id",
  …
}

Will there be two duplicate objects on the fediverse?

1 Like
2

Hi misaka! Welcome to the SocialHub forum. Right now, the ActivityPub spec doesn’t specify one way or the other whether URIs should be immutable, so implementations may have different behavior in this area. Mastodon, for example, uses Webfinger to uniquely identify actors, so it doesn’t let you change the domain or username of an account after it’s been created, but (in theory!) should allow you to change the URI. Personally, I think implementations should do their best, within reason, to handle mutable @id values, but obviously that adds a lot of additional complexity so it’s understandable that some implementations avoid it.

2 Likes
3

ID is only as immutable as any other URI would be on the Web. URLs can and do change, although this change should be minimized.

In the example given, it would be up to the software to handle the 30x redirect as it sees fit. For example, if it were a permanent redirect, then it might be a good idea to update the ID in any local references to that object. If your software uses a database, then you should be making references to the internal database key, and the ActivityPub ID can just be updated with a simple update query.

3 Likes
4

Are there other implementations interested in respecting 30x redirects for IDs? I’m mostly thinking of actor IDs, as WriteFreely enables users to change their username, but doing so currently means losing all followers on Mastodon, etc. (some discussion here)

1 Like
5

[2020-02-06 22:34:47+0000] Matt Baer via SocialHub:

Are there other implementations interested in respecting 30x redirects for IDs? I’m mostly thinking of actor IDs, as WriteFreely enables users to change their username, but doing so currently means losing all followers on Mastodon, etc. (some discussion here)

Uh I would rather avoid putting support for it tbh, we have ActivityPub activities for it now.

Reason would be that it’s quite abusable (similar to domain squatters just redirecting to garbage) and while pleroma&mastodon refresh the actor from time to time, it shouldn’t be required to do so and 30x redirects only actually works in this kind of case.

6

Seems like, at minimum, platforms could enforce certain rules to avoid abuse, like making sure an actor is still on the same host – e.g. redirecting my.instance/user/oldusername -> my.instance/user/betterusername == OK

Otherwise, how can we do this in a way that Pleroma (and other platforms) would be interested in supporting it?

3 Likes