

There is, but the protocol is designed that you can’t buy a domain for a month, set up a server, and then let it expire, leaving it unable to use ActivityPub for decades after because you posted a few things to Mastodon with popular usernames.
There is public/private key authentication, but the server is queried for its current keys when verifying content. This allows lemmy.ml to forward lemmy.dbzer0.com content to any other server without knowing the private key, because the receiving server will call back to the original server (if they key is not already cached) and use the user’s public key to verify the message.
Once the domain expires and a new person buys the domain, that new person is in charge of what keys a domain lists or not. That, combined with the fact blind key rollover is permitted, leaves it up to programmers of individual servers to decide if they accept the new keys or not (the spec says they should).
I don’t see why not. Based on the spec, a server submits a request signed by a keyId which the receiving server caches or obtains, but the new server is also queried for the keys belonging to the actor. You cannot reuse the old key IDs (probably) because it’ll stay in the cache, but you can just add new keys of your own.
Step 10 of the key verification algorithm explicitly instruct the server to ignore the old key and fetch a new one, in case the other server has done a blind key rotation.
In other words, the ActivityPub spec only verifies that an account was the source of a message at the time a server submitted or forwarded an event. It does not validate that an
Update
with new text contents belongs to the same server that onceCreate
d the object.Of course, I expect ActivitiyPub software to (mis)implement this spec in different ways. Some software will be protected against domain hijacking, others will leave domains once registered completely useless in the future for common actor names in ActivityPub.