NeXuS Compass¶
Session document — updated as we go Date: 2026-04-06
Read this when returning to this session's work. It tells you where you are, what was decided, and what is still open.
What NeXuS Is For¶
Trustless by code and math, operating on proof of service.
So ideas may freely flourish.
NeXuS is for humans and AI working hand in hand to promote freedom of ideas and freedom of identity. To be unknown yet seen. Carbon and silicon — not one serving the other. Both serving the idea.
mewe — sovereign me inside a we.
Standing Rules¶
- All documents must have a version number and date in the filename —
NAME_vX.X_YYYY-MM-DD.md - Working docs live in
/home/user/claude/— finished/output docs in/home/user/Projects/nexus-network-stack/docs/ - Back up before every edit
- Update the compass in real time — not at the end
The One Rule¶
You cannot hinder another's freedom. Enforced by protocol.
What a Node Is¶
A node is an individual — not a server, not infrastructure. Offline-first. Actively searching for a network, or starting one if none exists.
| Component | What it really is |
|---|---|
| Node | An individual |
| Client-side database | Sovereign identity + local history — proof they existed |
| DIVA commitment | Voluntarily being witnessed by the collective |
| Ghost Gate | Boundary of sovereign space — nothing crosses without consent |
Main Topics & Files¶
The full map. Start here to find anything.
Philosophy & Vision¶
| File | What it is |
|---|---|
| NEXUS_FOUNDATION_v2.0_2026-04-06.md | The why — principles, RIN, Ghost Gate, The One Rule |
| NEXUS_COMPASS.md | Previous compass — component definitions, earlier decisions |
The Node & Stack¶
| File | What it is |
|---|---|
| NEXUS_NODE_SPEC_v1.0_2026-04-06.md | Full technical spec — every layer, economy, transaction flows |
| NEXUS_COMPLETE_SYSTEM_MANUAL.md | Full system manual |
| 2026-02-23-rebuilt-NeXuS-DarkNet.md | Feb 23 build session — confirms what is actually running |
Proof System¶
| File | What it is |
|---|---|
| NEXUS_PROOF_SYSTEM_SPEC_2026-04-06.md | Complete proof system — 5 proof types, Magic Packet design, Ghost Gate additions, ZKP circuit inputs, build status |
The Economy & Blockchain¶
| File | What it is |
|---|---|
| NEXUS_NEXIUM_TOKENOMICS.md | NeXiuM spec — perpetual royalties, ephemeral wallets, smart contracts |
| NEXUS_DIVA_CHAIN_OVERVIEW.md | DIVA chain — PBFT, I2P-native, API reference |
| NEXUS_DIVA_PARTNERSHIP_PROPOSAL.md | Creator economy — namespace design, fan-buys-song flow, stakeholder model |
| NEXUS_DIVA_VALUE_EXCHANGE.md | What NeXuS needs from DIVA — blockers, open questions, mutual value |
| NEXUS_DIVA_QUESTIONS_KONRAD.md | Original Q&A batch for Konrad — PUT /tx, quorum, schema bugs |
| KONRAD.md | Living question log — Q1/Q5/Q9/Q-CONSENSUS/Q-PERSONAL-CHAIN now ANSWERED |
| KONRAD_MEETING_AGENDA.md | April 4/5 meeting agenda — ZKP jellybean explanation, Magic Packet = Proof of Storage convergence, sovereign rollup ask |
| diva-questions-final-v1.md | Final question set before April meeting |
Ghost Gate & Security¶
| File | What it is |
|---|---|
| NEXUS_SECURITY_MANIFESTO.md | Security architecture manifesto |
| NEXUS_PARANOID_SECURITY_ARCHITECTURE.md | Deep security design |
| ghost-gate.nft | Ghost Gate nftables rules (Phantom Tier) |
Mesh & Networking¶
| File | What it is |
|---|---|
| NEXUS_TRANSPARENT_ROUTING_ARCHITECTURE.md | Transparent routing design |
| NEXUS_NETWORK_SERVICES_MINDMAP.md | All network services mapped |
| NEXUS_DIVA_MULTINETWORK.md | DIVA as universal darknet backbone — Tor/Ygg/Ret routing to DIVA |
nexus-darknet-go (Live Implementation)¶
| File | What it is |
|---|---|
| PLAN_OF_ATTACK.md | 8 bugs ranked, 3 phases |
| services.yaml | Service registry — full stack |
| nexus-diva.sh | DIVA shell contract for TUI |
| nexus-diva-start.sh | Full DIVA devnet launcher |
Identity — RIN¶
| Topic | Where |
|---|---|
| RIN spec (7-point proof stack, PERMITTL Ring) | NEXUS_FOUNDATION_v2.0 — Section: RIN |
| RIN in node spec | NEXUS_NODE_SPEC_v1.0 — Section 9 |
AI Layer — CHACHA¶
| Topic | Where |
|---|---|
| CHACHA spec | NEXUS_NODE_SPEC_v1.0 — Section 7 |
Konrad Direct — April 2026¶
Verbatim context from Konrad. Treat as authoritative.
Call¶
Konrad offered a call. Available the next few weeks. Action: schedule it.
Rohaun — Deanonymized Chain (from meeting)¶
Konrad referenced Rohaun as a chain that was repeatedly deanonymized.
Separately: a 2025 paper demonstrated that I2P was successful in identifying a node. This is a known, published attack vector.
What this means for NeXuS: - I2P-native does not mean anonymous-by-default — I2P has a demonstrated node identification vulnerability - NeXuS cannot rely on I2P alone for anonymity - The multi-network stack (Tor + I2P + Yggdrasil + Reticulum) is not optional — it is the defense-in-depth response to exactly this class of attack - ZKP layer adds separation between chain activity and node identity even if the transport is compromised - Ghost Gate egress control prevents correlation attacks at the packet level
Attack vector: timing / live behavior alignment.
The Paper¶
"Time will Tell: Large-scale De-anonymization of Hidden I2P Services via Live Behavior Alignment (Extended Version)" Hongze Wang, Zhen Ling, Xiangyu Xu, Yumingzhi Pan, Guangchi Liu, Junzhou Luo, Xinwen Fu Submitted: December 17, 2025 — Accepted: NDSS Symposium 2026 https://arxiv.org/abs/2512.15510
How the Attack Works¶
- Deploy 15 floodfill routers passively for 8 months collecting router information
- Actively probe target hidden services to generate detectable behavior
- Analyze when routers join and disconnect from the network — on/off timing patterns
- Match those behavioral signatures against target hidden services
- Result: successfully deanonymized all controlled hidden services in real-world validation
This is not a content attack. It is a behavioral fingerprinting attack — the node's pattern of being online/offline becomes its identity.
What This Means for NeXuS¶
- A NeXuS node that runs 24/7 has a stable behavioral signature — harder to correlate
- A node with irregular uptime (laptop, mobile) leaks its on/off pattern as a fingerprint
- I2P-native DIVA inherits this exposure — every node committing to DIVA over I2P has a behavioral profile
- Ghost Gate must address behavioral fingerprinting, not just packet-level timing
- Always-on nodes are more resistant by design — NeXuS nodes should aim for continuous uptime
- ZKP layer still holds: even if the node's I2P identity is revealed, the chain sees a proof not the node
Clarification — Konrad and the paper agree¶
Both say the same thing: intermittent (off and on) = easier to fingerprint. - Always on → no on/off events → no behavioral signature - Frequently off and on → every reconnect is a data point → pattern becomes fingerprint
Why NeXuS Overcomes This (with refinement)¶
- Scale defense — the attack doesn't scale trivially against thousands of nodes with similar uptime patterns. Identifying a specific node requires narrowing the candidate pool. Large NeXuS network = harder correlation.
- Limited I2P exposure — NeXuS nodes don't run I2P continuously. I2P is used specifically for DIVA commits. Less exposure = smaller behavioral surface than a full-time I2P node.
- The nuance — a node that connects briefly, submits a ZKP proof, then disconnects on a regular schedule creates its own distinctive pattern. The fix is jitter: randomize when DIVA commits happen, not just whether the node is connected.
Actions¶
- Add jitter to ZKP commit timing — randomize submission delay, not just connection timing
- Maintain persistent I2P connection with cover traffic rather than connect-submit-disconnect cycle
- Add behavioral fingerprinting resistance to Ghost Gate spec
- Raise with Konrad on follow-up call — does Proof of Storage challenge/response create a predictable behavioral signature?
Commits — Thursday April 2nd (develop-deno branch)¶
These may already be live. Check
develop-denobranch.
| What | Detail |
|---|---|
| Spam protection | Argon-based PoW on network messages |
| Node joining | New node joining the network |
| Node leaving | Node leaving the network |
| MAJOR: New CAP implementation | A year of research — Consistency, Availability, Partition Tolerance redesign. This changed all vote-related source code. |
Why Proof of Storage replaced voting¶
"A permissionless vote-based system can be corrupted or slowed down to the point of unusability. Instead of 'voting' it's a 'proof of storage' to improve reliability and performance for an exchange within the I2P network. This is why you saw the half-done, very raw 'proof' source code."
The raw proof source code we found was not a bug — it was the in-progress Proof of Storage implementation mid-build.
Konrad's read on NeXuS papers¶
| Topic | Konrad's view |
|---|---|
| Identity management | ✅ Agrees |
| NFT | ✅ Agrees |
| Accounting | ✅ Agrees |
| Zero-Knowledge Proofs | ❓ Doesn't yet fully understand — this is our opening: explain ZKP clearly at the call |
Integration target confirmed¶
Branch: develop-deno — this is the right branch to build against.
Decision Log¶
CometBFT — Removed from Node Spec (2026-04-06)¶
Decision: CometBFT removed from the three-tier settlement table. Tier 3 marked as TBD.
What CometBFT was: Tier 3 settlement — irreversible, high-value, cross-network transactions. The BFT consensus engine extracted from Cosmos SDK (formerly Tendermint). Was intended for edge cases where DIVA Tier 2 finality wasn't enough guarantee — e.g. massive NeXiuM cashouts to another network.
Why it was removed: - We locked NO Cosmos SDK — too heavy for laptop hardware (the founding constraint of NeXuS nodes) - CometBFT is the engine Cosmos SDK is built on. They are separable in theory but tightly coupled in practice. The weight concern carries over. - 99.9% of NeXuS transactions never need Tier 3. Routing rewards, purchases, royalties all settle at Tier 2. CometBFT is a full international banking team hired for a transaction that almost never happens. - DIVA Proof of Storage with sufficient confirmation depth is likely the right Tier 3 answer at NeXuS scale — but that needs to be confirmed with Konrad.
What replaced it: Tier 3 = "Deep DIVA confirmation — mechanism TBD. Raise with Konrad on follow-up call."
What to ask Konrad: Does Proof of Storage at N confirmations provide the same irreversibility guarantee that CometBFT was meant to provide? If yes — Tier 3 is solved natively. If no — what is his recommended pattern for high-value irreversible settlement on DIVA?
Architecture Decisions Locked This Session¶
Two Chains¶
Every node runs two layers:
| Layer | Lives | What it is |
|---|---|---|
| Client-side database | On the node, local | Sovereign history — every action, master-key-signed, hash-linked |
| DIVA chain | Across the network, I2P-native | Public witness — receives ZKP proofs, holds NeXiuM balances + creator economy state |
Konrad confirmed: The personal chain is a client-side database, not a distributed chain.
Konrad confirmed: DIVA is moving to Proof of Storage — not voting. Nodes prove they are storing chain data. This replaces the voting/locking phase described in earlier DIVA docs.
The Economy — One Chain, Two Flows¶
Both economic flows use NeXiuM on DIVA. No second payment chain in docs.
| Flow | How |
|---|---|
| Proof of Service | Node routes traffic → Ghost Gate records → ZKP → DIVA commit → NeXiuM credited to cold address |
| Proof of Purchase | Fan pays creator in NeXiuM → license issued on DIVA → IPFS content unlocks → royalties distributed on-chain |
ZKP — gnark PLONK. Locked.¶
Universal setup. No trusted ceremony. Zero Trust aligned. The chain sees proof of valid work — never the identity behind it.
Blockchain Stack — Locked¶
gnark PLONK → proof execution / law
DIVA → ordering + witness + data availability (I2P-native)
IPFS → content storage (hash-addressed, encrypted)
char-gen-cli → client interface
Full Transaction Flows¶
Proof of Service (Node Earns NeXiuM)¶
1. Node routes traffic (Medusa/Tor)
2. Ghost Gate checks Three Heads (AI fingerprint + Operating Key + User Permit)
3. Ghost Gate writes proof_of_contribution (local)
4. Client-side database logs entry (hash-linked, master-key-signed)
5. ZKP generated (gnark PLONK) — proves valid work, reveals nothing
6. PUT /transaction → DIVA over I2P
7. DIVA consensus confirms (Proof of Storage)
8. nexus:nexium:<node_key_hash> balance credited
9. NeXiuM accumulates in cold address (never in transaction graph)
Proof of Purchase (Fan Buys Content)¶
1. Creator published: nexus:content:publish on DIVA (plaintext — discoverable)
File encrypted on IPFS
2. Fan queries DIVA → finds listing, price in NeXiuM, IPFS CID
3. Fan generates ephemeral wallet (BIP32 child key from master key)
Transfers spending amount: cold address → ephemeral wallet
4. Fan sends NeXiuM → DIVA: nexus:content:purchase (encrypted)
DIVA consensus confirms
5. Creator's node sees confirmed purchase → generates license key
Encrypts with fan's Ed25519 public key → commits to DIVA
6. Fan decrypts license key → decrypts IPFS content → file downloads
7. Royalty split: creator reads nexus:stake:* → distributes NeXiuM to each %
nexus:royalty:distribute committed to DIVA — permanent, automatic, forever
8. Both personal databases log the event (sovereign local record)
9. Ephemeral wallet dissolves — zero balance, no history linked to cold address
DIVA Namespace Structure¶
The namespace keys are I2P addresses. A node's identity on DIVA is its I2P destination. Privacy is structural — no separate anonymization layer needed. Only the node holding that I2P keypair can write to its namespace. This may resolve open question #2 (identity-locked writes) — I2P keypair ownership IS the write lock.
nexus:nexium:<i2p_address> → NeXiuM balance
nexus:content:publish → content metadata, IPFS CID, price (public)
nexus:content:purchase → encrypted license key (private)
nexus:royalty:distribute → encrypted royalty proof (private)
nexus:stake:create → stakeholder shares offered (public)
nexus:stake:purchase → encrypted stake record (private)
nexus:node:register → node identity (public)
Public entries: plaintext, discoverable. Private entries: data field encrypted Ed25519 → X25519 (libsodium). Network sees transaction occurred. Only parties can read it.
The I2P address as namespace key means: - Identity = I2P destination (cryptographic, not human-assigned) - Write authority = possession of the I2P private key - No separate identity system needed for namespace ownership - Cannot be linked to real-world identity without the private key
Master Key Architecture¶
Master Key (cold, never leaves the node)
→ signs genesis block = node's self-signed certificate
→ derives Session Key (hot, rotating)
→ signs DIVA commits
→ signs Ghost Gate permits
→ signs daily audit entries
→ derives Ephemeral Wallets (BIP32 child keys, spend-time only)
Open Questions¶
| # | Question | Why it matters | Source |
|---|---|---|---|
| 1 | ~~What replaced voting in DIVA consensus?~~ RESOLVED: Proof of Storage | Node Spec needs updating — replace all references to "voting" with Proof of Storage | Konrad — this session |
| 2 | Do DIVA namespaces support identity-locked writes? | NOT yet implemented. DIVA is currently permissionless — anyone can write to any namespace. Konrad said he could probably add namespace write protection. Feature request, not a blocker. Workaround: client-side ZKP rejects bad writes. Confirm timeline on follow-up call. | NEXUS_DIVA_VALUE_EXCHANGE.md |
| 3 | NeXiuM whitepaper — supply, emission, governance | Must be locked before ZKP circuit work begins | NEXUS_NEXIUM_TOKENOMICS.md |
| 4 | Namespace reservation: can nexus:* be claimed? |
Prevents collision / spam on our namespace | NEXUS_DIVA_VALUE_EXCHANGE.md |
Docs Written This Session¶
| File | What it is | Key changes |
|---|---|---|
| NEXUS_FOUNDATION_v2.0_2026-04-06.md | Philosophy doc — the why of NeXuS | RIN (7-point proof stack) added; Ghost Gate (Three Heads) added; 5 Laws collapsed to 1 Rule; "serving" → "obeying" removed; AI language lightened; ~150 lines of redundancy removed |
| NEXUS_NODE_SPEC_v1.0_2026-04-06.md | Technical node spec — the what and how | Full stack documented from running code; Economy section added (NeXiuM, DIVA, two flows); Proof of Service + Proof of Purchase transaction walks; Two chains (client-side DB + DIVA) explained; Konrad corrections applied |
Source Docs Referenced¶
| File | What it is |
|---|---|
| NEXUS_NEXIUM_TOKENOMICS.md | Complete NeXiuM spec — perpetual royalties, ephemeral wallets, smart contracts |
| NEXUS_COMPASS.md | Previous compass — component definitions, blockchain stack decisions, current position |
| NEXUS_DIVA_VALUE_EXCHANGE.md | Konrad meeting prep — what NeXuS needs, what DIVA needs, open technical questions |
| NEXUS_DIVA_PARTNERSHIP_PROPOSAL.md | Creator economy vision — namespace structure, privacy transaction layer, fan-buys-song flow |
| NEXUS_DIVA_CHAIN_OVERVIEW.md | DIVA chain Docker Hub spec — PBFT consensus, API endpoints, configuration |
| 2026-02-23-rebuilt-NeXuS-DarkNet.md | Feb 23 build session log — 99% complete, confirmed what is actually built |
Status¶
| Component | Status |
|---|---|
| Command Center (FastAPI) | ✅ Running |
| Tor / Medusa routing | ✅ Running |
| I2P | ✅ Running |
| Yggdrasil | ✅ Running |
| Reticulum | ✅ Running |
| IPFS, RetroShare, aMule, GNUnet | ✅ Running |
| Privoxy + blocklists | ✅ Running |
| Unbound DNS privacy | ✅ Running |
| Caddy TLS publishing | ✅ Running |
| nexus-hotspot (Freedom Box) | ✅ Built |
| AI Layer (CHACHA) | 🔄 In development |
| Ghost Gate (egress control) | 📐 Specced |
| RIN (identity) | 📐 Specced |
| B.A.T.M.A.N. mesh | 📐 Planned |
| DIVA integration | 🔄 In progress — testnet, 4 bugs patched locally |
| NeXiuM ZKP circuits | ⏳ Blocked on whitepaper + Konrad Q&A |
Sane • Simple • Secure • Stealthy • Beautiful Together Everyone Achieves More