Archipelago — open-source initial import
This commit is contained in:
+23
@@ -0,0 +1,23 @@
|
||||
---
|
||||
created: 2026-07-30T22:19:31.770Z
|
||||
title: Connected-nodes list must scroll at row-matched height, not grow to fit
|
||||
area: ui
|
||||
severity: blocker
|
||||
files:
|
||||
- neode-ui/src/views/web5/Web5ConnectedNodes.vue
|
||||
- neode-ui/src/views/web5/Web5.vue
|
||||
---
|
||||
|
||||
## Problem
|
||||
|
||||
Dorian reports (2026-07-30): the connected-nodes container's inner list was still meant to scroll, and currently it doesn't — it grows to fit all rows without a scrollbar. The intended behavior for the row layout:
|
||||
|
||||
- The connected-nodes container sits in a row next to another container (on the right).
|
||||
- If the right-hand container is TALLER, the connected-nodes inner list should extend/scale to match the right container's height.
|
||||
- Within that matched height the list must remain SCROLLABLE when it has more rows than fit — it must NOT expand to show all entries scroll-free (which stretches the row).
|
||||
|
||||
So: height is driven by the sibling (equal-height row), overflow inside is `scroll`, never grow-to-fit. Likely component: `Web5ConnectedNodes.vue` inside `Web5.vue`'s row layout (verify — "connected nodes" also appears in settings AccountInfoSection). This sounds like a regression/misimplementation of an earlier request ("was still meant to scroll").
|
||||
|
||||
## Solution
|
||||
|
||||
Classic equal-height-row + inner-scroll pattern: the row uses flex with stretch alignment; the connected-nodes card gets `min-height: 0` (or `h-full` with a min-h-0 flex column) and the inner list `flex-1 overflow-y-auto`, so its height tracks the taller right-hand sibling while the list scrolls internally. Confirm exact container with Dorian's screenshot/preview if ambiguous. Standing rule: change only this behavior — no other visual changes.
|
||||
+21
@@ -0,0 +1,21 @@
|
||||
---
|
||||
created: 2026-07-30T22:19:31.770Z
|
||||
title: Fedimint gateway must not install with a pre-set password
|
||||
area: security
|
||||
severity: blocker
|
||||
files:
|
||||
- core/archipelago/src (app orchestrator / secrets materialisation)
|
||||
---
|
||||
|
||||
## Problem
|
||||
|
||||
Dorian reports (2026-07-30): the Fedimint gateway app installs with a password already set up — i.e. a default/pre-baked credential rather than one generated at install time or set by the user. Default credentials on a Lightning/fedimint gateway are a security hole: anyone knowing the shipped default can access the gateway. Dorian rated this a blocker.
|
||||
|
||||
This also violates the repo's standing secrets invariant (CLAUDE.md): secrets must be manifest-declared (`generated_secrets`, materialised by `container::secrets`, 0600/rootless) — never hardcoded or per-app baked in.
|
||||
|
||||
## Solution
|
||||
|
||||
Tracked as requirement **FED-07** (Phase 1, ROADMAP success criterion 7 — needs a gap plan since phase 1's 10 plans predate it):
|
||||
- Find where the fedimint gateway app's manifest/install path sets its password (check `/opt/archipelago/apps/*/manifest.yml` for the gateway, and the orchestrator's secrets materialisation).
|
||||
- Move it to `generated_secrets` so each install gets a unique credential, or require explicit user setup.
|
||||
- Migration path for existing installs still carrying the default password (migrations must never destroy data).
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
---
|
||||
created: 2026-07-30T22:19:31.770Z
|
||||
title: Keep FIPS/Tor pills on cloud files and show them on mobile
|
||||
area: ui
|
||||
severity: blocker
|
||||
files:
|
||||
- neode-ui/src/views/Cloud.vue
|
||||
- neode-ui/src/views/CloudFolder.vue
|
||||
---
|
||||
|
||||
## Problem
|
||||
|
||||
Dorian loves the FIPS/Tor pills shown on cloud files ("really helpful") — they must be kept and never removed in any future cleanup or refactor. However, they do not (or may not) display on mobile widths, where they are hidden or cramped. Dorian rated mobile visibility a blocker: on mobile, users genuinely can't see the security/transport state of their files.
|
||||
|
||||
Context: captured 2026-07-30 during phase 02 (ui-performance) execution. The pills live in the Cloud file listing UI (Cloud.vue / CloudFolder.vue area — verify exact component when picking this up).
|
||||
|
||||
## Solution
|
||||
|
||||
Ensure the FIPS/Tor pills render at mobile breakpoints in the cloud file views — likely responsive-layout work (wrap/stack/compact-pill variant) rather than new functionality. Must follow the standing rule: no changes to existing desktop visuals/animations — mobile-only additions. TBD exact approach after inspecting the component at mobile widths.
|
||||
@@ -0,0 +1,54 @@
|
||||
---
|
||||
created: 2026-07-30T22:19:31.770Z
|
||||
title: Migrate all VPS2 references to https://source.archipelago-foundation.org (stop exposing IP; TLS everywhere)
|
||||
area: security
|
||||
severity: blocker
|
||||
files:
|
||||
- apps/*/manifest.yml
|
||||
- app-catalog/catalog.json
|
||||
- neode-ui/public/catalog.json
|
||||
- core/archipelago/src (update.rs, container/registry.rs, image_versions.rs, image_policy.rs, quadlet.rs, prod_orchestrator.rs, app_catalog.rs, companion.rs, api/rpc/package/*)
|
||||
- core/container/src/podman_client.rs
|
||||
- core/archipelago/src/fips/anchors.rs
|
||||
- scripts/self-update.sh
|
||||
- scripts/first-boot-containers.sh
|
||||
- scripts/create-release.sh
|
||||
- scripts/create-release-manifest.sh
|
||||
- scripts/image-versions.sh
|
||||
- scripts/generate-app-catalog.sh
|
||||
- scripts/bootstrap-switchover.sh
|
||||
- release-manifest.json
|
||||
- releases/manifest.json
|
||||
- tests/lifecycle/remote-lifecycle.sh
|
||||
- .gitea/workflows/demo-images.yml
|
||||
- neode-ui/src/components/CompanionIntroOverlay.vue
|
||||
---
|
||||
|
||||
## Problem
|
||||
|
||||
Dorian (2026-07-30, CRITICAL): every VPS2 service is referenced by raw IP `146.59.87.168` — plain HTTP for most — exposing the IP in shipped artifacts and requiring insecure-registry config on every node. Everything must move to `https://source.archipelago-foundation.org` "perfectly so all the stuff we use it for works".
|
||||
|
||||
**Verified inventory (2026-07-30):** ~196 references.
|
||||
- `:3000` (Gitea — git/raw/releases AND the OCI container registry): **194 refs** — every app manifest's `image:` field, both catalogs (app-catalog/catalog.json + neode-ui/public/catalog.json, 23 each), compiled Rust core (self-update, registry allow-list, image policy/versions, quadlet gen, package RPCs, podman client), OTA manifests (release-manifest.json, releases/manifest.json), lifecycle tests, release/first-boot/self-update scripts, CI workflows, docs, UI marketplace data.
|
||||
- `:2100` (companion APK package server): 1 ref (`CompanionIntroOverlay.vue`).
|
||||
- `:8444` (FIPS trust anchor, raw TLS — `ARCHY_ANCHOR_ADDR` in `fips/anchors.rs`): 1 ref.
|
||||
|
||||
**Domain coverage verified live (2026-07-30):**
|
||||
- git clone/ls-remote over HTTPS: ✓ (works; `gitea-ai` remote already switched)
|
||||
- Gitea raw + releases: ✓ (HTTP 200)
|
||||
- Container registry `/v2/` through the domain: ✓ (proper 401 auth-challenge; TLS pulls will work and the insecure-registry hack becomes removable)
|
||||
- `:2100` APK server: ✗ NOT behind the domain — needs an openresty route/subdomain on VPS2 (Dorian/VPS2-side)
|
||||
- `:8444` FIPS anchor: ✗ raw TLS service, can't share 443 — at minimum switch the constant to a DNS name (e.g. anchor host + :8444); check whether anchors pin certs before touching (security-sensitive)
|
||||
|
||||
## Solution
|
||||
|
||||
Execute as a dedicated quick task IMMEDIATELY AFTER phase 2's 02-08 (don't disturb the dev-pair perf measurements; requires core Rust rebuild + node verification per CLAUDE.md discipline):
|
||||
1. Mechanical rewrite of all `:3000` refs → `https://source.archipelago-foundation.org` (registry image refs become `source.archipelago-foundation.org/lfg2025/<img>:<tag>` — no port, implies 443/TLS).
|
||||
2. **Image-ref transition safety:** running containers/quadlets store the OLD image name; migration must not orphan or re-pull-break existing apps (migrations never destroy data). Plan the transition: catalog+manifests flip, orchestrator treats old/new registry names as equivalent during adoption, or staged re-tag.
|
||||
3. Rebuild core, run the lifecycle gate on a dev node (NOT the fleet), verify: self-update fetch, catalog fetch, image pull via domain, app install end-to-end.
|
||||
4. Keep the IP endpoints alive on VPS2 during transition — nodes updating FROM old releases still hit IP URLs (fallback window until fleet rolls past).
|
||||
5. `:2100` + `:8444`: Dorian is setting these up (2026-07-30) as:
|
||||
- `companion.archipelago-foundation.org` → replaces `http://146.59.87.168:2100` (companion APK downloads; update `CompanionIntroOverlay.vue` + any packaging docs). HTTPS assumed — verify before flipping.
|
||||
- `fips.archipelago-foundation.org` → replaces the raw IP in `ARCHY_ANCHOR_ADDR` (`fips/anchors.rs`), becoming `fips.archipelago-foundation.org:8444` (or whatever port Dorian lands on). SECURITY-SENSITIVE: check whether the FIPS anchor validation pins certificates/identity to the address before changing; verify anchor handshake against the new name from a dev node before fleet rollout.
|
||||
- As of 2026-07-30 22:50 UTC neither subdomain resolved yet — re-verify DNS + TLS at execution time; do not flip these two refs until both probes pass.
|
||||
6. Remove insecure-registry config from node provisioning once pulls verify over TLS.
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
created: 2026-07-30T22:19:31.770Z
|
||||
title: Add loader states to surfaces that take time to open
|
||||
area: ui
|
||||
severity: major
|
||||
files:
|
||||
- neode-ui/src/views (inventory needed — which opens are slow with no loading affordance)
|
||||
---
|
||||
|
||||
## Problem
|
||||
|
||||
Dorian (2026-07-30): "some stuff doesn't have loader states when it's gonna take time to open" — certain screens/actions with genuinely slow opens give no loading feedback, so the UI feels dead/broken while working.
|
||||
|
||||
## Solution
|
||||
|
||||
Inventory slow-open surfaces (02-08's PERF-AFTER timings + the flagged timing regressions are a starting list: Discover, Server, Web5, Fleet, AppDetails, OpenWrtGateway); add house-style skeletons/spinners where an open can exceed ~300ms, consistent with the phase 2 rule that cached revisits show no spinner. Clearest confirmed instance (02-08 classification, pre-existing since 2026-07-22): `Cloud.vue` `viewPaidItem()`'s `content.owned-get` call has a 60s timeout and zero loading indicator. `CloudFolder.vue`'s native file grid already has a skeleton (fine). Tracked as UIFIX-06 (phase 1).
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
---
|
||||
created: 2026-07-30T22:19:31.770Z
|
||||
title: Onboarding tickbox hidden below fold on short screens — make it beautifully obvious
|
||||
area: ui
|
||||
severity: blocker
|
||||
files:
|
||||
- neode-ui/src/views/OnboardingSeedGenerate.vue
|
||||
- neode-ui/src/views/OnboardingWrapper.vue
|
||||
---
|
||||
|
||||
## Problem
|
||||
|
||||
Dorian reports (2026-07-30): on shorter screens, the onboarding screen's tickbox (the seed-phrase confirmation checkbox in `OnboardingSeedGenerate.vue` — verify it's this step) sits below the fold inside a scrollable area, and it's not obvious it exists — users don't realize they need to scroll to find it, so onboarding appears stuck. Blocker: this stalls new-user onboarding on small displays.
|
||||
|
||||
## Solution
|
||||
|
||||
Make its presence obvious "in a beautiful way" (Dorian's words — design discretion, but it must feel intentional and match the house glass/dark style, not a bolted-on arrow). Candidate approaches to evaluate:
|
||||
- A soft bottom scroll-affordance: gradient fade at the container's bottom edge plus a subtle animated chevron/pulse when unscrolled content remains, disappearing once the tickbox is in view.
|
||||
- Or make the tickbox + continue button a sticky footer of the card on short viewports so it's always visible, with the seed content scrolling behind it.
|
||||
- Or auto-scroll/nudge the container after the seed is revealed.
|
||||
|
||||
Constraints: follow the standing rule — don't alter the existing onboarding look beyond this affordance; keep desktop/tall-screen appearance unchanged; whatever ships must be verified on an actual short viewport (e.g. small laptop / mobile landscape).
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
created: 2026-07-30T22:19:31.770Z
|
||||
title: Paid Files pictures open in a browser tab instead of the app lightbox
|
||||
area: ui
|
||||
severity: major
|
||||
files:
|
||||
- neode-ui/src/views/Cloud.vue (Paid Files sub-tab — locate the picture click handler)
|
||||
---
|
||||
|
||||
## Problem
|
||||
|
||||
Dorian (2026-07-30, on archi-dev-box; initially said "peer files", corrected to **Paid Files**): in the Cloud tab's Paid Files section, clicking a picture opens it in a new browser tab rather than the in-app lightbox that exists elsewhere ("the lightbox we've made"). Inconsistent media UX.
|
||||
|
||||
## Solution
|
||||
|
||||
Route Paid Files image clicks through the existing lightbox component. Classified by 02-08 (pre-existing, introduced f3393581 2026-07-22): `Cloud.vue`'s `viewPaidItem()` (~line 470) calls `window.open(...)` instead of routing into `MediaLightbox.vue`. Fix: invoke MediaLightbox the way My Files does. Tracked as UIFIX-04 (phase 1).
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
created: 2026-07-30T22:19:31.770Z
|
||||
title: PiP robustness — close lightbox fluidly, survive tab changes and buffering
|
||||
area: ui
|
||||
severity: major
|
||||
files:
|
||||
- neode-ui/src (lightbox/video player components — locate exact files)
|
||||
---
|
||||
|
||||
## Problem
|
||||
|
||||
Dorian (2026-07-30), two reports:
|
||||
1. Entering picture-in-picture on a video does not close the lightbox — it should close with a fluid on-brand animation as PiP begins.
|
||||
2. "Picture in picture must survive tab changes or video buffering pauses, doesn't seem to, please fix." — PiP currently dies when switching main tabs and/or when the video pauses to buffer.
|
||||
|
||||
Classified by 02-08 (all pre-existing, NOT phase 2): `src/utils/pip.ts`'s `togglePip()` (introduced f72d4b92 2026-07-23) never touches `MediaLightbox.vue`'s visibility state; no `onDeactivated` teardown exists in Cloud/CloudFolder/MediaLightbox (phase 2 added none there); pre-phase-2 tab switches fully unmounted the view, so PiP tab-survival never existed. The `<video>` has zero pause/waiting/stalled listeners — buffering behavior is pure native. KeepAlive actually helps now: the element persists off-screen, so survival is achievable by not letting anything pause/unmount it.
|
||||
|
||||
## Solution
|
||||
|
||||
- PiP enter → close the lightbox with a house-style fluid animation (handoff feel).
|
||||
- While PiP is active: the owning video element must not be paused/reset/unmounted by tab deactivation — exempt media playback from deactivate teardown when `document.pictureInPictureElement` is the view's video (or reparent the video to a persistent host).
|
||||
- Buffering (`waiting` events / `pause` from buffering) must not close PiP or the session — only explicit user stop should.
|
||||
Tracked as UIFIX-05 (phase 1 gap plan).
|
||||
Reference in New Issue
Block a user