usePlayer.play() never looked at song.sources[] — a real library track went
straight to (CSP-blocked) Wavlake and reported 'Not found on Wavlake' while
its bytes sat on the operator's disk. Node sources (same-origin /content/<id>,
Range-streamed) now play first; Wavlake is the metadata-only fallback.
FilmDetail likewise only played YouTube sources; own/peer/IndeeHub sources
(same-origin, media-src 'self') now win, YouTube stays the free-films
fallback.
Co-Authored-By: Claude <noreply@anthropic.com>
The archy content latch was global and permanent: once mount-time content
latched archyContentActive, no extracted [[film_ext:…]] recommendation card
could ever render again, and an empty tool result kept the latch — so a
'recommend me films' turn beside an empty catalogue showed prose only, with
'Nothing found' overwriting nothing. The chat had lost its rich previews.
- setArchyContent records which buckets the node actually supplied
(archySupplied) and latches active only on a non-empty delivery
- updatePanelFromText's no-overwrite guard is now per-bucket: node truth
wins buckets it filled; empty buckets stay writable for extracted previews
- the extraction fallback title no longer clobbers 'Nothing found'/'Loading…'
Regression tests: previews render in an empty bucket, node truth survives
tags in a filled bucket, 'Nothing found' survives a both-empty turn.
Co-Authored-By: Claude <noreply@anthropic.com>
Two reasons the content surface 'often doesn't surface the content':
- content.indeehub-projects items carried no mime/filename, so the UI
adapter classified every film 'excluded' and the films grid could never
render. They are films: they now declare video/mp4.
- apps_list surfaced the container-list RPC's BARE ARRAY; the broker reads
{ items: [...] }, so the apps grid was silently dropped every turn.
Wrapped at the tool boundary — the shared RPC's own shape is untouched.
Co-Authored-By: Claude <noreply@anthropic.com>
'recommend me 10 scifi films' answered prose-only and OFFERED to check the
catalogue — the preamble invited knowledge recommendations (paragraph 2) but
only ordered tool calls for existence questions (paragraph 3), so the model
never ran the tool and emitted none of the tags the iframe renders as rich
preview cards.
- discovery of a kind the node could hold (films/music/books…) now gets a
catalogue-and-peers check FIRST, knowledge picks on top
- the 'would you like me to look?' stall is banned outright — looking is
one tool call, do it then answer
- the preamble teaches the exact [[film_ext:Title|Year|Director]] /
tv_ext / song_ext / book_ext / podcast_ext formats, same-line with the
one-line reason, real titles only, never for items the tool returned
Co-Authored-By: Claude <noreply@anthropic.com>
vue-tsc rejected the double cast; vitest strips types so it slipped
through. Narrow once into a local instead.
Co-Authored-By: Claude <noreply@anthropic.com>
- serve_content takes owner_session: a validated operator session skips the
availability/paid gates (Availability::Nobody stays delisted); the cookie
is re-validated in the content handler, same discipline as the model proxy
- the Tor proxy serves already-purchased items from the local content_owned
cache with Range slicing (206) instead of re-hitting the seller's 402 —
the buyer-side store exists so an owned item is never bought twice, and
its cards were rendering as permanent placeholders
- adapter: 'own'-scope items never render locked (a locked card suppresses
the playable URL — the placeholder-only grid the operator reported)
- broker: normalize 'purchased' OwnedRpcItems per item with the seller's
onion, and group 'peers' items per seller onion, so buildMediaUrl gets a
peerOnion and card URLs stop coming out empty
Co-Authored-By: Claude <noreply@anthropic.com>
Reproduced live: 'show me paid for peer files' returned surfaces=1 with 3
purchased images over the bridge, then updatePanelFromText set panelOpen
from the REGEX-inferred tab list — a plain markdown list matches nothing,
so the panel closed and the user saw prose only. panelOpen now follows
orderedTabs (Archy tabs lead). Regression test pins the exact turn.
Co-Authored-By: Claude <noreply@anthropic.com>
S4: /aiui/api/web-search proxied straight to SearXNG with no auth — anyone
reaching the web port ran searches attributed to the node's IP. Now routed
through the daemon's session-gated model proxy like the claude/ollama legs
(both nginx server blocks), forcing format=json upstream (the client never
sent it — search could 200 with HTML that parsed as nothing).
S3: the forwarder also serves the STANDALONE frontend, whose bodies carry
full history/images with no assistant loop behind them — a pasted seed
phrase went to Anthropic unscreened. The forwarder now runs the egress
secret-shape scan (G-B1) with the node's own secrets dir as deny corpus on
Claude bodies and search queries; blocked requests get a plain-language 400.
Also fixes a REAL gap in the egress tokenizer found by these tests: a JSON
key glued to a string value's first word ('content":"abandon...') dropped
that word, so an exactly-12-word seed pasted as a bare message yielded an
11-member run — checksum misses, backstop misses. Non-member words now
rescan within the token. egress 15/15 + model_proxy 10/10 green.
Co-Authored-By: Claude <noreply@anthropic.com>
The browser broker redacted log lines (password=/token=/macaroon key=value,
64+ hex, 64+ base64) while the node-side tool only untrusted-wrapped — so a
log line carrying rpcpassword=<32-hex> crossed to cloud backends below the
egress screen's threshold. Port the broker's three patterns to the tool
boundary as a pure line redactor + JSON walker; unit-tested (124 assistant
tests green).
Co-Authored-By: Claude <noreply@anthropic.com>
ai_grants_unified UNIONED the assistant grants.json with the legacy
settings/ai_permissions.json on every read. On archi-dev-box legacy held
all-ten and grants.json held four, so the Settings UI and the AIUI frame
saw every category ON while the assistant refused six — and no UI toggle
could fix it, because both write paths existed but only ai.permissions.set
synced both files. Now: an existing grants.json answers alone; the legacy
file is consulted only when no grants file exists (pre-unification
upgrade), and that read migrates forward and persists the authority.
assistant.grants-set now also rewrites the legacy file in step. Regression
tests: authority is not widened by legacy; migration folds forward once.
Co-Authored-By: Claude <noreply@anthropic.com>
Per operator decision 2026-08-07 (mock content is isolated to
demo.archipelago-foundation.org, never in shipped code): the auto-seeded
'node-demo' conversation (invented balances, file listings, bitcoin.conf)
no longer ships on nodes — a VITE_DEMO_CONTENT build flag (or dev) gates
it, /seed, and the Guide 'Load Demo' button. The genuine onboarding guide
still seeds everywhere. The fixture's bitcoin.conf rpcpassword is now
unmistakably example-shaped: fake must never look like a real credential.
Co-Authored-By: Claude <noreply@anthropic.com>
The key rode the wholesale settings→localStorage save, sitting at rest
readable by any same-origin script, while the AES-256-GCM key-vault built
for exactly this sat bypassed. Now: the key lives in a memory-only store
ref, persists only into the encrypted vault when a passphrase session is
active (migrating into the vault on unlock), and a one-time migration lifts
any existing plaintext key out of localStorage and re-saves the scrubbed
settings object immediately. Settings UI reports honestly how the key is
held. Typecheck clean; test suite unchanged (348 pass, 3 pre-existing fails).
Co-Authored-By: Claude <noreply@anthropic.com>
The Network permission's Settings label promises 'no IP addresses', and the
browser-side broker honours it — but the node-side tool forwarded
network.diagnostics verbatim, so a granted Network category sent the node's
WAN IP and SSID (both location-identifying) to cloud model backends. Strip
both at the tool boundary; NAT/UPnP/Tor/DNS connectivity shape stays.
Pure helper + unit test (123 assistant tests green).
Co-Authored-By: Claude <noreply@anthropic.com>
Handoff carries the peer-files correction, the podman-lifecycle trap, the
concurrent-agent warning, and the release-binary drift that blocks the ISO.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Carries the full task list with per-item status, the three commits'
rationale, the live measurements that overturned the earlier
peers-have-no-content conclusion, the browser-verification recipe, and
the binary-drift blocker that must clear before the ISO.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Browser-verified on archi-dev-box; all three were only visible by
driving the real UI.
The tab bar. `setArchyContent` put the node's grids up, then
`updatePanelFromText` replaced the bar with tabs inferred from the reply
text. "show me my own shared content" therefore landed on an "AI Brief"
— a prose restatement of the answer already on the left — with the
populated image grid no longer reachable. Guarding the panel arrays was
not enough: they held the right data while the tab bar had discarded the
way to see it. Archy tabs now lead, and the title follows the leading
tab. The prose stays; it just is not the only thing shown.
Tab order follows bucket size. A node with 13 photos and 2 tracks opened
on Songs and titled itself "2 Songs" for a 15-item answer.
Web search never worked embedded. `searchWeb` hardcoded
`/api/web-search` while every other call is built from BASE_URL. Under
`/aiui/` that asked the HOST for a path only the AIUI-scoped nginx
location serves, so it hit the node's API gate for a 403 and the CSP
refused the connection on top. Now BASE-relative. Additionally, the
embedded path skips the client-side search entirely: `streamViaArchy`
sends only the user's text, so the system prompt those results were
folded into is never transmitted — it was a round trip and a console
error per turn whose output provably reached no model. Web search for
the embedded path belongs node-side, with the other tools.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
SearXNG defaults to `formats: [html]`. Its JSON API answers 403 —
and JSON is the only thing AIUI's web search speaks, since
`/aiui/api/web-search` proxies straight through to `/search`. Both
places that seed settings.yml (the first-boot script and the installer)
omitted `search.formats`, so web search has never worked on a node
whose SearXNG was installed, running and healthy. It reads as the
assistant being unable to search rather than as one missing config key.
Verified on archi-dev-box: `format=json` went 403 -> 200, returning 28
results for "bitcoin halving" from Brave and DuckDuckGo. Google and
Startpage self-suspend on a self-hosted instance (access denied /
CAPTCHA), which is expected and costs little given Brave's independent
index.
Existing nodes need the same two lines added to
/var/lib/archipelago/searxng/settings.yml and a restart; this commit
only fixes what new installs get.
Also fixes a build break: `fetchLibraryContent` built a bundle literal
that predates the images bucket.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Four defects, one visible symptom: a correct prose answer beside an
empty grid.
1. The assistant's curated RPC bridge had an arm only for
`content.list-mine`. `tools.rs` mapped the `peers`, `purchased` and
`films` scopes onto three real, dispatcher-registered handlers that
`assistant_dispatch_tool` had never heard of, so every non-"own"
scope died on its catch-all. Downstream that read as "the peers have
no content" — it was a missing match arm, and the tool never ran.
Regression test added: every scope the schema advertises must reach a
real handler.
2. `content.browse-all-peers` wrapped its whole fan-out in one
`timeout(..).unwrap_or_default()`, which DISCARDED every completed
batch the moment the budget expired. One slow peer turned a
partly-successful browse into "0 reached, 16 unreachable". Observed
live on archi-dev-box: back-to-back calls returned real peer items,
then nothing. Now accumulates per batch and checks a deadline between
them, so partial results always survive. Budget 20s -> 45s: two
batches of eight at a 10s per-peer timeout had no headroom at all.
3. `assistant.chat` returned only `{ text }`. The structured results of
any content tool the turn ran were dropped inside the loop, so the
surface had nothing to render. The turn now carries them through
(captured raw, before the untrusted wrap, since they go to a renderer
that treats every field as inert data, never back into the prompt).
4. The adapter classified images as 'excluded' and dropped them. A node
sharing mostly photos rendered as an empty grid while AIUI's image
grid sat unused. Images now have a bucket, with the paid-lock and
extension-fallback handling audio and video already had.
Also: the panel says "Loading…" while a turn is in flight and "Nothing
found" when it comes back empty, instead of leaving the previous
query's heading standing as though it answered this one; the system
prompt tells the model to call the content tool and summarise rather
than re-list what the cards already show; and a refused tool now names
its permission category so the trusted chrome can offer the settings
screen instead of leaving "I don't have a tool for that" as the only
clue.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
"What films are there from my peers" has three causes behind one answer, and
only one is being worked. The tool gap is in flight in a concurrent session
(content_list + SURFACE_TOOLS). Separately and unowned: AIUI declares six
context categories while the broker serves ten, so media/search/ai-local/notes
cannot be requested by AIUI at all — sanitizeMedia sits behind a door AIUI
cannot open, which is likely why the model claimed no capability rather than
reporting an empty library.
And the part neither fixes: measured with a real node-signed Nostr session
through the gate, /api/projects and /api/projects/private both return 0 items.
A correct "0 results" will be indistinguishable from a broken tool, so seed a
project or verify against a peer that has content before calling it done.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Persists the 17-item session task list so it can be rebuilt in a fresh session
(the task tool is session-scoped and would otherwise evaporate), with what
shipped and what each remaining item actually is.
Records the findings that change expectations rather than leaving them to be
rediscovered: the 16 federated peers are not serving content so peers_reached 0
is correct, IndeeHub's catalogue is genuinely empty, two AI permission stores
existed for the same ten categories, and tailscaled owns :443 so nginx must
bind LAN addresses explicitly or it fails EADDRINUSE and silently keeps the old
config.
STATE.md's stopped_at points at it, so /gsd-resume-work lands correctly.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
UNIFIED GRANTS. There were two stores for the same ten categories:
settings/ai_permissions.json (what Settings wrote) and
assistant/grants.json (what actually gates the tool list). Toggling Settings
did nothing for the assistant, so with grants stuck at {"apps","system"} the
model truthfully answered "I don't have a tool for that" no matter what the
operator enabled — the real cause behind "the settings I enable keep
disabling". Their serde forms already matched one-for-one, so this is a
duplicate rather than two concepts. ai.permissions.get/set now read and write
the assistant's grants; the legacy file is still written so a downgrade does
not lose grants, and anything recorded only there is folded in on read.
PEER BROWSE now mirrors Cloud.vue's peer-files fan-out, as the operator asked:
concurrent with a cap and a per-peer timeout, rather than sequential. Cloud
caps at 3 because CHROMIUM's connection pool was starved (02-08) — a browser
constraint the daemon does not share, and measurably wrong here: at 3 a 20s
budget got through 2 batches of 16 peers and reached none. At 8 every peer is
attempted inside the budget.
Measured after deploying: 20.0s, peers_total 16, peers_reached 0. FIPS itself
is healthy (anchor connected, 3 authenticated peers, 4 fips_ok dials) but 14
dials fall back and fail, so the peers are not serving /content. The empty
film list is therefore correct — the transport works and the peers are down.
Reported as partial with counts so the assistant can say so instead of
implying the peers have nothing.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
content.browse-all-peers had a per-peer timeout but no OVERALL budget. On this
node that meant >45s with no answer, which the assistant reported to the
operator as "having trouble accessing the peer content list". Measured cause:
16 federated peers, 1 reachable. Now bounded to 20s total, returning partial
results with peers_reached / peers_total / peers_unreachable / partial, so the
assistant can say "1 of 16 peers answered" instead of implying the rest have
nothing. Verified on the node: 20.015s, was >45s.
NodeCertificateSection had no container — I copied a section that sits INSIDE a
card rather than one that provides its own. Now uses the same
`glass-card px-6 py-6 mb-6` shell and heading level as every other settings
section, so it matches on desktop and mobile.
setup-node-ca.sh now also ensures the nginx HTTPS listener, because a CA is
useless if nothing serves TLS. It binds LAN addresses ONLY: tailscaled already
owns :443 on the tailnet addresses with its own Let's Encrypt cert, so a plain
`listen 443 default_server` binds 0.0.0.0 and fails EADDRINUSE — and nginx then
keeps running the OLD config while the reload reports success. Hit exactly that
on archi-dev-box. Port 80 keeps serving: nodes are reached by IP on LANs where
forcing a redirect would strand anyone who has not installed the CA.
Live now: https://192.168.63.240/ and https://<host>.local/ both 200 with
verify=0 against the node CA, http still 200, tailscaled's 443 untouched.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
"[Vue Error] ReferenceError: Cannot access 'b' before initialization" from
Ye.immediate, taking the whole Mesh view down.
A watcher with `immediate: true` runs DURING setup. This one calls
handleFetchContent, whose body touches consts declared further down the setup
block — so on any session where history already contained an inline
content_ref, it dereferenced a binding that did not exist yet. handleFetchContent
itself is a hoisted `function`, which is why the call site looked innocent.
The initial pass moves to onMounted, which runs after setup completes: every
binding is initialized, and already-loaded history still gets the same
treatment as new messages, which is what `immediate` was there for.
Also adds .planning/todos/pending/2026-08-07-open-task-list.md — one flat list
of everything open, including the app-lifecycle reports (fedimint guardian
installs but does not work, BTCPay wipe not wiping, Bitcoin Knots vanishing,
fedimint gateway dying at 88%), the missing app_install tool behind
"!ai install bitcoin knots", and the LND UI 401s.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Operator asked "what films are there to watch from my peers" and the model
answered, honestly, that it had no tool for it. It was right: content_list
mapped only to content.list-mine — this node's own shared files. Peer
catalogues and IndeeHub were unreachable from the assistant entirely.
content_list now takes scope: own | peers | purchased | films, dispatching to
content.list-mine / content.browse-all-peers / content.owned-list /
content.indeehub-projects. The model picks from a closed enum and never names
a method, so an invented scope falls back to "own" rather than reaching
anything it was not granted (T-13-34).
Two new RPCs behind it:
- content.browse-all-peers aggregates every federated peer in ONE call. The
dashboard fans this out client-side, but asking a model to enumerate peers
and loop is how it ends up claiming it has no tool. Rides FIPS —
PeerRequest::new(fips_npub, onion, "/content") with a 6s FIPS fast-fail then
Tor — so the onion is the peer's identity and FIPS is the transport.
Sequential with a per-peer timeout, not an unbounded fan-out: 02-08 traced a
real UI stall to browse-peer starving the connection pool. One peer being
down is the normal case and contributes nothing rather than failing the call.
- content.indeehub-projects fetches IndeeHub's catalogue, public plus (via a
node-signed NIP-98 login) the operator's private titles. Node-side because
signing that in the browser would put identity material next to the model,
which this phase rules out by name. Tolerant of IndeeHub's field spellings
across versions, and absent/stopped/empty all yield an empty list rather
than failing the caller.
action_key includes the scope, so listing peers cannot be replayed as listing
own files. 15/15 assistant::tools.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Regression from wiring the peers scope: requestArchyAllContent awaited all
three scopes together, so the grid waited on the slowest. `peers` browses every
federated node over FIPS (Tor fallback) and routinely takes tens of seconds or
times out when a peer is offline. On-device that read as
"content(peers) failed: Content request timed out" plus an AIUI that felt very
slow to open — with nothing rendered meanwhile, even though local content was
ready immediately.
Now `own` paints as soon as it lands and `owned`/`peers` fold in as they
arrive. A scope that times out costs only its own results.
Also records the operator's console findings as tasks: the `files` context
timeout, the web-search CSP block (13-09, now firing on every query), the
strfry icon 404, IndeeHub's relay.nostr.band socket, and the ask that `!archy`
over mesh be able to action container commands with text responses.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Operator-reported via a Bitcoin-films transcript: "Banking on Bitcoin" was
captioned with *The Rise and Rise of Bitcoin*'s description, "Cryptopia" with
*The Bitcoin Standard*'s, and the section header "Documentaries:" bled into the
first card of each group. Read as the model talking nonsense; the model's prose
was correct throughout and only the pairing was wrong.
Several patterns anchor with `(?:^|\n)` so they fire only at a line start.
That makes m.index point at the NEWLINE — one character before the line the
match is really on — so extractDescriptionForTag's window, which walks back
from `matchIndex - 1`, landed on the PREVIOUS line. The description became
"previous line + this item's own text".
Normalised inside the helper rather than at each of its nine call sites, so a
pattern that gains a `(?:^|\n)` anchor later cannot silently reintroduce it.
Fault-injected to prove the tests are not vacuous: with the fix removed, two
fail with exactly the reported strings — 'Documentaries: – Early documentary
fo…' and 'The Rise and Rise of Bitcoin – Early …'. 26/26 with it restored.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Operator: "the AI Data Access settings are not persistent through sessions,
often turns them all off."
They were stored in localStorage, which is scoped to an ORIGIN — and a node
answers on several: LAN address, Tailscale address, <host>.local, hostname.
Granting Media over the LAN and returning over Tailscale showed every switch
off again. Not reset: never set *there*. It also made a working content path
look broken, because every scope silently returns nothing without a grant, so
an ungranted permission is indistinguishable from an empty library — that is
exactly what an empty films search turned out to be.
The grant answers "what may the assistant read about THIS NODE", which is a
property of the node, not of one browser at one address. New
settings/ai_permissions.rs (same shape as session_policy: atomic temp+rename,
sanitised on read and write, fails closed on a corrupt file — an unreadable
grant file must never read as "everything allowed"). New ai.permissions.get /
.set, absent from the unauthenticated allowlist so they require a session.
Migration, not replacement: if this browser holds grants and the node holds
none, the local set is pushed UP rather than wiped. Without that, upgrading
would silently revoke the grants of everyone who set them before this change.
The node still wins in every other direction, so a revocation made on one
device takes effect everywhere — otherwise revoking would be impossible from a
second device.
Unknown category ids are stored verbatim rather than validated against a
hardcoded list: a third copy of that list would silently drop a new category on
upgrade. Storing a category grants nothing by itself — the broker checks before
fetching and the node re-checks before answering (T-13-33).
Hydration happens ONCE at broker start, not inside each permission gate: the
gates are hot-path, and awaiting there adds an RPC to every content and context
request. The first attempt did it per-gate and the existing broker tests caught
it by failing on consumed mocks.
Rust 7/7, store 18/18, broker 23/23.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The node signed a real NIP-98 event with its own key and presented it to
IndeeHub through the gate: 200, with a real JWT pair issued. The app's own
bearer token then rides back through the gate — /api/auth/me,
/api/projects/private and /api/projects all 200, matching loopback.
/api/projects/private was the endpoint recorded as unreachable without a
Nostr session, so item 4's private-films path is unblocked.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
secret_shaped_content_never_reaches_the_stub was RED because its fixture was
the first twelve wordlist entries — not a parseable mnemonic. The 2026-08-06
precision rewrite of screen_outbound moved from a word-run shape rule to BIP-39
checksum validation (the shape rule had blocked legitimate turns on a live node
twice); egress.rs's own test was updated to a checksum-valid fixture and this
copy was not, so it asserted behaviour that had been deliberately retired.
The named behaviour was intact throughout: screen_outbound runs on the Routstr
paid leg before any body is sent, a real mnemonic is blocked, and
checksum-invalid runs of 20+ wordlist members are still caught by
IMPLAUSIBLE_MEMBER_RUN. Fixture is now a checksum-valid mnemonic, asserted as
parseable so it cannot silently rot the same way again.
Also records the operator's rendering contract in the surfaces todo: chat gets
the mini version, the content/context surfaces expand it, nothing rich may
overflow the bubble at mobile width.
Nine of ten turns in the exported transcript answered in markdown prose where
the content surface (grids/cards) and context surface should have carried it.
Records each turn against the surface it should drive, plus two security items
found in the same evidence: a cleartext rpcpassword rendered into the chat, and
the RED screen_outbound test that lets a seed-shaped body reach a third-party
inference provider.
Item 1 was not an interception problem and needed no session-aware rule —
the gate was deleting the app's own Authorization header. Item 4's /relay
502 was a root-owned volume, not networking. Both deployed and verified on
archi-dev-box; the extension login itself still needs a human in a browser.
The gate removed `Authorization` unconditionally before proxying, so every
credential an app owns was destroyed one hop before the app saw it.
IndeeHub's Nostr login is the reported case: it signs a NIP-98 event and
sends `Authorization: Nostr <event>` to its own /api/auth/nostr/session.
The header arrived stripped and its backend answered "Authorization header
is missing" — a 401 that no signer could ever satisfy. That is why a NIP-07
browser extension in a tab, the parent frame's NIP-07 bridge
(nostr-provider.js) and AIUI all broke at once while the signing itself was
never at fault. Proven on the node: the same POST returns a real NIP-98
validation error on loopback and the gate's login page through the gate.
The gate accepts exactly one header credential — `Authorization: Bearer
<app-scoped device token>` — so only that one is ours to withhold. authorize()
now reports which credential allowed the request, and the header is dropped
only when it WAS the gate's token, mirroring the surgical cookie strip
directly above it. Any other scheme (Nostr, Basic, an app's own bearer)
rides through untouched.
Credential-less allowlist paths still drop the header: nothing there needs
auth, so an unverified token is not handed to the app.
Tests: an app's Authorization is not classified as the gate's, and a real
proxy hop against a local server shows the app's credential arriving intact
while a gate device token does not.
Everything needed to continue cold: the loop protocol with real deploy and
verify commands, the ordered work list with each item's evidence, Phase 13's
exact remaining state (13-15 only, check 4 passed on-device), and the traps
that cost time tonight — verify on the node not from source, rustls does not
check key/cert pairing, build-aiui.sh hangs after succeeding, AIUI needs
VITE_BASE_PATH=/aiui/.
STATE.md's stopped_at now points at it, so /gsd-resume-work lands correctly.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
IndeeHub worked all year and broke when the gate rolled out. Cause, verified on
the node: GET /manifest.json returns 401 + the gate's login HTML. A browser
fetches <link rel="manifest"> in no-credentials mode unless the tag opts in
with crossorigin="use-credentials", so the session cookie is NEVER offered and
the gate challenges a fully authenticated user. The app's service worker then
serves its cached shell, whose every network call fails — which reads as "the
app is broken" rather than "the gate refused it". Any gated app with a PWA
manifest has the same failure.
Passed through unauthenticated on purpose, and deliberately as small as the
problem: an EXACT-match allowlist of /manifest.json, /site.webmanifest and
/favicon.ico. Static, non-user-specific, and no more revealing than the gate's
own login page, which already shows the app's name and icon.
Exact match, never a prefix — a prefix would let /manifest.json/../api/secrets
ride through. A test pins that: 8 near-miss paths (traversal, query-string
traversal, /api/manifest.json, /manifest.jsonx, case variants, /admin,
/api/auth/nostr/session) must all still be challenged.
19/19 appgate tests pass. This does NOT address the app's own auth endpoints
being intercepted — that needs a session-aware decision and is recorded
separately.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Every item was observed on archi-dev-box or read from source, not inferred:
the content-card parser mispairing titles with the previous description (the
real cause of "idiotic responses" — the model's prose was correct), IndeeHub's
three independent faults (empty public library, Nostr-only private auth, relay
502 on loopback), the fleet-wide gate bug that 401s credential-less PWA
manifest fetches and app-owned auth endpoints, and AI Data Access grants living
in per-origin localStorage when they are a property of the node.
Input for a research + plan pass, explicitly not the plan itself.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
On-device, an empty films search looked like a broken fetch. The console said
only "library: not permitted" — the content scopes returned null without a
word, so an ungranted Media/File permission was indistinguishable from "this
node genuinely has no films". That ambiguity cost real diagnosis time and sent
me looking for a code fault that was not there.
Each scope now names itself when denied. The permission was the whole cause;
no content path was broken.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Reported on-device: searching for films in AIUI returns nothing. Init only ever
asked for scope 'own' (content.list-mine — this node's own shared files), so
IndeeHub and everything else purchased, which lives in 'owned'
(content.owned-list), and other nodes' catalogs in 'peers' were never fetched.
Both scopes existed only as type-signature options with no call site anywhere
in the app.
requestArchyAllContent() now loads all three concurrently and merges once.
Merged rather than three setArchyContent calls because that sink REPLACES
films/podcasts — separate pushes would leave only whichever resolved last, the
same class of bug as the shared sequence guard fixed in aac81503. Deduped by
id, since a title can legitimately appear both owned locally and offered by a
peer. Each scope is caught individually so one dead or slow peer costs only its
own results, which is normal rather than exceptional.
requestArchyContent also stops clobbering songs with an empty array, mirroring
what requestArchyLibrary already did for films/podcasts.
vue-tsc clean, 3/3 useArchy tests pass, and the change is verified present in
the built bundle rather than assumed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Found on archi-dev-box the moment the gate tried to serve TLS: the key was
installed root:root 0600, nginx's master reads it as root, but the archipelago
daemon runs as User=archipelago and got "Permission denied (os error 13)".
Every app port then quietly stayed plain HTTP — the exact fail-open shape the
gate exists to prevent, and it would have looked like "TLS just doesn't work"
with no obvious cause. The warn-level log the tls module deliberately emits for
a present-but-unloadable certificate is what turned this into a ten-second
diagnosis instead of a hunt; it earned its keep on its first real deployment.
Key is now group-owned by the service user at 0640, with a fallback to the
user's primary group and a clear message when no such user exists. Nothing
wider than that.
Verified on the node afterwards, on one gated port (8096):
https 401 verify=0 TLS terminated, chain valid against the node CA
http 401 same port, plain HTTP, unchanged
no CA verify=20 untrusted client correctly rejected
The reissued key was also picked up with NO daemon restart — the mtime reload
path proven in production, not just in a unit test.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Records why 13-15's check 2 cannot pass as written (peers/owned scopes have no
caller) and the merge design settled before stopping, so the next session does
not rediscover that setArchyContent replaces rather than merges.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The AIUI-03 stale-response guard used ONE counter for every content:request,
so requests for different kinds cancelled each other.
useArchy.ts init fires content('all','own') and library('own') back to back.
Both sequence numbers are assigned synchronously, before either awaits, so the
first request always resolved with a stale number and was silently discarded.
Films, podcasts and this node's own files never reached the grid no matter what
the user did — only music ever arrived. Nothing logged, because discarding is
the guard working as written.
The guard is now keyed by kind+scope. Different kinds populate different grids
and cannot stale each other by definition; only a newer request for the same
grid can, which is what the guard was actually for. The existing out-of-order
test (same kind twice) is untouched and still passes.
This is the same shape as the defect 13-11 already fixed once: machinery built
and unit-tested end to end, while nothing real ever reached the UI.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Includes the rustls finding (it does not verify key/certificate pairing) so
the explicit check is not later mistaken for redundant, and the archi-dev-box
caveat: it has no HTTPS dashboard, so it cannot reproduce the iframe failure.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
An app port must answer whatever the browser asks for: an HTTP dashboard
embeds http://host:PORT, an HTTPS one embeds https://host:PORT, and an HTTPS
page cannot embed an HTTP frame at all. So the choice is per-node, not
per-fleet, and a second port number would mean every manifest changes and
torrc doubles.
Instead the gate peeks the first byte. A TLS ClientHello is 0x16; no HTTP
method starts with it. peek() leaves the bytes in the socket buffer, so the
acceptor still sees a complete, untouched ClientHello. TLS and plain share one
generic serve_http(), so authentication, proxying and upgrade handling cannot
drift apart by scheme.
EXISTING NODES ARE UNAFFECTED BY CONSTRUCTION. Anything that is not a TLS
handshake takes the identical path as before, and a node with no certificate
serves plain HTTP exactly as today — TLS is strictly additive.
rustls does NOT verify that a private key matches its certificate. Established
by test, not assumed: with_single_cert accepted a pair from two different keys
and would only have failed mid-handshake in a user's browser — a security
control that reports success and does nothing, the exact shape this module's
own docs warn about. So the pairing is now proven explicitly (sign a fixed
message with the key, verify against the certificate's public key) and a
mismatch refuses to serve.
Also: cert and key mtimes are stamped as a PAIR, because reissuing writes them
separately and keying on one would serve a certificate that no longer matches
its key; a 15s first-byte timeout closes the slowloris window one step earlier
than the existing header-read timeout; PKCS#8 and PKCS#1 keys are both
accepted so a hand-made key does not silently downgrade a working node.
Deps pinned to the rustls 0.21 line reqwest already resolves — no new vendor,
no second rustls major. Test fixtures are throwaway (localhost SANs only), not
any node's identity.
38/38 appgate tests pass.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
