Comment by grishka
1 month ago
> Spin up a VPS, create A@X, send out some messages, nuke the VPS, spin up a new VPS and create a new A@X, send out some more messages, and check how well remote instances handle the situation.
If you do it in a rapid succession, then of course it would not work. You have to wait at least a day, and then, when you send something to another server, there's a good chance it would refresh your actor and pick up the new key. You can also force a refresh on a server where you have an account by pasting your self-hosted account's username or URL into the search.
> Proper account migration would mean moving the account itself
There is no such thing as "account itself" as a separate entity in ActivityPub. The URL that points to the actor object JSON, aka the ID, is your account, and that includes the domain. There are no higher-level identities.
Exactly my point. Account migration simply isn't supported. Not in any practical sense.
> there's a good chance it would refresh your actor and pick up the new key.
And how will this be displayed to users of remote instances? Last I checked it was a confusing mess on most implementations (ie every one I have experience with) and the mess would persist indefinitely without manual intervention in the db by a given remote admin.
In the event a domain has changed hands then even with remote intervention no truly satisfactory outcome is possible. This is due to, as you rightly point out, there being no higher level identities. The domain is a fundamental part of the account as modeled by AP which makes conflicts a serious problem.