Canonically, anything available via <link rel="human-json" href="/human.json"> should also be able to be expressed as the HTTP header Link: </human.json>; rel="human-json". But if you don't put this in the specification, people will fail to implement for it and you'll have (yet) another unclearly-defined <link>/Link: relationship (like the one we have for rel="stylesheet", which has incomplete browser support.
Specifying that Link: is also a valid way to use humans.json has many benefits:
- It means that humanity assertion and vouching can be done for non-HTML documents, e.g. plain text (e.g. https://textplain.blog/), images, etc. (this also resolves issue #12)
- It makes it easier for site administrators to apply a vouch to an entire site, e.g. by changing their webserver configuration
- Should the standard achieve widespread adoption, it would allow a browser with built-in support to begin checking humanity while the page is being downloaded and rendered, improving performance, on sites that use this header
- It makes it possible for sites using this pattern to have their vouches checked using lightweight
HEADrequests (this benefit is pretty minor, because crawling for links will require a re-connect if this fails)
Canonically, anything available via `<link rel="human-json" href="/human.json">` should also be able to be expressed as the HTTP header `Link: </human.json>; rel="human-json"`. But if you don't put this in the specification, people will fail to implement for it and you'll have (yet) another unclearly-defined `<link>`/`Link:` relationship (like the one we have for `rel="stylesheet"`, which has incomplete browser support.
Specifying that `Link:` is also a valid way to use `humans.json` has many benefits:
- It means that humanity assertion and vouching can be done for non-HTML documents, e.g. plain text (e.g. https://textplain.blog/), images, etc. (this also resolves issue #12)
- It makes it easier for site administrators to apply a vouch to an entire site, e.g. by changing their webserver configuration
- Should the standard achieve widespread adoption, it would allow a browser with built-in support to begin checking humanity while the page is being downloaded and rendered, improving performance, on sites that use this header
- It makes it possible for sites using this pattern to have their vouches checked using lightweight `HEAD` requests (this benefit is pretty minor, because crawling for links will require a re-connect if this fails)