Lace-010 · Records

Tags: record, stored-format

Purpose

Distributed data needs identity that follows bytes plus enough structure for indexing, versioning, and attribution after bytes arrive from another source. Lace records provide canonical bytes with stable hashes, optional coordinates and fields, and optional By/Mark evidence. Stored records have three content forms: Blob record for bytes, Plex record for coordinate-bearing record versions, and Seal record for one Mark over a Plex record.

This document enables record and higher-layer implementors that consume record facts to parse, validate, store, hash, mark, and index the current H3 record forms.

Defines

Blob records, Plex records, Seal records, field-line rules, TAI, coordinate field validation, record-link fields, and examples.

Every stored record starts with a record glyph line

🖧: <hash-text>

<hash-text> is T.<b64a>.H3, where T is B, P, or S. The B64A payload is the BLAKE3-256 digest of the canonical payload after the record glyph line LF.

Implementations MUST verify that the record glyph line type matches the record type and that the digest matches the canonical payload.

Shared field-line rules keep bytes canonical

Field-line syntax is <Name>: <value>.

Implementations MUST enforce these rules:

field names are non-empty;
field names MUST NOT contain :, space, or tab;
exactly one space follows :;
field values are non-empty;
field names and values are UTF-8 NFC;
H3 NFC uses Unicode Normalization Form C under Unicode 17.0.0;
field lines end with LF only;
CR and CRLF are invalid;
control bytes 0x00..0x1F and 0x7F are forbidden in field-name and field-value bytes; the required terminating LF is structural and is excluded from this prohibition;
one complete field line, including <Name>: <value>, is at most 128 UTF-8 bytes, excluding LF; byte counting occurs after NFC validation;
whitespace is data and is never trimmed.

Blob records carry raw bytes

A Blob record gives arbitrary bytes hash identity without an application coordinate, version time, or By value. It carries bytes plus the length needed for canonical parsing and hashing.

🖧: B.<digest>.H3
Data-Length: <len>

<data>

The Blob record canonical payload is Data-Length, a blank line, and exactly <len> data bytes.

Blob record rules:

Data-Length MUST use ASCII decimal digits [0-9] with no leading zero except 0;
readers MUST consume exactly <len> bytes;
Blob data MUST NOT exceed 32 MiB.

Blob data is opaque and may contain any bytes.

Plex records attach coordinates and fields to a Blob record

A Plex record wraps Blob bytes in selectable, versioned, hash-significant coordinate and field data. Other participants can verify the same Group/App/Name/TAI and extra facts that a rule or index uses for selection.

🖧: P.<digest>.H3
Group: <group>
App: <app>
Name: <name>
TAI: <tai>
[Extra fields]*
🖧: B.<digest>.H3
Data-Length: <len>

<data>

The Plex record canonical payload is all Plex fields followed by the full embedded Blob record.

Plex record rules:

Group, App, Name, and TAI MUST each appear exactly once;
required fields MUST appear in that order;
extra fields MUST follow TAI;
extra fields are hash-significant.

A Plex record is a coordinate-bearing record version. It can produce claims only when a policy or profile explicitly allows unmarked Plex-record claims.

Seal records carry a Mark over a Plex record

A Seal record carries one Mark over one Plex-record digest without mutating the Plex record. The Plex record remains addressable, and each Seal wrapper is an addressable record with its own hash.

🖧: S.<digest>.H3
By: <verification-key-text>
Mark: <mark>
🖧: P.<digest>.H3
Group: <group>
App: <app>
Name: <name>
TAI: <tai>
[Extra fields]*
🖧: B.<digest>.H3
Data-Length: <len>

<data>

The Seal record canonical payload is By, Mark, and the full embedded Plex record.

Seal record rules:

By MUST appear first and contain canonical V.<b64a>.H3 verification-key text defined by 009;
Mark MUST appear second and be a Mark over the embedded Plex-record digest;
readers MUST verify the Seal-record hash and check the Mark using By.

A Seal record proves only that the matching By-secret value produced this Mark over the digest of these exact Plex-record bytes. It does not by itself prove human identity, authorship, truth, authorization, ownership, observation, permission, or selection by any policy.

TAI gives record versions a sortable time

TAI is fixed-width version-ordering text. Its shape preserves bytewise lexical sort order for record-version comparisons without local civil-time or time-zone interpretation. TAI format is seconds:subseconds: exactly 10 ASCII decimal seconds digits [0-9], :, then exactly 9 ASCII decimal nanosecond digits [0-9].

The seconds field counts SI seconds on the TAI time scale from epoch 1970-01-01T00:00:00 TAI. Implementations MUST NOT reinterpret TAI as local time or UTC text. TAI is version-ordering data; a Mark made with the matching By-secret value is not proof that anyone observed that time.

Implementations MUST reject any other TAI shape.

Coordinate fields define an indexed record coordinate

Group, App, and Name describe record subsets: a community or scope, an application contract inside that scope, and an app-local hierarchical name. They are coordinate fields for selection, indexing, display, and rule authoring; they are not record identity. Many records may share the same coordinate. The record hash is the durable identity.

Group is a root-to-leaf path.

Group rules:

value MUST contain one or more non-empty /-separated segments;
value MUST NOT start or end with /;
each segment MUST be at most 120 UTF-8 bytes;
total value MUST be at most 120 UTF-8 bytes;
segments MUST NOT contain {, }, |, or #;
segments MUST NOT equal . or ...

App rules:

value MUST contain one or more non-empty /-separated segments;
value MUST NOT start or end with /;
each segment MUST be at most 120 UTF-8 bytes;
total value MUST be at most 120 UTF-8 bytes;
segments MUST NOT contain {, }, or |;
segments MUST NOT equal . or ...

Name rules:

value MUST contain one or more non-empty /-separated segments;
value MUST NOT start or end with /;
each segment MUST be at most 120 UTF-8 bytes;
total value MUST be at most 120 UTF-8 bytes;
segments MUST NOT contain {, }, or |;
segments MUST NOT equal . or ...

Extra fields are sorted after required fields

Extra fields MUST be sorted by field name using bytewise ascending order. Same-name extra fields MUST be consecutive and MUST preserve user-defined order.

A Plex record MUST contain at most 512 extra fields.

Reserved extra field names are: Type, Data-Length, Group, App, Name, TAI, By, Mark, 🖧, and ⋯🖧. Type is the synthetic record-type field defined by 020. Verifier is not reserved and has no standard meaning; an application MAY use it as an ordinary Plex extra field.

Record-link fields describe hash references

A Plex record extra field named +Link or ending with +Link is a record-link field. Record-link fields are ordinary extra fields: sorted, hash-significant, and subject to all extra field rules.

A well-formed record-link field value is:

<link-data> <target-hash>

Rules:

<link-data> MUST be non-empty;
the separator MUST be exactly one ASCII space;
<target-hash> MUST be typed record hash text beginning with B., P., or S.;
record-link parsing MUST NOT require the target hash suffix to be H3;
the record definition named by the target hash suffix defines the target hash payload syntax and validation rules;
<link-data> is application-defined text and MAY contain spaces except for the final separator space before <target-hash>.

The link data and target hash share the ordinary 128-byte complete field-line budget with the record-link field name and : separator. Malformed record-link fields do not invalidate a record unless they violate ordinary field-line rules; they remain ordinary extra fields. Layers that index record-link fields MUST ignore malformed values. A target hash whose record format is unsupported by the local store MAY be indexed as a link target, but it MUST NOT become Have unless received bytes validate under a supported record definition.

Examples:

+Link: evidence S.EXAMPLE_SEAL_HASH.H3
Chunk+Link: 0..33554432 B.EXAMPLE_BLOB_HASH.H3

Examples

Example hash strings and By values are symbolic. Real record hashes use BLAKE3 digests of canonical payload bytes; real By values use canonical 009 verification-key text. The V prefix is 009’s verification-key type tag.

Blob record:

🖧: B.EXAMPLE_BLOB_HASH.H3
Data-Length: 11

hello room7

Plex record:

🖧: P.EXAMPLE_PLEX_HASH.H3
Group: eu/lab
App: chat
Name: room-7/123
TAI: 1640995200:000000000
Content-Type: text/plain
🖧: B.EXAMPLE_BLOB_HASH.H3
Data-Length: 11

hello room7

Seal record:

🖧: S.EXAMPLE_SEAL_HASH.H3
By: V.EXAMPLE_BY_B64A.H3
Mark: EXAMPLE_MARK
🖧: P.EXAMPLE_PLEX_HASH.H3
Group: eu/lab
App: chat
Name: room-7/123
TAI: 1640995200:000000000
Content-Type: text/plain
🖧: B.EXAMPLE_BLOB_HASH.H3
Data-Length: 11

hello room7

Boundary examples

A complete field line of 128 bytes is valid, while the same line extended to 129 bytes is invalid. For example, X: plus 125 ASCII a bytes is accepted and X: plus 126 is rejected. The limit counts UTF-8 bytes, not characters: X: plus 62 NFC é characters and one ASCII a is 128 bytes and is accepted; adding one more ASCII byte is rejected.

Each coordinate value is independently bounded. A Group, App, or Name value containing 120 ASCII a bytes is accepted, while 121 is rejected. The same byte rule applies to multibyte NFC text: 60 NFC é characters are 120 bytes and accepted; 61 are 122 bytes and rejected.

Common rejection examples

Implementations reject records with a 129-byte complete field line, a 121-byte coordinate value, CRLF line endings, non-NFC field-line text, Data-Length: 01, missing required Plex record fields, invalid Group paths such as /eu, eu/, eu//lab, eu/./lab, or eu/lab#x, extra fields out of order, a Seal missing its required first By field, a mismatched record glyph line digest, or an invalid Seal-record Mark or By value.