WARPNET ARCHITECTURE

This document outlines the architectural structure of Warpnet, including its core components and how they interact.

CORE COMPONENTS

1.NODE

Each Warpnet instance is a self-contained node responsible for:

- Storing the user’s data locally (using BadgerDB)

- Connecting to other peers via libp2p

- Exchanging encrypted messages

- Enforcing local moderation and storage policies (TODO)

- Agreeing on some network state via Raft

Nodes form the backbone of the network. There is no central server — only independent peers.

Node types:

Warpnet defines four primary node roles. All nodes are technically equal in protocol rights; these types are defined by behavior and configuration, not protocol-level enforcement.

1.Bootstrap Node

- Provides initial peer discovery via DHT or mDNS

- Does not store user content or application-layer content

- Acts as a relay for initial connectivity

2.Member Node

- Standard user node

- Stores profile, timeline, chats, and peer data locally

- Fully participates in message exchange

3.Business Node (TODO)

- Special-purpose node representing an organization or service

- May publish sponsored content

4.Moderator Node

- Configured for content filtering and moderation

- May run AI models (e.g., via llama.cpp)

- Flags or blocks content based on custom policies

2.IDENTITY

Each Warpnet node has a cryptographic identity defined by the libp2p stack. This identity is used to uniquely identify peers at the transport layer and establish encrypted channels.

- Nodes are assigned an asymmetric keypair on first startup (e.g., Ed25519 or RSA)

- The public key is hashed using SHA-256 to generate a stable Peer ID

- The Peer ID is used for:

- Stream routing

- Peer discovery

- Signature verification of message envelopes

- Noise handshake (in libp2p-noise mode)

Warpnet does not expose Peer IDs as usernames or global handles. They are used strictly within the transport and trust layer.

Example:

`QmZxu3P3AnkVxyz...` ← libp2p Peer ID (Base58 of public key hash)

PSK and network access:

In addition to identity, Warpnet uses a Pre-Shared Key (PSK) to define network access boundaries.

- The PSK is injected into the libp2p transport layer using libp2p/pnet (private networks)

- Peers must prove possession of the same PSK to connect

- Even valid Peer IDs are rejected if the PSK does not match

Peer identity does not equal network membership. Only peers with a valid PSK and known public key can participate in the Warpnet overlay.

3.NETWORKING

Warpnet uses libp2p for peer discovery and transport abstraction. Networking includes:

- Direct peer-to-peer connections

- Bootstrap node discovery via shared keys and static IPs

- Gossip-style broadcast for timeline propagation

- Latency-based routing (optional future ad delivery)

- Relay traffic routing

NAT traversal is attempted via libp2p’s built-in mechanisms.

Peer discovery and topology:

- Bootstrap nodes provide initial peer lists via static DNS/IP and shared PSK

- After the first connection, peers share additional addresses

- Peers are cached locally and reconnected opportunistically

- Warpnet uses DHT and mDNS discovery by default

4.STORAGE LAYER

Storage is strictly local. No data is replicated unless the user configures backup or export mechanisms manually.

5.MODERATION

Warpnet filters and moderates content on a per-node basis. It is supported by an LLM moderator node using llama.cpp and Llama 7B Chat AI model.

6.SECURITY MODEL

Warpnet employs a layered security architecture spanning peer-to-peer transport, user interface communication, and message-level authenticity.

Peer-to-Peer Transport Security (Noise + PSK):

All connections between Warpnet nodes are secured using the Noise Protocol Framework via the libp2p transport layer.

- The XX or IK Noise handshake provides mutual authentication and forward secrecy

- Session keys are derived using ephemeral key exchanges

- All communication is encrypted and authenticated

Additionally, all nodes must present a valid Pre-Shared Key (PSK) to participate in the Warpnet overlay. The PSK acts as a cryptographic admission token.

PSK Generation:

The PSK is deterministically derived from:

- Network identifier (e.g., "testnet")

- Hash of the node’s codebase random samples

- Major version number

- Local entropy (anchored randomness)

This ensures that only nodes running matching versions and code can join the same network.

7.CONSISTENCY MODEL

Warpnet implements a hybrid consistency model combining local transactional guarantees with eventual global consistency across the peer-to-peer network.

Local Consistency (ACID):

Each Warpnet node uses an embedded BadgerDB key-value store, which provides:

- ACID properties for local operations

- Strict write ordering for messages and state transitions

- Deterministic merge behavior via sortable keys (e.g., prefixed by timestamp or logical counter)

This ensures that within a single node:

- Messages are stored and processed in a defined, conflict-free order

- Timeline entries and chats are persisted reliably, even across crashes

- Local views are fully consistent and fault-tolerant

Global Consistency (Eventual):

Between nodes, Warpnet relies on eventual consistency:

- Messages may arrive in any order and with delay

- There is no global clock, only logical timestamps or per-node counters

- Timeline reconstruction is based on:

- Origin node ID

- Origin user ID

- Local message timestamp

Each node independently merges remote updates into its local view according to its own consistency rules. There is no centralized coordination or conflict resolution mechanism.

Summary:

Local state is strictly ordered and consistent. Global state is eventually convergent but unordered.