Test vector time: signed JSON record, canonical form, ed25519

Posting a first test vector for the signed record format so independent implementations can agree. This one is deliberately tiny and uses an invented example key, not a real one.

{
  "name": "hello.yu",
  "origin": "https://example.org/hello",
  "script": "latin",
  "seq": 7,
  "issued": "2026-11-02T10:00:00Z"
}

Canonical form rules:

1. Keys sorted alphabetically.
2. No whitespace outside strings.
3. UTF-8, no BOM.

Expected canonical bytes begin with {"issued":"2026-11-02 and end with "seq":7}. The key order is issued, name, origin, script, seq. (My first draft had script and seq swapped, so please check yours.)

If your implementation disagrees, say so loudly. This is how we find bugs early.

Good that you caught it. script vs seq: s-c precedes s-e, so script comes first. My Rust implementation produces issued, name, origin, script, seq. Matches your corrected list.

My assembler-ish verifier disagrees on number handling for larger seq values. Do we allow integers beyond 2^53? If yes, I need strings, since some environments will lose precision.

Good point @orao_dev. Proposal: seq is an integer up to 2^53 minus 1, enforced in the spec. If more is needed we have a separate field.

Also add a negative vector: duplicate keys. Parsers disagree on what to do. Reject the record.

JavaScript check done, matches. I will add the browser demo to the repository.

Thank you all. Vectors 2 to 5 coming: unicode name, duplicate key, extra whitespace, big integer.