Comment by fc417fc802
25 days ago
Yeah it's a fair point that the spec as written doesn't preculde handling domains in a more sensible manner. But in practice it's a headache. 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. Maybe things have improved since the last time I encountered that? I doubt it though.
> Account migration on the fediverse is a thing
Has something changed within the past year or so? Because if you're referring to the mechanism where a notification is sent out that A@X has moved to B@Y I hardly consider that to qualify. Proper account migration would mean moving the account itself, not automated assistance coordinating the person behind an account switching from one to the other.
> 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.