robida commented 2026年03月19日 20:17:53 +01:00

Hi, all!

I want to first thank everyone for all the comments, suggestions, questions, and feedback on human.json. I was really suprised by how well received the project was, and by how quickly people started adopting it!

I went over the open issues with feedback and classified them in 2 groups:

• Non-controversial changes that we should probably adopt;
• Changes that need more discussion and thought.

I'm thinking about writing a 0.2.0 spec that incorporates the first group, and open a discussion about the second group in a separate thread.

Non-controversial changes that we should probably adopt

• Add a note about vouches.
• Declare multiple URLs for yourself.
• Use RFC 3339 instead of ISO 8601.

Changes that need more discussion and thought

• Using "knows" instead of "vouch".
• Specify degree of humanity.
• Non-HTML discovery.

human.json 0.2.0

Here's how the new file would look like:

{
 "version": "0.2.0",
 "url": "https://example.com/~alice",
 "urls": ["https://alice.example.com"],
 "vouches": [
 {
 "url": "https://bob.example.com",
 "vouched_at": "2026年01月15日T00:00:00Z",
 "note": "I know Bob personally and have read his work for years."
 }
 ]
}

Version 0.2.0 would be backwards compatible with 0.1.1, so:

• It can have both url and urls properties, and they will be combined.
• The property vouched_at can be either RFC 3339 (recommended) or ISO 8601.
• The property note is optional.

Moving forward we would drop the compatibility, so that:

• The property url will no longer be valid.
• The property vouched_at will have to be RFC 3339.

I started a branch with the changes to the JSON schema and the browser extensions: https://codeberg.org/robida/human.json/src/branch/spec-0.2.0

Hi, all! I want to first thank everyone for all the comments, suggestions, questions, and feedback on `human.json`. I was really suprised by how well received the project was, and by how quickly people started adopting it! I went over the open issues with feedback and classified them in 2 groups: - Non-controversial changes that we should probably adopt; - Changes that need more discussion and thought. I'm thinking about writing a 0.2.0 spec that incorporates the first group, and open a discussion about the second group in a separate thread. # Non-controversial changes that we should probably adopt - Add a [note about vouches](https://codeberg.org/robida/human.json/issues/13). - Declare [multiple](https://codeberg.org/robida/human.json/issues/15) [URLs](https://codeberg.org/robida/human.json/issues/28) for yourself. - Use [RFC 3339 instead of ISO 8601](https://codeberg.org/robida/human.json/issues/26). # Changes that need more discussion and thought - Using ["knows" instead of "vouch"](https://codeberg.org/robida/human.json/issues/21). - Specify [degree of](https://codeberg.org/robida/human.json/issues/9) [humanity](https://codeberg.org/robida/human.json/issues/18). - [Non-HTML](https://codeberg.org/robida/human.json/issues/12) discovery. # `human.json` 0.2.0 Here's how the new file would look like: ```json { "version": "0.2.0", "url": "https://example.com/~alice", "urls": ["https://alice.example.com"], "vouches": [ { "url": "https://bob.example.com", "vouched_at": "2026年01月15日T00:00:00Z", "note": "I know Bob personally and have read his work for years." } ] } ``` Version 0.2.0 would be backwards compatible with 0.1.1, so: - It can have both `url` and `urls` properties, and they will be combined. - The property `vouched_at` can be either RFC 3339 (recommended) or ISO 8601. - The property `note` is optional. Moving forward we would drop the compatibility, so that: - The property `url` will no longer be valid. - The property `vouched_at` will have to be RFC 3339. I started a branch with the changes to the JSON schema and the browser extensions: https://codeberg.org/robida/human.json/src/branch/spec-0.2.0

khinsen commented 2026年03月21日 10:08:25 +01:00

"Degree of humanity" could also include a distinction between sites run by individuals vs. sites run by collectives (thinking of English Wikipedia that just decided not to allow LLM-generated content).

"Degree of humanity" could also include a distinction between sites run by individuals vs. sites run by collectives (thinking of English Wikipedia that just decided not to allow LLM-generated content).

gedankenstuecke commented 2026年03月21日 14:50:21 +01:00

My feeling is that going for a full timestamp for the vouching is not really necessary for the use case here and only makes adding new pages (slightly) more complex compared to just typing out the date.

It's maybe not a big point of friction for most folks but could be a drawback for some folks for little payoff?

My feeling is that going for a full timestamp for the vouching is not really necessary for the use case here and only makes adding new pages (slightly) more complex compared to just typing out the date. It's maybe not a big point of friction for most folks but could be a drawback for some folks for little payoff?

andypiper commented 2026年03月21日 14:52:26 +01:00

I agree that the timestamp thing is a minor annoyance, but it was to address #26 - @edent any thoughts?

I agree that the timestamp thing is a minor annoyance, but it was to address #26 - @edent any thoughts?

gedankenstuecke commented 2026年03月21日 14:58:51 +01:00

@andypiper I think RFC 3339 does also allow for just keeping YYYY-DD-MM , see 5.6.

full-date = date-fullyear "-" date-month "-" date-mday

So unless I misinterpret it, changing over to RFC 3339 would not require an actual change in format, one could keep the existing format but use a different standard to justify it, that's also how I understood @edent's point 🙂

@andypiper I think RFC 3339 does also allow for just keeping `YYYY-DD-MM` , see [5.6.](https://www.rfc-editor.org/rfc/rfc3339#section-5) `full-date = date-fullyear "-" date-month "-" date-mday` So unless I misinterpret it, changing over to RFC 3339 would not require an actual change in format, one could keep the existing format but use a different standard to justify it, that's also how I understood @edent's point 🙂

andypiper commented 2026年03月21日 23:55:42 +01:00

It looks like I've misunderstood things here, so defer to you and others! 👍

It looks like I've misunderstood things here, so defer to you and others! 👍

gedankenstuecke commented 2026年03月22日 02:53:39 +01:00

I might equally be wrong, so let's see if edent can chime in! 🙏

I might equally be wrong, so let's see if edent can chime in! 🙏

edent commented 2026年03月22日 21:33:28 +01:00

Reporting! Yes, RFC 3339 allows for just a date like 2026年03月22日. I guess if someone really wanted to vouch with millisecond precision they could use the full representation.
But, yes, just keep it as YYYY-MM-DD for simplicity.

Reporting! Yes, RFC 3339 allows for just a date like `2026年03月22日`. I guess if someone really wanted to vouch with millisecond precision they could use the full representation. But, yes, just keep it as YYYY-MM-DD for simplicity.

EvanHahn commented 2026年03月24日 14:55:39 +01:00

My two cents on these changes:

• I think it's confusing to have both url and urls in the same file. If both are present, an error should be shown to the user. I think that's clearer than trying to combine them.
• The spec should explain what happens with "conflicting" URLs. For example, what happens if https://foo.example.com and https://foo.example.com/bar are both listed?
• I worry about adding too much flexibility (like "degree of humanity"), which could make the protocol complex. Not sure about any specific feature, but I wouldn't want to see this protocol take on too much.

Related to version bumps more generally: the spec should explain what clients should do when they encounter unexpected data. What if vouched_at is a number instead of a string? What should I do if I encounter a newer version?

My two cents on these changes: - I think it's confusing to have both `url` and `urls` in the same file. If both are present, an error should be shown to the user. I think that's clearer than trying to combine them. - The spec should explain what happens with "conflicting" URLs. For example, what happens if `https://foo.example.com` and `https://foo.example.com/bar` are both listed? - I worry about adding too much flexibility (like "degree of humanity"), which could make the protocol complex. Not sure about any specific feature, but I wouldn't want to see this protocol take on too much. Related to version bumps more generally: the spec should explain what clients should do when they encounter unexpected data. What if `vouched_at` is a number instead of a string? What should I do if I encounter a newer `version`?

Fireye commented 2026年04月26日 21:12:04 +02:00

I really like the relationship semantics put forth in #21 as a basis for a human-readable "level of trust." Vouching for a friend I met on a forum and for someone I know in real life are separate things which should probably be differentiable, as I can only be 100% certain of the latter.

It also sounds like there are two related, but distinct, schools of thought regarding the usage of human.json:

• Determining human-ness
• Determining level of LLM usage by a given human, if any.

Right now, to my understanding, the protocol only does the former. If it's to expand to encompass the latter, we should probably make an effort to keep these two separate. eg: I should be able to confirm the human-ness of someone without necessarily making comment on their AI usage, as I simply might not know.

I really like the relationship semantics put forth in #21 as a basis for a human-readable "level of trust." Vouching for a friend I met on a forum and for someone I know in real life are separate things which should probably be differentiable, as I can only be 100% certain of the latter. It also sounds like there are two related, but distinct, schools of thought regarding the usage of human.json: - Determining human-ness - Determining level of LLM usage *by* a given human, if any. Right now, to my understanding, the protocol only does the former. If it's to expand to encompass the latter, we should probably make an effort to keep these two separate. eg: I should be able to confirm the human-ness of someone without necessarily making comment on their AI usage, as I simply might not know.