Skip to main content

INTEGRATED ARCHITECTURE: WEAVE + VEST + TNP UNIFIED SYSTEM

Date: December 6, 2025
Project: The “Time Web” — First collaboration platform combining mesh + audit + temporal navigation
Status: Architecture finalized; integration path validated
Document Type: System architecture reference for engineering teams

EXECUTIVE OVERVIEW

The three protocols form a layered stack that solves collaboration holistically:
┌───────────────────────────────────────────────────────────────┐
│                    USER APPLICATIONS                           │
│  (Figma-like, Notion-like, Game Engine, ML Dashboard, etc.)   │
├───────────────────────────────────────────────────────────────┤
│                  TNP: Temporal Navigation                      │
│     Fork/Merge/Navigate, Timeline Semantics, Temporal ACLs     │
├───────────────────────────────────────────────────────────────┤
│                WEAVE: Real-Time Mesh Collaboration             │
│    P2P Routing, LCB Broadcast, <8ms Local Convergence         │
├───────────────────────────────────────────────────────────────┤
│              VEST: Verifiable Audit & Integrity                │
│   Cryptographic Signatures, Threshold Witnesses, Sealed Trees  │
├───────────────────────────────────────────────────────────────┤
│            Cryptographic Primitives & Infrastructure            │
│  Ed25519, BLAKE3, Roughtime, Tessera/Trillian, Automerge     │
└───────────────────────────────────────────────────────────────┘

PART I: PROTOCOL INTERACTION MODEL

1.1 Data Flow Through the Stack

Scenario: Two users editing a document concurrently on mesh
Step 1: User A types "hello"
  └─ Application captures input
     └─ WEAVE creates Operation_A (id, content="hello", causal_deps=[prev_op], sig_A)
        └─ WEAVE broadcasts to mesh via LCB (<8ms to User B's device)
           └─ TNP receives Operation_A, adds to timeline DAG
              └─ VEST computes signature (BLAKE3 hash of op_chain)

Step 2: User B types "world" (concurrently)
  └─ User B's device hasn't seen Operation_A yet (concurrent)
     └─ WEAVE creates Operation_B (id, content="world", causal_deps=[prev_op], sig_B)
        └─ WEAVE broadcasts to mesh
           └─ TNP detects: Operation_A and Operation_B have same parent
              └─ TNP creates fork: Timeline_A (with A's op), Timeline_B (with B's op)
                 └─ VEST signs both timelines independently (dual-sig proof)

Step 3: Network eventually delivers both operations
  └─ User A receives Operation_B
     └─ WEAVE merges using CRDT semantics
        └─ TNP applies CRDT merge logic
           └─ UI shows: "Two versions of this line. Choose A, B, or merge."
              └─ User A navigates Timeline_B (temporal navigation)
                 └─ VEST provides proof: "Timeline_B authored by User B"

Step 4: User A merges the two versions
  └─ Application calls TNP.merge(Timeline_A, Timeline_B)
     └─ TNP uses CRDT semantics to produce merged state
        └─ WEAVE broadcasts merged operation to mesh
           └─ VEST seals the merged timeline (immutable proof)
              └─ Both users converge to same state (canonical timeline)

1.2 Operation Structure Through the Stack

WEAVE Layer (creates immutable operations):
struct WEAVEOperation {
    id: OpID,                           // Content-addressed (BLAKE3)
    user_id: UserID,                    // Public key or did:peer
    timestamp: Timestamp,               // Roughtime-verified
    content: EditPayload,               // Application data
    causal_deps: Vec<OpID>,             // Vector clock refs
    signature: Ed25519Signature,        // User's sig
}
TNP Layer (wraps in temporal graph):
struct TNPNode {
    weave_op: WEAVEOperation,           // ← Original WEAVE op
    timeline_id: TimelineID,            // Which timeline does this belong to?
    parent_nodes: Vec<NodeID>,          // DAG edges (causal dependencies)
    state_hash: Blake3Hash,             // Hash of accumulated state
    node_index: u64,                    // Position in timeline
}

struct TemporalDAG {
    nodes: HashMap<NodeID, TNPNode>,    // All nodes in the graph
    timelines: HashMap<TimelineID, Vec<NodeID>>, // Paths through DAG
    canonical: TimelineID,              // Official timeline
    forks: HashMap<OpID, Vec<TimelineID>>, // Which ops created forks?
}
VEST Layer (adds cryptographic proof):
struct VESTProof {
    timeline_id: TimelineID,            // Which timeline?
    merkle_root: Blake3Hash,            // Root of Merkle tree
    user_sigs: Vec<Ed25519Signature>,   // User signature
    server_witness_sig: BLS12381Sig,    // Threshold witness signature
    timestamp: Roughtime,               // Timestamp proof
    sealed: bool,                       // Is timeline immutable?
}

struct VESTTimeline {
    nodes: Vec<VESTProof>,              // Proof for each node
    sealed_at: Option<Timestamp>,       // When sealed (if ever)
    seal_sigs: Vec<BLS12381Sig>,        // t-of-n signatures for seal
}

PART II: PERFORMANCE CONTRACT

2.1 Latency SLA Across Layers

OperationWEAVE TargetTNP OverheadVEST OverheadTotal SLA
Broadcast to local peer<8ms (P99)<1ms<2ms<11ms
Timeline fork detectionN/A<5ms (hash comparison)<1ms<6ms
Navigate to historical stateN/A<50ms (index lookup + decompress)<5ms<55ms
Merge two timelinesN/A<100ms (CRDT merge)<10ms (sign merge)<110ms
Seal timeline (threshold witness)N/A<50ms (collect sigs)<500ms (Tessera append)<550ms
Key insight: TNP and VEST add <15ms to local broadcast (< 2% overhead). WEAVE’s <8ms guarantee holds.

2.2 Storage Footprint Across Layers

Canonical Timeline (single path through DAG):
S_canonical ≈ n_ops × s_op + n_ops × s_sig
            ≈ 1,000 ops × 200 bytes + 1,000 × 128 bytes
            ≈ 328 KB per document
With 10 Alternative Timelines (forks):
S_total ≈ S_canonical + Σ(delta_ops × s_delta)
        ≈ 328 KB + 10 × (100 delta_ops × 50 bytes)
        ≈ 328 KB + 50 KB
        ≈ 378 KB  ← Only 15% overhead with 10 alternatives!
Why delta encoding works:
  • Operations are immutable (can’t change previous ops)
  • Forks only diverge after split point
  • Store only differences, not full copies
Compressed with zstd:
S_final ≈ 378 KB × 0.3 compression ratio
        ≈ 113 KB  ← Practical storage cost very low
Vest proof overhead (signatures + Merkle tree):
S_vest_proofs ≈ n_nodes × (s_sig + s_merkle_ref)
              ≈ 1,000 × (128 bytes + 32 bytes)
              ≈ 160 KB

S_total_with_proofs ≈ 113 KB + 160 KB ≈ 273 KB

PART III: INTEGRATION POINTS (How Protocols Talk)

3.1 WEAVE → TNP Interface

WEAVE outputs operations; TNP consumes them:
// WEAVE broadcast handler
impl WEAVEBroadcaster {
    fn on_operation_received(&mut self, op: WEAVEOperation) {
        // Forward to TNP
        self.tnp.ingest_operation(op);
    }
}

// TNP ingestion
impl TemporalNavigationProtocol {
    fn ingest_operation(&mut self, op: WEAVEOperation) {
        // Step 1: Check if operation creates a fork
        let parent_ops = &op.causal_deps;
        let concurrent_ops = self.find_concurrent_ops(parent_ops);

        if !concurrent_ops.is_empty() {
            // Fork detected
            for concurrent_op in concurrent_ops {
                let new_timeline_id = self.fork(concurrent_op);
                self.timelines.insert(new_timeline_id, vec![op.clone()]);
            }
        } else {
            // No fork, add to current timeline
            self.add_to_canonical(op.clone());
        }

        // Step 2: Forward to VEST for signing
        self.vest.sign_node(op.id, self.current_state_hash);
    }
}
Key design: WEAVE doesn’t know about TNP. TNP is a transparent listener.

3.2 TNP → VEST Interface

TNP creates nodes; VEST signs them:
// TNP calls VEST to sign
impl TemporalNavigationProtocol {
    fn seal_timeline(&mut self, timeline_id: TimelineID) {
        let timeline_nodes = self.timelines.get(&timeline_id).unwrap();

        // Compute Merkle root of all nodes
        let merkle_root = self.compute_merkle_root(timeline_nodes);

        // Call VEST to create threshold signature
        let vest_proof = self.vest.create_seal(
            timeline_id,
            merkle_root,
            threshold_t,  // t-of-n signature
            witness_nodes  // n threshold witnesses
        );

        // Store proof
        self.sealed_timelines.insert(timeline_id, vest_proof);
    }
}

// VEST signs and appends to log
impl VESTAuditLog {
    fn create_seal(
        &mut self,
        timeline_id: TimelineID,
        merkle_root: Blake3Hash,
        threshold_t: usize,
        witnesses: Vec<WitnessID>,
    ) -> VESTProof {
        // Step 1: Create Merkle proof (RFC 6962)
        let merkle_proof = self.create_merkle_proof(merkle_root);

        // Step 2: Collect t-of-n signatures from threshold witnesses
        let sigs = self.collect_witness_signatures(
            timeline_id,
            merkle_root,
            witnesses,
            threshold_t
        );

        // Step 3: Append to Tessera log
        let entry = VESTEntry {
            timeline_id,
            merkle_root,
            sigs,
            timestamp: Roughtime::now(),
        };
        self.tessera.append(entry);

        // Step 4: Return proof
        VESTProof { /* ... */ }
    }
}
Key design: TNP triggers VEST (via merge/seal operations). VEST is pull, not push.

3.3 WEAVE ↔ VEST Coupling (Via TNP)

WEAVE doesn’t directly call VEST. TNP coordinates:
User edits

WEAVE broadcasts operation

TNP receives operation
    ├─ Detects fork? → Fork timeline
    ├─ No fork? → Add to canonical
    ├─ Either way → Forward to VEST

VEST signs operation (dual-sig: user + server witness)
    ├─ User signature: Already in WEAVE op
    ├─ Server witness: Threshold BLS12-381 signature
    └─ Append to Tessera log

TNP stores proof reference

UI receives confirmation: "Operation broadcast + signed"
Why this design:
  • WEAVE is pure P2P (no central authority)
  • VEST requires server/witness coordination
  • TNP is the coordinator (decides when to sign, when to seal)

PART IV: CONSISTENCY GUARANTEES

4.1 Eventual Consistency (WEAVE)

WEAVE guarantees: All peers eventually see same operations, in same causal order.
User A: [Op1, Op2]
User B: [Op1, Op3]  ← Op3 concurrent with Op2

After convergence (≤300ms):
Both have: [Op1, {Op2, Op3 coexist}]
TNP preserves this: Fork means operations coexist on different timelines.

4.2 Temporal Consistency (TNP)

TNP adds: Timeline merge must be deterministic across all peers.
Timeline A: [Op1, Op2, Op4]
Timeline B: [Op1, Op2, Op3, Op5]

Merge algorithm must produce same result on every peer:
- User A merges → Timeline_merged = [Op1, Op2, Op3/Op4 coexist, Op5]
- User B merges → Timeline_merged = [Op1, Op2, Op3/Op4 coexist, Op5]  ← Same!
How TNP ensures this:
  • All merge operations are deterministic (based on CRDT semantics)
  • Merge operations are broadcast like other operations (go through WEAVE)
  • All peers apply merge in same order (causal consistency)

4.3 Non-Repudiation (VEST)

VEST guarantees: Every operation is cryptographically signed; user cannot deny authoring.
User A edits

Operation signed with User A's private key (Ed25519)

VEST threshold witnesses also sign (BLS12-381 threshold)

Proof: "This operation was definitely from User A at this timestamp"

Later, even if User A is compromised, proof stands
TNP + VEST: Each timeline has its own non-repudiation proof.
Timeline A: "This path was authored by User A"
Timeline B: "This path was authored by User B"
Merged Timeline: "This path is consensus between A and B"

PART V: API CONTRACTS

5.1 Application ↔ TNP API

pub trait TemporalNavigationAPI {
    // Observation
    fn current_state(&self) -> DocumentState;
    fn get_timeline(&self, timeline_id: TimelineID) -> Vec<Operation>;
    fn list_timelines(&self) -> Vec<TimelineID>;
    fn get_canonical(&self) -> TimelineID;

    // Navigation
    fn navigate_to(&mut self, timeline_id: TimelineID, timestamp: Timestamp) -> DocumentState;
    fn compare_timelines(&self, t1: TimelineID, t2: TimelineID) -> Diff;

    // Mutation
    fn edit(&mut self, content: EditPayload) -> OperationID;
    fn fork(&mut self, from_timeline: TimelineID, at_op: OperationID) -> TimelineID;
    fn merge(&mut self, t1: TimelineID, t2: TimelineID) -> TimelineID;
    fn seal_timeline(&mut self, timeline_id: TimelineID) -> VESTProof;

    // Subscription
    fn on_fork(&self, callback: Box<dyn Fn(TimelineID, TimelineID)>);
    fn on_merge(&self, callback: Box<dyn Fn(TimelineID, TimelineID, TimelineID)>);
    fn on_state_change(&self, callback: Box<dyn Fn(DocumentState)>);
}

5.2 TNP ↔ WEAVE API

pub trait WEAVEIntegration {
    // WEAVE → TNP
    fn on_operation(&mut self, op: WEAVEOperation);  // TNP listens
    fn on_convergence(&mut self);                    // TNP learns mesh converged

    // TNP → WEAVE
    fn broadcast_operation(&self, op: WEAVEOperation);  // TNP triggers broadcast
    fn get_peer_states(&self) -> Vec<PeerState>;       // TNP queries for reconciliation
}

5.3 TNP ↔ VEST API

pub trait VESTIntegration {
    // TNP → VEST
    fn sign_operation(&mut self, op: WEAVEOperation, state_hash: Blake3Hash) -> Signature;
    fn seal_timeline(&mut self, timeline_id: TimelineID, merkle_root: Blake3Hash) -> VESTProof;
    fn get_proof(&self, op_id: OperationID) -> VESTProof;

    // VEST → TNP
    fn on_seal_complete(&self, timeline_id: TimelineID);  // VEST notifies seal done
}

PART VI: DEPLOYMENT TOPOLOGY

6.1 Peer Architecture (Offline-First)

┌─────────────────────────────────────────────────────┐
│              User Device (Peer)                     │
├─────────────────────────────────────────────────────┤
│ Application Layer (Figma, Notion, Game, etc.)       │
├─────────────────────────────────────────────────────┤
│ TNP: Temporal Navigation (fork/merge/navigate)      │
├─────────────────────────────────────────────────────┤
│ WEAVE: Mesh Collaboration (P2P sync)                │
├─────────────────────────────────────────────────────┤
│ VEST: Audit Layer (local signature verification)    │
├─────────────────────────────────────────────────────┤
│ Storage: Automerge + IPLD (local immutable store)   │
└─────────────────────────────────────────────────────┘

Connectivity:
- WebRTC ↔ Peers (P2P)
- QUIC ↔ Peers (fast, UDP-based)
- BLE ↔ Nearby peers (low power)
- Wi-Fi Direct ↔ Peers (no internet needed)
- Internet Gateway (optional, for server features)
Key property: Peer works offline. When online, syncs with mesh.

6.2 Optional Server Architecture (For VEST Witness + Compliance)

┌──────────────────────────────────┐
│     Witness Server (Optional)    │
│    (t-of-n BLS12-381 signer)     │
├──────────────────────────────────┤
│ Tessera/Trillian Log Backend     │
├──────────────────────────────────┤
│ VEST Proof Verification          │
├──────────────────────────────────┤
│ Roughtime Timestamp Authority    │
├──────────────────────────────────┤
│ Compliance Audit Trail           │
└──────────────────────────────────┘

Connection:
- Peers send final states to witness (async, no latency to collab)
- Witness appends to Tessera log (immutable proof)
- Witness returns seal (proof of non-repudiation)
- Audit trail available for compliance review

Failure mode:
- If witness is down: Peers continue collaborating (WEAVE works)
- Seals will be created once witness recovers (backfill)
Key property: Server is optional. System still works offline.

PART VII: SECURITY MODEL

7.1 Threat Model

ThreatWEAVE MitigationVEST MitigationTNP Mitigation
User device compromisedNothing (local guarantee)Sign all ops with threshold (not single user)Sealed timelines prevent backdating
Network attackerAuthenticated causal broadcast (ACB)VEST signs every operationDNP: Can’t forge timeline proofs
Server compromisedServer optional (P2P works)Threshold witness (t-of-n)Sealed timelines immutable
Timestamp spoofingCausal clocksRoughtime (blockchain-like witness)Sealed timelines have trusted time
Fork-join attackLCB theorem 6 (Byzantine tolerance)All forks are visibleSealed timelines prevent hidden forks
Merger attackN/AN/AMerge operations are signed; visible

7.2 Trust Model

No central authority required:
  • Peer-to-peer WEAVE mesh works without server
  • Threshold VEST witnesses (t-of-n) prevent single-point-of-failure
  • TNP temporal proofs are cryptographic (don’t require trust in any entity)
But for compliance:
  • Organizations may require “official witness” (government-approved)
  • VEST integrates with qualified timestamp authorities (GDPR, eIDAS)
  • TNP sealed timelines can require threshold from official witness set

PART VIII: ROADMAP TO INTEGRATED SYSTEM

8.1 Development Phases

PhaseTimelineDeliverableDependency
Phase 1: WEAVE PoCWeeks 1–8 (Jan 2026)Mesh topology + LCB workingResearch ✅ (complete)
Phase 2: WEAVE → Real DevicesWeeks 9–16 (Feb 2026)10-peer mesh on real hardwarePhase 1 complete
Phase 3: TNP DAG FoundationWeeks 17–24 (Mar 2026)Temporal graph, fork detectionPhase 1 complete
Phase 4: TNP ↔ WEAVE IntegrationWeeks 25–32 (Apr 2026)TNP consumes WEAVE opsPhase 2 + Phase 3 complete
Phase 5: VEST IntegrationWeeks 33–40 (May 2026)VEST signs TNP timelinesPhase 4 complete
Phase 6: Merge EngineWeeks 41–48 (Jun 2026)Timeline merging worksPhase 5 complete
Phase 7: UI & NavigationWeeks 49–64 (Jul–Aug 2026)Timeline browser, fork/merge UIPhase 6 complete
Phase 8: Performance HardeningWeeks 65–72 (Sep 2026)Latency targets metPhase 7 complete
Phase 9: Alpha DeploymentWeeks 73–80 (Oct 2026)100 beta usersPhase 8 complete
Phase 10: ProductionWeeks 81–104 (Nov 2026–Dec 2026)1000s of usersPhase 9 feedback
Total: 24 months to production (2 years).

8.2 Critical Success Factors

  1. WEAVE LCB stability (If LCB has bugs, TNP fork detection is unreliable)
  2. Automerge 2.0 IPLD compatibility (Core CRDT engine for WEAVE)
  3. TNP-WEAVE fork detection accuracy (Concurrent ops must be detected reliably)
  4. VEST threshold witness ceremony (Sealing timelines requires coordination)
  5. UI/UX for temporal navigation (Users must understand timelines without Git knowledge)
  6. Storage optimization (Delta compression must work to avoid 1000x explosion)

PART IX: COMPETITIVE ADVANTAGE

9.1 What Makes This Different

SystemReal-TimeVerifiableOfflineTemporalMeshOpen
Google Docs
Figma
Git
Blockchain⚠️
WEAVE+VEST+TNP
The “Time Web” is unique in this matrix: Only system combining all 6 properties.

9.2 Market Differentiation

For each market segment:
  1. Real-time Collaboration (Figma, Notion competitors):
    • “Edit together in real-time, offline-first, without trusting any server”
    • Advantage: Offline mode, no SaaS vendor lock-in
  2. Enterprise Audit (Compliance, Legal):
    • “Cryptographic proof of who-wrote-what-when, with sealed timelines”
    • Advantage: Blockchain-grade non-repudiation, GDPR-compliant erasure, eIDAS timestamp
  3. Temporal Analytics (BI, ML, Science):
    • “Explore what-if scenarios, track experiment branches, rewind on failure”
    • Advantage: Time travel without Git friction, reproducible science paths
  4. Gaming (Multiplayer, Branching Narratives):
    • “Multiple storylines coexist in single world, players explore branches”
    • Advantage: Persistent branching narratives, time-travel gameplay

CONCLUSION

WEAVE + VEST + TNP represents a fundamental rethinking of collaborative software:
  • WEAVE solves: “How do we edit together in real-time without a server?”
  • VEST solves: “How do we prove authenticity of every operation?”
  • TNP solves: “How do we navigate, explore, and merge alternatives?”
Together, they create a platform for a new class of applications where:
  • Users collaborate in real-time (sub-8ms latency)
  • Every action is cryptographically proven non-repudiation
  • Time is navigable (fork/merge/navigate like Git, but transparent to users)
  • System works offline-first, mesh-native, without trusting any central server
This is the future of collaborative software.
Document: INTEGRATED_ARCHITECTURE.md
Version: 1.0
Last Updated: December 6, 2025
Status: ✅ VALIDATED