archy/docs/REMAINING-ISSUES-PLAN.md

# Remaining issues — implementation plans

Written 2026-06-17. Covers the open Gitea issues not closeable in the single-box
dev env. Each plan lists the files to touch, the approach, and how to verify
(most need .116 + .198, a companion phone, or funded wallets). Issues #3 (VPN)
and #5 (OpenWRT/TollGate) are intentionally out of scope per the user.

Status of the rest at time of writing:
- **#31** group chat over Tor — dedup-by-`msg_id` fix already shipped (open only
  for a 2-node Tor confirmation). See its Gitea comment.
- **#43** install on .70 — blocked: .70 unreachable. Plan below is a code-side
  hardening that doesn't depend on .70's logs.

---

## #46 — Pay for peer files (local wallet OR invoice+QR to seller)

> **Status (2026-06-17): Phase 1 DONE & compiles** (LN invoice + QR + release).
> Seller: `content_invoice.rs` entitlement store, `GET /content/{id}/invoice`
> + `/invoice-status/{hash}`, invoice-paid path in `serve_content`
> (`X-Invoice-Hash`), LND `create_invoice`/`invoice_is_settled`. Buyer:
> `content.request-invoice` / `.invoice-status` / `.download-peer-invoice` +
> `PeerFiles.vue` picker modal + QR + poll. Phases 2 (on-chain) and 3 (local
> LN/on-chain methods) remain; needs live funded-wallet verify. Issue left open.

**Goal.** At the paid-download step in Cloud → peer files, let the buyer choose
how to pay: (a) their local wallet (ecash today; LN/on-chain later), or (b) get
an invoice with a QR drawn on the **selling** node's wallet, pay from any
external wallet, and have the file release on confirmation.

**What exists already**
- Buyer ecash auto-pay: `content.download-peer-paid` (mints ecash, downloads
  atomically) — wired in `neode-ui/src/views/PeerFiles.vue` `downloadFile()`.
- Payer-side builder: `streaming.prepare-payment` RPC + `wallet/ecash.rs`
  (`build_payment_token`, cross-mint), `swarm/payment.rs`.
- Free streaming download: `/api/peer-content/:onion/:id` (Range-capable).
- LND invoice RPC: `lnd.createinvoice`; ecash balance: `wallet.ecash-balance`.

**Backend work**
1. **Seller-side invoice RPC** (new), e.g. `content.request-invoice`
   `{ onion, content_id }` → asks the *selling* node (over the existing
   `/archipelago/...` peer transport, same path machinery as
   `content.download-peer-paid`) to produce a payment request for `price_sats`:
   - LN: `lnd.createinvoice` on the seller, return `bolt11` + `payment_hash`.
   - on-chain: `lnd.newaddress` on the seller, return `address` + `amount`.
   - Seller records a pending entitlement keyed by `payment_hash`/address →
     content_id → buyer.
2. **Payment confirmation + release**: seller polls its own LND
   (`lnd.lookup-invoice` / address watch); on settle, marks the entitlement
   paid. Buyer side polls `content.invoice-status { payment_hash }` → when paid,
   downloads via the existing `/api/peer-content` (gate now passes because the
   entitlement is satisfied). Reuse the streaming gate in `streaming/` — add an
   "invoice-paid" path alongside the ecash-token path.
3. Keep `content.download-peer-paid` (local-ecash) as the (a) fast path.

**Frontend work** (`PeerFiles.vue`)
1. Before a paid download, open a small **payment-method picker** modal:
   - "Pay from this node's wallet" → existing ecash flow (show balance; if
     insufficient, the LN/on-chain local options when those land).
   - "Pay from another wallet (QR)" → call `content.request-invoice`, render the
     `bolt11`/address as a **QR** (add a tiny QR lib or reuse one already in the
     bundle — check `package.json`), show amount + a live "waiting for
     payment…" state polling `content.invoice-status`, then auto-download.
2. Reuse the existing `purchaseError`/`downloading` state + `triggerDownload`.

**Verify**: .116 (seller) + .198 (buyer), a funded regtest/LN wallet. Buyer
picks QR, pays from a 3rd wallet, file releases. Then the local-ecash path.

**Effort**: large (multi-day). Phase it: (1) LN-invoice + QR + release, (2)
on-chain, (3) local LN/on-chain methods.

---

## #18 — Companion app: "open in external browser" apps don't work

> **Status (2026-06-17): DONE & compiles (Rust + TS); Android unbuilt here.**
> Reverse relay hop added: `external_open_tx` channel, kiosk publishes
> `{"t":"o","url"}` on `/ws/remote-relay` (URL-validated), forwarded to the
> companion's `/ws/remote-input`. `requestExternalOpen()` in `remote-relay.ts`
> wired into all four `appLauncher.ts` external-open sites; `InputWebSocket.kt`
> + `RemoteInputScreen.kt` open it via `ACTION_VIEW`. Issue closed; live pairing
> test pending.

**Goal.** Apps configured to open in a new/external browser should launch on the
**phone** when driven from the companion controller, using the phone-default-
browser request pattern.

**What exists**
- Relay protocol in `neode-ui/src/api/remote-relay.ts` — message cases `m`
  (move cursor), `c` (click), `s` (scroll, just fixed in #7). Click resolves the
  element under the virtual cursor via `deepElementFromPoint`.
- The kiosk side runs the dashboard; "open external" apps currently try to
  `window.open` on the **kiosk**, which the phone never sees.

**Approach**
1. **Detect external-open intent on the kiosk**: when a click lands on an
   element that would open externally (anchor with `target=_blank` / an app
   flagged `opensExternally`, or an intercepted `window.open`), instead of
   opening locally, send a new relay message to the phone:
   `{ t: 'open-url', url }` over the `/ws/remote-relay` channel (the kiosk is the
   relay server side — find where it sends frames back to the companion).
2. **Companion (phone) side** handles `open-url` by doing `window.open(url,
   '_blank')` / `location.href = url` so it opens in the phone's default browser.
   - If the companion is the **Android APK** (separate codebase, see
     `Android/` + memory `feedback_companion_apk_not_in_update`), add an
     intent-based handler there; if it's a mobile web client, handle in JS.
3. Intercept `window.open` on the kiosk dashboard globally (a small shim that,
   when remote-relay is active, forwards to the phone instead of opening).

**Verify**: phone + kiosk paired; tap an "open external" app from the companion;
it opens in the phone browser.

**Effort**: medium; needs the companion device + possibly an APK change.

---

## #50 — Integrate Meshroller into our mesh features

> **Decision made 2026-06-17: seam (a) — Rust-native lift.** Full design with
> verified seam anchors (message types, dispatch, send API, event/trust gates,
> Ollama call) is in **`docs/meshroller-integration-design.md`**. Summary below.

Source: https://gitea.l484.com/clasko/Meshroller

**Phase 0 — review (DONE 2026-06-17)**
- Reviewed. Meshroller is a single ~29KB Python script (`meshroller.py`): a
  daemon that bridges a **Meshtastic** radio (via the `meshtastic` Python serial
  module, `SerialInterface`) to an **Ollama** LLM (`qwen2.5-coder`). It has
  trusted-node auth, scheduled/queued messaging, and command handling on mesh
  channels. It is a **daemon**, not firmware or a library.
- **License**: in-house (our own developer) — no third-party license blocker.
- **Hardware/transport reality**: it rides **Meshtastic serial + a local
  Ollama**. Our radio is **Meshcore** (Heltec V3) and our mesh stack targets
  meshcore. The `meshtastic` module does NOT speak meshcore, so the script
  cannot drive our radio unmodified.
- **Decision needed (architecture)**: per user, integration **must work with
  meshcore**. Two seams:
  - (a) Lift Meshroller's *behaviors* (LLM bridge, trusted-node auth, scheduled
    messaging, command parser) into our Rust mesh stack as typed message kinds —
    native to meshcore, no Python/Meshtastic dependency. Preferred for meshcore.
  - (b) Package the Python daemon as a container app and add a meshcore serial
    backend to it (keeps the script, but requires writing meshcore I/O the
    `meshtastic` module doesn't provide).
  This choice is the remaining gate; the rest of Phase 1 below stands.

**Phase 1 — choose the seam**
- Our mesh stack: `core/archipelago/src/mesh/` (`mod.rs` `MeshService`,
  `listener/`, `protocol.rs`, `types.rs`). Decide:
  - If Meshroller is a *protocol/feature on the same radio* → implement it as a
    typed message kind in our `MeshMessageType` + `listener/dispatch.rs`
    (mirrors how block headers / alerts are handled).
  - If it's a *separate transport/daemon* → wrap it behind our transport router
    (`transport/`) like FIPS/LAN/Tor.
- Reuse the event seam (`MeshEvent`) so the UI gets pushes (same path we just
  wired for #48).

**Phase 2 — UX** (ties into `project_mesh_telegram_plan`)
- A dead-simple onboarding + usage flow in the Mesh tab. Define the 1–2 killer
  actions and design the setup wizard.

**Verify**: 2 radios (the .116 Meshcore + a second). 

**Effort**: multi-day; gated on the Phase 0 review + a license/architecture
decision.

---

## #15 — netbird app doesn't work (LOW PRIORITY)

> **Status (2026-06-17): DIAGNOSED LIVE on .198 + FIXED (option A shipped); login works.**
> THE real blocker: the dashboard needs a **secure context** —
> `window.crypto.subtle is unavailable` over plain http, so OIDC PKCE threw
> before login. Fix: proxy now serves **HTTPS** (self-signed cert at install,
> `8087:443`, all origins `https://`); frontend opens netbird in a **new tab**
> (self-signed-HTTPS iframe is blocked). Layered fixes also in `stacks.rs`:
> nginx `resolver <gateway>` + variable upstreams (IP-cache 502; `resolver
> local=on`/`${NGINX_LOCAL_RESOLVERS}` FAIL on nginx:1.27-alpine), LAN-IP
> canonical origin + CORS + multi-origin redirect URIs, `/nb-auth`+`/nb-silent-auth`
> SPA fallback (were 404), and a stale-store note (wipe to re-init). Also found:
> `conmon died` zombie containers (recreate fixes; #53). Validated on .198,
> registration+login succeed. Trusted-cert/iframe (option B) = #56;
> registry-app migration = #52. Existing nodes need a clean reinstall.

**Diagnose first** (likely a container/config issue, like other app fixes):
1. On a node: `podman logs <netbird container>` — capture the actual failure.
2. Check the app manifest + install path (`container/` install, env, ports,
   the four iframe-sync places per memory `feedback_gitea_iframe_setup` if it
   has a UI).
3. netbird needs a management URL / setup key — confirm whether the app expects
   config we don't provide, or a host capability (TUN device / NET_ADMIN) the
   rootless-podman setup lacks.

**Likely fix**: either supply the missing env/setup-key UI, or add the required
container capability. Low priority — schedule after the above.

---

## #43 — Install errors at DID-creation + password screens (.70); FIPS slow

`.70` is unreachable, so we can't read its logs. Code-side hardening that helps
regardless:
> **Status (2026-06-17): hardening DONE & compiles.** Root cause was a
> non-idempotent `seed.generate` that overwrote node keys under the client's
> retry storm on slow first boot. Fixed: idempotent generate + retry-safe
> verify (`seed_rpc.rs`), transient-vs-genuine error handling in
> `OnboardingSeedGenerate/Verify.vue`, and a non-blocking FIPS status on
> `OnboardingDone.vue`. Issue closed; full closure wants a fresh install on a
> reachable node + re-test on .70.

1. **Onboarding error surfacing** — in the seed/DID + password onboarding views
   (`OnboardingSeed*`, the password step) and their RPC handlers
   (`seed.generate` / `seed.verify` / `auth.setup`), make a *successful*
   operation never show an error toast, and make genuinely-failed ops show the
   real message + a retry — so cosmetic errors (op actually succeeded) stop
   alarming users. Audit the promise/catch paths for races where a slow backend
   resolves after a timeout fires.
2. **FIPS start delay** — confirm `spawn_post_onboarding_fips_activate`
   (`api/rpc/seed_rpc.rs`) isn't blocking onboarding; it already runs detached.
   Consider surfacing "FIPS starting…" status instead of letting it look stuck.

**Verify**: a fresh ISO install on a reachable node (.198 or a scratch box),
watch the DID + password screens; then re-test on .70 once reachable.

**Effort**: small–medium (the hardening); full closure needs a repro node.