Ah, thanks. Might you consider going full DHT for name lookup then?
There’s some DHT-based DID methods so it’s possible - one of the nice things about the DID abstraction layer is that could be added.
As I understand, atproto is intentionally limiting to PLC and Web for now, and monitoring the ecosystem. Every method has to be implemented by every client, so you naturally want to be cautious in how many you support.
(I don’t work for or represent Bluesky, so can’t speak to any plans other than what they’ve stated publicly!)
did:web: eg is literally HTTP, did:dns: is DNS, and there’s loads of others.
This extra level of abstraction allows of arbitrary IDs, which is what the PLC DIDs were created for.
Let’s say that I am currently known as rmccue.com.au. I move overseas and now want to be rmccue.scot - or worse, because I am no longer in .au, I can’t even keep my old domain name. How do you persist this identity?
With PLC, I can instead be an abstract did:plc:hv27plmlx6zkuv7bnzbqb6xr (an arbitrary hash of the genesis entry for my DID). I associate rmccue.com.au with this via a TXT record, and back the other direction by recording the domain as an alias.
If I change my handle, I’m still the same arbitrary handle everywhere, everyone keeps following me, and in theory old references to my alias could even continue resolving.
(Similarly, this solves the issue for trademark changes, name changes throughout a person’s life, and changing job roles.)
The core of it is basic tech:
1. Look up _atproto.rmccue.io for a TXT record
2. If it’s did:plc:… send a HTTP request to the directory - eg https://plc.directory/hv27plmlx6zkuv7bnzbqb6xr
3. Parse the JSON response to get my signing keys and where I’m hosted.