17
205
Fork
You've already forked human.json
6

Use the exiting XFN vocabulary or "knows" instead of "vouch"? #21

Open
opened 2026年03月17日 00:01:00 +01:00 by chrismessina · 0 comments

<insert XKCD comic about standards>

XFN has been around forever and uses link rel to define the relationship between two URLs, which typically represent humans.

The relationship semantics are orthogonal (I suppose) to the purpose of human.json, but since the current spec only defines a unidirectional relationship, it misses the chance to detect bi-directional claims, e.g. where two links point to each other with the 'friend' relationship.

"Vouch" is also exceedingly vague and subjective, lacking domain specificity.

For this effort to be truly useful, reusing existing/established conventions could help advance its utility and adoption, and insisting on clarity around the relationship semantic (i.e. I would propose using "knows" instead of "vouches") would reduce the likelihood of implied transitive assumptions (e.g. if I vouch for Rob, and Rob vouches for Mike, we shouldn't assume that I vouch for Mike, and that should be clarified in the spec).

Anyway — I like the idea of humans.txt (which already exists!) or humans.json, but what I like even more is widespread adoption and use of these protocols!

&lt;insert [XKCD comic about standards](https://xkcd.com/927/)&gt; [XFN](https://gmpg.org/xfn/) has been around forever and uses `link rel` to define the relationship between two URLs, which typically represent humans. The [relationship semantics](https://gmpg.org/xfn/11) are orthogonal (I suppose) to the purpose of `human.json`, but since the [current spec](https://codeberg.org/robida/human.json/src/branch/main/schema/0.1.1.json) only defines a unidirectional relationship, it misses the chance to detect bi-directional claims, e.g. where two links point to each other with the 'friend' relationship. "Vouch" is also exceedingly vague and subjective, lacking domain specificity. For this effort to be truly useful, [reusing](https://microformats.org/wiki/reuse) existing/established conventions could help advance its utility and adoption, and insisting on clarity around the relationship semantic (i.e. I would propose using "knows" instead of "vouches") would reduce the likelihood of implied transitive assumptions (e.g. if I _vouch_ for Rob, and Rob _vouches_ for Mike, we shouldn't assume that I _vouch_ for Mike, and that should be clarified in the spec). Anyway — I like the idea of [humans.txt](https://humanstxt.org/) (which already exists!) or `humans.json`, but what I like even more is widespread adoption and use of these protocols!
Sign in to join this conversation.
No Branch/Tag specified
main
spec-0.2.0
crawler
No results found.
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
robida/human.json#21
Reference in a new issue
robida/human.json
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?