Client Information Discovery without relying on microformats parsers.

[Zegnat]

This issue was created in response to a discussion in #indieweb-dev. The essentials should be summarised here, but for full context, see the chat logs starting at 11:31, ending around 11:55.

---

@pfefferle asked if it were possible to use a separate parser just for extracting h-app (IndieWeb wiki) information. Because for such “a very simple and uncomplicated format […] it would be a bit too much to include the mf2 parser”.

The problem with a boiled down parser is it would be making assumption with regards to how the author is adding the h-app object to a page. And as soon as more complex microformats structures (nesting, implied values, vcp) are introduced to the mix anything that is not a full mf2 parser will likely fail.

Conversely there might be reasons why shipping a full mf2 parser with every authorization endpoint is a problem. These problems can range from unavailability of a parser in a language, to more specific issues with packaging. The latter is what is happening for WordPress. Multiple plugins all have to ship their own version of the parser, fighting with each other over which one gets used, because there is no concept of shared dependencies.

The IndieAuth specification only depends on microformats for extracting application information during client information discovery. If this could be changed or offer an alternative straight from the HTML without further dependencies that might help authorization servers in doing this discovery.

(Note that the discovery of redirect urls already depends on HTML parsing for finding <link> elements, so depending on HTML parsing for other client information should be fine.)

Some possible alternatives mentioned during the discussion:

• Open Graph – embed the application meta data in <meta> elements. As there is no application type, this may require defining a new namespace.
• HTML – use standard HTML elements and relationships. rel="icon" for the logo, rel="self" for the client_id. The application name could be extracted from <title> or more specific <meta name="application-name"> elements.
• Web App Manifest – a JSON encoded sidefile containing all the necessary meta data. This will require discovery of the manifest file, and then a second HTTP request to retrieve it. Once retrieved the parsing is extremely straight-forward.
• JSON-LD – if a strictly specified subset is used it could be parsed with any JSON parser (no need for full JSON-LD parsing) and can be embedded within HTML (<script type="application/ld+json">…</script>).

[Zegnat]

I have started some initial documentation to see exactly what applications are publishing for discovery. Current statistics:

h-app	h-x-app	rel=redirect_uri	rel=manifest
8.70% (2/23)	34.78% (8/23)	13.04% (3/23)	34.78% (8/23)

rel=icon	rel=apple-touch-icon	rel=mask-icon
56.52% (13/23)	39.13% (9/23)	17.39% (4/23)

Next it would be helpful to see what other meta data points these pages are publishing, and have in common.

Please help expand that wiki page with any further ideas!

[Zegnat]

The table above has been updated with new statistics. This shows that rel="manifest" are equally as likely to be found on client pages as h-x-app. This Web App Manifests may be a more logical alternative than previously realised.

Further developments in mostly chronological order, for those who do not want to read a day’s worth of chat logs:

• @dshanske is reports looking for other ways to discover application logos.

  • This will likely be based on the wiki documentation on home page icons.

• @aaronpk provides another reason why h-app (and the microformats2 parser requirements it brings along) may not align with IndieAuth, as it relates to his future goal of the spec:

  • my next goal with IndieAuth is to get just the client ID part written up as an i-d and proposed to the OAuth WG

  • and I’m a bit apprehensive of including microformats parsing in that proposal

• @kevinmarks proposes native HTML fallbacks for the h-app properties:

  • url: fall back to [the page’s] url

  • logo: fall back to icons

    • The problem with this is also pointed out: which icon? Icons can mean many things, from the default rel="icon" to a slew of rel="apple-touch-icon-*", and more.

  • name: fall back to <title> or other metadata

    • Another problem is raised: <title> elements are often filled with more than just a name. This problem was already pointed out in the original discussion this morning.

• @tantek points out that localisation of client names might be important. This is something explicitly covered by <meta name="application-name"> elements, but not available to current h-app implementations.

• @EdwardHinkle gives another voice to the client implementers and comments on the friction added by reading h-app:

  • […] while I’ve found Microformats to be extremely helpful in many cases, mf2 in the IndieAuth process is the biggest friction I’ve ever found. I wouldn’t be opposed to there being a different way to find client info from a url

  • Easy to add mf2 to an app’s page. But when writing IndieAuth client code, you either have to add an mf2 library just for that one step or roll your own just for the h-app stage which typically ends up buggy

  • @Zegnat adds that the manifest file would also be easy enough to implement in selfauth, and would get his preference over bringing an mf2 parser.

• @tantek wonders if Web App Manifest is the answer and asks for implementer feedback.

  • @aaronpk points out that it requires an extra HTTP request, but also that the extra HTTP request may be preferred over running an mf2 parser.

  • @EdwardHinkle notes that the JSON offered by the WAM will be much easier, also in the context of an authorization endpoint.

  • @sknebel wonders if it is “weird to use [WAM] for non-web-apps”.

  • @aaronpk is concerned about the effects of publishing a WAM for a page that isn’t itself a web application, but rather just an information page about an external (sometimes web) application.

    • @sknebel points out that there are multiple “installability signals” and that it is unlikely such a minimal manifest file will trigger unwanted behaviour.

    • @EdwardHinkle publishes a minimal WAM for Indigenous for iOS at manifest.webmanifest for testing. Nobody notices any unwanted side-effects.

• @EdwardHinkle points out that the manifest file can also help advertise the actual application:

  • I put in name, icons, prefer_related_applications and related_applications. The last two aren’t required obviously, but helpful if browsers decide to use that to prompt for App Store links.

From the discussions had it seems like everyone is having a positive outlook on Web App Manifest as a place to find application meta-data.

[EdwardHinkle]

Display Together's Client Info using WAM

[Zegnat]

The survey has been updated to tally how many client pages are advertising logos in the form of rel="icon", rel="apple-touch-icon", and rel="mask-icon" links, as extracted by a microformats parser.

Both rel="icon" and rel="apple-touch-icon" have wide support across pages.

[snarfed]

Raised again in chat today via @capjamesg who's interested in using h-x-app in service of https://indieweb.org/store .

Stats from https://indiemap.org/ (2017): out of 2700 sites and 5.7M pages, h-x-app appears on 10 sites, 25 pages (121 non-canonical). Here are the names: Quill, IndieAuth.com, Teacup, redaktor, Switchboard, Taproot Notes, A WebMention Endpoint, unrelenting.technology Game logs, unrelenting.technology Crawl log, Woodwind (defunct).

[capjamesg]

In the chat, myself and one or two others discussed how the IndieWeb Search crawler could act as an effective way to aggregate apps into a store.

This information would be displayed on a separate search view so as to be distinguishable from regular search results.

h-x-app seems logical in its structure for IndieAuth use cases but I do wonder if a dedicated manifest would be more appropriate for advanced applications such as an App Store whose contents are populated / aggregated from sites.

I see that h-x-app is supported by a few clients but I am unsure if it is appropriate for my needs. I do think this should be discussed further. Is JSON-LD or a manifest file still worth exploring?

On a side note I can collect stats from IndieWeb Search on any of the aforementioned proposals if such data would prove useful.

(Thank you @snarfed for tagging and also for collecting data from IndieMap)

[capjamesg]

In the context of IndieAuth itself, has there been any more recent implementer feedback to suggest h-x-app may not be appropriate for client discovery? I find the solution quite elegant in its markup -- providing just what a client needs -- but I understand the low adoption and the need for a microformats parser need to be considered.

[dshanske]

Should we close this in favor of #133 ?

[Zegnat]

As creator of this issue, I am not opposed. I think a client metadata document and a way to discover it is a perfectly valid alternative to parsing microformats. And probably much better than any of the other side-file ideas offered herein.

Let’s give people some time to oppose, and if nothing, close this issue in a couple days?

[capjamesg]

I am in agreement with @Zegnat's position.

[dshanske]

So am I.. Just wanted to get the discussion started.

[aaronpk]

Great, sounds like we generally have support for this. I merged in #138 so I'll close this now.