[mg]

Nice! So the file approach does work. Do you have a link to the documentation of the file approach?

Why does the DNS approach exist at all? Couldn't users who own a hostname but have not connected it to a webserver have achieved the same by adding a CNAME to a service like Bluesky?

[bnewbold]

I don't really understand your question.

Maybe it helps to clarify that the concept of a handle is totally distinct from the "Personal Data Server" or PDS. You look up the PDS for a handle by resolving the DID first (via DNS TXT or HTTP fallback), then get a DID document, which has a URL to the PDS. This is a bit confusing and multiple steps, but is what makes the handles so easy to use. It is totally fine to have a cool domain to use as a handle and just not have a webserver associated with it.

If you pointed the domain with a CNAME to a particular service, you would need to update that every time you change hosting providers. Which is maybe not often, but it would be disruptive and potentially poor experience because of DNS propagation issues.

For a hypothetical brand like google.com, look up the TXT records. There are a bunch of verifications for various services. This is a relatively standard mechanism. TTL and caching are built-in to DNS, or you can punch through with a recursive query when needed.

[mg]

The challenges around changing hosting providers are the same for websites, aren't they? It seems to me they are well understood these days. I don't hear many people having a pain point around it anymore. A short TTL usually is enough to avoid a lot of DNS caching issues.

And wouldn't changing the name server have the same effect on the DNS solution? "Every time you change your name server provider ...". Which for many users is the same as their hosting provider.

Do I assume correctly, that you don't link to the HTTP fallback documentation because you don't want people to use it?