atproto handle resolution tries DNS TXT first, then will try an HTTP endpoint. the endpoint is not a ".well-known", it is an "/xrpc/"-prefixed endpoint with a query parameter, which is workable on some static hosts (like github pages), but not others.
not well documented yet. may try to do a ".well-known", but don't want a sprawling set of options with complex priority levels and caching behaviors.
At this point not just using webfinger just feels contrarian for the sake of it.
But then again so does a whole lot of Bluesky. That is, a whole lot of Bluesky could have been designed to interoperate with the fediverse without sacrificing functionality. The choice to instead privately design something entirely different to me speaks strongly to an attitude to openness and community building that makes it a non-starter for me.
Webfinger is entirely separate from ActivityPub, and is already used by other things like e.g. RemoteStorage.
Even if we postulate that what you say is true (I don't agree it doesn't scale, and there are increasingly commercial offerings if you don't want to run your own and there will be more, but let's put that aside), none of that stops people from using webfinger. If you want more than one user on the domain, it requires at a minimum the ability to dynamically rewrite a URL to redirect to a static URL (or you can of course have a fully dynamic endpoint), otherwise it just requires the ability to serve up a single static file.
While I kind of like using DNS myself, and might have gone that way if starting from scratch without an alternative existing, the existence of webfinger and the fact it is in use for multiple things would have made me stop and think twice and just use webfinger.
To late to edit here, but an additional thought: If Bluesky starts getting traction, a move to undercut it from Fediverse proponents would be embrace and extend: Augment clients with webfinger, provide bridging to the Fediverse, and generally aim to make Bluesky users expect to be a part of the wider Fediverse. Only if Bluesky very rapidly overtakes Mastodon to the point of dwarfing it or remain an irrlevance, will it have a realistic prospect of remaining what they want it to be rather than turn into some hybrid that runs away from them.
Webfinger needs to be updated or replaced anyhow - it wasn’t specified in a static file hosting compatible way and expects a dynamic response or custom server rules. Not that bluesky helps here either.
Those are steps for running a server with rules engine. I don’t want a server, I want users to be able to access a CDN directly which may not have such flexible rewrite rules. I’m building a kind of bluesky alt that works entirely statically and should be flexible to file hosting
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?
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.
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?
not well documented yet. may try to do a ".well-known", but don't want a sprawling set of options with complex priority levels and caching behaviors.