> Identities should be URIs (a la IndieWeb). IMO WebFinger was a bad idea for ActivityPub in the first place (and it's not in the spec).
ActivityPub only deals with URIs. Including in Mastodon. Mastodon then layers WebFinger on top, but you can still give Mastodon the actor URI and it works just fine, and all underlying interactions use the actor URIs. E.g. follows are between actors by URI, not between webfinger IDs. If you want to pretend Webfinger isn't involved, you can choose to do so.
> It makes it a lot more hacky to statically host your profile, and the indirection is confusing. As far as I know the presupposition that users would find URIs as IDs confusing is just an assumption that was made early on.
I wish WebFinger specified a URI format that made it possible to do fully statically without breaking the spec -, but the minimal "implementation" using an otherwise static file takes a URL rewrite with a single small regexp. It's not an issue for anyone who understands what's going on well enough to need/want to decouple their webfinger response from their ActivityPub actor. If you just want to point at an instance you can just do a static redirect.
However, that is mostly orthogonal to the portability issue.
> Or just eschew this complexity entirely and use URIs as IDs. Make permanent personal domains much easier to buy and use.
Then you've traded one kind of complexity that provides decentralization as an option, for a massively larger complexity problem that involves navigating a lot of government bodies, a highly self-interested bureaucracy, and a number of major multinational companies. I co-founded the company that launched ".name" - the bureaucracy may have tapered off a bit, but it's still a nightmare. Reforming that space in any kind of meaningful way that wouldn't leave your identity beholden to an intersection of centralized government and corporate interests in not likely to happen anytime over the next decade or three.
The portability matters to some of us. It just doesn't require ditching ActivityPub. And it doesn't require all that much complexity - all it requires is to allow DIDs to be used as an alternative means to identify or update the actor URL in a relationship. You can keep backwards compatibility by allowing resolved actor URLs to keep working, and just add a signed reference to the DID in the profile and the webfinger response. Then clients and servers that supports it can use the DIDs to allow discovering a moved profile, while clients and servers that don't support it will behave just as before (work as long as the actor URL works; fail if it stops working without a preceding move).
Because of federation, it's even fairly trivial to sort out a simple DID method that needs no central authority: Spread the DID document to all the instances you have followers on, and allow rediscovery by pinging those servers from a new instance with a request to use the keys to validate an updated DID document at a provided new instance. Let every instance act as a first resort to bootstrap recovery, and every instance you interact with act as fallbacks to help you recover control, as long as your clients keep backups of the relevant private keys.
And if you include those DID references in the profile as well, then just as now you can choose to ignore webfinger if you prefer.
Yes, this will take time to get right, but some variant of proper portability is just a question of time.