1  # Abzu: A Sovereign Mesh Network Protocol
  2  
  3  > **Technical Overview v0.2** — January 2026  
  4  > *A decentralized, censorship-resistant communication protocol built entirely in Rust.*
  5  >
  6  > *"The system should not depend on secrecy, and it should be possible for it to fall into enemy hands without inconvenience."* — Auguste Kerckhoffs, 1883
  7  
  8  ---
  9  
 10  ## Abstract
 11  
 12  Abzu is a multi-protocol mesh networking engine designed for censorship resistance, privacy, and sovereignty. It combines geometric routing techniques from overlay networks with content-addressed storage, wrapped in a stealth transport layer that evades deep packet inspection.
 13  
 14  This document describes the architecture, threat model, design decisions, and current implementation status.
 15  
 16  ---
 17  
 18  ## Table of Contents
 19  
 20  1. Vision and Motivation
 21  2. Threat Model
 22  3. Architecture Overview
 23  4. Core Components
 24  5. Cryptographic Foundations
 25  6. Transport Layer: FakeTLS
 26  7. Routing Layer: Geometric Routing
 27  8. Wire Protocol
 28  9. Content-Addressed Storage
 29  10. Control Plane
 30  11. Known Limitations and Threat Surface
 31  12. Current Status
 32  13. Roadmap
 33  14. Design Principles
 34  15. References and Prior Art
 35  
 36  ---
 37  
 38  ## Vision & Motivation
 39  
 40  ### Why Abzu Exists
 41  
 42  The internet was designed for resilience in wartime, but has evolved into a centralized surveillance apparatus. DNS, TLS certificate authorities, BGP, and cloud infrastructure create natural chokepoints that enable both state and corporate censorship.
 43  
 44  Abzu is designed to operate **beneath** this infrastructure — using the existing internet as a transport substrate while providing:
 45  
 46  - **No central servers** — No single point of failure or coercion
 47  - **No tracking** — No logs, no metadata collection, no user accounts
 48  - **Encrypted tunnels** — End-to-end encryption with forward secrecy
 49  - **Censorship resistance** — Traffic that looks like normal HTTPS
 50  
 51  ### Design Philosophy
 52  
 53  Abzu follows the **Sovereign OS** principle: your communication infrastructure should be something you *own*, not something you *rent* from a corporation. It implements the cryptographic equivalent of squatter's rights on the internet.
 54  
 55  ### Kerckhoffs' Principle: Open Design Security
 56  
 57  Abzu is designed to be **safe to open-source**. Its security derives entirely from:
 58  
 59  1. **Cryptographic primitives** (Ed25519, ChaCha20-Poly1305, BLAKE3) — publicly audited
 60  2. **Protocol design** — documented in this paper
 61  3. **Key secrecy** — the *only* secret is your private key
 62  
 63  An adversary with complete access to this document and the full source code gains no advantage. The architecture assumes Kerckhoffs' Principle: security through obscurity is not security at all.
 64  
 65  This is not a philosophical position — it's an operational requirement. The moment a protocol depends on implementation secrecy, it becomes vulnerable to reverse engineering, insider leaks, or simple observation. Abzu's threat model assumes the adversary has read this document.
 66  
 67  ---
 68  
 69  ## Threat Model
 70  
 71  ### Who Are We Defending Against?
 72  
 73  | Adversary | Capability | Abzu Defense |
 74  |-----------|------------|--------------|
 75  | **ISP/Carrier** | Traffic logging, DNS hijacking, IP blocking | FakeTLS masquerade, geometric routing |
 76  | **State Actor** | CALEA compliance, metadata analysis, BGP manipulation | No central infrastructure, cryptographic addressing |
 77  | **Passive Observer** | Traffic pattern analysis, flow correlation | Length-prefixed encrypted frames, keepalive noise |
 78  | **Active Attacker** | MITM injection, connection hijacking | Ed25519 identity verification, ChaCha20-Poly1305 AEAD |
 79  
 80  ### What Abzu Does NOT Defend Against
 81  
 82  > [!IMPORTANT]
 83  > **Honest Limitations — Read This Section**
 84  
 85  1. **Infrastructure-level attacks**: If your ISP physically disconnects you, or a state actor controls all network egress points in a region, no overlay network can help. Abzu runs *over* the existing internet, not around it.
 86  
 87  2. **Traffic analysis at scale**: A sufficiently powerful adversary monitoring all network traffic globally can perform timing correlation attacks. Abzu adds latency noise but does not implement full mix-network anonymity (see: Nym, Tor).
 88  
 89  3. **Endpoint compromise**: If your device is compromised (malware, physical access), the encryption is irrelevant. Abzu assumes a trusted local environment.
 90  
 91  4. **IANA/ARIN dependency**: IP addresses are centrally allocated. Abzu traffic still traverses the routed internet and is subject to BGP-level blocking. This is a fundamental constraint of any overlay network.
 92  
 93  5. **CALEA and lawful intercept**: While Abzu encrypts traffic end-to-end, carriers in the US are required to provide intercept capability at the network level. Abzu's defense is that intercepted traffic is encrypted and appears as normal TLS noise.
 94  
 95  **Philosophy**: We are honest about what we can and cannot do. Anyone claiming "total anonymity" is either lying or doesn't understand the problem space.
 96  
 97  ---
 98  
 99  ## Architecture Overview
100  
101  ```
102  ┌─────────────────────────────────────────────────────────────────┐
103  │                        Control Plane                             │
104  │                    JSON-RPC 2.0 (jsonrpsee)                     │
105  └─────────────────────────┬───────────────────────────────────────┘
106                            │
107  ┌─────────────────────────▼───────────────────────────────────────┐
108  │                       abzu-daemon                                │
109  │                   (CLI, Config, RPC Server)                      │
110  └─────────────────────────┬───────────────────────────────────────┘
111                            │
112            ┌───────────────┼───────────────┐
113            │               │               │
114  ┌─────────▼────┐  ┌───────▼──────┐  ┌─────▼─────────┐
115  │  abzu-core   │  │ abzu-router  │  │ abzu-transport│
116  │ ─────────────│  │ ─────────────│  │ ──────────────│
117  │ Node Engine  │  │ Spanning Tree│  │ AbzuFrame     │
118  │ Switchboard  │  │ Coordinates  │  │ FakeTLS       │
119  │ ContentStore │  │ Sovereign IP │  │ ChaCha20-Poly │
120  │ (Sled+BLAKE3)│  │ Derivation   │  │               │
121  └──────────────┘  └──────────────┘  └───────────────┘
122  ```
123  
124  ### Crate Structure
125  
126  | Crate | Responsibility | Key Types |
127  |-------|----------------|-----------|
128  | **abzu-core** | Node lifecycle, peer management, event loop, storage | `Node`, `Switchboard`, `ContentStore` |
129  | **abzu-router** | Pure-logic routing decisions (no I/O) | `RoutingTable`, `TreeCoords`, `Address` |
130  | **abzu-transport** | Wire protocol, encryption, DPI evasion | `AbzuFrame`, `FakeTlsStream`, `AbzuInterface` |
131  | **abzu-daemon** | CLI binary, configuration, RPC server | `Config`, RPC method handlers |
132  
133  ---
134  
135  ## Core Components
136  
137  ### 1. Node Engine (`abzu-core`)
138  
139  The `Node` struct is the central state container:
140  
141  ```rust
142  pub struct Node {
143      identity: SigningKey,           // Ed25519 private key
144      address: Address,               // Derived sovereign IPv6
145      router: Arc<RwLock<RoutingTable>>,
146      peers: Arc<Mutex<HashMap<PeerKey, PeerConnection>>>,
147      store: Db,                      // Sled embedded database
148      chats: Tree,                    // Persistent message storage
149      contacts: Tree,                 // Address book
150      pending_fetches: Arc<DashMap<[u8; 32], Arc<Notify>>>,
151      shutdown: Arc<Notify>,
152  }
153  ```
154  
155  **Key Design Decisions**:
156  
157  - **Ed25519 identity**: All addressing is derived from public keys. Your identity *is* your address.
158  - **Tokio async runtime**: Non-blocking event loop with `select!` for multiplexed I/O
159  - **Sled embedded DB**: Local-first persistence with atomic transactions
160  - **DashMap for pending fetches**: Lock-free concurrent map for content discovery coordination
161  
162  ### 2. Switchboard (`abzu-core/switchboard.rs`)
163  
164  Event dispatcher handling all frame types:
165  
166  | Incoming Frame | Action |
167  |----------------|--------|
168  | `KeepAlive` | Update peer activity timestamp |
169  | `Chunk` | Verify BLAKE3 hash, store in Sled, notify waiting fetches |
170  | `Route` | Check if target is local, process; else forward to next hop |
171  | `Request` | Check local store; if found, send `Chunk` back to requester |
172  | `Chat` | Decrypt, store in chat history, send `ChatAck` |
173  | `ChatAck` | Mark corresponding outbound message as delivered |
174  
175  ### 3. Peer Connections
176  
177  ```rust
178  pub struct PeerConnection {
179      pub interface: Box<dyn AbzuInterface>,  // Trait object for transport agility
180      pub last_activity: std::time::Instant,
181      pub tx_bytes: u64,
182      pub rx_bytes: u64,
183  }
184  ```
185  
186  The `AbzuInterface` trait enables transport swapping:
187  
188  ```rust
189  #[async_trait]
190  pub trait AbzuInterface: Send + Sync {
191      async fn send(&self, data: &[u8]) -> Result<(), TransportError>;
192      async fn recv(&self) -> Result<Vec<u8>, TransportError>;
193      async fn close(&self) -> Result<(), TransportError>;
194      fn is_connected(&self) -> bool;
195      fn local_addr(&self) -> Option<String>;
196      fn peer_addr(&self) -> Option<String>;
197  }
198  ```
199  
200  This allows the same node logic to work over TCP, UDP (future), QUIC (future), or even LoRa (aspirational).
201  
202  ---
203  
204  ## Cryptographic Foundations
205  
206  ### Identity: Ed25519
207  
208  Each node generates or loads an Ed25519 keypair on startup:
209  
210  - **Private key**: 32 bytes, never transmitted
211  - **Public key**: 32 bytes, serves as node identifier
212  - **Signature**: 64 bytes, used for message authentication
213  
214  **Why Ed25519?**
215  
216  - Fast signing and verification (critical for high-throughput routing)
217  - Small key sizes
218  - Deterministic signatures (no nonce management)
219  - Widely audited and trusted
220  
221  ### Encryption: ChaCha20-Poly1305
222  
223  All data encryption uses ChaCha20-Poly1305 AEAD:
224  
225  - **ChaCha20**: Stream cipher, constant-time, software-friendly
226  - **Poly1305**: Authenticator tag prevents tampering
227  - **Nonce**: 12 bytes, unique per message
228  
229  **Why not AES-GCM?**
230  
231  - ChaCha20 is faster in software (no AES-NI required)
232  - More resistant to timing attacks
233  - Preferred for embedded/mobile targets
234  
235  ### Hashing: BLAKE3
236  
237  Content addressing uses BLAKE3:
238  
239  - **Output**: 32 bytes
240  - **Speed**: Fastest cryptographic hash available
241  - **Merkle tree support**: Built-in for chunked content
242  - **Keyed mode**: Can be used as a MAC
243  
244  ---
245  
246  ## Transport Layer: FakeTLS
247  
248  ### Problem Statement
249  
250  Deep Packet Inspection (DPI) systems can identify and block non-standard protocols. Even encrypted traffic can be fingerprinted by packet sizes, timing, and handshake patterns.
251  
252  ### Solution: TLS 1.3 Masquerade
253  
254  Abzu's `FakeTlsStream` mimics a legitimate TLS 1.3 connection:
255  
256  **Connection Phase:**
257  
258  1. Client sends a valid TLS 1.3 `ClientHello` with randomized fields:
259     - Random session ID
260     - Legitimate cipher suites (AES-GCM, ChaCha20)
261     - SNI extension with plausible hostname
262  2. Server consumes and discards the `ClientHello` (we don't complete real TLS)
263  3. Both sides switch to Abzu's encrypted frame protocol
264  
265  **Post-Handshake Frame Format:**
266  
267  ```
268  [4 bytes: length (big-endian)]
269  [12 bytes: nonce]
270  [N bytes: ciphertext]
271  [16 bytes: Poly1305 tag]
272  ```
273  
274  **DPI Evasion Properties:**
275  
276  - Initial handshake looks like TLS 1.3
277  - Frame lengths are consistent with TLS records
278  - No distinguishing protocol headers after handshake
279  - Keepalive frames add traffic noise
280  
281  ### Limitations
282  
283  - Does not provide traffic analysis resistance (timing, volume patterns)
284  - Sophisticated adversaries may notice incomplete TLS handshake
285  - SNI hostname is visible until encrypted (ECH would help, future work)
286  
287  ### WebSocket Transport
288  
289  For browser and mobile client connectivity, Abzu also supports **WebSocket transport**:
290  
291  ```rust
292  pub struct WsStream {
293      sink: Arc<Mutex<SplitSink<WebSocketStream<TcpStream>, Message>>>,
294      stream: Arc<Mutex<SplitStream<WebSocketStream<TcpStream>>>>,
295      peer_addr: Option<String>,
296      connected: Arc<AtomicBool>,
297  }
298  ```
299  
300  **Key Properties:**
301  
302  - Maps naturally to AbzuInterface's message-based API
303  - Binary frames carry encrypted AbzuFrame payloads
304  - 64KB max message size (matching FakeTLS)
305  - Enables web-based clients without native code
306  
307  This allows Abzu nodes to accept connections from JavaScript clients running in browsers, providing a path to mass adoption without requiring app installs.
308  
309  ---
310  
311  ## Routing Layer: Geometric Routing
312  
313  ### Conceptual Model
314  
315  Traditional routing requires global coordination (BGP) or centralized infrastructure (DNS). Overlay networks like Tor require directory authorities.
316  
317  Abzu uses **geometric routing** inspired by Yggdrasil:
318  
319  1. The network forms a **spanning tree** rooted at the most stable long-lived node
320  2. Each node has **tree coordinates**: a path from root (e.g., `[2, 5, 1]` = "root, child 2, child 5, child 1")
321  3. Routing decisions are made purely from local state -- no global knowledge required
322  
323  ### Sovereign IP Derivation
324  
325  Every Ed25519 public key deterministically maps to an IPv6 address in the `0200::/7` range:
326  
327  ```rust
328  // Algorithm (from Yggdrasil):
329  // 1. Invert the public key bytes
330  // 2. Count leading 1 bits in inverted key
331  // 3. Address format:
332  //    - Byte 0: PREFIX (0x02)
333  //    - Byte 1: Number of leading 1s
334  //    - Bytes 2-15: Remaining bits after stripping leading 1s and first 0
335  
336  pub fn address_for_key(public_key: &VerifyingKey) -> Address {
337      // ... implementation
338  }
339  ```
340  
341  **Properties:**
342  
343  - **Deterministic**: Same key always produces same address
344  - **Self-certifying**: The address *is* derived from the public key
345  - **Compact**: Fits in standard IPv6 space
346  - **Collision-resistant**: Inherits cryptographic properties of Ed25519
347  
348  ### Routing Algorithm
349  
350  ```rust
351  pub enum RouteDirection {
352      Self_,          // Destination reached
353      Up,             // Route to parent in tree
354      Down(u32),      // Route to child at port N
355  }
356  ```
357  
358  **Tree Routing Priority:**
359  
360  1. If target is descendant: route down toward it
361  2. If target is ancestor: route up toward it
362  3. If target is neither (different branch): route up to common ancestor
363  
364  **Greedy Fallback:**
365  When tree routing fails (incomplete tree, dynamic topology), XOR distance on addresses provides a greedy fallback.
366  
367  ---
368  
369  ## Wire Protocol
370  
371  ### Frame Types
372  
373  ```rust
374  #[derive(Debug, Clone, Serialize, Deserialize)]
375  pub enum AbzuFrame {
376      KeepAlive,
377      Chunk { cid: [u8; 32], data: Vec<u8> },
378      Route { target: [u8; 32], next_hop: [u8; 32], payload: Vec<u8> },
379      Hello { ephemeral_pub: [u8; 32], timestamp: u64 },
380      HelloAck { ephemeral_pub: [u8; 32], confirmation: Vec<u8> },
381      Request { cid: [u8; 32], requester: [u8; 32] },
382      Chat { id: u64, to: [u8; 32], msg: Vec<u8>, timestamp: u64 },
383      ChatAck { id: u64 },
384  }
385  ```
386  
387  ### Serialization: Postcard
388  
389  Frames are serialized with **postcard**, a Rust-native `no_std` compatible binary format:
390  
391  - **Minimal overhead**: Variable-length integers, no field names
392  - **Embedded-friendly**: Works on microcontrollers (future: LoRa mesh)
393  - **Fast**: Zero-copy deserialization where possible
394  
395  **Size Examples:**
396  
397  - `KeepAlive`: 1 byte
398  - `ChatAck { id: 42 }`: ~10 bytes
399  - `Chunk` with 1KB data: ~1040 bytes
400  
401  ---
402  
403  ## Content-Addressed Storage
404  
405  ### Design
406  
407  All content is stored by its BLAKE3 hash (Content ID / CID):
408  
409  ```rust
410  // Store content, return its CID
411  pub fn store_content(&self, data: &[u8]) -> Result<[u8; 32], NodeError> {
412      let cid = *blake3::hash(data).as_bytes();
413      self.store.insert(&cid, data)?;
414      Ok(cid)
415  }
416  
417  // Retrieve by CID
418  pub fn get_content(&self, cid: &[u8; 32]) -> Result<Option<Vec<u8>>, NodeError>
419  ```
420  
421  ### Storage Engine: Sled
422  
423  Sled is an embedded, pure-Rust key-value database:
424  
425  - **ACID transactions**: Atomic commits
426  - **Lock-free reads**: High concurrency
427  - **Crash-safe**: Write-ahead logging
428  
429  **Async Hazard Mitigation:**
430  Sled operations are blocking. In async contexts, they're wrapped with `spawn_blocking`:
431  
432  ```rust
433  tokio::task::spawn_blocking(move || {
434      store.insert(&cid, &data)
435  }).await?
436  ```
437  
438  ### Content Discovery Protocol
439  
440  When a node requests content it doesn't have locally:
441  
442  ```
443       Requester                Network                   Holder
444           │                       │                        │
445           ├── Request{cid} ──────►│                        │
446           │   (broadcast to peers)│────────────────────────►
447           │                       │                        │
448           │                       │◄──── Chunk{cid, data} ─┤
449           │◄── Chunk{cid, data} ──│                        │
450           │                       │                        │
451       (verify hash, store locally)
452  ```
453  
454  ---
455  
456  ## Control Plane
457  
458  ### JSON-RPC 2.0 Interface
459  
460  The daemon exposes a local RPC interface for integration with UIs and other tools:
461  
462  | Method | Parameters | Description |
463  |--------|------------|-------------|
464  | `get_info` | — | Node identity, address, peer count, store stats |
465  | `connect` | `addr: String` | Initiate connection to peer |
466  | `list_peers` | — | Return active peer list with stats |
467  | `upload_content` | `data: Base64` | Store content, return CID |
468  | `download_content` | `cid: Hex` | Retrieve by CID (network fallback) |
469  | `send_message` | `to: Hex, data: Base64` | Route encrypted payload to target |
470  | `send_chat` | `to: Hex, msg: String` | Send persistent chat message |
471  | `get_chat_history` | `peer: Hex` | Retrieve message history |
472  | `add_contact` | `alias: String, pubkey: Hex` | Add to address book |
473  | `get_contacts` | — | List all contacts |
474  | `shutdown` | — | Graceful termination |
475  
476  ---
477  
478  ## Known Limitations & Threat Surface
479  
480  ### Infrastructure Dependency
481  
482  Abzu runs *over* the internet, not independently of it. This means:
483  
484  - **IANA/ARIN allocation**: IP addresses are centrally controlled
485  - **ISP-level blocking**: Sufficiently motivated adversaries can block all traffic
486  - **BGP manipulation**: Route hijacking affects underlying connectivity
487  - **CALEA compliance**: US carriers must enable lawful intercept
488  
489  **Mitigation Strategy**: Defense in depth. FakeTLS makes traffic hard to identify. Geometric routing makes the network hard to map. But we cannot defeat physics or law.
490  
491  ### Traffic Analysis
492  
493  Abzu encrypts content but does not fully anonymize traffic patterns:
494  
495  - **Timing correlation**: When you send, responses arrive
496  - **Volume analysis**: Large transfers are noticeable
497  - **Metadata leakage**: Connection establishment reveals peer relationships
498  
499  **Future Work**: Integrate mix-network techniques (constant-rate traffic, batching, delayed delivery).
500  
501  ### Endpoint Security
502  
503  The weakest link is always the device itself:
504  
505  - Compromised OS leads to compromised keys
506  - Physical access leads to key extraction
507  - Malware -- all bets are off
508  
509  **Assumption**: Users have trusted local environments.
510  
511  ---
512  
513  ## Current Status
514  
515  ### What Works Today (v0.2.0)
516  
517  - [x] **Node lifecycle**: Create, run, shutdown gracefully
518  - [x] **Peer connections**: Connect, maintain, disconnect
519  - [x] **FakeTLS transport**: DPI-resistant encrypted channels
520  - [x] **WebSocket transport**: Browser/mobile client connectivity
521  - [x] **Wire protocol**: All frame types implemented
522  - [x] **Content storage**: BLAKE3-addressed local store
523  - [x] **Content discovery**: Request/Chunk protocol
524  - [x] **Chat messaging**: Persistent encrypted messages with delivery ACKs
525  - [x] **Contact management**: Local address book
526  - [x] **JSON-RPC interface**: Full control plane
527  - [x] **38+ passing tests**: Core functionality verified
528  
529  ### Demonstrated Capability
530  
531  **First file teleportation** between two nodes with:
532  
533  - FakeTLS encrypted connection
534  - Content-addressed storage
535  - Verified BLAKE3 hash on retrieval
536  
537  ---
538  
539  ## Roadmap
540  
541  > [!NOTE]
542  > Timelines are intention, not commitment. This project moves at the speed of focused execution.
543  
544  ### Foundation (Current Phase)
545  
546  - [ ] **Multi-hop routing**: Full spanning tree implementation
547  - [ ] **Bootstrap nodes**: Well-known entry points for new nodes
548  - [ ] **Key exchange protocol**: Perfect forward secrecy per session
549  - [ ] **NAT traversal**: STUN/TURN integration for hole punching
550  
551  ### Expansion
552  
553  - [ ] **UDP transport**: QUIC-style reliability over UDP
554  - [ ] **Mobile clients**: iOS/Android via Rust FFI
555  - [ ] **Desktop interface**: Native management and visualization
556  - [ ] **Group messaging**: Multi-party encrypted chat
557  
558  ### Horizon (Research-Ready)
559  
560  - [ ] **LoRa transport**: Off-grid mesh for disaster/protest scenarios
561  - [ ] **Mix-network integration**: Trade latency for stronger anonymity (Nym-style)
562  - [ ] **Threshold cryptography**: No single point of key compromise
563  - [ ] **Incentive layer**: Optional economics for relay operators (if demand warrants)
564  
565  ---
566  
567  ## Design Principles
568  
569  ### 1. Pure Logic Routing
570  
571  The routing layer (`abzu-router`) performs **no I/O**. It takes state snapshots and returns decisions. This enables:
572  
573  - Deterministic testing
574  - Easy reasoning about behavior
575  - Separation from transport concerns
576  
577  ### 2. Transport Agility
578  
579  The `AbzuInterface` trait abstracts transport details. The same node logic works over:
580  
581  - TCP (current)
582  - UDP (planned)
583  - QUIC (planned)
584  - LoRa (aspirational)
585  
586  ### 3. Stealth First
587  
588  Every design decision considers DPI evasion:
589  
590  - FakeTLS masquerade
591  - Randomized keepalive intervals
592  - No protocol magic bytes
593  - Variable-length frames
594  
595  ### 4. Content Integrity
596  
597  All stored and received data is verified against its hash before use. No trust in transit.
598  
599  ### 5. Local First
600  
601  Data is stored locally by default. The network is for discovery and synchronization, not primary storage.
602  
603  ### 6. Async Safety
604  
605  All blocking operations (Sled, filesystem) are explicitly wrapped with `spawn_blocking` to prevent runtime stalls.
606  
607  ---
608  
609  ## References & Prior Art
610  
611  Abzu draws inspiration and techniques from:
612  
613  | Project | Contribution |
614  |---------|--------------|
615  | **Yggdrasil** | Spanning tree coordinates, sovereign IP derivation |
616  | **Iroh** | Content-addressed networking, BLAKE3 CIDs |
617  | **Reticulum** | Transport abstraction pattern, embedded-first design |
618  | **Tor** | Onion routing concepts (simplified in Abzu) |
619  | **Nym** | Mix-network principles (future integration) |
620  | **Automerge** | CRDT-based sync (planned for collaborative data) |
621  
622  ### Academic Background
623  
624  - **Geometric routing**: Kleinberg's work on greedy routing in small-world networks
625  - **Spanning tree protocols**: Perlman's original IEEE 802.1D work
626  - **Content-addressed storage**: Git, IPFS, BitTorrent
627  
628  ---
629  
630  ## License Philosophy
631  
632  **Current**: MIT License — Adrian Murray, 2026
633  
634  The core logic will be open sourced because **this needs to belong to everyone, not just one person**.
635  
636  ### Why MIT (for now)
637  
638  | License | Tradeoff |
639  |---------|----------|
640  | **GPL v3** | Strong copyleft, but creates friction for embedded/commercial integration. Historically, some projects (e.g., pfSense) moved to BSD specifically to escape GPL constraints. |
641  | **BSD/ISC** | Maximum permissiveness. Risk: adversaries can fork without contributing back. |
642  | **MIT** | Functionally identical to BSD. Simple, widely understood, minimal legal overhead. |
643  
644  MIT is the current choice for simplicity and adoption. This may evolve based on community input — particularly around whether a copyleft variant better serves the sovereignty mission.
645  
646  The key principle: **the license should not be a barrier to deployment in hostile environments**. Someone running Abzu in a protest camp shouldn't need a lawyer.
647  
648  ---
649  
650  ## Contact & Contribution
651  
652  When the repository goes public:
653  
654  - GitHub: [TBD]
655  - Threads: @adriancmurray
656  
657  For security issues, please use responsible disclosure.
658  
659  ---
660  
661  *"The best way to predict the future is to build it." — Alan Kay*