Skip to main content

​
Temporal Navigation Protocol

​
What is it?

TNP is the foundation of TimeChain. It defines how time and history are represented in the system. Think of it as the rules that describe the “reality” of your collaborative space.

​
What does it do?

  • Organizes edits, events, and operations across multiple timelines.
  • Ensures every change has a place in time.
  • Maintains the causal relationships between actions.
  • Acts as the “map” for all operations in TimeChain.

​
Summary

TNP is like a city blueprint — it doesn’t tell people what to build, but it defines the streets, plots, and layers where everything goes.

​
Fork Node Protocol

​
What is it?

FNP is the engine that handles changes and updates to documents or shared state. It’s responsible for making changes safe, mergeable, and conflict-free.

​
What does it do?

  • Applies edits in real-time using CRDTs (data structures that merge automatically).
  • Handles multiple timelines (“forks”) so users can explore alternative versions.
  • Works entirely on encrypted data.
  • Uses cryptography to ensure operations are legitimate.

​
Summary

FNP is like a highly skilled librarian who can organize all versions of a book, including drafts, edits, and parallel storylines — without ever reading the actual content.

​
Verified Event Sequence Trust

​
What is it?

VEST is the proof system that verifies every change. It makes sure nothing is faked or lost.

​
What does it do?

  • Checks that every edit is valid and authorized.
  • Provides a verifiable history of all operations.
  • Uses cryptography and zero-knowledge proofs so the server or other users cannot tamper with data.
  • Guarantees accountability while preserving privacy.

​
Summary

VEST is like a trusted notary who stamps every action, proving it happened exactly as claimed, without needing to see the content.

​
Weighted Event-Adaptive Vector Exchange

​
What is it?

WEAVE is the network layer that moves operations between peers. Instead of relying on a central server, it forms a dynamic, self-organizing mesh of participants.

​
What does it do?

  • Sends edits and updates across the network efficiently.
  • Ensures all peers receive operations, even if some go offline.
  • Automatically optimizes routes and recovers missing data.
  • Makes the system resilient to network failures and partitions.

​
Summary

WEAVE is like a group of couriers who deliver letters directly between neighbors, automatically choosing the fastest and safest path, even if some streets are blocked.

​
Putting It All Together

TimeChain is the combination of these four layers working together:
LayerPurpose
TNPDefines the structure of time and causality
FNPHandles encrypted changes, merges, and forks
VESTVerifies every operation and maintains trust
WEAVEMoves operations between peers efficiently
Summary analogy:
  • TNP = the city map
  • FNP = the librarian organizing changes
  • VEST = the notary certifying each action
  • WEAVE = the courier network delivering edits
Together, TimeChain enables private, real-time collaboration that is resilient, verifiable, and scalable, even without a central server.

​
1. Executive Summary

Purpose: Provide a high-level overview for stakeholders of all technical backgrounds. Contents:
  • Introduction to TimeChain: vision, goals, and novelty.
  • Core protocols: FNP (ForkNode), VEST, WEAVE.
  • Problems solved (traditional systems failings, e.g., server trust, P2P scalability, real-time collaboration challenges).
  • Brief explanation of architecture layers:
Application Layer
   └── ForkNode (FNP) — CRDT logic
        └── VEST — cryptographic validation
             └── WEAVE — transport mesh
Visual Reference:

​
2. Introduction & Motivation

Purpose: Lay out the research problem, context, and motivation. Contents:
  • Limitations of current collaborative systems.
  • Challenges in cryptographic real-time collaboration:
    • End-to-end privacy
    • Scalability
    • Forkable timelines
    • Offline-first reliability
  • Definition of novel concepts:
    • Multi-timeline states
    • Verifiable operation consensus
    • Mesh-native operation propagation
  • Goals for TimeChain as a trustless, scalable, end-to-end encrypted collaboration framework.
Visual Reference:

​
3. Protocol Overview

Purpose: Introduce each protocol layer at a high level and show interactions.

​
3.1 ForkNode Protocol (FNP)

  • CRDT design: mergeable operation objects
  • Homomorphic operations (encrypted state transformation)
  • Causal DAG structure
  • Forkable timeline semantics
  • Post-quantum cryptography
  • Operation packet content:
struct ForkNodeOp {
    payload: EncryptedPayload
    causal_parents: Vec<Hash>
    vector_clock: HashMap<PeerID, LamportTimestamp>
    zk_proof: ZKProof
    signature: PQSignature
}
Mermaid Example:

​
3.2 VEST Protocol (Verifiable Operation Consensus)

  • Purpose: cryptographically validate operations
  • ZK proof verification
  • Post-quantum signature validation
  • Merkle DAG inclusion proofs
  • Operation ordering / timeline verification
  • Packet content:
struct VESTOp {
    op_hash: Hash
    user_signature: Signature
    server_signature: Signature
    merkle_proof: Vec<Hash>
    timestamp_proof: RoughtimeProof
}
Mermaid Example (Audit Flow):

​
3.3 WEAVE Protocol (Mesh Transport Layer)

  • Fully dynamic mesh of peers
  • Server demoted to “fast peer”
  • Gossip protocol for operation propagation
  • Missing operation recovery (Have/Want messages)
  • Adaptive routing and latency optimization
  • Offline-first resilience
  • Packet content:
struct MeshOperation {
    content_hash: Hash
    parent_hashes: Vec<Hash>
    payload: SignedPayload
    timestamp: LamportClock
}

struct HaveMessage {
    peer_id: PeerID
    operation_hashes: BloomFilter
}

struct WantMessage {
    operation_hashes: Vec<Hash>
    preferred_peer: Option<PeerID>
}
Mermaid Example (Mesh Topology):

​
4. Data Models & Packet Structures

Purpose: Define every message, operation, and proof type in the protocol.
  • ForkNode operation packets
  • VEST verification packets
  • WEAVE transport packets (Have / Want / Operation)
  • Bloom filter usage for compact representation
  • Merkle DAG structures
  • Vector clocks and Lamport timestamps
Mermaid Example (Causal DAG):

​
5. Consensus & Validation

Purpose: Formal definitions of how nodes agree and verify operations.
  • VEST consensus rules
  • CRDT merge validation
  • Fork resolution policies
  • ZK verification
  • Post-quantum signature verification
  • Conflict resolution strategies
  • Merkle inclusion verification
Mermaid Example (Consensus Flow):

​
6. Network Layer & WEAVE Routing

Purpose: Fully describe the dynamic mesh, routing, and operation propagation.
  • Peer discovery and connection establishment
  • Multi-hop gossiping
  • Adaptive routing algorithm
  • Bloom filter optimization for bandwidth
  • Handling partitions and peer failures
  • Offline-first synchronization
  • Optional server acceleration
Mermaid Example (Routing Flow):

​
7. Security Model

Purpose: Define cryptographic guarantees.
  • Post-quantum signature schemes
  • ZK proof assumptions
  • Tamper-proof Merkle DAGs
  • Anti-replay / nonce schemes
  • Peer authentication & Sybil resistance
  • Privacy guarantees (end-to-end encryption)

​
8. Performance & Scalability

Purpose: Provide expected performance metrics.
  • Operational complexity (O(log n), O(1) in typical operations)
  • Gossip bandwidth estimates
  • Latency under different peer counts
  • Scalability limits of DAG / mesh
  • Offline operation propagation statistics
Mermaid Example (XY Chart for Latency vs Peer Count):

​
9. Deployment & Maintenance Guidelines

Purpose: Guide real-world deployment.
  • Bootstrapping TimeChain networks
  • Mesh peer management
  • Operational monitoring
  • Upgrade procedures
  • ForkNode / VEST / WEAVE versioning
  • Handling network partitions and recovery

​
10. R&D & Experimentation Index

Purpose: Act as a knowledge index for ongoing research.
  • References to post-quantum crypto papers
  • References to CRDT literature
  • Benchmarks for gossip and latency
  • Test harnesses for ForkNode DAG merges
  • Simulated attack vectors
  • Verification engineer checklists
  • Continuous integration / automated verification frameworks
Mermaid Example (Knowledge Index Map):

​
11. Glossary & Notation

  • Standardize terms across TNP, ForkNode, VEST, WEAVE
  • Symbols, DAG node definitions, vector clocks, hashes
  • Naming conventions for packet fields

​
12. References & Resources

  • Research papers, RFCs, cryptography references
  • Open-source libraries and toolkits
  • Future recommended experiments
  • Cross-references to temporal collaboration literature

​
✅ Outcome

This specification document fully defines the scope, contents, and visual references for the TimeChain whitepaper. It also functions as the master knowledge index: every future protocol, experiment, deployment guide, and verification task should map to one of these sections.
I can next produce a visual architecture diagram combining all 4 layers (TNP + FNP + VEST + WEAVE) including packet flow, DAG references, and verification paths for maximum clarity. Do you want me to generate that next?