STARv1 samples (hex-encoded) and their expected decoded contents or a description of why they are not valid. These fixtures cover the DASL-STAR framing:

|------ header ------| |--------- data pairs ---------| | end |
[ magic | len | meta ] [ 1 | len | key | len | val ] *  [  0  ]

Valid STARs (must parse) #

./valid-star-fixtures.json

An array of JSON fixture objects, each with the following structure:

{
  "comment": "empty-string $type, one empty-key/empty-val",
  "star_hex": "2A6C010008A16524747970656001000000",
  "decoded": {
    "meta": { "$type": "" },
    "pairs": [
      { "key_hex": "", "value_hex": "" }
    ]
  }
}

Binary values (keys with _hex in their name) are hex-encoded. All meta content and every item of the pairs array must match the parsed output in the given order.

Header meta follows the atprotocol convention for representing DRISL as JSON. See the DRISL spec for details.

Invalid STARs (must fail to parse) #

./invalid-star-fixtures.json

An array of JSON fixture objects, each with the following structure:

{
  "comment": "wrong magic (0x01 instead of nul fourth byte)",
  "star_hex": "2A6C010108A16524747970656000"
}

Binary STAR content (star_hex) is hex-encoded. Parsers must fail to parse every fixture.

Some fixtures can fail for multiple reasons, and for now the type of failure for each fixture is not defined. However, parsers should not fail by panic, resource exhaustion, or otherwise crashing the process.

Status of these vectors #

hex encodings are written in uppercase, but might be converted to lowercase since most encoders use lowercase? (artifacts of doing this by hand oops)
no application profile tests -- for example, atproto spaces repo exports will restrict key/value sizes, have additional required meta fields, and impose strict lexicographic sort ordering on data pair keys, none of which are tested here.
fixture comment fields are just informative commentary, not meant to be parsed/matched.