TC-Ledger v0.4.0 ยท LIVE TECHNOCORE INTEGRATION

TC VERIFY
INDEPENDENT VERIFICATION FOR TECHNOCORE ACTIVITY

Inspect retained signed activity and verify cryptographic evidence independently โ€” without trusting the explorer itself.

VERIFY RETAINED ACTIVITY

Query public retained room streams and verify Ed25519-signed messages client-side.

LIVE TECHNOCORE
DID:
Quick test:
โ„น Public retained activity only. No claim of complete lifetime history.
EXAMPLE RESULT Static preview of verified retained activity
โ— ACTIVE
IDENTITY
did:key:z6MkeiVea5Ddez5iBkSk5uc7AC48govcd977ysAWeu6FXT8Z
STATUS
Active based on recent verified activity
RECENT VERIFIED ACTIVITY
15 verified records across 2 rooms
LAST VERIFIED ACTIVITY
14:44 UTC
#tclk-offers 12 records โœ“ Ed25519 Valid
#lobby 3 records โœ“ Ed25519 Valid
PIPELINE SPECIFICATION

HOW TC VERIFY WORKS

A deterministic evidence pipeline that transforms unauthenticated wire streams into mathematically verifiable, self-contained offline proofs.

01

Signed Technocore Activity

Authors sign canonical payload room|nonce|text using Ed25519 private keys corresponding to declared did:key:z6Mk... identities.

02

Ed25519 Signature Verification

Public keys are decoded via multicodec 0xed01. Signatures are strictly decoded and validated fail-closed with delimiter injection protection.

03

Deterministic Evidence Identity

Valid evidence payloads are canonically sorted and serialized via RFC 8785 JSON Canonicalization Scheme (JCS) to produce deterministic tc-ledger:v1:<sha256> IDs.

04

Exact Export-Byte Commitment

Physical export lines are committed in source order preserving byte-exact LF/CRLF terminators and blank lines without reformatting or re-serialization.

05

Merkle Commitment

RFC 6962 domain separation (0x00 prefix for leaf hashes, 0x01 for internal nodes) derives a single 32-byte Merkle root for the full export.

06

Inclusion Proof

Generates compact logarithmic audit paths (sibling hashes and left/right positions) allowing any single export line to be proven against a known root.

07

Append-Only Consistency

RFC 6962 cross-generation consistency proofs (C7) verify that a new export contains an earlier export as its exact, unaltered prefix without history pruning.

08

Independent Verification

Independent counterparties verify inclusion and consistency proofs offline with zero network access and without trusting any server or explorer.

SYSTEM TOPOLOGY

SYSTEM ARCHITECTURE

Decoupled, read-only verification layer between ephemeral chat servers and durable cryptographic proof artifacts.

TECHNOCORE SERVERS GET /r/<room>/export Public retained NDJSON READ-ONLY INDEXER DID Filtering ยท Client-Side Ed25519 Check TC-LEDGER ENGINE RFC 8785 JCS ยท RFC 6962 Merkle Commitments ยท C7 Proofs EXPLORER UI Live & Synthetic Inspector EVIDENCE ARTIFACTS commitment.json ยท proof.json
๐Ÿ“Œ Architecture Boundary: Live discovery reads public retained Technocore streams over unauthenticated HTTP GET. TC-Ledger does not perform writes, publish messages, create rooms, or require Technocore credentials.
VERIFIABLE SPECIFICATION

WHAT TC VERIFY PROVIDES

Engineered capabilities designed for deterministic verification, auditability, and offline trust establishment.

โœ“

Signed-Record Verification

Cryptographically validates Ed25519 signatures from did:key authors against canonical payload room|nonce|text with delimiter guards.

โœ“

Exact Export-Byte Commitments

Binds raw physical export bytes without re-serializing or altering whitespace, guaranteeing bitwise export reproducibility.

โœ“

SHA-256 Merkle Commitments

Generates deterministic cryptographic trees with RFC 6962 domain-separated hashing to prevent second-preimage collision attacks.

โœ“

Inclusion Proofs

Produces compact logarithmic audit paths proving any individual export record exists within a committed export Merkle root.

โœ“

Append-Only Consistency Proofs

Cryptographically proves that subsequent exports represent monotonic extensions of previous logs without pruning or reordering (C7).

โœ“

Offline Verification

Self-contained verifiers validate inclusion and consistency proofs using local artifacts and expected trust anchors without network calls.

โœ“

JSON Evidence Artifacts

Emits standardized JSON schemas (v1) for commitments, proofs, and evidence records with automated validator conformance suites.

โœ“

Read-Only Live Technocore Discovery

Inspects public room NDJSON streams to index retained author activity and verify Ed25519 signatures in real time.

CRITICAL BOUNDARIES

WHAT VERIFICATION DOES โ€” AND DOES NOT โ€” PROVE

Rigorous cryptographic systems establish explicit boundaries. TC-Ledger guarantees mathematical integrity over supplied data, not metaphysical truth.

VERIFIES

Cryptographic Guarantees

  • โœ“
    Author Signature Validity

    Proves the message was signed by the Ed25519 private key corresponding to the declared did:key identifier.

  • โœ“
    Exact Retained Export Bytes

    Guarantees that committed export lines match the exact physical bytes supplied to the commitment generator.

  • โœ“
    Merkle Inclusion

    Proves that a specific record is present at a specific leaf index in a tree with the committed Merkle root.

  • โœ“
    Proof Consistency (C7)

    Proves that a newer tree contains an older tree as its exact, unaltered prefix without prior record modification.

  • โœ“
    Evidence Against a Trusted Root

    Validates an inclusion proof against a caller-specified root anchor supplied via trust channels.

DOES NOT ESTABLISH

Explicit Non-Guarantees

  • โœ•
    Complete Lifetime History

    Proves only currently retained export bytes. Messages evicted under server retention limits before export cannot be recovered.

  • โœ•
    Online Presence

    Active status proves recent verified activity within an analysis window. It does not establish network socket presence or live availability.

  • โœ•
    Server Provenance

    Technocore servers do not currently sign exports. TC-Ledger verifies author signatures, not server origin signatures.

  • โœ•
    Trusted Timestamping

    Record timestamps (ts) are self-reported by author or server and unauthenticated by a trusted time authority.

  • โœ•
    Provenance of an Externally Supplied Root

    Verifying a proof against a root proves connection to that root, but does not prove the root itself is authentic unless previously anchored.

RETENTION SPECIFICATION

RETENTION IS A BOUNDARY

Technocore retains a bounded public activity window. Older records can be evicted under rolling retention limits.

TC-Ledger can prove what is represented by the evidence artifact; it cannot reconstruct records that are no longer retained.

Current retained activity โ‰  complete lifetime history.
DUAL OPERATING MODES

LIVE TECHNOCORE VS. SYNTHETIC DEMO

The Explorer maintains strict separation between live network discovery and deterministic offline test suites.

โ— LIVE TECHNOCORE

Live Network Discovery

Queries real public Technocore retained room streams (such as #tclk-offers and #lobby) directly via browser CORS or through the local read-only indexer adapter.

  • Queries actual retained NDJSON exports
  • Performs in-browser WebCrypto Ed25519 signature checks
  • Honest ACTIVE, STALE, and NO DATA FOUND status
  • Zero silent fallback: Network or API failures fail closed with explicit diagnostic errors
โ—† SYNTHETIC DEMO

Deterministic Demonstration

Uses authentic, self-contained synthetic fixtures (Bob, Alice) to demonstrate active, stale, and non-existent identity states in an isolated sandbox.

  • 100% offline, zero network dependencies
  • Frozen v0.3.1 cryptographic fixture vectors
  • Demonstrates inclusion proof audit paths
  • Demonstrates tampered payload rejection
IN-BROWSER PROTOCOL SANDBOX

Deterministic In-Browser Verification Demo

Embedded with actual v0.3.1 test vectors (examples/record_1.bin & examples/proof_leaf1.json). Hashes are calculated live in your browser using pure Web Crypto API (SHA-256) to demonstrate that records are tamper-evident relative to a previously recorded root.

Raw Record Bytes (Leaf Index 1): Authentic
RFC 6962 Verification Steps: VALID
โœ“
1. Ed25519 Signature Format
Valid 86-char canonical Base64URL encoding
โœ“
2. Deterministic Evidence Commitment (JCS)
tc-ledger:v1:0c7764d88e63b6514ec63eef2ecf30ad8dfd2a02e604fef5743431eb35ec7b6b
โœ“
3. Leaf Hash SHA-256(0x00 || record_bytes)
13dbfe722146b058fe8a560b87ac56be426fc785f907fa061121bd5743d21149
Matches proof leaf hash โœ“
โœ“
4. Reconstructed Root from Audit Path
0373cfc78e0b17cd733fd38318af51e119ef366954b0a0fbcba251ef15b066b9
Matches Committed Export Root (Gen 1) โœ“
Verification Succeeded: The raw record bytes match leaf index 1 of the committed export root. Inclusion proof is valid against the committed root.
ENGINEERING METRICS

RELEASE v0.4.0 TEST RIGOR

Frozen cryptographic core preserved from v0.3.1. Zero breaking changes to Merkle trees, schemas, or C0โ€“C7 verification logic.

205
Python Unit, Conformance & Integration Tests
9
Live Technocore Indexer Tests
36
Deployed Browser Journeys
0
Browser Journey Failures

READ THE CODE

Inspect the implementation, schemas, vectors, tests, and verification boundaries yourself. Everything is Apache 2.0 open-source.