f273816405
Phase 5 mesh networking: - E2E encrypted TX relay (X25519 + ChaCha20-Poly1305) — non-Archy nodes relay encrypted blobs transparently via Meshcore native routing - Steganographic encoding modes (WeatherStation, SensorNetwork) — traffic looks like sensor data on the wire, 0xAA marker, configurable per-node - Pre-flight Bitcoin Core health check on relay node — specific error codes (bitcoin_unreachable, bitcoin_syncing, tx_rejected) instead of generic fails - mesh.relay-status RPC endpoint — frontend polls for relay result every 3s - On-Chain / Lightning tabs in Off-Grid Bitcoin panel - Archy Peers vs Mesh Broadcast relay mode selector - Mesh view fills viewport (no page scroll), internal panel scrolling - Version bump to 1.2.0-alpha Also includes: deploy hardening, container fixes, IndeedHub updates, boot screen, dashboard improvements, MASTER_PLAN task tracking Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
127 lines
7.4 KiB
Markdown
127 lines
7.4 KiB
Markdown
# MASTER PLAN
|
|
|
|
> Archipelago project task tracking and roadmap.
|
|
|
|
## Roadmap
|
|
|
|
| ID | Title | Priority | Status | Dependencies |
|
|
|----|-------|----------|--------|--------------|
|
|
| **BUG-1** | **Random logout / CSRF mismatch** | **P0** | PLANNED | - |
|
|
| **TASK-2** | **Roll incoming-tx into deploy & ISO** | **P2** | PLANNED | - |
|
|
| **BUG-3** | **IndeedHub WebSocket spam in console** | **P2** | PLANNED | - |
|
|
| **FEATURE-4** | **Onboarding loading screen with progress** | **P1** | IN PROGRESS | - |
|
|
| **INQUIRY-5** | **Offline balance check via mesh relay** | **P2** | PLANNED | - |
|
|
|
|
## Active Work
|
|
|
|
### BUG-1: Random logout / CSRF mismatch (PLANNED)
|
|
**Priority**: P0 — Critical
|
|
**Status**: PLANNED (2026-03-15)
|
|
|
|
Sessions expire unexpectedly during normal use. Backend sessions now persist to disk (`/var/lib/archipelago/sessions.json`) but CSRF token mismatch (403) still causes logouts. Need to investigate CSRF token lifecycle and fix the mismatch between cookie and header values.
|
|
|
|
**Root cause analysis so far**:
|
|
- Sessions were purely in-memory — fixed with disk persistence
|
|
- CSRF validation compares cookie value vs `X-CSRF-Token` header — both present but don't match
|
|
- Log: `403 CSRF mismatch — rejecting RPC call ... has_cookie=true has_header=true`
|
|
- Possible cause: cookie value rotated (e.g., new login in another tab) but frontend cached old value
|
|
|
|
**Key files**:
|
|
- `core/archipelago/src/session.rs` — session store (now persisted)
|
|
- `core/archipelago/src/api/rpc/mod.rs:273-307` — CSRF validation
|
|
- `neode-ui/src/api/rpc-client.ts:18-45` — frontend CSRF extraction from cookie
|
|
|
|
**Tasks**:
|
|
- [ ] Investigate CSRF token rotation — when/why cookie and header diverge
|
|
- [ ] Add logging to CSRF validation to capture actual cookie vs header values
|
|
- [ ] Consider returning CSRF token in response body (not just cookie) for explicit client storage
|
|
- [ ] Test multi-tab scenario where one tab's login rotates the CSRF token
|
|
- [ ] Verify session persistence survives deploys (second deploy test)
|
|
|
|
### TASK-2: Roll incoming-tx into deploy & ISO (PLANNED)
|
|
**Priority**: P2 — Medium
|
|
**Status**: PLANNED (2026-03-16)
|
|
|
|
The incoming transactions feature (lnd.gettransactions RPC + wallet badge UI + auto-refresh) is working on .228. Roll changes into deploy-to-target.sh and build-auto-installer-iso.sh so fresh installs and deploys get it automatically. Do not break existing changes.
|
|
|
|
**Key files changed**:
|
|
- `core/archipelago/src/api/rpc/lnd.rs` — new `handle_lnd_gettransactions` method
|
|
- `core/archipelago/src/api/rpc/mod.rs` — registered `lnd.gettransactions` route
|
|
- `neode-ui/src/views/Web5.vue` — incoming tx badge, panel, auto-refresh polling
|
|
- `neode-ui/src/style.css` — incoming-tx-badge, incoming-tx-row, incoming-tx-slide classes
|
|
|
|
**Tasks**:
|
|
- [ ] Verify changes are already captured by existing deploy (backend build + frontend build)
|
|
- [ ] Ensure ISO build captures the updated Rust binary and frontend dist
|
|
- [ ] Test that no existing deploy/build logic is broken
|
|
|
|
### BUG-3: IndeedHub WebSocket spam in console (PLANNED)
|
|
**Priority**: P2 — Medium
|
|
**Status**: PLANNED (2026-03-16)
|
|
|
|
`ws://localhost:7777/` connection refused fills browser console endlessly when IndeedHub is loaded in iframe. IndeedHub's compiled frontend bundle hardcodes `localhost` for WebSocket connections. When loaded from a remote host, `localhost` resolves to the user's machine, not the server.
|
|
|
|
**Root cause**: IndeedHub's Next.js build bakes `localhost:7777` into the WebSocket URL. The nginx WebSocket proxy at `/app/indeedhub/ws/` exists but is unused because IndeedHub loads via direct port 7777, not through the proxy path.
|
|
|
|
**Tasks**:
|
|
- [ ] Rebuild IndeedHub with `NEXT_PUBLIC_WS_URL` env var pointing to relative URL or actual server address
|
|
- [ ] Alternatively, configure IndeedHub to use relative WebSocket URLs (`/ws/` instead of `ws://localhost:7777/`)
|
|
- [ ] Test that WebSocket reconnection works after the fix
|
|
|
|
### FEATURE-4: Onboarding loading screen with progress (IN PROGRESS)
|
|
**Priority**: P1 — High
|
|
**Status**: IN PROGRESS (2026-03-17)
|
|
|
|
Users hit the onboarding screen before the backend is ready, resulting in "Server is still starting up" errors that block identity creation. The onboarding flow should not begin until the server is fully operational.
|
|
|
|
**Solution**: Show the existing screensaver as a loading/boot screen with server startup progress. Swap the inner logo for animated pixel art icons (smiley face, Bitcoin logo, etc.) that cycle while services come online. Show progress indicators for each backend service (identity store, container runtime, LND, etc.). Only transition to onboarding once `/health` returns ready.
|
|
|
|
**Key considerations**:
|
|
- Reuse the existing screensaver component as the boot screen
|
|
- Animated pixel art icons rotate in the center (smiley, BTC, lightning bolt, etc.)
|
|
- Progress bar or status checklist showing which services are ready
|
|
- Poll `/health` endpoint for service readiness
|
|
- Smooth transition from boot screen → onboarding once all critical services are up
|
|
- First-boot vs normal boot: first boot shows onboarding after, normal boot goes to dashboard
|
|
|
|
**Key files**:
|
|
- `neode-ui/src/views/Onboarding.vue` — current onboarding flow
|
|
- `neode-ui/src/components/Screensaver.vue` — existing screensaver to repurpose
|
|
- `core/archipelago/src/api/rpc/mod.rs` — health endpoint
|
|
- `core/archipelago/src/server.rs` — startup sequence and service initialization
|
|
|
|
**Tasks**:
|
|
- [ ] Investigate current health endpoint — what services does it check, what's missing
|
|
- [ ] Design boot screen component: screensaver background + animated pixel icons + progress
|
|
- [ ] Create pixel art icon set (smiley, BTC, lightning, shield, etc.) as SVG/CSS animations
|
|
- [ ] Implement service readiness polling (health check with granular service status)
|
|
- [ ] Add backend support for granular startup progress (which services are ready)
|
|
- [ ] Build boot screen component with smooth transition to onboarding/dashboard
|
|
- [ ] Handle edge cases: very slow starts, partial service failures, timeout fallback
|
|
- [ ] Test on fresh ISO install (first-boot scenario)
|
|
|
|
### INQUIRY-5: Offline balance check via mesh relay (PLANNED)
|
|
**Priority**: P2
|
|
**Status**: PLANNED (2026-03-17)
|
|
|
|
Design how to query wallet balance (LND/Bitcoin Core) from an off-grid node by relaying the request through mesh peers to an internet-connected Archy node that responds with the balance. Uses the same E2E encrypted relay infrastructure as TX relay.
|
|
|
|
**Approach options**:
|
|
- New typed message pair: `BalanceRequest` (type 13) / `BalanceResponse` (type 14)
|
|
- Off-grid node sends `BalanceRequest` to Archy peers
|
|
- Internet-connected peer queries its own LND `walletbalance` or the requesting node's LND (if accessible)
|
|
- Challenge: the relay peer doesn't have access to the requesting node's wallet — need to either trust the relay peer's balance report, or have the relay peer proxy the RPC to the requesting node's LND over Tor/LAN
|
|
- Simplest: relay peer reports its OWN balance (useful for checking if your remote node has funds)
|
|
- Advanced: relay peer forwards the LND RPC call to the off-grid node's LND via reverse mesh tunnel
|
|
|
|
**Tasks**:
|
|
- [ ] Define `BalanceRequest` / `BalanceResponse` typed messages
|
|
- [ ] Implement balance relay handler on internet-connected node
|
|
- [ ] Add "Check Balance" button to Off-Grid Bitcoin panel
|
|
- [ ] Consider trust model — relay peer could lie about balance
|
|
- [ ] Explore UTXO set proof (SPV-style) for trustless verification
|
|
|
|
## Completed
|
|
|
|
<!-- Done tasks are moved here -->
|