archy/docs/post-1.9.0-work-backlog.md

# Work requested after 1.9.0-alpha

Status: implementation and qualification in progress. 1.9.0-alpha was published
separately; these follow-ups are not in its immutable artifacts. The list below
remains the complete acceptance scope, not a claim that every item is finished.

Current evidence is recorded in [Fleet metrics](fleet-metrics-followup.md),
[peering reliability](peering-reliability-followup.md), and the
[IndeeHub design review](indeehub-distribution-current-design.md). Monitoring and
the tested signer/dashboard candidate are deployed to dev and Yaya with rollback
backups; actual IndeeHub image publication is deferred until the end as requested.
Framework's authenticated Monitoring check awaits an operator dashboard login.
Streaming, storage-source integrations, AIUI setup, V4V packaging/player,
companion hardware checks and the full Fleet acceptance matrix remain open.

Current implementation and qualification evidence: [2026-10-06 checkpoint](post-1.9.0-progress-20261006.md). The scope below remains authoritative.

## 1. Distributed IndeeHub publishing and paid viewing

- Recover and reconcile the earlier design in
  [the streaming plan](phase4-streaming-ecash-plan.md) and
  [the distribution design](dht-distribution-design.md) against current source.
  Their implementation/status statements are historical, not fresh evidence.
- Review current primary Nostr, Cashu and Bitcoin/Lightning specifications before
  selecting the protocol. Distinguish interoperable standards from custom events.
- Publishing through one instance's Backstage must make the content discoverable
  through other instances' **Archipelago** content source. This source is intended
  to become the default eventually; do not change the default without qualification.
- Reuse supported node-to-node discovery/transports and the file-payment method
  negotiation: show methods the recipient actually accepts. Include Cashu and
  Lightning to the automatically provisioned ecash Lightning address from first
  use; do not require a producer to operate LND to receive initial payments.
- Pay the producer's wallet, verify settlement before granting access, and make
  payment retries/delivery recovery idempotent. Keep producer revenue separate
  from any optional hosting/relay bandwidth charges in the older plan.
- Define timed viewing entitlements, start/expiry semantics, reconnect, resume,
  seek, device/session scope and clock/error handling. Evaluate encrypted media
  and authorized key delivery without claiming that delivered video or keys can
  be made impossible to copy or revoked retroactively.
- Use the operator's video uploaded to **Yaya Cloud**, publishing through Backstage
  for the demo. Identify the exact file and preserve the source; do not select an
  unrelated personal video or publish other Cloud contents. Payment-test amounts
  need explicit bounded authorization before real funds are spent.
- Deliver a coherent demo: publish on one node, discover on another, select a
  supported payment method, pay producer, watch, resume without repayment, and
  enforce expiry. Cover publisher outage, duplicate events, wrong mint, failed/
  delayed payment, restart and lost responses. Preserve privacy and access rules.
- Treat this as the foundation for future fully featured node-sharing apps,
  introduced and qualified individually.

## 2. IndeeHub native Nostr signer and companion reliability

- Reproduce intermittent native-signer login failure and companion grey screen
  requiring refresh/re-login. Inspect both browser and actual Android WebView.
- Cover iframe origins, signing permissions, redirects, callback/session state,
  background/resume, expired sessions, refresh and cancellation without weakening
  authentication or exporting signing keys. Preserve useful errors and recovery.
- Consult existing signer bridge documentation and prior origin/reload fixes;
  do not assume those earlier fixes address this fresh report.

## 3. Node peering and discovery

- Diagnose Yaya ↔ Archy dev: requests appear approved/pending but neither node
  appears in the other's peers; the flow is also slow.
- Trace request, delivery, approval, identity, persistence and both-node peer-list
  reconciliation. Test restart, retry/duplicates, offline recovery and reciprocal
  visibility; distinguish requested, approved, connecting and connected states.
- Show Nostr requests in the appropriate discovery/request UI.
- Rename **Find Nodes** to **Connect with Nodes**, consistently with accessibility,
  navigation and translation conventions.

## 4. Framework Monitoring

- Investigate the reported non-working Monitoring screen on Framework with
  read-only diagnostics first. Verify actual metrics, loading/error states,
  permissions and refresh/reconnect on that node. Preserve wallet/radio state.

## 5. Immich / Nextcloud files in Cloud

- Assess integration so installed Immich/Nextcloud files appear under the correct
  Cloud Files categories, without duplicating storage or exposing another user's
  private data. Determine supported APIs, user identity/permissions, thumbnails,
  originals, virtual paths and large-library pagination/indexing.
- Define view/download/edit/delete semantics per source. Preserve application
  ownership, databases, metadata and trash/versioning; do not directly mutate
  application-managed storage to bypass its API.
- Test installation/removal, permissions, unavailable apps, overlapping filenames,
  duplicate detection and category accuracy before enabling an integration.

## 6. Web5 header and node connection flow planning

- Inspect the top-bar **Wallet** label in Web5. The operator requests removing
  this cosmetic label; preserve any actual wallet navigation or accessibility
  function until its role is established, and report if it is more than a label.
- Plan a less hidden, clearer discovery and peering journey on mobile and desktop
  using the existing design system, visual styles and components. This is a flow
  and information-placement change, not a visual redesign.
- Include visible entry to **Connect with Nodes**, incoming/outgoing Nostr
  requests, approval, pending/connecting/connected status, reciprocal peer
  confirmation, offline/retry recovery, and clear return paths. Show how this
  relates to existing peers and node details rather than adding duplicate flows.
- Produce reviewable mobile/desktop flow plans before broad navigation changes;
  cover first connection and repeat use, touch/keyboard access, empty/error
  states, and the current Yaya/dev approval bug. Keep diagnostic implementation
  details out of normal user-facing steps.

## 7. Companion app launch latency

- Reproduce intermittent long app-opening delays on the actual companion and
  compare desktop/mobile browser timing for the same node/app. Measure discovery,
  readiness polling, authentication/signing, route/proxy connection, WebView
  creation and first useful rendered content separately.
- Remove avoidable waits, duplicated checks and retry loops without launching
  before an app can accept connections. Cover cold/warm launches, switching apps,
  background/resume, flaky connectivity, expired authentication and app restarts.
- Keep feedback clear and immediate, with bounded cancellation/retry and preserved
  navigation. Record before/after measurements and test actual Android devices.

## 8. Fleet comprehensive acceptance

- Inventory every current Fleet capability and turn it into a test matrix rather
  than assuming a working overview proves all functions work.
- Cover discovery, identity/deduplication, authorization, adding/removing nodes,
  status/metrics freshness, selections/filters, remote actions, update discovery
  and progress/results, reconnect/offline/restart recovery and error handling.
- Include mixed software versions, slow/unreachable nodes, partial success,
  duplicate/late replies, permission rejection and desktop/mobile behavior.
- Use disposable fixtures for destructive/restart/update scenarios; preserve real
  node wallets, application data and user choices. No new spending is authorized.

## 9. AIUI first-use/provider/funding experience

- When AIUI opens without a usable AI connection, guide the user to setup rather
  than presenting only a failed model response. Distinguish missing configuration,
  invalid credentials, insufficient Routstr funds and temporary provider outage.
- Offer concise choices to add a Claude credential, configure the supported
  OpenAI/Codex connection, or fund Routstr. Verify the actual provider/runtime
  authentication methods before labeling a credential field or promising support.
- Chat may present action buttons; use a private credential form/modal for keys,
  not an ordinary chat message. Keep credentials out of model prompts, history,
  logs and screenshots; use existing secure storage and permission boundaries.
- Open Routstr funding as a coherent modal where supported, show balance/payment
  state and update availability after funding. Preserve any unsent prompt and
  let the user continue when setup succeeds. No surprise automatic charges.
- Match the existing design system and support small screens, keyboard access,
  cancellation, invalid/expired keys, funding delay, reload/background/resume and
  successful first response. Test actual companion and desktop flows.

## 10. Node availability, offline duration and network map

- Make availability easy to scan in Fleet and Connected Nodes using explicit
  status text as well as existing visual indicators. Show last successful contact
  and an elapsed duration, such as "Last seen 2 hours ago"; only say "Offline for"
  when an observed offline transition supports that claim. Never equate an old
  relay advertisement, failed monitoring query or unknown status with proof that
  a node has been continuously offline.
- Place confirmed offline nodes after online nodes by default, with stable order
  within each group. Specify how connecting and unknown/stale nodes are ordered;
  preserve user-selected sorting, filters, selection and scroll position.
- Show offline and unknown/stale nodes distinctly on the network map, with text
  or accessible detail including last contact. Do not present retained historical
  links as live connections or silently drop long-offline nodes from the map.
- Retain useful last-contact history across refresh/restart; reconcile timestamps
  across discovery, peering and monitoring. Handle clock skew, never-seen nodes,
  stale cached data, long outages and reconnects without false precision.
- Test short/long outages, stale relay events, monitor-only failures, network
  partitions, app background/resume and status recovery on desktop and companion.
  Use the existing design system and avoid color-only status communication.

## 11. Web5 connection/sync speed and responsive navigation

- Profile and improve connection establishment, discovery, peer synchronization
  and Web5 data loading. Measure each stage and reduce avoidable serial waits,
  duplicate requests, excessive timeouts and retry storms. Preserve identity,
  trust verification and accurate readiness/status reporting.
- Reproduce delayed taps/navigation for Web5 and Cloud, especially in the Android
  companion, and the Find Nodes / nodes entry into **Federation & Peers**. Record
  tap-to-feedback, route-render and useful-data timings separately on cold/warm
  loads and with realistic slow/offline nodes and larger peer/file lists.
- Every navigation tap must give immediate feedback using existing components;
  render the destination shell promptly and load independent data incrementally.
  One slow node/request must not block the whole screen or tab navigation.
- Keep cached content visibly identified when stale; use bounded loading states
  and useful retry/error feedback. Preserve back navigation, scroll, selection
  and in-progress work; cancel or ignore superseded requests safely.
- Cover all tabs, not just these reported routes. Test rapid tab switching,
  repeated taps, background/resume, expired sessions, unavailable peers, partial
  responses and recovery on actual companion hardware and desktop/mobile browsers.
- Record before/after latency distributions and agree measurable budgets after
  establishing a baseline. Faster feedback alone is not evidence that the
  underlying connection/synchronization delay has been fixed.

## 12. Missing Fleet card metrics and secure FIPS transport

- Reproduce missing metrics on multiple Fleet **Nodes** cards; trace collection,
  authorization, transport delivery, identity matching, subscriptions/cache and
  rendering separately. Verify each metric is real, current and associated with
  the correct node; show unavailable/stale explicitly rather than invented zeros.
- Evaluate and use existing FIPS transport wherever supported and measurably
  beneficial across Fleet, discovery, peering and synchronization. Preserve peer
  authentication, access controls, confidentiality and existing trust boundaries;
  transport reachability must never grant permission to read metrics or act.
- Prefer fresh authenticated updates without duplicate polling or excessive
  subscriptions. Measure propagation latency and resource use, including large
  fleets, while retaining safe fallback for unavailable/incompatible FIPS peers.
- Test spoofed/unauthorized peers, expired trust, disconnect/reconnect, partial
  metrics, stale/out-of-order/duplicate messages, mixed transport capability and
  fallback recovery. Do not claim FIPS is faster until timings demonstrate it.

## Required qualification before user acceptance testing

Operator explicitly requires extensive headless testing using the authorized
nodes before deploying the next features for UAT. For each task, qualify source
regressions, actual browser behavior, integration between appropriate nodes,
permissions and failure/recovery paths first. Use existing access and useful
read-only checks on real nodes; use isolated fixtures for destructive scenarios.
Headless browser success does not substitute for actual companion/WebView checks
where lifecycle, native signing, media or navigation behavior is involved.

Record exact revisions/artifacts, nodes, environments, before/after measurements,
executed scenarios, failures and untested boundaries. Retest fixes and relevant
regressions; do not mark gaps passed or claim perfection. UAT handoff must contain
short node-specific steps with expected outcomes, deployment scope and rollback.
Preserve wallets, files, identities and operator app choices throughout.

If IndeeHub changes are needed, include its app update explicitly: build and test
the versioned image, preserve app data and configuration, qualify fresh install,
upgrade/restart and rollback, publish through the signed app catalog, and verify
existing nodes discover and apply the intended version. Distinguish an app-only
release from any backend/OTA dependency; use the documented decoupled app-update
path where supported. Do not silently require a full OTA for an app-only change.

Sequencing clarification: finish1.9.0-alpha first. Publish any required IndeeHub
app update at the end of the follow-up implementation and qualification, not
ahead of that work or as an untested addition to the current release.

## 13. V4V Portainer demo as a Yaya node app

- After the current release, deploy/package the existing V4V Portainer deployment
  as a demo app on Yaya, showcasing how an ordinary third-party app works on a
  node. Updated operator instruction on6October supersedes the original
  no-native-signer brief: use Nostr sign-in and the native signer, replacing the
  alpha password gate for this demo. Preserve explicit signing consent and
  cryptographic authentication; newly registered users gain no operator powers.
- Inspect the actual existing Portainer source, branch/image revision, Compose
  stack, access/authentication and data before changes; retain the working V4V
  site, stack and persistent state. Do not confuse this with the public Archipelago
  software demo at demo.archipelago-foundation.org.
- Follow the current app-development guide and supported app packaging/gate/
  lifecycle conventions. Define the app card/icon/category, launch URL/readiness,
  network/auth boundaries, health, configuration and persistent mounts properly.
  Integrate the supported native signer without implicitly granting permissions.
- Qualify fresh installation in isolation, then Yaya deployment, desktop/mobile/
  companion launch, normal app functionality, restart, update/rollback and safe
  removal behavior. Verify the deployed app actually runs the intended V4V source
  revision, not a stale build or unrelated image.
- Record a short reproducible demo flow and operator UAT checklist. Preserve
  existing Gitea/Portainer connectivity and unrelated apps; no new payment or
  public sharing of private test content is implied by the demo packaging.

### V4V node-only catalog and Sovereign Music promotion

- Source is on the existing Gitea on the146 server; locate the actual V4V repo,
  branch and deployment revision there rather than guessing a replacement source.
- Add a **Sovereign Music** banner for V4V on Yaya, following the existing
  Sovereign Streaming banner treatment. Updated request: use the final intro
  cymatic still as the background and a music/play graphic on the right, or adapt
  the app's For You banner treatment. Inspect the actual intro ending and assets.
- Fix the reported real managed-app regression: closing V4V leaves playback
  running without the native bottom player. Qualify against the signed catalog
  and real installed app, not only browser-injected package fixtures.
- Both demo app availability and its promotion must be confined to Yaya. Evaluate
  a signed per-node/DID-scoped demo catalog or existing supported node-specific
  candidate mechanism. Do not publish the demo to the global catalog or let
  unrelated nodes install it implicitly through a shared catalog cache.
- Test matching/nonmatching identities, copying URLs/catalogs between nodes,
  missing identity, refresh/restart/update and promotion visibility. Catalog
  selection or visibility must not bypass normal artifact-signature enforcement.
- This may become a real app later; preserve an explicit tested promotion path
  from node-only demo to proper public app release without duplicate app IDs,
  conflicting state, lost configuration or automatic exposure before approval.

### Private demo distribution correction

The operator authorized removal of the publicly downloadable V4V demo container
on 6 October. Preserve Yaya's working installed demo, its data, and a private
recovery image. V4V application source and images must remain private until the
operator explicitly approves publication. Audience restriction on a signed node
catalog does not make the referenced registry image private. Updated deployment
must use a qualified private delivery path; do not republish the demo image.

### V4V persistent playback and existing demo music catalog

- Use the demo song catalog from the existing V4V Portainer demo in the Gitea
  repository identified above. Inspect its actual catalog configuration and media
  sources; preserve artist attribution and payment destinations. Do not substitute
  an invented catalog or copy credentials into public app configuration.
- Integrate V4V with the local player bar: leaving or closing the app view must
  retain playback, expose track information and playback controls, and offer a
  button to reopen V4V at the same track and position without restarting playback.
  Explicit stop remains available. This concerns closing the app view; operating
  system termination/background restrictions require separate qualification.
- Inspect supported app/player integration before choosing an implementation.
  Maintain one playback session, prevent duplicate audio on reopen, authenticate
  app-to-shell messages, and support the updated native Nostr sign-in requirement.
- Test navigation, repeated close/reopen, pause/resume/seek, track changes,
  disconnect/recovery and unavailable media on desktop and the actual companion.
  Check track, queue and position continuity, accessible compact controls and
  mobile background behavior. Record platform limitations rather than promising
  playback after an operating system terminates the app.
- Keep catalog and player integration within the Yaya-only demo scope until
  separately approved for general release.

## Federated Nodes state sync reliability and progress

- Federated Nodes sync currently gives too little feedback and can take a long
  time when one peer is unreachable. Show an accessible spinner, the number of
  eligible nodes, current phase and a clear success/partial-failure result.
- Bound concurrent peer syncs so one slow or dead peer cannot serialize the
  entire federation refresh. Prefer the authenticated FIPS route when
  available, preserve the existing bounded fallback, and keep per-peer errors
  visible without discarding successful results.
- Keep sync state convergent across retries and reconnects; prevent duplicate
  clicks, stale responses or an incomplete refresh from looking like success.
  Qualify healthy, slow, offline, mixed-transport, large-federation and mobile
  layouts before acceptance.

## 14. FIPS media transport requirement

- Operator explicitly requires FIPS for streaming peer files and distributed
  IndeeHub media. Verify the actual node-to-node media-byte path uses FIPS, not
  merely discovery, metrics, payment negotiation or a connection-status label.
- Reconcile the earlier multi-transport/swarm design with this requirement.
  Preserve normal authenticated browser/companion playback interfaces while
  carrying the inter-node stream over authenticated, authorized FIPS connections.
- Cover progressive/range requests, HLS segments as applicable, seek, pause/resume,
  reconnect, producer/cache-peer outage, backpressure, bandwidth and resource use.
  Preserve encrypted-content and timed-entitlement/payment enforcement end-to-end.
- Define and expose behavior when no usable FIPS route exists. Do not silently
  call another media transport FIPS or mark this requirement complete while the
  actual stream continues over an unrelated fallback. Any fallback policy must
  be explicit and reconciled with the operator's all-streaming requirement.
- Instrument transport selection and verify it in headless multi-node integration
  tests and actual mobile/desktop playback. Keep technical diagnostics available
  without burdening normal playback with implementation details.

## 15. MeshCore public-channel reliability and settings clarity — perform last

Added by the operator on 2026-10-06, explicitly at the end of this backlog.
Framework is Heltec V4; Archi dev is Heltec V3. The operator configured both for
UK in Frequency Plan but reports no messages between them, no other radios
visible, Framework reporting “mesh listener isn't running”, and intermittent
502 Bad Gateway on the mesh page. This request reopens Framework radio
investigation for this scoped task; earlier hardware deferral is not a pass.

- Diagnose actual firmware/protocol, device identity and serial ownership,
  listener lifecycle, channel identity/key and every relevant RF parameter on
  both radios. Matching regional labels alone does not prove matching settings.
  Preserve radio identity and existing settings; do not flash or reset merely
  because discovery is empty. Use the authorized UK plan and verify applicable
  hardware/firmware constraints before transmitting.
- Trace public-channel transmission and reception end to end on both nodes:
  UI acknowledgement, serial command/result, radio delivery and listener event,
  persisted message and rendered conversation. Distinguish sent from received;
  report listener/USB/RF failures accurately. Do not claim no nearby radios means
  broken discovery without a known transmitting peer.
- Investigate the missing-listener error and intermittent 502 separately.
  Cover service readiness, process ownership, competing serial clients, USB
  detach/reconnect, background/resume, stale connections, backend/radio restart,
  bounded retries and recovery without duplicate listeners/messages.
- Compare current official MeshCore documentation and established MeshCore apps
  when needed. Qualify actual public-channel behavior and interoperability;
  do not substitute another protocol's radio settings or infer compatibility.
- Simplify the satellite/settings tab using the existing design system. Explain
  and organize Radio Settings versus Frequency Plan, show actual applied/read-back
  values, and distinguish a proposed change from one confirmed on the radio.
- After earlier backlog work: implement, deploy, test real messages in both
  directions between Framework and dev, investigate failures, repair and repeat.
  Include desktop and companion, private-key-safe diagnostics, long-running
  listener stability, restart/reconnect and meaningful negative cases. Record
  firmware/builds, radios, conditions and results. Simulated or headless checks
  alone do not constitute RF acceptance or a claim of flawless operation.

### MeshCore channel scope clarification

The operator explicitly requires the standard MeshCore public channel(s) used
by the wider community, not an Archipelago-specific/custom channel. Verify the
current official default channel identity/key/configuration and interoperability
with standard MeshCore clients on the selected UK RF plan. Two Archipelago radios
agreeing with each other on a private/custom channel is not acceptance. Custom
channel creation/configuration is deferred to later work and must not be added
as a substitute for repairing the standard public-channel experience.


## 16. Web5 card footer alignment

- Keep Monitoring buttons anchored to the bottom of their card when adjacent
  cards grow, including search/loading/results changes. Apply the same footer
  behaviour to matching cards without changing the design system or adding
  unnecessary minimum height.
- Preserve normal document flow and space between content and actions; avoid
  absolute positioning that overlaps content. Verify tall neighbours, shrinking
  results, long labels, keyboard access and mobile/desktop layouts.
- Record actual browser geometry checks and deployment acceptance separately.

## 17. HTTPS embedded app authentication (reported 6 October)

- User reports opening apps inside an iframe on an HTTPS node shows the app gate, while opening the same app in a separate tab works. Reproduce both modes with the same authenticated session before identifying a cause.
- Trace generated launch origins, cookie attributes and scope, bootstrap redirects, iframe navigation and gate session exchange. Preserve authentication and public-management access restrictions; do not bypass the gate or expose credentials to embedded apps.
- Test HTTPS iframe and tab, HTTP LAN compatibility, desktop/mobile companion, reload, expired sessions, denied access and logout. Record actual-node evidence separately from fixtures. This remains open, not a confirmed diagnosis.

### Task 17 progress

Yaya's app gate could not read its root-only TLS leaf key; logs confirmed
permission denied. Correcting only its group/mode restored authenticated HTTPS
iframe loading, while unauthenticated requests still return401. Source fixes
cover startup migration, hostname regeneration, first boot and explicit rotation;
tests pass. Exact operator hostname/app, trusted TLS and companion acceptance
remain open. See `docs/https-app-gate-followup-20261006.md`.

## 18. Firewall and tunnel UI/settings

Status: handover read and acknowledged on6October; implementation pending.
The private handover and acknowledgement live in the separate mining review
checkout. Do not commit its deployment addresses or operational details here.

- Keep this task after the previously deferred MeshCore work. The subsequent
  connection UX additions below follow all other tasks and their acceptance.
- Network → Local network: make the Firewall Active row clickable and add a
  bottom-anchored Firewall & tunnels button. Both open one central settings
  screen; app pages may link to it, but are not the primary configuration UI.
- Show firewall services/ports, protocols, allowed sources and effective state;
  tunnel connection/handshake status, peers and endpoints; manifest-backed app
  and service selection, existing tunnel, public port and domain when relevant.
- Treat transport reachability separately from browser/app-gate authentication.
  Raw TCP services need a copyable protocol endpoint, not an HTTP proxy host or
  certificate requirement. Keep mining service exposure separate from admin UI.
- Own the complete route: public forwarding, container/host listener and node
  tunnel firewall, restricted to the tunnel peer. Show independent checks and
  name the precise failing stage. Unmanaged/unreachable VPS must show VPS setup
  required with concrete instructions, never a misleading success indication.
- Preserve unrelated rules/tunnels/apps; validate before applying, persist scoped
  changes, roll back failures, remove only owned exposure rules on disable, and
  provide repair/reconcile for detected drift.
- Preserve the manual node repair. The handover's later external mining success
  supersedes its earlier unverified-forwarding notes. Treat this as received
  evidence, not newly performed validation. Reboot/persistence gates remain open.
- Use the requested shared browser-check skill when located; it is not available
  in this session's skill catalog. Keep its browser scenarios outside repositories
  as requested, while retaining repository regression and release requirements.
- Review and integrate once through ngit, preserve the already integrated mining
  work, and mirror accepted commits to Gitea. No release gate is waived.

## Deferred expansion of tasks 3/6: connection UX and final functional review

Operator sequencing on6October: finish all other tasks, related deployments,
tests, app deployments and UAT first. Then perform this expansion and the final
functional/UX review. These are additions to existing groups, not closed work.

- Distinguish peer relationships from federation membership in labels, actions
  and removal confirmations, including nodes with both relationships. Remove only
  the selected relationship; describe exactly what changed.
- Anchor removal buttons at card bottoms. Show an immediate per-action spinner,
  prevent duplicate submissions, and show an accurate completion/error toast.
- Add a bottom-anchored Network map button to the Connected Nodes container,
  linking directly to the network map screen on desktop and mobile.
- Include peer and trusted-node counts in the Connected Nodes top summary row,
  with explicit labels and a compact responsive layout. Derive counts from the
  authoritative relationship/trust state, update them automatically, and avoid
  double-counting identities in the overall node total when categories overlap.
- Lay out these card-footer actions for mobile as well as desktop: maintain
  bottom alignment within the card, clear labels, comfortable tap targets and
  consistent spacing. Stack actions when needed instead of squeezing them;
  prevent clipping, overlap and horizontal overflow. Check narrow phone widths,
  enlarged text and loading states while preserving the existing design system.
- Measure and reduce removal latency. Verify whether an authenticated existing
  FIPS connection is preferred; implement that priority where supported, with
  bounded fallback and no weakening of identity or authorization checks.
- Hide rejected, expired and otherwise resolved Nostr requests from actionable
  lists. Prevent relay replay or stale refresh results from resurrecting them;
  retain any history needed for diagnostics separately.
- Give incoming peer requests useful notifications linking directly to the
  correct Federation/Peers request and its accept/reject actions.
- Update relationship, request, availability and operation states automatically
  across screens without routine manual sync. Handle reconnect, missed events,
  out-of-order replies and failed refreshes without invented success states.
- Federated Nodes sync is currently reported as unreliable and slow. Diagnose
  the actual transport, queue and reconciliation path; prevent indefinite
  waits; show a loader with a useful phase/status message and elapsed progress;
  provide bounded retry and a truthful success, partial-success or failure
  result. Preserve the last known state while a refresh is in flight and make
  the next retry safe and idempotent.
- When a request changes the 3D map layout, rotate its node to the front, top
  centre and clearly expose the request action. Cover multiple requests,
  completion, user camera interaction, reduced motion and mobile viewports.
- Review complete desktop/mobile connection flows after the other work passes:
  put useful node capabilities and actions first, reduce unnecessary navigation
  and scrolling, and assess direct links to permitted peer Cloud files. Preserve
  the design system, trust boundaries and meaningful loading/error feedback.
- Qualify real reciprocal removal/requests, offline and reconnect behavior,
  duplicate/replayed events, automatic UI convergence, notifications/deep links,
  map positioning and responsive card geometry before claiming acceptance.

## 19. Reusable media developer guide and companion Cloud video PiP

Added by the operator after the V4V player refinements. Preserve the earlier
instruction to complete the other work before the deferred final connection UX
review; this new media task is part of that preceding work.

- Document the reusable audio manifest, handshake/state/control protocol,
  security boundaries, login redirects, queue ownership, artwork, lifecycle,
  mobile layout and reproducible test/deployment steps for developers and agents.
  Use V4V as the reference; distinguish implemented source from live acceptance.
- Implement companion picture-in-picture for Cloud videos first. Investigate
  viewer controls and native Android support together, preserving the same video
  and authorized/FIPS transport rather than opening an unauthenticated second URL.
- Scope PiP to video, never expose the dashboard/management UI in the PiP window.
  Test entry/exit, play/pause/close, return, aspect ratio, rotation, background,
  completion, unsupported/disabled PiP, session expiry and network interruption.
- Require physical Android companion acceptance and signed APK distribution.
  Document the supported video/PiP contract for other apps after qualification;
  do not claim the audio postMessage bridge already implements video PiP.

Source inspection so far: MainActivity declares no supportsPictureInPicture flag,
and the native sources contain no PiP entry/controller implementation. Existing
WebViewFullscreen handles fullscreen; this is not evidence of native PiP support.

## 20. Companion background media for V4V and other apps

Later media-platform task requested by the operator. When a user closes an
embedded V4V demo or another authorized media app on the companion, playback
must continue through the phone's native media session instead of stopping or
playing invisibly without controls. Apply the same lifecycle contract to audio
and video, with video using picture-in-picture where the device supports it.

- Keep the current track/video, position, queue, artwork and authorization when
  the app surface closes; reopening resumes the same session without a second
  stream or duplicate payment.
- Expose native notification/lock-screen/headset controls for play/pause,
  previous/next, seek where supported, shuffle and stop, with controls kept in
  sync with the app and the dashboard bottom player.
- For video, move to a native PiP surface on close or explicit PiP request when
  supported, preserve aspect/orientation and return to the same WebView session;
  fall back to audio-only/background rules when PiP is unavailable.
- Enforce origin, session, entitlement and transport boundaries during
  background playback; expiry, logout, network loss and user stop must halt or
  degrade truthfully and release media resources.
- Qualify V4V on physical Android at phone, lock-screen, background, rotation,
  reconnect, completion and reopen states, then publish the reusable contract
  for other audio/video apps. No live app deployment or payment is accepted
  from browser-only tests.


## 21. Public files and folders — final task

Added by the operator on 2026-10-07. Perform after the existing tasks, including
previously deferred work. Status: queued; no public visibility has been changed.

- Add **Make public** to the More menus for both files and folders. Public means
  discoverable by any node, including nodes with no peering or federation
  relationship to the owner. Relationship approval must not be required merely
  to discover a public item.
- Reuse the existing **Share with peers pricing interface**, including optional
  charging and its supported pricing/payment choices. Use the existing brand
  **blue tints instead of orange** for this public-sharing variant; do not create
  a separate pricing interaction or change the peer-sharing colour treatment.
- Place a very small blue public-state marker at the **top-left of the file or
  folder icon**. Keep the marker readable and accessible without covering the
  thumbnail or replacing the existing icon.
- Separate public discoverability from paid access: listed paid content must
  still enforce its price/entitlement. Reuse settlement and recovery protections
  so retries do not charge twice.
- Make folder scope explicit in the reused flow, including existing/new children,
  nested items and individual visibility/pricing overrides. Preserve private
  items until the owner actually applies the action; provide a way to withdraw
  public sharing and reflect that state in menus, listings and markers.
- Qualify file/folder menus, shared pricing UI with blue styling, tiny marker,
  unrelated-node discovery, paid access, withdrawal and mobile/desktop layouts.
  No live file publication or real payment is authorized merely by adding this
  task to the backlog.