feat: v1.2.0-alpha — E2E encrypted mesh relay, steganography, relay status polling
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>
This commit is contained in:
Dorian
@@ -9,6 +9,8 @@
|
||||
| **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
|
||||
|
||||
@@ -66,6 +68,59 @@ The incoming transactions feature (lnd.gettransactions RPC + wallet badge UI + a
|
||||
- [ ] 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 -->
|
||||
|
||||
Reference in New Issue
Block a user