Decoupling identity from social is a good idea but you can't just migrate the key storage to a single custodian entity. There'd need to be a multiple custodians to ensure the same power imbalances didn't reappear in a different form (e.g. Google owning everyone's logins).

All that is needed is a to create your local identity (e.g. like storing fingerprint biometrics on your laptop) and a clever way to sync between physical devices (e.g. through bluetooth).

We're in this weird situation where people don't want to be responsible for managing their own data/id, but can't trust others to do so for them.

I was toying with an idea/protocol where:

1. You add a TXT/CNAME that points to a trusted "authentication provider".

2. When you try and login to a website that supports the protocol, it checks the DNS record and redirects you to your provider.

3. You then "prove" that you own the domain to the provider - how this is done would be specific to each provider, but one possible method could be by providing a signed message that can be verified vs. a public key stored in a DNS record.

4. The provider redirects you back to the original website with a token.

5. Finally the original website consumes this token by sending it in a request to the provider. The response contains the domain as confirmation of the user's identity.

This approach removes the need for self-hosting as users can point and setup their names with third party providers.

Users can also trivially switch to a different/self-hosted provider by changing the CNAME.

Communities could also allow direct registration by hosting their own provider instance and pointing a wildcard subdomain at it: (i.e. *.users.ycombinator.com).

Users could then sign up to said provider using traditional email/password and claim a single subdomain: (i.e. tlonny.users.ycombinator.com)

Thoughts?

Though what you described is just a regular federated identity workflow, except autodiscovery through DNS (though that is already a thing for some)