Been thinking about this a bit as well, and I've mostly come to the conclusion that Mastodon doesn't have a robust theory of identity OR culture, and is likely doomed to obscurity. I could be wrong, and your suggestion is one part of a solution - get away from server-centrism, to true individual control of their identity and routing.
Webfinger is super-simple, and would be easy for all e-mail hosting providers to give away with their services. Better would be a cryptographic signature for an identity, and follows/permissions can be transparently moved with that key. With DNS used as the temporary resolution to that UID, so you can change e-mail addresses or domains (or have multiple active simultaneously) without changing identity. Full blockchain would be overkill, but decoupling the follow/friend relationships from server name would be a great thing.
Or maybe I'm overthinking it. The right answer might be just for everyone to use the server that corresponds to their e-mail address. If Google, Microsoft, AOL, and Yahoo provide this, everyone else will just about have to.
All this assumes that the schizophrenic foundation of Mastodon (servers have culture and norm-enforcement, but also federate to servers with FAR different expectations) gets resolved somehow. When the first big server with lots of heavily-federated posters starts allowing spam or ads, it's going to be an unpleasant discussion on EVERY smaller server whether to block them. I suspect that'll be the end of this concept, as everyone realizes that it's pretty much a reinvention of Usenet.
edit: your proposal (followers use the canonical/webfinger address, and cache the routing address for performance reasons) is a worthwhile, simple improvement. Regardless of long-term viability, this would make Mastodon more portable and useful.
I'm pretty certain that mastodon knows that is the wrong thing, it's just a low-energy project. The author of the underlying protocol, ActivityPub, is brilliant, though, and she's been working on foundational stuff for a new set of protocols, spritely, oriented around capabilities, distributed transactions and racket. Judging from her promotion of the petname system I'm guessing she's going to think of just making user IDs content-hashes to an object with a public key and an update rule for account recovery. IIRC a content-addressed distributed storage system was proposed for spritely at some point.
Yip, came to the same conclusion pretty quickly after setting up the webfinger. It would be great if once you had validated an alias (by use of the .well-known/webfinger) that a mastdodon instance would then allow you to toot? out using that domain.
Still, in the meantime, having your own identifier is a decent start.
When I
joined Mastodon I was
@jefftk@schelling.pt. A few days ago that server had an
incident and I moved to
mastodon.mit.edu, becoming
@jefftk@mastodon.mit.edu. This got me thinking about a
wart in the current Mastodon design: while you can normally move
followers with you if you switch instances, this requires the
cooperation of the instance you're leaving. In this case that
instance couldn't cooperate because its domain name had expired, but I
could also imagine someone having a falling out with their local
admins and getting kicked off in a way that precluded transfer.
Ideally this would be like email: I send and receive email as
jeff@jefftk.com. The actual server I use is
gmail.com, but the people I interact with don't need to
know that. If I ever want to move to a different email server I don't
need Gmail's permission and I don't need to tell my contacts; I can do
it entirely on my end. Similarly jefftk.com currently
points to a Contabo VPS, but if I had an issue with them I could move
anywhere just by adjusting my domain settings.
Current Mastodon is partway there: I
can give out @jeff@jefftk.com, which uses a webfinger file
(thanks, Chris)
to redirect @[anything]@jefftk.com to
@jefftk@mastodon.mit.edu. But then the original address
is forgotten, and it only records that they're following my
mastodon.mit.edu account.
One way for this to work would be that when following someone you store both their current account name and a canonical account name. Almost everything would use the former, but once a day in your instance would check whether the canonical account still pointed to the same place and adjust if necessary.
(For more discussion along these lines see Issue 3796.)