# LCP — Log Construction Profile, v1 # KNO Schema Version: 0.1.0 # Status: Draft # Last Updated: 2026-08-04 # # The append-only Merkle log construction beneath the messaging # service's act store: domain-separated leaf/interior hashing, leaves # committing sequence position + record digest, realm-signed epoch # checkpoints in C2SP tlog-checkpoint shape, and retained consistency # proofs — all from the first write (council ruling forge #3370, # winning plan N1.6 + divergent front 1: checkpoints are NOT an # unscheduled upgrade). # # PROOF-SCOPE HONESTY (council T1 v1.1): this profile provides # INCLUSION (leaf + checkpoint proof) and CONSISTENCY (append-only # proof between checkpoints). It does NOT provide split-view defense — # single-operator checkpoints cannot prevent fork presentation; # witnessing is a carried residual owned by the realm-log owner, and # the first external checkpoint-relying consumer BLOCKS on a # witnessing plan. No "self-certifying" or anti-equivocation claims # may cite this profile. # # ============================================================================= # @kno:manifest # ============================================================================= $schema: kno@0.0.9 id: 01KZ744JS3CRCAKYY513VWEDB5 slug: lcp-spec type: spec version: 0.1.0 title: "Log Construction Profile (LCP) v1" purpose: | Define the single append-only Merkle log each realm's messaging service maintains: leaf framing, domain separation, checkpoint shape and cadence, and the proofs produced and retained. A pre-pour deliverable of the record-layer council ruling — the first data write already conforms. status: draft created: "2026-08-04" authors: - "Possibility Contributors" provenance: origin: id: 01KZ744JS3CRCAKYY513VWEDB5 timestamp: "2026-08-04T10:15:00Z" emerged_from: - kno://research/council-research/2026-08-03-communicative-acts-record-layer - kno://specs/kcf-spec tool: ai-assisted-authoring issue: "forge#3376" taxonomy: topics: - record-layer - merkle-log - integrity - checkpoints keywords: - lcp - merkle - checkpoint - inclusion - consistency - append-only relationships: conforms_to: - xri: "kno://specs/kno-spec" reason: "RFC-001 defines kno@0.0.9 schema" depends_on: - xri: "kno://specs/kcf-spec" reason: "Leaves commit KCF record digests; the digest constructions are domain-separated siblings" - xri: "pspace://rfc:rfc-023-communicative-acts" reason: "The act log this profile constructs (§9.2 log construction)" related_to: - xri: "kno://specs/act-schema" reason: "Acts and durable activities are the records the log's leaves commit to" visibility: public quality: completeness: 0.7 review_status: draft _history: retention: full format: snapshot versions: - version: "0.1.0" date: "2026-08-04" author: "Possibility Contributors" summary: "Initial draft — RFC 6962-shape Merkle tree with domain-separated hashing, leaf framing over (sequence, record_digest), C2SP-shape realm-signed epoch checkpoints with event-relational cadence, inclusion + consistency proofs from write 1, explicit non-claims (no split-view defense without witnessing)" content: | ## 1. One log per realm Each realm's messaging service maintains exactly ONE append-only Merkle tree over all accepted records (acts AND durable activities — every log citizen). Segments are checkpoint epochs of the single tree, never separate trees. The log is the substrate; every surface (lane projections, chains, feeds) is a query over it. ## 2. Leaf framing and domain separation Hashing follows the RFC 6962 construction with domain-separated prefixes: ``` leaf_hash = SHA-256( 0x00 || leaf_bytes ) interior_hash = SHA-256( 0x01 || left_hash || right_hash ) ``` `leaf_bytes` is the KCF-canonical serialization (JCS) of the leaf record: ```json {"position": , "record_digest": "sha256:"} ``` where `position` is the zero-based sequence position assigned at append (total order within the realm log) and `record_digest` is the record's KCF FRAME digest. **Distinct constructions rule (council N1.4):** the record digest (over FRAME), body digests, and these leaf/interior hashes are domain-separated and never interchangeable. The 0x00/0x01 prefixes separate leaf from interior; the FRAME's PAE encoding separates record digests from both. **From the first write:** leaf hashes and sequence positions are computed and durably stored at append time from write 1 — retrofit is forbidden (divergent front 1; a bare append table with "hashing later" violates the pour). ## 3. Checkpoints (C2SP tlog-checkpoint shape) A checkpoint is a signed note in the C2SP tlog-checkpoint format: ``` — ``` - **Origin line:** `pspace.dev/messaging/` — unique per realm log, never reused across logs. - **Signer:** the realm-log key (one of the four distinct signing roles — council Position 5.5; adapters and personas never sign checkpoints). - **Suite:** Ed25519 default with mandatory cryptosuite agility — every checkpoint carries a suite identifier via its key name hash; migration never shrinks signed scope (council N1.7). **The inconsistency prohibition (verbatim, C2SP):** a log MUST NOT sign a checkpoint that is inconsistent with any checkpoint it previously signed. Enforcement: the signer persists its latest-signed (size, root) and refuses to sign any (size', root') that does not verify a consistency proof from (size, root). **Cadence is event-relational, never wall-clock:** | Event | Checkpoint? | |-------|-------------| | Segment close (count backstop: every N=1024 appends at most) | REQUIRED | | Realm-log key rotation | REQUIRED (final checkpoint under old key, first under new) | | Federation egress (when it exists — currently structurally gated) | REQUIRED | | Publication epoch (Publish occurrences batch-anchored) | REQUIRED | | Idle periods | No checkpoint (nothing to anchor) | ## 4. Proofs - **Inclusion proof:** standard RFC 6962 audit path from a leaf to a checkpointed root. Produced on demand for any (position, record_digest) against any checkpoint whose tree size exceeds the position. - **Consistency proof:** RFC 6962 consistency path between successive checkpoints. Produced at every checkpoint signing and RETAINED durably from M0 (council N1.6) — the retained chain of consistency proofs is what lets an auditor verify append-only history end-to-end without replaying the log. ## 5. Explicit non-claims (T1 discipline) | Claim | Status | |-------|--------| | Inclusion (record is in the checkpointed tree) | PROVIDED | | Consistency (later checkpoint extends earlier) | PROVIDED | | Split-view defense (all consumers see one history) | NOT PROVIDED — requires witnessing; carried residual, owner: realm-log owner; first external checkpoint-relying consumer blocks on a witnessing plan | | Attributable authority of records | NOT this profile's scope — signature + binding + policy at log position (trust policy) | | "Self-certifying log" | PROHIBITED phrasing anywhere this profile is cited | ## 6. Storage obligations (pour floor) The service's first migration carries, per record: stored canonical bytes, record digest, sequence position, leaf hash; per epoch: checkpoint note bytes, consistency proof bytes. Physical locators and serving indexes are unsigned rebuildable metadata.