2023/SD/fynd
Follow Your Nose Discovery was a session at IndieWebCamp San Diego 2023.
- Archived from: https://etherpad.indieweb.org/fynd
Participants
- Tantek Γelik (facilitator)
- Joe Crawford
- Angelo Gladding
- gRegor Morrill
- David Shanske
- Peter Kaminski
- Anthony Ciccarello
- Add yourself here⦠(see this for more details)
Session Proposal
- Follow Your Nose replace or fallback for the use-cases that people use WebFinger, #FYND, Tantek Γelik
- Who is interested in this? Joe is interested. Pete likes this. David Shanske likes this Chris Aldrich Isaac is interested
- Tantek: understand the use cases of webfinger
- Figure out a "follow your nose"-style replacement
- follow your nose
Notes
- follow_your_nose
- History: focus was "what do you want to do with your website?" in early indie web camps - this ends up concentrating the
- solving user problems, rather than technical philosophy
How do we cope with lots of rels?
Feedback on the follow your nose page itself:
- MIssing an explanation of what follow your nose is.
- Definition needs an actual description
- Would be good to have a small concrete example of follow your nose
Other examples of hardcoded paths:
- e.g. using rel=icon instead of /favicon.ico
- e.g. crossdomain.xml
- e.g. /robots.txt - see robots_txt page
- e.g. /.well-known/* - see well-known wiki page
- e.g. /.well-known/atproto-did is one option for claiming a domain for BlueSky - https://atproto.com/ but they also allow for a more follow your nose mechanism and can add an http header
- IndieAuth has a recommendation for locating metadata at .well-known as well
Can you cache rel values across pages? E.g. domain scope vs page scoped for webmention
How do you cache a rel discovery?
- Answer: how you cache anything, HTTP caching headers
Principles for follow your nose
- The owner of a site should have full sovereignty over all the paths at that site. (path sovereignty) HTTP requests to that site.
- Consuming code perspective: you should be able to discover everything about a page, from something inside that page.
Some other examples of "self-sufficiency" (similar to path sovereignty, self-documenting, etc.), via question from Peter Kaminski to GPT-4: https://chat.openai.com/share/a60e0ced-c72c-4ff4-9e51-14aecdd70443 )
Even redirects still impose on your site. E.g. BridgyFed.
Is anyone consuming hardcoded paths from someone else's website?
/ is a well known path. do we free ourselves from that as well?
- what's the goal you're trying to accomplish?
- difference between information about a page and information about a domain
- prior behavior from browsers is perhaps ok to build on?
- or is it up to the server?
Web pages should be self-documenting, anything relevant to a certain web page would include in the metadata that's necessary to understand that web page. Privacy policy, other kinds of things.
Should information about a site belong to DNS?
- There have been DNS text record proposal for information about a domain
- There's a DNS text record to use your domain name as your Bluesky username - an alternative to /.well-known/atproto-did
- From https://indieauth.spec.indieweb.org/#url-canonicalization: "Since IndieAuth uses https/http URLs which fall under what [URL] calls "Special URLs", a string with no path component is not a valid [URL]. As such, if a URL with no path component is ever encountered, it MUST be treated as if it had the path /. For example, if a user provides https://example.com for Discovery, the client MUST transform it to https://example.com/ when using it and comparing it."
Follow your nose applies to http URLs. Thus at least a "/" is required in the path.
E.g. you could 404 "/" but still return something a "/home" for example.
The owner of a site should be able to decide what is the home page of a site, cannot assume "/".
E.g. when spoken, "My URL is tantek.com, the slash is implied".
Use-case: splash page at "/"
"/" is implied by:
- if you type a domain into a browser, it adds the slash
- if you type a domain into a social media post, it adds the slash
- if you type a domain into a txt message, it adds the slash
What are the hard coded paths that folks depend on retrieving information from that we could use FYN instead?
E.g. /favicon.ico, do you have code that depends on that?
- 11ty's IndieWeb Avatar uses it as a fallback after <link rel="icon">
- rel="icon" instead
- maybe libravatar β uses a DNS record instead, with fallback to CDN, see https://wiki.libravatar.org/api/
What properties are anyone's code consuming from Webfinger?
- What does BridgyFed have to responde to (from Mastodon Webfinger requests)
Use-cases:
- If you're trying to look up user x at mastodon y, you go to site y/.well-known/webfinger?resource=acct:x@y
- it returns a JSON document which is an object with a bunch of properties
- which of those properties are necessary?
- "subject" (returns what you passed in as acct:)
- "
https://docs.joinmastodon.org/spec/webfinger/
- goal is to discover that is actually needed by implementations instead of what is prescribed by docs
What failures occur if you remove something?
If no failures, then that thing wasn't necessary
Aside: brief discussion about partial vs complete h-cards
- For Angelo: h-card#partial_vs_complete
Angelo's minimum webfinger response: https://ragt.ag/.well-known/webfinger
- subject
- aliases β what would break if this was omitted?
- links β all link rels, which could be embedded on the page instead
Modest proposal: for any link rels in the "links" collection for a user profile URL, instead use HTML link rels on that profile URL directly instead. Thus
- given a profile URL
- first get the HTML at that URL
- do link rel discovery for the rel values you need
- if you don't find the rel value you are looking for
- you may fallback to a fixed path
FYN is RESTful in a way an api endpoint is not REST
Which rel values are implementations looking for and for what functionality? Using Angelo's as a minimal example:
- self β what does removing it do?
- http://webfinger.net/rel/profile-page β
- http://ostatus.org/schema/1.0/subscribe
This works for the following use-cases:
- You can see Angelo on Mastodon, which works via rel="self" to the actor file:
Follow-up discussion:
- What properties from actor are necessary?
Connections between FYN and REST/HATEOAS:
- https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-753 - βfollow your noseβ. That is the phrase we usually use to distinguish the process of following information-provided transitions/semantics versus following a set procedure or interface declaration outside of that flow of information. Basically, how far ahead is the client looking?
- https://ws-dl.blogspot.com/2013/11/2013-11-19-rest-hateoas-and-follow-your.html - REST = "URIs are nouns, not verbs" and HATEOAS = "follow your nose". "Follow your nose" simply means that when a client dereferences a URI, the entity that is returned is responsible for providing a set of links that allows the user agent to transition to the next state.
- https://www.w3.org/wiki/FollowYourNose
Pete's webfinger response from mastodon.social <https://mastodon.social/.well-known/webfinger?resource=acct:peterkaminski@mastodon.social>
{ "subject": "acct:peterkaminski@mastodon.social", "aliases": [ "https://mastodon.social/@peterkaminski", "https://mastodon.social/users/peterkaminski" ], "links": [ { "rel": "http://webfinger.net/rel/profile-page", "type": "text/html", "href": "https://mastodon.social/@peterkaminski" }, { "rel": "self", "type": "application/activity+json", "href": "https://mastodon.social/users/peterkaminski" }, { "rel": "http://ostatus.org/schema/1.0/subscribe", "template": "https://mastodon.social/authorize_interaction?uri={uri}" }, { "rel": "http://webfinger.net/rel/avatar", "type": "image/png", "href": "https://files.mastodon.social/accounts/avatars/109/258/304/923/927/524/original/91dcfac3050ec880.png" } ] }