OH thank you so much I was missing the point of a lot of these threads, thanks for patiently pointing it out. I agree with
And I agree with you in that same thread that an instance operates as an authority, not as a controller, and that implicit or underspecified in current practice is an assumption of a client/server relationship authorizing that authority. This is convincing me to adopt your suspicion of HTTPS URI being enshrined forever! This could cause real problems for interop with P2P architectures beyond HTTP.
IPFS URIs (or the IPNS URI subset of that URI namespace, or DID URIs) are definitely the upgrade path I was looking to long-term, but I agree that the short-term path requires alignment on relational semantics and buy-in from major implementations, 1000%. So maybe more on that later, since short-term alignment is way more urgent.
As for the alsoKnownAs chaos, I am convinced that the rel=me system makes the most sense for one logical human maintaining multiple accounts over time, which is of course a major usability feature of modern social media anyways independent of migration and tombstoning.
What I would propose for the interrelated problems of migration and tombstoning is something very different and more hierarchical, which is closer to the DID semantic controller, i.e., that identifier HAS AUTHORITY OVER this account/identifier. For example, it could mean:
- this authenticator/signer/private key has been authorized to sign for the subject anywhere its signatures are accepted,
BUT ALSO
- this external identifier/authN mechanism is authorized to authenticate migration requests,
AND
- this external AuthN is authorized to tombstone this account, after migration, or keep it as a
rel=me,
AND (perhaps riskiest for buy-in from today’s implementations)
if this server bans the user and freezes/closes their account, this authority has already been externalized and migration can still happen if records of the authorization can still be verified.
If instances can get OK with that pre-authorization/authority-export which overrides, say, a ban or a boot then maybe AP isn’t locked into the authority of the webserver forever?
Have I understood the most relevant open questions or am I still missing some?