lfg2025/archy

Files

T

archipelago 2ccc0381bc docs: reconcile companion guide with confirmed playback and PiP

2026-10-07 19:53:09 -04:00

45 KiB

Raw Blame History

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, peering reliability, and the IndeeHub design review. 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. The scope below remains authoritative.

1. Distributed IndeeHub publishing and paid viewing

Recover and reconcile the earlier design in the streaming plan and the distribution design 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.

Task 5 assessment — source and version checks, 7 October

Cloud currently sends every category through File Browser, using /Photos, /Music, /Documents and /. Its client obtains a File Browser token from app.filebrowser-token; that credential is not an Immich or Nextcloud identity. An installed application therefore cannot safely become a new filesystem mount or inherit access to all of that application's accounts.

The candidate catalog declares Immich2.7.4 and Nextcloud29. This is catalog metadata, not verification of each installed node's actual image/version. Before enabling a connector, probe the running version and supported API.

Source	Verified interface for the catalog version	Proposed initial behavior
Immich	2.7.4 `POST /api/search/metadata` accepts page/size and returns `nextPage`; asset metadata, original and thumbnail endpoints require `asset.read`, `asset.download` and `asset.view`; `/api/users/me` requires `user.read`	Explicitly connect the intended user's scoped key; list photographs/videos, stream permitted thumbnails/originals; preserve albums and original asset identifiers
Nextcloud	Authenticated WebDAV under `/remote.php/dav/files/{user}/`; PROPFIND exposes stable file ID, MIME, ETag and permissions; GET downloads bytes	Use the user's Login Flow/app-password authorization; navigate folders without copying storage; apply source permissions on every request

Primary references checked against the catalog versions: Immich2.7.4 API schema, Nextcloud29 WebDAV, Nextcloud29 Login Flow. The Immich specification SHA256 was d6378294dcddcf772ffdefe470da17d62a5503a74fe1bd6a28f921196901d121. Current upstream docs can describe newer APIs; do not substitute them silently.

Proposed implementation boundaries (design, not enabled features):

Add source adapters behind owner-authenticated node endpoints, keeping scoped upstream credentials in private node storage. Bind every connection to the selected upstream account and installation; never use administrator-wide enumeration or expose keys in browser storage, URLs or logs. Resolve only installed service endpoints; reject redirected credential forwarding.
Represent each item by (source, installation, account, upstream ID), with display path, MIME, size, revision and operation capabilities. Identical names across sources remain separate; a matching name is not proof of duplicate bytes or ownership. Display a source label beside integrated category results.
Start with browse/preview/download and Open in source. Editing, rename, move, delete, trash and versions remain source-owned until individually implemented and tested through its API; never modify its data directory directly. No public or paid sharing is implied by importing a source listing.
Stream bytes through authenticated bounded endpoints, preserving valid range and revision semantics. Recheck authorization for both previews and originals; encrypted/unavailable content must not fall through to privileged disk reads.
Page Immich results and lazily expand Nextcloud folders. A bounded, cancellable per-account metadata index can support whole-library category/search results; do not claim WebDAV folder enumeration is a global paginated search API. Label incomplete indexing and stale results, and invalidate on revocation, disconnect, uninstall or source revision changes. Never duplicate original file storage merely to populate Cloud.
Before enablement, qualify two users with disjoint/private/shared libraries, expired/revoked credentials, denied preview/download, install/remove/reinstall, source outage/recovery, duplicate names, renamed items, large libraries, bounded cancellation, MIME classification and account-scoped cache deletion. These cases have not been executed; no source connector is accepted yet.

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.

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

Done — 2026-10-07 browser/deployment acceptance: Monitoring, Identities and Federation cards passed on dev/Yaya at390px/1440px, including tall/shrinking neighbours, long action labels, bottom geometry, no overlap/overflow, keyboard focus and Monitoring navigation. Stress content existed only in the disposable browser DOM. Evidence:~/.local/state/archipelago/release-qualification/web5-footer-20261007/. The separate Framework Monitoring owner-browser check remains open.

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.

Nearly finished: Cloud PiP is implemented and was delivered in companion 0.5.35/build55; the operator accepted the reported Cloud PiP flow on 2026-10-07. The reusable audio adapter and developer guide are implemented in app-media-integration.md. Remaining physical edge checks include disabled/unsupported PiP, session expiry, FIPS interruption and process recreation. The accepted flow does not establish that complete matrix.

20. Companion background media for V4V and other apps

In progress — background playback operator-confirmed on APK0.5.37 (2026-10-07): The earlier APK0.5.36 failed after locking/switching apps. After installing0.5.37, the operator reports playback now works and the notification is present; song artwork is missing. Record this as acceptance of the reported background flow, not proof of the complete controls/queue/reconnect matrix or a confirmed root cause. Artwork correction and remaining lifecycle checks are ongoing. USB access is unavailable.

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 — deferred end-of-list 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.

Added by the operator after task21 on 2026-10-07. Append after public sharing; status: queued. Plan the node-to-node sharing design before implementation. Preparation: source-grounded sharing plan; no implementation or public visibility change is enabled.

Clicking Share file in Mesh opens a source-choice modal with From node and From computer. From computer opens the local device file picker; plan upload/staging and delivery within the same send flow.
From node opens a polished file-browser modal using the existing design system, with folder-tree navigation and search across all of the user's own files, not just the currently open folder. Preserve ownership/permissions; show useful paths for matching names and truthful loading/empty/error states.
Allow multiple file selections. Retain selections across tree navigation and searches, collect them in a selection area at the bottom, allow individual removal, and provide a clear Send action with a selected-file count. Keep the browser and selection area usable on mobile and desktop.
Plan and compare the supported node-to-node delivery paths before choosing the implementation: reuse existing authenticated file sharing, discovery and FIPS transports where suitable. Determine what the Mesh message carries, how recipient identity/access is checked, where file bytes reside, and how local-computer files become available without duplicate uploads or exposing unrelated/private files. Distinguish Mesh messaging from bulk-file transport; cover sender offline, recipient offline, reconnect, expiry and resumable delivery with explicit progress and failure/retry behaviour.
Support sharing an existing paid file and configuring a paid share through the existing pricing flow. When a recipient opens a paid file, present the usual purchase/payment interface and supported payment methods; verify settlement/entitlement before releasing paid content. Reuse ownership and recovery logic so repeat opens, retries and lost replies do not charge again.
Define mixed free/paid multi-file messages, recipient previews, per-file price and delivery states, existing entitlements and source deletion/withdrawal. Selecting or sending a file must not silently make it globally public; preserve the distinction from task21 public discovery.
Qualify both source choices, tree navigation, whole-library search, retained multi-selection/removal, Send, cross-node receipt/open/download, free and paid access, duplicate/reconnect recovery and responsive/accessibility behaviour.

45 KiB Raw Blame History