apply_update's binary swap called `sudo install -m 0755 src
/usr/local/bin/archipelago`. install opens the destination for write
with O_TRUNC; the kernel returns ETXTBSY (exit 1) when the path is a
currently-running executable, which it always is during apply because
apply_update is called by the archipelago RPC handler — running as
archipelago itself. Every previous "Failed to apply update" was this
one root cause; the manual sideload path only worked because we
stopped the service first.
rename() doesn't modify the file it replaces — it repoints the path
at a new inode while the old inode stays alive for any process that
has it mapped. `mv` uses rename(). Switched to `sudo mv` (with prior
chmod+chown on the staging file) so the swap is atomic and tolerant
of the running binary.
Frontend tarball byte-identical to v1.7.7-alpha; only the binary
version string changes.
Artefacts:
archipelago 2753daec…48094d 40377648
archipelago-frontend-1.7.8-alpha.tar.gz 4fb79664…0172e9 76984615 (reused)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Pure version bump. No code changes. First release shipped with the
reinforced apply_update (timestamped staging + all-mv) and frontend
with 95% progress cap — this OTA should walk through cleanly from
.116/.198/.253 without any sideload intervention.
Artefacts:
archipelago e3f1740d…006025 40373392
archipelago-frontend-1.7.7-alpha.tar.gz 4fb79664…0172e9 76984615 (reused)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
apply_update frontend swap
Transient EROFS on .198 (filesystem hiccup — root FS mounts with
errors=remount-ro so a fleeting glitch can bounce /opt to RO for a
moment) caught the pre-cleanup `rm -rf web-ui.new web-ui.bak` mid-
stride and aborted the apply. Rewrote the swap to use a timestamped
staging dir (web-ui.new.<ms>) and a timestamped old-copy path so
nothing needs to be rm'd before the extract. After the new tree is
mv'd into place, the previous rollback copy is rotated aside with a
.<ms> suffix (best-effort) and this apply's old copy becomes the new
web-ui.bak. If the final mv fails, the staged old is restored so
nginx keeps serving.
handle_update_check manifest override
handle_update_check takes the git path whenever ~/archy/.git exists.
On the dev box (.116) that meant the Pull & Rebuild button was
always the only option even though the manifest-path OTA was
already wired via ARCHIPELAGO_UPDATE_URL. Now: if that env var is
set, we skip the git detection entirely and use the manifest path.
The regular fleet (no env var, no repo) hits the manifest branch
naturally; beta dev nodes (repo + no env var) still get Pull &
Rebuild; dev nodes with the env var explicitly set can finally test
the manifest OTA end-to-end.
Artefacts:
archipelago 356e78cc…91a6dd 40372288
archipelago-frontend-1.7.6-alpha.tar.gz 4fb79664…0172e9 76984615 (reused)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Trivial version-only bump. No code changes; binary differs only in its
embedded CARGO_PKG_VERSION string. Frontend tarball is byte-identical
to v1.7.4-alpha's (same sha), copied under the new filename to satisfy
the manifest component naming.
This exists so the fleet nodes (.116/.198/.253), all now running
v1.7.4-alpha with the fixed apply_update tar flow, can exercise the
full OTA pipeline from the UI: Check → Download (30-min timeout) →
Install (sudo install binary + sudo tar to web-ui.new + atomic swap) →
auto-restart (systemctl --no-block) → sidebar updates → state sync.
Artefacts:
archipelago 7422a695…a1a2a6 40362432
archipelago-frontend-1.7.5-alpha.tar.gz 4fb79664…0172e9 76984615 (reused)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
apply_update was extracting the frontend tarball with
`tar -xzf -C /opt/archipelago`, but the tar contents are the *inside*
of web-ui/ (root entries are ./test-aiui.html, ./assets/, etc.). So
the files landed directly in /opt/archipelago instead of under web-ui/,
and tar bailed on nginx-owned paths mid-extraction. First end-to-end
OTA test (.198) found it: "tar: ./assets/SystemUpdate-…js: Cannot
open: No such file or directory".
Now extracts into web-ui.new, chowns, then atomically swaps: move
existing web-ui → web-ui.bak, then web-ui.new → web-ui. Same pattern
as the manual sideload that's been working.
Frontend: SystemUpdate.vue fake download progress was capped at "<90"
with a Math.random()*15 increment — the last tick could push to
~104.99%. Capped at 95% with a smaller step so it stops at 95 and the
real RPC completion jumps it to 100.
Artefacts:
archipelago a14ad7e4…2a2be3 40361984
archipelago-frontend-1.7.4-alpha.tar.gz 4fb79664…0172e9 76984615
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sidebar version
detect_build_version() no longer reads /opt/archipelago/build-info.txt
first. That file was written by the ISO installer at flash time and
never rewritten by OTA or sideload, so after any binary swap the
sidebar kept advertising whatever the ISO shipped with. Now just
returns env!("CARGO_PKG_VERSION") unconditionally — always matches the
running binary.
FIPS card
The two-column grid in FipsNetworkCard.vue placed version/npub boxes
side-by-side on mobile but the anchor-status panel forced col-span-2,
creating an unbalanced empty column at every desktop width. Anchor
status moves to its own full-width row below the grid. When the
anchor is not reached, a "Reconnect" button appears next to the
status line; it calls fips.restart (45s timeout), waits 5s for the
daemon to come back, then reloads fips.status. Surfaces whether the
restart actually recovered the anchor in a status flash.
Profile picture render
Uploaded profile pictures are stored with an onion-rooted URL so
external Nostr clients can fetch them. The local browser isn't
Tor-routed though, so the <img src> silently 404'd and the UI fell
back to showing initials. Added a displayableUrl() helper on
Web5Identities.vue that rewrites http://<onion>/blob/<cid>[?...] to
same-origin /blob/<cid> for rendering, while the stored URL keeps
its onion prefix so publishing to Nostr still works for external
viewers. Pass-through for data: URLs and already-relative paths.
Identity row title
The identity list header now renders profile.display_name (when set)
and keeps identity.name as a muted parenthetical. Before, only the
internal name was shown and a user who'd customised their Nostr
display_name saw a mismatch between their own UI and what peers
rendered.
Artefacts:
archipelago 99184b95…22dc1b 40350664
archipelago-frontend-1.7.3-alpha.tar.gz 7b933cf4…74a8bc 76987031
Changelog layman-style per the saved feedback.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Three user-visible fixes shipped together.
1. update.apply permission-denied
apply_update() was doing fs::copy into /usr/local/bin/archipelago and
tar xzf into /opt/archipelago as the archipelago user — both root-owned.
The backup step succeeded (it wrote to data_dir) but the swap failed
with a silent permission denied, wrapped as "Failed to apply archipelago".
Now uses `sudo install -m 0755` for the binary and `sudo tar -xzf` for
the frontend, plus a post-apply `sudo systemctl --no-block restart
archipelago` scheduled 2s after the RPC reply so the UI sees success.
2. Apply → Install label
en/es locale strings: applyUpdate / applyTitle / applyNow changed from
"Apply" to "Install". Matches the user's mental model and distinguishes
the user-facing verb from the internal apply_update() function.
3. Identity avatar backfill
Identities created before df83163f had profile=None on disk and so
rendered as initials. load_record() now synthesizes an IdentityProfile
with a default picture (identicon for regular identities, the hex node
SVG for derivation_index=0) when profile is missing. The synthetic
profile lives only in the returned record; the file stays untouched so
a later explicit Save persists whatever the user actually chose.
Artefacts:
archipelago 70e5444e…67c589 40381960
archipelago-frontend-1.7.2-alpha.tar.gz 806b027b…358a824 76983699
Changelog rewritten layman-style per saved feedback.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Trivial bump on top of df83163f. No code changes — this exists purely so
the fleet nodes now sitting on 1.7.0-alpha have a real target to exercise
the OTA pipeline against: check → download → apply → restart → state
reconciliation. The binary content differs only in the embedded
CARGO_PKG_VERSION string.
Frontend tarball reused from v1.7.0-alpha (same bytes, copied to a new
filename to match the manifest component name convention).
Artefacts:
archipelago 7f7981bd…56eef0 40391760
archipelago-frontend-1.7.1-alpha.tar.gz (dup of 1.7.0) dc3b63af…e9a8370 76984288
Manifest changelog is a single plain-language sentence explaining that
this is the test release — per the saved feedback about keeping
fleet-facing strings readable.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Follow-up to 1fb71b4b on the same v1.7.0-alpha line.
Identity avatars
• New module `avatar.rs` generates two deterministic SVG styles keyed
off the pubkey: a 5×5 mirrored identicon for sub-identities and a
hexagonal-network motif for the master (seed index 0) identity.
Both returned as base64 data URLs, so a fresh identity has a
recognisable picture before the user uploads anything.
• `IdentityManager::create()` and `create_from_seed()` populate
`profile.picture` on creation. Index 0 gets the node SVG; all
other seed-derived + ad-hoc identities get the identicon.
Blob store — public flag for profile assets
• `BlobMeta.public` (default false) added; `BlobStore::put()` takes
a `public: bool`. Missing in legacy meta files = false.
• `POST /api/blob` now stores uploads with public=true and returns
`public_url` alongside `self_test_url`. public_url is
`http://<node-onion>/blob/<cid>` (no cap) if Tor has published the
archipelago hidden service, else falls back to the local path.
• `GET /blob/<cid>` bypasses the HMAC capability check when the
requested blob is flagged public — external Nostr clients fetching
a kind-0 `picture` URL can't hold a cap.
• Mesh callers (content_ref attachments, dispatch rehydration) pin
public=false explicitly so nothing leaks out of the mesh path.
Profile editor UX
• Collapsed Save + Save & Publish into one button — the Save action
now persists locally AND publishes the kind-0 metadata event in
one step. Uploads store `public_url` into `profile.picture` /
`profile.banner` so the published URL is reachable by external
clients.
Update client — the 15-second cliff
• Frontend `rpcClient.call` for `update.download` now has an
explicit 30-minute timeout (was falling back to the default 15 s).
`update.apply` gets 5 min, `update.git-apply` gets 15 min. Matches
what the backend is actually willing to wait for.
• Backend `load_state()` reconciles `state.current_version` with
`CARGO_PKG_VERSION` on every start. Sideloaded or reflashed nodes
were stuck advertising the old version even with a new binary in
place, which kept re-offering the same release as an update.
Manifest changelog rewritten for fleet readers per the saved feedback
(no function names, no file paths). Artefacts refreshed:
binary 12f838c5…5ba82d 40381864
frontend dc3b63af…e9a8370 76984288
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Follow-up to 56d4875b, same v1.7.0-alpha shipping band.
Backend download timeout bumped from 300s to 1800s (update.rs) with an
explicit 30s connect timeout. git.tx1138.com raw-file throughput can sit
around 70–80 KB/s, which meant OTA downloads were timing out at ~55%
through the 40 MB binary even though the SHA would have matched on a
full pull. 30 min gives ample headroom for the worst LAN-to-VPS link we
actually hit.
Frontend: SystemUpdate.vue now formats downloadPercent with toFixed(2)
via a new computed, so the progress card shows "45.23%" instead of
"45.270894%". Cosmetic only; the underlying ref still tracks raw floats.
Manifest changelog rewritten in user-facing language per the saved
feedback — no file paths, function names, or "root cause" phrasing.
Artifacts refreshed:
binary d85a71c5…982f4 40360936
frontend 8adcdacf…e687f6 76986852
ISO at image-recipe/results/archipelago-installer-unbundled-x86_64.iso
(Apr 20 09:00) carries both fixes for fresh installs.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Follow-up to 8b7cb002 (no version bump — same v1.7.0-alpha manifest):
* WireGuard peer persistence. Kernel peer state is ephemeral; the add-peer
RPC wrote each peer to data_dir/nostr-vpn/peers/*.json but nothing
re-pushed them on reboot. Result on .198: wg0 came up listening with zero
peers after last night's reboot. Added vpn::restore_wg_peers() — reads
the peers dir, waits up to 30s for wg0 to exist, then replays each via
`archipelago-wg add-peer`. Spawned from main.rs alongside the other
startup tasks.
* Reconcile + filebrowser drift. scripts/container-specs.sh load_spec_
filebrowser now declares SPEC_NETWORK="archy-net" (to match what
first-boot-containers.sh creates) and pins the filebrowser-data volume
+ wget-style healthcheck so the reconciler stops reporting network
drift. Without this, reconcile would kill the healthy first-boot
filebrowser container and recreate it on bridge, breaking the archy-net
DNS name the backend proxies to.
Manifest binary sha/size refreshed:
6c178a76…3582cc, 40361912 bytes.
Rebuilt ISO at image-recipe/results/archipelago-installer-unbundled-x86_64.iso
(Apr 20 07:10) carries both fixes baked in.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two fixes bundled into the OTA:
1. update.download hard-fail on git-path nodes. handle_update_check's git
branch reported update_available=true + update_method="git" but never
populated state.available_update, so update.download returned "No update
available to download" even though the UI showed one. SystemUpdate.vue
now routes update_method=="git" through update.git-apply (pull+rebuild+
restart via self-update.sh); manifest-path nodes keep the download→apply
flow. i18n strings + confirm modal added for the git path.
2. Reconciler creating containers behind the user's back. On fresh
unbundled installs (.198, .253) archy-mempool-db and archy-btcpay-db
materialised ~10 min after first boot because reconcile-containers.sh
walked container-specs.sh's canonical tier list and created any
"missing" container. reset_spec() now defaults SPEC_OPTIONAL="true",
so reconcile is strictly a repair tool — baseline comes from
first-boot-containers.sh (filebrowser on unbundled), everything else
from the install RPC.
Also forces OTA trigger for nodes on 1.6.0-alpha that otherwise saw
"I'm at manifest.version, nothing to do" and skipped the refreshed 1.6
artifacts.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Refreshes release binary to include 6b78bd69:
- FIPS auto-activates at onboarding end (spawn_post_onboarding_fips_activate
fires from handle_seed_generate/restore the moment fips_key lands on disk).
Previously the startup-time auto-activate ran once at boot and exited
before the user ever got to onboarding, so fresh installs still needed
a manual Activate click.
- Kiosk health-poll window 60s -> 5 min (TimeoutStartSec=360) so slower
hardware like .198 doesn't race Chromium against a not-yet-ready
backend and white-screen on first boot.
Frontend tarball unchanged — no frontend diff since 78e7c59e.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1. FIPS auto-activate at server startup only fires if fips_key already
exists on disk, which on a fresh install is never true until AFTER
onboarding. By the time the user completes seed-generate/restore,
archipelago has been running for minutes and the startup task has
long since exited. User still had to hit Activate.
Fix: call spawn_post_onboarding_fips_activate() from the tail of
handle_seed_generate and handle_seed_restore — the moment the
fips_key materialises, a detached task runs `fips::config::install`
+ `archipelago-fips.service activate`. Logged only, never blocks
the onboarding RPC.
2. Kiosk health-poll window was 30 × 2s (configs/ copy was 60 × 2s
but unused — the heredoc in build-auto-installer-iso.sh is what
actually lands on disk). On .198's slower hardware archipelago
/health wasn't ready within 60s, so Chromium launched against a
not-yet-running backend → blank window until manual reboot. Bumped
to 150 × 2s (5 min) + TimeoutStartSec=360. .253 was already well
within the window; this protects the slower box too. Standalone
configs/archipelago-kiosk.service updated in lockstep so the two
copies don't drift.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Supersedes the earlier v1.6.0-alpha artifacts from today (which were
identical to v1.5.0-alpha and only existed for the update-flow smoke
test). This drop actually changes behaviour:
- archipelago-fips auto-activates on startup when fips_key exists; no
Activate button needed.
- fips_key on-disk format migrated to bech32 nsec; legacy raw-byte
files from v1.5.0-alpha self-heal when this version reads them.
- fips.yaml schema matches upstream jmcorgan/fips 0.3+.
- VPN status row shows "Not configured" instead of "Starting…" when
wg0 isn't up — no VPN peer added yet is not a failure state.
New SHA256s + sizes in manifest.json. Fleet nodes .116/.228/.253 will
notice within 30 min (periodic update-check). Also lets .198 self-heal
its crashlooping archipelago-fips when it picks up the update.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Problems addressed (all observed on .198):
* fips_key was written as raw 32 bytes; upstream fips daemon reads it
with read_to_string() and bailed with "stream did not contain valid
UTF-8", crashlooping indefinitely.
* Activate button racy: user had to hit it, and it would keep failing
silently because the daemon couldn't parse its own config.
* FIPS schema drift (already fixed in 7d8a5864) put the config write
path behind the same broken "Activate" flow, so the fix alone
didn't help existing nodes.
* Journal was on tmpfs — every reboot wiped install/onboarding history,
making post-hoc debugging impossible.
Changes:
* identity.rs: write fips_key as bech32 nsec + newline. load_fips_keys
now auto-migrates legacy 32-byte files to bech32 the first time it
reads them, so OTA updates from v1.5.0-alpha self-heal without user
action.
* server.rs: post-onboarding auto-activate task runs on every
archipelago startup. If fips_key exists it ensures /etc/fips/fips.yaml
is schema-current and starts archipelago-fips.service. Pre-onboarding
nodes stay quiet (guarded on fips_key_exists).
* ISO build: un-mask archipelago-fips + archipelago-wg + wg-address —
all use ConditionPathExists on their key files, so systemd silently
skips them pre-onboarding (no MOTD [FAILED]). Only nostr-vpn stays
masked (legacy service, superseded by upstream fips).
* Journald made persistent via /var/log/journal + 500M cap, so
install and first-boot logs survive reboots for diagnosis.
After this, a fresh install + onboarding should bring FIPS up automatically
with no user interaction. The UI "Activate" button can stay as an escape
hatch (the RPC is still there) but is no longer on the critical path.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
No functional changes from v1.5.0-alpha — this release exists only to
validate the in-app update pipeline end-to-end (manifest check → staged
download → apply → restart → version bump in UI sidebar).
Dropping just the manifest + artifacts; no manual deploy to the fleet.
.116/.228/.253 should notice within 30 min (periodic update-check
interval) and surface the update in the dashboard.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Anchored regex was too strict — `strings` concatenates adjacent printable
bytes so the version never sits on its own line. The 1.5.0-alpha binary
DOES contain the version but as part of `1.5.0-alpharpcNot Found`. Fixed
by switching to `grep -qF $VERSION`: substring match is safe because the
version string is specific enough that accidental collisions are
vanishingly unlikely.
Caught mid-build today: check rejected the correct local binary, fell
through to container source-build — ISO still produced correctly but
wasted ~10 min on an unnecessary rebuild.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1. FIPS daemon config schema drifted: upstream jmcorgan/fips now takes
`node.identity.persistent: true` (keys read from config-dir/fips.key)
and `transports.udp.bind_addr: "0.0.0.0:PORT"` instead of
`identity.key_file/pub_file` + `transports.udp.enabled/port`. The
`tor:` transport was dropped entirely; archipelago handles Tor
fallback itself. fips.yaml generated by archipelago::fips::config
now matches the upstream schema, and archipelago-fips.service stops
crashlooping on Activate. Observed on .198: 52 restarts with
"data did not match any variant of untagged enum TransportInstances
at line 7 column 3".
2. ISO backend-binary capture didn't verify that the captured binary
matched the checked-out Cargo.toml version. Today's 14:40 ISO
shipped a stale 1.4.0 binary because `core/target/release/archipelago`
pre-dated the 1.5.0-alpha bump — the build grabbed it via the
first-priority "local release build" path without looking at it.
All four capture sources now go through verify_backend_version()
which greps the binary for the expected version string; mismatches
are skipped so the build falls through to the source-build path.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
On this host (and potentially others with a particular podman/overlay
state), passing the multi-hundred-line stage-2 script via
`debian:trixie bash -c '...'` caused debootstrap to fail at
"Extracting apt... tar failed" on the very first package — no matter
what patch, storage cleanup, or env-reset we tried.
Running the exact same script body via a bind-mounted file
(`bash /installer-env.sh`) succeeds. So: write the body to a temp
file in WORK_DIR, bind-mount it read-only, and have the container
bash execute it from the file. Same behavior, different invocation,
works.
Was blocking every ISO rebuild since ~10:57 local. First successful
build since: 14:40, sha256 41fad2ff…, 2.3GB.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Debian Trixie apt 3.0.3's data.tar has duplicate entries for the same
path (regular file + symlink at e.g. libapt-private.so.0.0), and tar
bails on the second entry with "Cannot create symlink: File exists",
failing debootstrap on the very first package. Patch debootstrap's
tar invocation to use --skip-old-files so the duplicate is ignored.
Was blocking every unbundled ISO rebuild since the Trixie apt bump.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Previous build's STEP 47/50 log showed:
RUN for svc in nostr-vpn archipelago-wg archipelago-wg-address; do
rm -f /etc/systemd/system/.service
ln -sf /dev/null /etc/systemd/system/.service
done
The Dockerfile is generated via <<DOCKERFILE heredoc in the build
script, so unescaped $svc resolved in the outer bash BEFORE Docker
ever saw it, leaving nostr-vpn/wg masks as a hidden `.service` file
with no effect. nostr-vpn still tries to start on boot → [FAILED].
Fixed with \$svc so the literal lands in the Dockerfile for Docker's
shell to expand per iteration.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Fresh install of .198 reported "FIPS has an npub but says inactive".
The debian package writes /etc/fips/fips.pub during install (whence
the npub) but leaves the upstream fips.service disabled. Result:
FipsStatus.service_active = false, dashboard shows "inactive" until
the user hits Activate. Explicit `systemctl enable fips.service`
in the Dockerfile so first boot brings the daemon up immediately.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1. nostr-vpn still failing despite last mask attempt — confirmed in
the 6th ISO's rootfs.tar: the .service file was present but
not in multi-user.target.wants. Previous `systemctl mask` silently
no-oped because the real file was already there. Fixed properly
with explicit `rm -f` + `ln -sf /dev/null` for nostr-vpn,
archipelago-wg, and archipelago-wg-address — same /dev/null
symlink state that `mask` would produce on a clean install.
2. Kiosk didn't come up on first boot, only on reboot. Extended the
ExecStartPre health-poll from 30s → 120s (unbundled ISO takes
longer to settle on first boot: archipelago initializes state,
pulls FileBrowser, frontend settles), raised TimeoutStartSec to
180s, and added After=systemd-user-sessions.service +
After=network-online.target so X / Chromium aren't racing.
3. /init: line 29: can't create /root/etc/network/interfaces error
on installer boot — debootstrap --variant=minbase omits ifupdown
so the target has no /etc/network/ directory, and live-boot's
init tries to seed it. Non-fatal but noisy. Added ifupdown +
isc-dhcp-client to the debootstrap --include list.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
5th ISO attempt died in rustables's build.rs (which uses bindgen to
wrap libnftnl) with "couldn't find any valid shared libraries
matching: libclang". bindgen requires libclang.so at build time
to parse C headers. rustables also needs libnftnl-dev + libmnl-dev
for the actual wrappers.
Added to the fips-builder stage apt install line.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Third time's the charm. The upstream fips Cargo.toml puts fips-gateway
behind features.gateway = ["dep:rustables"], so the previous two
attempts (--bins, --workspace --bins) never produced the binary —
only the default feature set was compiled. cargo deb --no-build then
panics looking for the missing binary.
Inspected /tmp/fips-investigate (fresh clone of upstream main on
2026-04-19) to confirm — the feature flag is the gate, not a
workspace layout issue.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Plain `cargo build --release --bins` only built the root crate's
binary targets. fips-gateway is a workspace member, so we need
--workspace to pull every member's bins. Without it cargo deb
--no-build panics looking for target/release/fips-gateway.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Consumes the new authenticated_peer_count + anchor_connected fields
from fips.status. Shows a cyan dot + "connected" when fips.v0l.io is
in the identity cache (DHT routing to unknown npubs will work), or
an orange "not reached" with a one-line explainer that federation
and messaging will fall back to Tor until the anchor reconnects.
Peer count appears on the same row so users see "3 peers" when the
fleet-pair script has been run, or "0 peers" on a fresh install
still waiting for the anchor handshake.
Block only renders when service_active — pre-onboarding the FIPS
package is masked so there's nothing meaningful to report.
Covers the UI half of task #20. Multi-anchor defaulting is still
open (need real anchor addresses beyond fips.v0l.io).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two new fields on the /rpc fips.status payload:
- authenticated_peer_count: how many FIPS peers the daemon has an
authenticated session to right now. 0 means isolated / not on
the mesh; >0 means traffic to any known npub can DHT-route.
- anchor_connected: true when the public anchor (fips.v0l.io,
npub1zv58cn7…) is present in the daemon's identity cache. The
anchor bootstraps DHT routing for general-case deployments, so
this is the best single-value indicator the UI can show for
"will federation traffic over FIPS work between previously-
unknown peers?"
Implementation: fips::service::peer_connectivity_summary shells
out to `sudo -n fipsctl show peers` + `... show identity-cache`
(archipelago user already has NOPASSWD:ALL per the ISO sudoers
and live fleet nodes, confirmed). Failure returns (0, false) so
the UI degrades to "unknown" state without crashing.
Only queried when service_active — pre-onboarding / daemon-down
nodes skip the fipsctl call entirely.
UI side (FipsNetworkCard) consumes the full status JSON, so the
two new fields are available via existing prop plumbing; visual
treatment can come later.
Also fixes ISO build (commit 3e04456c wasn't sufficient): the
Dockerfile needs `cargo build --release --bins` — upstream FIPS
added a `fips-gateway` binary target, and plain `cargo build
--release` only builds the default bin list, which caused
`cargo deb --no-build` to fail hunting for the missing binary.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Until now federation.sync-state only fired on (a) user clicking Sync
in the UI or (b) server-name push. That meant own_fips_npub,
last_transport, peer state updates — all the things v1.5 added for
auto-upgrade from Tor to FIPS — didn't propagate until the user
poked the button.
Fix: spawn a background task in server.rs that runs
federation::sync_with_peer for every Trusted peer every 30 minutes.
First run is 60s after boot (let onboarding settle) and peers are
staggered 5s apart to not hammer Tor's SOCKS proxy with concurrent
connects.
The sync path already prefers FIPS (via PeerRequest), so once peers
have learned each other's fips_npub (now automatic thanks to the
own_fips_npub broadcast in state snapshots), subsequent periodic
syncs route over FIPS — transport badge cycles from 'tor' to 'fips'
on its own without user action.
Covers task #30.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
rust:1-slim-bookworm doesn't include dbus/ssl dev headers, and
jmcorgan/fips upstream started linking against libdbus-sys + openssl
at some recent commit. Observed during the 2026-04-19 v1.5.0-alpha
rebuild: libdbus-sys's build.rs panics when pkg-config can't find
dbus-1.pc, which kills the whole cargo build → the whole ISO build
→ ships an ISO without FIPS installed.
Also mask nostr-vpn.service + archipelago-wg*.service in the rootfs
Dockerfile: these have WantedBy=multi-user.target so systemd pulls
them into the default boot target, but their EnvironmentFile + an
ExecStartPre guard cause them to [FAILED] in the boot MOTD on every
fresh install until onboarding writes their env files. Masking
keeps the startup clean; the onboarding / install RPC handlers
unmask + start them when prerequisites exist (same model as
archipelago-fips).
Bonus discovery from same diag: the default build was silently
reusing a stale rootfs cache from Apr 12 — before the FIPS
integration landed. So the v1.5.0-alpha ISO I shipped had no FIPS
package at all. Rebuild pass with --rebuild forces fresh rootfs.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The original v1.5.0-alpha cut (commit 77206a89) captured the binary
at that exact point in main. Since then ~12 commits landed that are
now live on every fleet node — own_fips_npub in state sync,
bidirectional peer flow, lazy-bind peer listener, self-peer guard,
multi-relay nostr publish + UI, avatar/banner upload, bidirectional
network requests. Rather than bump to v1.5.1-alpha for an in-flight
alpha iteration, refresh the artifacts in place so the manifest +
binary + frontend all agree.
- archipelago: sha 77206a89→e3df7a68, 40,020,488→40,078,936 bytes
- archipelago-frontend-1.5.0-alpha.tar.gz: sha 83fbacf3→2bf973ee,
53,359,792→53,358,751 bytes
- changelog extended from 7 to 15 lines to cover every landed item.
check-release-manifest.sh passes — safe to publish.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ISO itself stays out of git (2.4GB), but this pointer file records
the hash + retrieval path so anyone flashing to a fresh .253-style
install knows exactly what they're getting. Summary of code landed
in this ISO listed at the bottom so the changelog isn't scattered
across commit messages.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Previously the profile editor only accepted external URLs for
picture/banner — typing in a URL works, but anyone without their
own image host couldn't use an avatar at all. Now there's an
"Upload" button next to each field that pushes the selected file
to /api/blob and pastes the returned capability-signed local URL
(`/blob/<cid>?cap=…&exp=…&peer=…`) straight into the form field.
- Two new refs: avatarUploading / bannerUploading so each button
shows "Uploading…" independently.
- uploadAsset(ev, 'picture' | 'banner') wraps the POST, validates
HTTP 200 + presence of self_test_url, surfaces failures in the
existing profileError banner.
- File input is re-cleared on completion so the user can pick the
same file again without refreshing.
- Live preview in the <img> at the top of the editor updates
immediately because profileForm[field] is reactive.
Image persists through Save & Publish via the existing
identity.update-profile + identity.publish-profile (both now
multi-relay). The image URL is still local-only — external nostr
clients won't resolve it until we integrate a public image host
(noted in task #29).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Pairs with the backend change that broadcasts kind:0 to every
enabled relay. Web5Identities.vue's publishProfile() now reads the
richer response ({accepted, rejected, relays_attempted, published})
and shows one of three states:
- all relays accepted → "Published to all N relays (event_id…)"
- partial → "Published to X/N relays" plus a warning with the first
relay's rejection reason
- zero → "Published to 0/N relays — check Manage Relays" (error)
User can now tell at a glance whether their profile actually made
it to the wider nostr network or only the local relay.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Previously handle_identity_publish_profile defaulted to a single
hard-coded relay (ws://localhost:18081) so the user's kind:0 profile
event only ever landed on the local relay — hence "Manage Relays
shows N connected, but profile edits don't propagate" from testing.
Fix — two-layer change:
- identity_manager::publish_profile now takes `&[String]` relays
instead of one URL. Adds each relay to the nostr-sdk client,
gives 15s for handshakes, publishes, then surfaces per-relay
accept/reject in a new ProfilePublishOutcome struct so the UI
can show WHICH relays accepted vs. rejected and WHY.
- RPC handle_identity_publish_profile no longer defaults to the
local relay: pulls the ENABLED list from nostr_relays::list_relays
(the same table that powers Manage Relays) and publishes to every
entry. Accepts an optional `relays: [...]` override for tests.
- At-least-one-accept guarantee: if every relay rejects, the call
errors instead of silently reporting published=true. User gets a
real error message listing the failures.
- Response shape: `{event_id, accepted: [urls], rejected: [[url,
reason]], relays_attempted: N, published: bool}` so the UI can
show a useful status block after clicking Publish.
relay_url_matches is tolerant of trailing-slash / case differences
since nostr-sdk canonicalises URLs internally.
Covers the publishing half of task #29; avatar/banner upload UI is
still open.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Before: Alice sent /network.send-request to Bob, Bob accepted via
/network.accept-request and gained Alice in his peers list, but Alice
was never notified — her pending row sat there and she had to
manually add Bob separately. User complaint: "it's strange you have
to do it both ways."
Fix — the accept now fires a best-effort connection_accepted message
back to the requester:
- handle_network_accept_request: after writing the local peer record,
assembles a `{type: "connection_accepted", request_id, from_did,
from_onion, from_pubkey}` JSON, signs + encrypts + POSTs it to the
requester via node_message::send_to_peer. Uses PeerRequest internally
so it prefers FIPS and falls back to Tor.
- handle_node_message: parses incoming plaintext as JSON; on a match
for type=connection_accepted, auto-adds the sender to peers.json
(the existing self-pubkey guard in add_peer still applies) and
short-circuits the normal store_received path so the acceptance
doesn't also land as a chat message in Alice's inbox.
Offline handling: if Alice is offline when Bob accepts, the notify
warns and the local accept still succeeds. Alice will receive any
subsequent message from Bob normally; future iteration could
retry on reconnect.
Federation-invite flow (federation.accept-invite → notify_join) was
already bidirectional; this closes the gap for the peer flow.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
need an archipelago restart
Previously the server checked `fips0` once at startup; if the
interface wasn't up (pre-onboarding, or post-onboarding before the
user clicked Activate FIPS), the peer listener never bound and stayed
unreachable until the next archipelago restart.
Replaced with a `peer_late_bind_loop` background task: polls every
30s for an fd00::/8 address on `fips0` and binds the listener the
moment one appears. First tick fires immediately so the hot path —
fips0 already up at startup — is still zero-cost. Cancellation
cascades through the same `tokio::sync::watch` channel the main
listener uses.
Side effects:
- main.rs no longer computes peer_addr eagerly; dropped the unused
param from serve_with_shutdown.
- FipsTransport::is_available already caches the service probe so
the 30s poll doesn't thrash systemctl.
Covers task #21. Unblocks the first-boot + onboarding flow for
fresh ISO installs on .253.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Pre-v1.4 federation pairs (who exchanged invites before fips_npub
was part of the invite code) had no path to learn each other's FIPS
npub — they'd stay Tor-only forever even after upgrading. Fix:
every state snapshot now carries the sender's own_fips_npub, and
update_node_state refreshes the stored fips_npub on the receiver
side whenever it differs.
- NodeStateSnapshot.own_fips_npub (serde default for back-compat).
- build_local_state takes own_fips_npub alongside the other
single-value fields.
- handle_federation_get_state populates own_fips_npub from
identity::fips_npub, with a fallback to the upstream daemon's
/etc/fips/fips.pub for legacy nodes that never materialised a
seed-derived key.
- storage::update_node_state now writes fips_npub into the
FederatedNode when a new value arrives and trims whitespace
before comparing, so key rotations also flow through.
- Test fixtures (storage + transport/delta + sync) updated for the
new field; existing tests pass.
Net effect: on the next sync, .116 and .228 learn each other's
fips_npub (currently null from the old invite) and subsequent
federation calls route FIPS-first automatically.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Observed on .228: /var/lib/archipelago/peers.json contained an entry
matching the node's own node_key.pub pubkey. It had been added
2026-03-02 and stuck around forever since add_peer() only dedupes by
pubkey — nothing stops a pubkey that happens to be ours.
How it probably got there: somewhere in the auto-add paths
(node-message receive, mesh federation bridge, invite back-and-forth)
a message we'd sent was fed back and the receiver-side add used the
echoed from_pubkey without realising it was us. Doesn't matter which
path — the guard belongs in storage.
add_peer now short-circuits when the candidate pubkey matches
data_dir/identity/node_key.pub. Helper is_own_pubkey best-effort:
unreadable identity → returns false so normal peers aren't blocked.
Also manually purged the one stray entry on .228 (1 removed, 2 real
peers remain). Future deploys include this guard so the phantom can't
come back.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Real 413 root cause on .116 and .228 turned out not to be the body-size
limit — their /etc/nginx/sites-enabled/archipelago was a stale regular
FILE, not a symlink to sites-available, so every nginx update since
someone froze the active config had been invisible to running nginx.
The /api/blob location, added at some point after that freeze, didn't
exist in sites-enabled, so every attachment upload hit nginx's default
1m client_max_body_size and returned 413 regardless of attachment
size.
Deploy now re-creates the symlink on every run: if sites-enabled is a
regular file or missing, we replace it with a symlink to
sites-available. Idempotent if it's already correct.
Also applied the fix live on all 4 fleet nodes — /api/blob now
responds 401 (session-auth required, as designed) instead of 413 on
2MB+ test uploads.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Was seeing "upload failed: 413" on mesh attachment sends between
federated nodes — a ~7MB image becomes ~10MB base64 in the
typed_envelope wire and hit the 10m client_max_body_size on
/archipelago/, /content/, and /dwn/. Bumped those six locations
(two per server block, regular + HTTPS) to 256m so modern
attachments/blobs don't trip the proxy. /rpc/ stays at 1m —
internal JSON-RPC calls are small and don't need the headroom.
Applied to all 4 fleet nodes live; ISO source config updated so
fresh installs get the same limits.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Versioning was drifting on three axes — fixed all of them:
1. Cargo.toml → 1.5.0-alpha (was 1.5.0). User wants `-alpha` suffix
on every pre-stable release; this is the current state of main.
2. neode-ui/package.json was still 1.3.5 — brought in line.
3. /opt/archipelago/build-info.txt was stale on .198 (1.3.4) and
.253 (1.3.5), absent on .116/.228. That file OVERRIDES the
binary's CARGO_PKG_VERSION for the UI sidebar, which is why
.198/.253 kept showing old versions even with fresh binaries.
scripts/deploy-to-target.sh now writes build-info.txt on every
deploy, reading the version straight from Cargo.toml — so the
sidebar can never drift from the binary again.
Release artifacts + manifest:
- releases/v1.5.0-alpha/archipelago (40M, sha in manifest)
- releases/v1.5.0-alpha/archipelago-frontend-1.5.0-alpha.tar.gz (51M)
- releases/manifest.json bumped with full 7-line changelog covering
FIPS-first routing, Settings toggle, transitive federation, cancel
button, transport badges, peer listener, and the build-info fix.
- scripts/check-release-manifest.sh — new pre-publish guard. Refuses
to pass if: Cargo.toml ≠ manifest version, changelog is empty
(release notes are mandatory), or any component's sha256/size
doesn't match the file on disk. Run locally or from CI.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Every federated node card now shows a colored badge indicating how
archipelago actually reached the peer on the most recent successful
call — FIPS / TOR / LAN / MESH — not a prediction based on available
addresses. The badge is hidden when we've never reached the peer.
Backend:
- Cargo.toml: 1.4.0 → 1.5.0 (visible in the sidebar health endpoint).
- FederatedNode gains last_transport + last_transport_at (serde
default for back-compat with v1.4 nodes.json files).
- federation::storage::record_peer_transport(did, onion, transport)
— writes both fields plus last_seen after each successful peer
call. Matches by DID first, falls back to onion.
- federation::sync::sync_with_peer now calls record_peer_transport
immediately after a successful PeerRequest return, so the badge
on the sync'ing peer's card reflects the transport the call
actually rode (fips vs tor).
Frontend:
- types.ts FederatedNode gains last_transport / last_transport_at
(union-typed to the four known kinds).
- NodeList.vue: new transportBadge(node) returns {label, cls, title}
tuned per transport. Hidden when last_transport is absent so we
never lie. Tooltip shows "Last reached via <x> · <time ago>" so
stale data is self-evident. Removed the predictive icon from the
transport store — badge is now 100% ground-truth.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Previously the Pending Peer Requests panel only had Approve/Reject for
inbound rows; outbound rows in the 'sent' state had no action and
would sit there until the target explicitly approved or rejected. Now
you can Cancel an outbound request — the local row is dropped and a
PeerCancel nostr DM is sent so the target's inbound row also
disappears.
Backend:
- HandshakeMessage::PeerCancel {reason: Option<String>} variant.
- nostr_handshake::send_peer_cancel() mirrors send_peer_reject.
- handshake.poll handler dispatches inbound PeerCancel: finds the
matching inbound pending row (same from_nostr_pubkey, state=Pending)
and deletes it. Reply shape gains `cancelled_inbound: [id]`.
- federation::pending::delete() — hard-remove (set_state only
transitions; we don't want 'Cancelled' ghosts in the audit trail).
- federation.cancel-request RPC: outbound+Sent only, default
notify=true (cancelling silently is a footgun), best-effort DM
(relay failure doesn't block local deletion). Wired in dispatcher.
Frontend:
- PendingRequestsPanel.vue: Cancel button appears only on
outbound+sent rows. Emits 'cancel' event with request id.
- Federation.vue: cancelPending(id) handler calls
rpcClient.federationCancelRequest and reloads the list.
- rpcClient.federationCancelRequest(id, reason?, notify=true).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- TransportPrefsCard.vue: import from '@/api/rpc-client' (not
'@/api/rpc') so vue-tsc resolves the module during build.
- scripts/fleet-fips-unpair.sh: companion to the fleet-pair script —
rewrites each node's fips.yaml to anchor-only (fips.v0l.io) so we
can prove the general-case deployment works without the LAN
fast-path. Prints per-node peer counts + DHT AAAA resolution for
every cross-node pair after the change.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
When Alice syncs state with a Trusted peer Bob, she now learns about
Bob's other Trusted peers and auto-adds them as Observers on her side
— so Carol's fips_npub is known locally and subsequent federation
traffic to Carol can route directly over FIPS without a separate
invite round-trip.
- NodeStateSnapshot gains a `federated_peers: Vec<FederationPeerHint>`
field (serde default for backward compat with v1.4 snapshots).
- FederationPeerHint is a minimal projection: did, pubkey, onion,
name, fips_npub — excludes per-receiver fields (trust_level,
added_at, last_seen, last_state).
- build_local_state takes the local federation list and includes only
Trusted peers. Observer/Untrusted peers are NOT re-exported — a
node shouldn't launder other people's federation through its own
authority.
- sync_with_peer merges the received hints via merge_transitive_peers
when the source is Trusted: existing entries get fips_npub
refreshed if missing; unknown DIDs are added at Observer trust
(never auto-promoted to Trusted).
- Bounded to 1 hop: merged Observer entries do NOT get re-exported in
the local node's own snapshots. So Bob → Alice learns Carol, but
Alice's snapshots to Dave do not include Carol.
- Tests: round-trip + filter-non-trusted-from-snapshot coverage.
- Storage + delta test fixtures updated for the new field.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
scripts/fleet-fips-pair.sh writes a deterministic /etc/fips/fips.yaml
on each of our 4 dev fleet nodes (.116/.198/.228/.253), listing the
other three as static FIPS peers over their LAN IPs (UDP 2121 / TCP
8443). Also flips `node.identity.persistent: true` so the npub stays
stable across restarts — without this the daemon rolls a new keypair
on every restart and federation invites that carried the previous
npub go stale.
The script is NOT the general deployment mechanism:
- Every archipelago install already ships fips.v0l.io as an anchor
peer, so any node can DHT-route to any npub that has ever announced
on the public mesh.
- Federation invites (v1.4+) carry the peer's fips_npub, so accepting
an invite is enough for crate::fips::dial::peer_base_url(npub) to
reach the peer through the anchor network.
- This script is a LAN fast-path optimization so intra-fleet traffic
stays on the wire instead of bouncing through fips.v0l.io.
Usage:
scripts/fleet-fips-pair.sh # apply to all nodes
scripts/fleet-fips-pair.sh --verify # print current peer state
Verified: all 4 fleet nodes now report 3 authenticated peers each
(their 3 fleet siblings), plus fips.v0l.io in the identity cache.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
