nexus-design - Action Report¶
Project: /home/user/Documents/nexus-design Created: 2026-03-08
Created NEXUS_ECONOMY_ARCHITECTURE.md — full economic design doc (2026-03-08 23:08)¶
What: Committed full NeXuS economy architecture to file covering blockchain stack, DIVA integration, node economy, Townhall marketplace, fee structure, and wallet design.
Why: Design session produced complete coherent architecture — needed to capture before context lost.
Files: - /home/user/Documents/nexus-design/NEXUS_ECONOMY_ARCHITECTURE.md
Covers: - NeXuS chain (Dero fork, RandomX, dPoW via Komodo model) - DIVA chain (coordination/proofs) + DIVA exchange (liquidity/atomic swaps) - Node economy (passive + active earning) - Master key + programmable child keys - Townhall marketplace with 3%/5% fee tiers - Secondary market 90/5/5 split (seller/creator/NeXuS) - Supply caps enforced by smart contract - Wallet tiers (burn/session/reputation/creator) - Identity dial (full anon to selective disclosure) - ZK proofs for middle ground - Real-world asset tokenization
Pending design questions tracked in doc section 10.
Wallet Command Center + Reputation System (2026-03-09 02:31)¶
What: Redesigned wallet as full NeXuS browser/portal with peer reputation voting and DIVA smart contract integration.
Why: Wallet needed to be the single interface for all NeXuS interaction, not just a key management tool. Reputation system needed to be social (peer-voted) not just protocol-earned. DIVA smart contract capability identified as the right layer for coordination/social tasks.
How: - Wallet redesigned as Command Center with 7 panels: Dashboard, Assets, Swap, NFT Forge, Finance (stake/loan), Command Center (resource sliders), Keys - Two badge types: protocol-issued (auto on-chain actions) + peer-voted (thumbs up/down) - Vote weight = voter contribution score — Sybil resistant, cannot be bought - Downvote costs more than upvote (brigading prevention) - DIVA chain namespaces defined: nexus:badges, nexus:reputation, nexus:storage, nexus:exchange, nexus:governance - Division of labour locked: DIVA=coordination/social, NeXuS=value/enforcement - Architecture stack diagram updated to include wallet + social layer
Files: NEXUS_ECONOMY_ARCHITECTURE.md (3 commits this session)
Created NEXUS_REQUIRED_APPLICATIONS.md + .md standardisation (2026-03-09 17:44)¶
What: Created the definitive required applications list for NeXuS base OS and converted all stray .txt docs to .md.
Why: Need a clear spec of what ships with NeXuS before publishing. All docs must be .md for consistency and rendering.
How: - Created NEXUS_REQUIRED_APPLICATIONS.md with 6 layers: Transport, Privacy, Node Services, UI, CLI Tools, Bootstrap - Each app has status: EXISTS / NOT INTEGRATED / NOT BUILT - Phase 1 builds (chain, wallet, IPFS, diva-connector, node-monitor) and Phase 2 builds listed - Explicit no-ship list (no telemetry, no KYC, no bloat) - Converted 5 .txt session logs to .md across nexus-network-stack and nexus-divachain - Removed .bak files
Files: NEXUS_REQUIRED_APPLICATIONS.md (new), cleanup across Projects/
Created NEXUS_INSTALL_ARCHITECTURE.md (2026-03-09 18:01)¶
What: Definitive container vs native split for the NeXuS base OS install.
Why: Need architectural clarity before writing the install script — wrong decisions here are hard to undo.
How: - Rule: container=external-facing/exploitable, native=hardware/boot/user-interface - Containerized: tor, i2p, privoxy, haproxy, dnscrypt, unbound + Phase 1 (diva, ipfs, chaind) - Native: nftables (first), chrony (crypto time), podman, yggdrasil, reticulum, ollama, all desktop/audio/CLI - Yggdrasil and Reticulum flagged to migrate from current compose to native - 9-step install flow documented - Open questions captured (3wm, ollama bundle, quadlet vs compose) - Wired into MkDocs docs site
Files: NEXUS_INSTALL_ARCHITECTURE.md (new), mkdocs.yml (updated nav)
NeXuS full design session — economy, wallet, install, what-is (2026-03-09 19:08)¶
What: Complete design documentation session covering economy architecture updates, wallet redesign, install architecture, required applications, and NeXuS history synthesis.
Why: Need comprehensive design docs before publishing base OS and building Phase 1 components.
How: - NEXUS_ECONOMY_ARCHITECTURE.md: Fixed base chain to Monero (MIT), AstroBWT confirmed, DERO/DENERO both blocked by Research License. Added peer reputation voting on DIVA chain, DIVA smart contract namespaces defined - NEXUS_REQUIRED_APPLICATIONS.md: Full 9-layer app list with container vs native split, status per app - NEXUS_INSTALL_ARCHITECTURE.md: Definitive container vs native architecture, 9-step install flow - NEXUS_WHAT_IT_IS.md: Full history synthesis from original docs — OS origin through economy layer - Wallet redesigned as Command Center with Dashboard/Assets/Swap/NFT Forge/Finance/Command Center/Keys - NFT badges: protocol-issued + peer-voted (thumbs up/down, vote weight = contribution score) - All docs wired into MkDocs site
Key decisions locked: - Base chain: Monero MIT fork - Mining: AstroBWT (ecosystem-contained) - DIVA chain handles: badges, reputation, storage proofs, exchange matching - NeXuS chain handles: value transfer, royalties, supply caps, stake/loan
Files: NEXUS_ECONOMY_ARCHITECTURE.md, NEXUS_REQUIRED_APPLICATIONS.md, NEXUS_INSTALL_ARCHITECTURE.md, NEXUS_WHAT_IT_IS.md
NEXUS_ECONOMY_ARCHITECTURE.md — base chain, wallet, DIVA layer (2026-03-09 19:37)¶
What: Rewrote economy architecture doc with corrected base chain decision, full wallet/Command Center design, DIVA smart contract layer, peer reputation system.
Why: Previous doc had incorrect base chain (DERO fork) blocked by Research License. Needed full wallet spec and social layer design.
How:
Base chain decision: - DERO and DENERO both use DERO Research License v1.1.2 — Section III.B prohibits commercial/production use - Changed to Monero fork (MIT license) — clean, production-safe, inherits RingCT + stealth addresses + bulletproofs - Mining algorithm changed from RandomX to AstroBWT — prevents external Monero pools from dominating/51% attacking NeXuS chain; forces miners to be integrated NeXuS nodes - DERO architecture used as inspiration only under Residual Rights clause (Section III.B of Research License permits this)
DAG block structure: - Side blocks pay 67% reward (no orphans), DERO-inspired implementation from scratch - dPoW (delayed Proof of Work) — Komodo model, notary nodes write NeXuS chain state into Bitcoin every ~10 min
DIVA Two-Chain model (new Section 3.2): - NeXuS chain = value/enforcement layer (monetary) - DIVA chain = coordination/social layer (no native coin, small tx fee for network survival) - 5 DIVA namespaces defined: nexus:badges, nexus:reputation, nexus:storage, nexus:exchange, nexus:governance - PUT /tx structure documented with correct JSON array format (confirmed working HTTP 204)
Wallet rewrite (Section 7 — 10 subsections): - Wallet as Command Center, not just key manager - Assets tab: balance display, peer badge voting (thumbs up/down), vote weight = contribution score - Swap tab: atomic swaps XMR/BTC/NeXuS - NFT Forge: creator tools, supply cap (immutable), rights tiers (listen/sync/remix/master), secondary royalty % - Finance: stake/loan contract — lend credits to pool, borrow against over-collateralized tokens - Command Center: resource sliders (CPU/storage/bandwidth %, default 5%) - Keys: HD key derivation BIP32-style (creator/reputation/governance/session/stealth child keys), invisible to user - ZKP+HE: Phase 2 feature — ZKP for balance claims, HE for blind computation, noted must be built separately since Monero not DERO fork - Sybil resistance: downvotes cost more than upvotes, vote weight = contribution score prevents brigading
Peer reputation / badge system: - Protocol badges (automatic): issued by chain when thresholds met - Peer badges (voted): thumbs up/down from other nodes, recorded on DIVA nexus:reputation namespace - Soul-bound: non-transferable, non-buyable, burned on misbehavior
Erasure coding: - Removed archive node tier (identified as centralization risk) - Chain history split into 10 chunks (any 6 reconstruct), distributed across all nodes flat-rate
Files: /home/user/Documents/nexus-design/NEXUS_ECONOMY_ARCHITECTURE.md
NEXUS_REQUIRED_APPLICATIONS.md — created full app stack list (2026-03-09 19:37)¶
What: Created NEXUS_REQUIRED_APPLICATIONS.md — definitive list of every application in the NeXuS stack with purpose, install method, and current status.
Why: Needed a single authoritative reference for what's in the OS, what needs to be added to the install script, and what's still not integrated.
How: - 9 layers documented: Transport, Privacy, Node Services, UI, AI Layer, CLI Tools, Media, Window Management, Bootstrap - Each entry: what it does, install method (apk/native/container/nix), current status (EXISTS / NOT INTEGRATED / NOT BUILT) - Decisions captured: Yggdrasil and Reticulum flagged for migration from compose → native (hardware-level mesh) - chrony added as required (time sync critical for crypto operations) - AI layer: ollama (native GPU/CPU inference), aichat (native), podman (rootless), podman-compose - Media additions: mpv, musikcube - CLI additions: nix-shell, pv (pipe viewer), lynx - Window management: labwc (primary Wayland compositor) + sway (fallback) - Bootstrap: 4 simultaneous methods — Tor bridge (obfs4/Snowflake/WebTunnel) + IPFS/IPNS + BitTorrent BEP46 + Reticulum - Status summary at end: READY NOW list vs NEEDS ADDING TO INSTALL SCRIPT list
Files: /home/user/Documents/nexus-design/NEXUS_REQUIRED_APPLICATIONS.md (new file)
NEXUS_INSTALL_ARCHITECTURE.md — container vs native decisions (2026-03-09 19:38)¶
What: Created NEXUS_INSTALL_ARCHITECTURE.md — definitive container vs native architecture decisions for every NeXuS component.
Why: 'Should this run in a container or native?' was being decided ad hoc. Needed a clear rule and a table for every component.
How:
Core rule defined: - Container = external-facing / exploitable (network services, daemons with attack surface) - Native = hardware-access / boot-critical / user-interface (things that need the metal or must survive container failure)
Containerized services table: - nexus-tor, nexus-i2p, nexus-privoxy, nexus-haproxy, nexus-dnscrypt, nexus-dns (all Phase 0 — exist now) - nexus-diva, nexus-ipfs, nexus-chaind (Phase 1 — to be built) - Each entry includes: image, compose service name, ports/sockets, why containerized
Native components table organized by layer: - Boot Layer: nftables (first — before any network), chrony (time sync), greetd/tuigreet - Network Layer: Yggdrasil, Reticulum (flagged for migration FROM compose TO native) - AI Layer: ollama, aichat (need GPU/CPU direct access) - Desktop: labwc, sway, foot, tmux, fuzzel (optional — user chooses) - Audio: pipewire, wireplumber, pipewire-pulse - CLI: full toolkit (fzf, bat, rg, fd, neovim, htop, pv, lynx, nix) - Node Services Phase 1: nexus-node-monitor (native health checker)
9-step install flow: 1. nftables (lock down first, before anything opens ports) 2. chrony (time sync — crypto depends on accurate time) 3. podman + podman-compose (container runtime) 4. native network layer (Yggdrasil + Reticulum) 5. containers up (tor, i2p, privoxy, haproxy, dns) 6. AI layer (ollama pull, aichat config) 7. desktop (optional — skip for headless nodes) 8. CLI toolkit 9. nexus-doctor.sh verify
Open questions documented: - '3wm' clarification needed: sway vs i3wm (sway assumed — Wayland native) - Yggdrasil/Reticulum migration: confirm native move - ollama model bundle: include starter model or pull-on-first-run? - podman-compose vs systemd quadlet for production
Files: /home/user/Documents/nexus-design/NEXUS_INSTALL_ARCHITECTURE.md (new file)
NEXUS_WHAT_IT_IS.md — full history synthesis (2026-03-09 19:38)¶
What: Created NEXUS_WHAT_IT_IS.md — synthesis of the complete NeXuS story from origin to present, compiled from all historical docs.
Why: Needed one document that tells the whole story — where NeXuS came from, what it evolved into, what it is today — for new contributors and the docs site.
How: Source documents read and synthesized: - nexus-overview.md, nexus-white-paper-v1.md, nexus-report-v1.md - NEXUS_FOUNDATION.md, NEXUS_MANIFESTO.md, NEXUS_COMPLETE_SYSTEM_MANUAL.md
7 evolutionary layers documented: 1. OS origin — personal Alpine Linux hardening project 2. Privacy fortress — Tor + I2P + firewall stack 3. Mesh — Yggdrasil + Reticulum added, off-grid capability 4. CLI tools — full modern toolkit (fzf, bat, rg, etc.) 5. AI layer — Ollama + aichat, local-only inference 6. Crypto-republic identity — NEXUS_FOUNDATION.md philosophical crystallization 7. Economy — chain + wallet + DIVA social layer (Phase 1)
8-layer stack diagram included (matches index.md homepage)
Timeline table: origin year through Phase 1/2 targets
v0.1 scope (what exists now) vs Phase 1 targets clearly delineated
CIA+MOE+POP+YMCA framework referenced as the operating philosophy backbone
Files: /home/user/Documents/nexus-design/NEXUS_WHAT_IT_IS.md (new file)