follow your nose
follow your nose is an intentional local & web-centric methodology for designing discovery algorithms that start with a specific URL that to discover things about, inspecting its contents, often for specific hyperlink rel values to predictably discover information about & resources for that URL, in contrast to the “well-known” approach of instead checking outside that URL, like using only its domain with a hardcoded path.
“Follow your nose” creates more predictable portability.
When you move a document that is on one site to another, everything “about” that document moves with it or is inside it where you can easily check, there’s no need to additionally check random “other places” (whether at the root of the domain or somewhere else) for “other things that need to move with it”.
more robust portability
“Follow your nose” creates anti-fragile portability, that is, when a document only depends on follow your nose discovery methods, you can fully inspect it for any and all dependencies and be sure of having taken care of all such dependencies.
In contrast, for anything that depends on any hardcoded domain-based paths (like .well-known), you have no idea when you are ”done” moving something or what new dependencies may have accrued by new hardcoded paths.
less dependent on document context
“Follow your nose” can work even when documents are places without domains or root paths that the document owner can control, like local multi-user file systems, or alternative non-DNS systems like IPFS, in contrast to well-known which makes assumptions about domains and root control.
document rather than domain scoped discovery
“follow your nose” allows for each page to define their own rel links, whereas all links are domain-scoped with .well-known discovery.
fetching each page separately
In cases where rel values could or should be domain-scoped rather than page-scoped (e.g. webmention endpoint links), a follow-your-nose approach will require far more network traffic to send webmentions to multiple pages on the same domain than a domain-scoped link discovery method such as .well-known, which would require a maximum of one page fetch per domain.
In practice, most usage of the webmention link rel is domain-scoped rather than page-scoped (i.e. a webmention endpoint fetched from https://example.com/posts/1 can be used to send webmentions for any page on https://example.com). In cases like this, consumers could reduce network traffic while retaining the advantages of page-scoped rel discovery by using the following fetch-on-error algorithm when sending webmentions for multiple pages on a domain:
- Trying to send a webmention for https://example.com/posts/1
- Look for a cached webmention endpoint for that domain?
- If no cached webmention endpoint found for this domain, fetch the resource and parse for rel-webmention, store in cache.
- Attempt sending a webmention
- If the webmention endpoint returned an error, and a cached endpoint was used, fetch https://example.com/posts/1 and look for a new webmention endpoint
- Potentially update the cached endpoint for the domain
If no webmention endpoint was found on the first fetch, caching the negative result could lead to missed webmentions in the future. Some potential solutions could involve
- simply not caching negative results
- caching negative results for a much shorter time than positive results
- only cache negative results if they’re from pages with mf2 markup on, so that no webmention endpoint being found on a “plain” page with no mf2 wouldn’t prevent checking for webmention endpoints in future pages from the same URL
This approach could be generalised to a variety of domain-scoped endpoints.
- 2002 possible first use of concept/phrase: