Skip to content

CEG normative absorption for v4.0: streaming + fountain + ALM + WholenessWitness + holonomic primitives #85

@emooreatx

Description

@emooreatx

Goal

By CIRIS v4.0 (CEWP-1.0 holonomic federation seal), everything we've designed across the realtime A/V + holographic storage + holonomic substrate work must be promoted from informative implementation guidance to normative CEG wire format.

Without normative status, two independent implementations of the federation will diverge at exactly the points where the holonomic property requires agreement — Merkle roots over the same claim sets must match across implementations; ALM planners must arrive at the same tree from the same inputs; fountain symbol IDs must be deterministic; rarity computations must agree; witness reconciliation depends on byte-equal canonical encodings.

This issue scaffolds the cross-repo coordination for what CIRISRegistry needs to absorb into CEG normative sections by v4.0.

What is currently informative + needs to become normative

Each of these is shipped or designed at the edge / persist / verify layer today as implementation guidance. They MUST become CEG normative for interoperability at scale.

From CIRISEdge v3.6.x – v3.8.0 (shipped substrate)

Component Current state Normative ask
`SealedAvChunk` wire byte layout Informative (docs/CEG §10.5.8 discussion) §N realtime A/V chunk wire-format normative
`codec_id` namespace Filed at #84, not ratified §N.1 codec_id namespace ratified (0x01 AV1 SVC / 0x02 JPEG XS / 0x03 MDC / 0xFF opaque)
`ChunkLayer { spatial, temporal, quality }` Informative §N.2 normative layout
`SubStreamPath = Vec` Informative §N.3 variable-depth MDC path encoding
MLS ciphersuite `0x004D` X-Wing openmls 0.8.1 ships; no IANA code-point §N.4 CEG-reserved code-point until IANA assigns; migration rule
`RosterDelta::Batch` wire shape Informative §N.5 mass-join commit batching

From CIRISEdge v3.8.0 ALM substrate

Component Current state Normative ask
`RelayCapacity` advertisement canonical bytes Informative (`b"CIRISALM-CAPv2\0\0"` domain sep) §M ALM capacity-advertisement wire normative
`SignedRelayCapacity` envelope Informative §M.1 signed envelope, hybrid sig fields
`SubStreamCommitment` shape Informative §M.2 per-substream commitment layout
`has_room_for_substream` algorithm Informative §M.3 deterministic admission algorithm (so two ALM planners agree)
`AlmJoinPlanner::plan` selection algorithm Informative §M.4 deterministic parent selection (stale → layer → room → reachability filter, then RTT ascending sort, tiebreaks specified)
`MultiParentSubscription` dedup discipline Informative §M.5 `(epoch, chunk_seq)` dedup key normative

From CIRISPersist#227 — fountain content + eviction

Component Current state Normative ask
`FountainManifestV1` canonical bytes Drafted, edge#133 ratified, persist starting §P.1 manifest wire layout (incl. the `original_content_length` add I flagged)
`FountainSymbolV1` layout Drafted §P.2 symbol byte layout
`retention_priority: u8` computation Edge owns; persist treats opaque §P.3 edge-side priority encoding (SVC layer × source/repair × position bucket) so two edge implementations agree on byte values for the same input
SHA-256 per-symbol hash discipline Drafted §P.4 hash chain in manifest
Hybrid signature requirements Following #225 hard cut §P.5 reference to #225's signing rules + manifest-binding
Eviction tier table (T1..T5 + EnvelopeOnly) Drafted §P.6 retention tier definitions (keep counts, reconstruction guarantees)
Decay trigger (consent SLA) Drafted §P.7 dual-trigger (DiskPressure + consent decay)

From CIRISEdge#133 — codec wiring (v3.9.0)

Component Current state Normative ask
RaptorQ wrap canonical mapping TBD in v3.9.0 work §Q fountain encode/decode contract (so different implementations produce identical symbol bytes for the same input)
AV1 chunk → fountain symbols mapping TBD §Q.1 chunking + padding discipline
Opus frame → fountain symbols mapping TBD §Q.2 voice chunking
Per-codec wire compatibility floor TBD §Q.3 minimum-decode requirement per codec_id

From CIRISEdge#134 — swarm-coordinated rarest-shard retention (v3.10.0)

Component Normative ask
`FountainCompressRequest` canonical bytes §R.1 swarm-coordination request envelope
`FountainHoldingClaim` canonical bytes §R.2 holding-claim envelope
Rarity computation algorithm §R.3 deterministic rarity scoring (so two peers compute the same priority recomputation)
Reweighted `retention_priority` formula §R.4 deterministic byte formula (so persist's ORDER BY produces the same evictions everywhere)
Deadline / propagation requirements §R.5 swarm-coordination timing

From CIRISEdge#135 — WholenessWitness (v3.10.0 keystone)

Component Normative ask
`WholenessWitness` canonical bytes (`b"CIRIS-WITNESS-v1\0\0"`) §W.1 witness envelope normative
Merkle tree construction algorithm §W.2 leaf encoding (sha256 of canonical envelope bytes), sort order (`(claim_kind, claim_id)` ASCII), odd-node duplication rule (so two peers arrive at identical roots)
Publish cadence requirements §W.3 minimum publish frequency for conformance
Reconciliation protocol §W.4 Merkle-proof exchange + claim envelope fetch
Hybrid signature discipline §W.5 reference to #225 + ML-DSA-65 required
`covers_claim_kinds` namespace §W.6 valid claim-kind strings ("federation_key", "trace", "relay_capacity", "holding_claim", etc.)

From CIRISEdge v3.10.0 — deterministic ALM topology (new)

Component Normative ask
Tree topology = pure function of (capacity_ads, trust_graph, reachability_snapshot) §T.1 the function MUST be specified — sort order, tiebreaks, root-of-tree selection rule
Two peers with identical inputs produce identical trees §T.2 conformance test (input vector → expected tree hash)

From CIRISEdge v3.10.0 — recursive trust bootstrap (new)

Component Normative ask
Trust chain following algorithm §B.1 deterministic admission rule (any signed claim chaining to a trust root in the receiver's graph)
Bootstrap admission test §B.2 conformance test (a peer joining with no priors arrives at a valid federation view)

Why this matters for v4.0

A holographic substrate (v3.8.0 + v3.9.0 + v3.10.0 part 1) gives graceful degradation. A holonomic substrate (v3.10.0 parts 2-4) gives graceful reconstitution from any sufficient fragment.

Both depend on byte-equal canonical encodings + deterministic algorithms. Without normative CEG status:

  • Two implementations of `WholenessWitness` produce different Merkle roots from the same claim set → reconciliation is impossible
  • Two implementations of `AlmJoinPlanner` arrive at different ALM trees from the same inputs → the holonomic topology fails
  • Two implementations of `retention_priority` evict different symbols under the same pressure → swarm coverage diverges
  • Two implementations of `FountainSymbol` produce different bytes for the same content → persist's symbol_hashes verification fails

These aren't theoretical risks — they're the immediate breakage modes of a non-normative substrate.

What CIRISRegistry needs to produce

A CEG 1.1 spec absorbing all of the above into normative §N / §M / §P / §Q / §R / §W / §T / §B sections, with:

  1. Canonical byte encodings for every envelope shape — length-prefixed, sort-order specified, domain separators frozen
  2. Deterministic algorithms for retention_priority computation, rarity scoring, Merkle tree construction, ALM topology, trust-chain following
  3. Conformance test vectors — input → expected output pairs that any CEG-conformant implementation must reproduce byte-for-byte
  4. Migration paths for each currently-informative-to-normative promotion (no flag day; existing v3.6+ wires interop with v4.0 wires)
  5. §0.1 conformance language updates acknowledging the new sections

Sequencing

This work proceeds in lockstep with edge cuts:

Edge cut CEG normative addition
v3.8.0 (shipping) §N realtime A/V chunk wire + §M ALM substrate envelope shapes — immediate priority
v3.9.0 (next) §Q codec wiring contract (rav1e/dav1d/opus/raptorq fountain mapping)
v3.10.0 §P fountain content/manifest (incl. `original_content_length` add) + §R swarm rarity + §W WholenessWitness + §T deterministic topology + §B recursive trust bootstrap
v4.0 CEG 1.1 published with all of the above normative; conformance test vectors locked; FREEZE

Filed-by

Claude Code (CIRIS Edge v3.8.0 ship coordination → v4.0 cross-repo scaffolding). Architectural framing from @emooreatx ("they need to make everything else we have done normative, streaming and fountain encoding etc... all necessary for the mesh to operate at scale as desired").

Composes with:

  • CIRISEdge#84 (codec_id namespace — already filed here)
  • CIRISEdge#131 (v3.8.0 PR — substrate shipping)
  • CIRISEdge#133 (v3.9.0 codec wiring)
  • CIRISEdge#134 (v3.10.0 swarm rarity)
  • CIRISEdge#135 (v3.10.0 WholenessWitness)
  • CIRISPersist#227 (v8.0.0 layer-aware eviction)

This is the gate to v4.0 on the spec side. Without this work landing in CEG 1.1, v4.0 cannot ship as "the holonomic federation seal" because the federation isn't actually interoperable across implementations.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions