Hacker News

Google has recently added `llms.txt` to Chrome's Lighthouse check for agentic browsing (https://searchengineland.com/google-llms-txt-chrome-lighthou...), so adoption may be coming. Admittedly, I put more faith in

  <link rel="alternate" type="text/markdown" href="https://example.com/foo.md" title="Markdown version of the &lt;Foo&gt; page">

I have created an `llms.txt` for my website anyhow. I use a fixed LLM prompt to generate it from the internal links in `index.md`.

The same could be said of robots.txt

And anything else that might tell them not to access something.

To be fair, "not adopted by any major AI player" is probably the most web-standard-compliant phase of a new web standard.

Wow. Talk about a storm in a teapot...

Back in 2018 when the internet wasn't completely fun, but still more fun than today...

Not many people could have gotten that done. Sounds like expertise to me.

> add a robots.txt

Which bots will then ignore.

If the website implements it. What about email preferences? Removing account links? There are many use-cases you might want to redirect a user to, but having to make their own well known for it seems dumb instead of using a more generic one. I guess the more flexible it is, the harder adoption becomes as the usage within a spec might diverge, or it grows outside of the spec and becomes unofficial. So maybe password-reset is correct level of specification.

Anyway discord domain verification can tell in their onboarding docs to put it anywhere. It being well known does nothing. If there was a root level domain verification, then you might as well put it under that. But otherwise why go through a process?

Having all those TXT records at the domain apex like that makes the TXT query reply huge, which affects, for instance, every mail recipient who merely wants to check the SPF record. This is a bad pattern to follow.

Domain verifications leak information that they shouldn't - it should be "random key.domain.com in TXT randomkey"

"Domain-verifications" is an invitation for everyone else that might need it to use the same standard and convention. "Discord-domain-verification" is not, it's what feels like polluting the global namespace with the company name that might cease to exist in a few years.

At the very least, it should be "domain-verification-discord", "-google" and so on. Maybe even "-com.discord", "-com.google"? And the first part clearly standardized and registered, instead of one entity using "domain" and another one "site".

Literally the inner platform effect. We have multiple kinds of DNS record. Let's use them instead of creating a key value store inside a key value store.

Perhaps he's trying to drive adoption of ECH. SNI is better than nothing, but it leaves the name of the destination domain in plaintext.

Why not call it .junk-drawer instead ;)

exactly! in fact, that's most of the whole point of .well-known!

> I spent 10 minutes searching for one in the article, in the RFC, in the wikipedia page, on google, to search for a .well-known example. Couldn't find one.

I don't know how that can be, since you claim to have found the RFC; the RFC straight-forwardly states,

> 5. IANA Considerations

> This specification updates the registration procedures for the "Well-Known URI" registry, first defined in [RFC5785]; see Section 3.1.

& then of course directs IANA to establish a registry. We'd expect this section, given the very nature of the RFC is that it establishes a collection of things, so that there is an IANA considerations section should be wholly unsurprising…

If you see the linked section…

> The "Well-Known URIs" registry is located at <https://www.iana.org/assignments/well-known-uris/>.

And there's a link to a listing of every standardized .well-known URI there is.

> What is it with technical documentations that go deep describing what it is in plenty words but refusing to give a single example?

The RFC provides an example in the form of "example", but also in the form of "robots.txt" (as a "it could have used this, had this existed", but what else could it have done?).

I've been setting up some federated servers (Matrix, activitypub) and I ran into .well_known/ paths in many of them. Webfinger resolver for activitypub and a more custom matrix server-to-server federation endpoint.

Are they actually, though?

Not one of them links to the actual well-known resource, only pdf specifications. And several I picked randomly leads to dead ends.

Here's one I could find: https://accounts.google.com/.well-known/openid-configuration

But how does one even find this?

I would say acme-challenge is one of the most used ones. How else would one get SSL certificates today

Another one that is emerging is the A2A agent card https://a2a-protocol.org/latest/topics/agent-discovery/#1-we...

I think the blog author is the one who wrote the original RFC. To be fair to him, there once was a time web servers were more commonly thought of as truly being remote directories of files you can view or link to, not just domains the browser hides the rest of, and dotfiles would commonly act like dotfiles in local file listings. Nowadays, the assumption is if you go to the base URL it should only ever serve the default page and if you try to go to a directory it should throw an error. Well, unless you're one of those ancient sites like https://ftp.mozilla.org/

I'm not saying it's good or bad how things turned it, but the choice of a dotfile for this sure did not pan out well as the web went the exact opposite direction it would have been relevant in.

The main point of consideration here probably was how to avoid conflicts with URLs of existing sites, not exactly people who aren't able to serve an endpoint with a dot within its path...

TBF, those people are already hit with problems on their apache configuration and fixed their tooling long before the lack of .well-known gives them any problem.