follow your nose

👃

This article is a stub. You can help the IndieWeb wiki by expanding it.

follow your nose is an intentional principle for designing discovery algorithms that start with the specific URL you want to discover things about, retrieving headers or contents, and parsing for particular link rel values to URLs to the desired information, in contrast to the “well-known” approach of looking outside the specific URL, like using only its domain and a hardcoded path.

Examples

There are lots of examples of follow your nose web discovery across IndieWeb building blocks and other specifications:

IndieAuth: user identity homepage -> rel=indieauth-metadata -> IndieAuth server metadata endpoint for authentication
Micropub: website home page -> rel=micropub -> Micropub endpoint for publishing
Microsub: homepage/profile -> rel=microsub -> Microsub endpoint for server discovery, reading list, feeds etc.
rel-me: homepage/profile -> rel=me -> account to verify -> ✅ verified
Webmention: target URL -> rel=webmention -> Webmention delivery endpoint
Web sign-in: user identity homepage -> rel=me -> profile on OAuth service -> delegated sign-in flow
WebSub: homepage/feed file -> rel=hub,rel=self -> hub and canonical feed for subscribing to notifications of updates
...

Adoption by standards groups

Various standards organizations and groups have adopted, sometimes officially, a design principle that specifications should use follow your nose for discovery.

W3C in general — various groups/citations/encouragements since 2002
W3C Social Web Working Group: resolved on 2015-03-18 to prefer follow-your-nose discovery in architecture and APIs
IndieWeb specifications
...

Advantages

web-centric

“Follow your nose” re-uses existing web topology (links from URLs on the web to URLs on the web) for discovery, and thus both better fits with existing web publishing & interaction methods, and helps to reinforce the web’s interconnected nature & expectations.

This is in contrast to “well-known” approaches which use a hardcoded path which is much more of a legacy (pre-web) operating system specific way of thinking where key resources were located at the same hardcoded path inside their top level root directory or system drive.

predictable portability

“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.

Disadvantages

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.

potential mitigation

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.

Brainstorming

FYN

Tantek Çelik has proposed "FYN" as an easier to speak ("fin") and write shorthand for "follow your nose", e.g. "FYN-based discovery" or just "FYN discovery" thoughts?

+1/0/-1 Add yourself here… (see this for more details)

FYND

Building on #FYN above, Kevin Marks has proposed "FYND" as a shorthand for "follow your nose (based) discovery", cleverly pronounced as "find".

+1 Tantek Çelik
+1/0/-1 Add yourself here… (see this for more details)