Decide: opening a space link connects to, and authenticates with, whatever relay that link names

[usekaneo]

From the CON-43 security audit (2026-09-14). Severity medium. This is a decision, not a bug report — the behaviour follows from how NIP-29 addresses work and is shared with every Nostr client that uses relay-hinted addressing. What is missing is that we ever decided it, and that the docs say it.

What happens today

A space address is <relay-host>'<group-id> and lives in the URL: /s/<host>'<group>. The chain is short and fully automatic:

1. src/ui/layout/AppShell.tsx:37-39 — parseGroupAddress(params.group) turns the route parameter into relayUrl, with no allowlist and no prompt.
2. useRelay(relayUrl) → client.want(relayUrl) opens the WebSocket.
3. src/nostr/relay-status.ts:19 additionally fetches https://<host> for the NIP-11 document.
4. src/nostr/client.ts:172 — this.pool.automaticallyAuth = (url) => this.signAuth(url). If the visitor is signed in, the NIP-42 AUTH event is signed and sent without any interaction.

So following a link is enough to make a signed-in user's browser contact a host of the link author's choosing and hand it a signed statement of who they are. The signature is scoped to that relay per NIP-42 and is not replayable elsewhere, but the pubkey, the IP and the timing are disclosed, and the visitor never chose to trust that relay.

Why this needs a decision rather than a fix

The relay is part of the group's identity in NIP-29 — a space address without a relay host is not an address. Refusing unknown relays outright would mean the app can only ever open spaces on relays already known to it, which breaks the one thing a shareable space link is for. So the plausible answers are not "fix it" but a choice:

• Accept and document. Treat it like the image decision (docs/09-security-privacy.md → "Images are loaded directly"): a stated, deliberate trade. Cheapest, and defensible — but only once it is actually written down.
• Ask on first contact. An unknown relay host prompts once ("This space lives on relay.example. Connect?") and is remembered per host. Costs one interaction on a genuinely new space, and removes the drive-by entirely.
• Connect but do not authenticate. Open the socket to an unknown relay, but withhold AUTH until the user has confirmed the host. Reading a private group then fails until they confirm, which is most of the value — but it does keep the pubkey back, which is the part that identifies a person.

The closed-teams model (reading always needs sign-in and an invitation) argues that visitors will be signed in essentially always, so the disclosure is the normal case, not an edge case.

Scope

• Pick one of the three and record why in docs/09-security-privacy.md.
• Implement it, unless the decision is "accept", in which case the docs change is the whole change.
• Either way, extend the privacy section of docs/09-security-privacy.md: it currently discusses only images, so a reader can reasonably assume relay connections are more guarded than they are. The audit found no place where code and that document contradict each other — this is the one omission.
• If the decision introduces a known-hosts list, note the interaction with the CSP ticket: a narrow connect-src and arbitrary relay hosts pull in opposite directions, and an allowlist is what would let both exist.

Out of scope

The startsWith prefix bug in the same function is its own ticket and should land regardless of what is decided here.

Acceptance

• The decision and its reasoning are in docs/09-security-privacy.md.
• If code changed: the dev setup (localhost:8080) still opens without friction, and tests cover the new path.
• npm run typecheck && npm run lint && npm test && npm run build pass.

Affected: docs/09-security-privacy.md, possibly src/nostr/client.ts, src/ui/layout/AppShell.tsx, src/nostr/group-address.ts

Source: CON-43, finding A4.

---

_{Task: lisl309duhciphb3mt2rq515}

[usekaneo]

CON-46

[usekaneo]

**** commented:

Technical refinement — the relay-trust decision

1. The chain, verified

1. src/ui/layout/AppShell.tsx:37-39 and src/routes/space-route.ts:24-26 — the route parameter becomes relayUrl, with no allowlist and no prompt.
2. useRelay(relayUrl) (src/nostr/relay-status.ts:42-60) does two things to the host the link named: client.want(relayUrl) (:48) opens the WebSocket, and fetchRelayInfo (:17-39, invoked at :53) fetches https://<host> with Accept: application/nostr+json.
3. src/nostr/client.ts:172 — this.pool.automaticallyAuth = (url) => this.signAuth(url), so a signed-in visitor answers the AUTH challenge without any interaction.

One detail the ticket understates: AUTH is not only triggered through automaticallyAuth. signAuth(url) is also passed explicitly as onauth to every read and publish (client.ts:486, 515, 556, 576, 597) and called by refreshAuth (:430). Any "withhold AUTH" implementation that touches only automaticallyAuth leaves every read signing anyway — the gate has to live inside signAuth.

2. Two corrections to the option analysis

(a) "Connect but do not authenticate" is weaker than it sounds. The NIP-11 fetch in point 1 above already discloses the visitor's IP, the timing and which space to the host, before any AUTH. Withholding only AUTH still leaves the socket and that fetch. If option 3 is chosen, the decision record must state that this leak remains — or the NIP-11 fetch has to be gated too, at which point option 3 has converged on option 2 with more moving parts.

(b) A known-hosts list cannot make connect-src narrow. connect-src is baked at build time; relay hosts are discovered at runtime from links. Unless the deployment has exactly one relay host, the CSP relay sources stay scheme-scoped (wss:/https:) no matter what the trust gate remembers. The scope bullet "an allowlist is what would let both exist" should be corrected — it is not achievable with a static bundle. This is also noted in CON-44.

3. Recommendation: ask once per new host (option 2)

For a closed-teams deployment the visitor is signed in essentially always, so the question is not whether to disclose the pubkey but whether the link author gets to choose the recipient. One prompt per genuinely new host, remembered afterwards:

• keeps a shareable <host>'<group> link working — the property that rules out "refuse unknown relays";
• puts the decision where the user already is (they just followed a link);
• keeps the pubkey, the IP and the timing back from a host the user did not choose;
• is strictly better than option 3: it withholds everything option 3 withholds, plus the NIP-11 fetch, with less state.

Make loopback and the DEFAULT_RELAY_URL host trusted by construction, so the dev workflow (./scripts/dev-relay-up.sh, .env currently ws://localhost:8081) never prompts. Reuse CON-45's exported local-host predicate instead of writing a second one.

4. Implementation sketch (if option 2 is chosen)

src/nostr/known-relays.ts (new)

• isTrustedRelay(host), trustRelay(host), forgetRelay(host), backed by localStorage under e.g. nc-trusted-relays, read in one defensive try/catch the way readCollapsed() in AppShell.tsx:22-28 and the theme bootstrap do (private mode / corrupt JSON must not break the app).
• Loopback (CON-45 helper) and the host of DEFAULT_RELAY_URL are trusted without storage.
• Key by bare host (the exact GroupAddress.host string, e.g. relay.example:443), not by relayUrl — the scheme must not become part of the trust key.

A gate in AppShell

• Shell currently owns the useRelay/useSpace hooks (AppShell.tsx:38-40). Move the relay-consuming part into a child and let Shell render either that child or the prompt. This is required by the rules of hooks: an untrusted host must not call useRelay/useSpace even once, because useRelay opens the socket and fires the NIP-11 fetch from effects.
• The prompt names the host literally ("This space lives on relay.example. Connect?"), with "Remember this relay" on by default, and a way back.
• Cheap add-on, can be deferred: a "Trusted relays" list in space settings (forget).

Not here: profile relays from VITE_PROFILE_RELAYS and DEFAULT_RELAY_URL are operator configuration, not link input. State that boundary in the docs so it is explicit; do not put them behind the prompt.

5. Docs — docs/09-security-privacy.md

• add a subsection "Relay connections follow links" with the chain above, the three options, the chosen one and the reasoning;
• add a row to the "Client-side attack surface" table (the document today discusses images in prose and says nothing about outbound relay connections);
• state the residual risk and the interaction with CON-44's connect-src, per correction (b);
• if option 1 ("accept and document") wins instead, the docs change is the ticket — but the reasoning and the table row still have to be written.

6. Tests

• known-relays.test.ts (jsdom): trust/forget round-trip; corrupt/absent storage leaves the decider usable; double-trust is idempotent (StrictMode runs effects twice); loopback is trusted without storage.
• A component test in the style of src/nostr/relay-status.test.tsx (dynamic import to reset module state, jsdom): mounting the shell for an unknown host renders the prompt and calls neither fetch nor client.want; after confirming, the relay store is told to connect.
• Acceptance: the dev setup still opens without friction (loopback/default host trusted); the four commands pass.

7. Out of scope

CON-45 (the startsWith downgrade) lands independently; it does not substitute for this decision.

[usekaneo]

**** commented:

Implemented — branch con-46-relay-trust-prompt, worktree .worktrees/con-46 (uncommitted)

Decision taken: option 2, ask once per new host.

Base: this branch sits on con-45-group-address-host, so it contains CON-45's commit 8ed3501. It imports isLocalRelayHost from there rather than keeping a second copy of the loopback rule. Merge order therefore matters: CON-45 first.

New

• src/nostr/known-relays.ts — isTrustedRelay / trustRelay / forgetRelay over localStorage key nc-trusted-relays, one defensive try/catch per read and write. Keyed by the bare lowercased host, never by a relay URL, so the scheme cannot become part of the trust key. Loopback delegates to isLocalRelayHost; the host of DEFAULT_RELAY_URL is trusted without storage.
• src/ui/SpaceGate.tsx — RelayTrustPrompt and InvalidSpaceLink.
• src/nostr/known-relays.test.ts (7) and src/ui/layout/AppShell.trust.test.tsx (6).

The gate

AppShell is now three components. Shell reads the route and decides, calling no relay hook at all. SpaceShell holds every relay-consuming hook — useRelay, useSpace, <Outlet> — and either mounts or does not. ShellFrame is the presentational chrome. That split is forced, not stylistic: both disclosures happen in effects inside useRelay, so "do not connect" has to mean the hook is never called, and a hook cannot be called conditionally.

A Gate union keeps the two reasons apart — {kind:'unreadable', address} and {kind:'untrusted', group} — because they are different things to tell a reader. Per-visit clearance lives in a ReadonlySet<string> of hosts, so "Remember" left unchecked still connects, and following a link on to a different host asks again instead of inheriting the previous answer.

The prompt names the host in monospace (it is there to be judged), says plainly what connecting discloses — IP, timing, and a signed NIP-42 event naming the npub — offers "Remember this relay" checked by default with "Kept in this browser only", and a way back.

Verified independently

typecheck clean · lint clean · npm test 47 files, 485 passed · build clean.

The negative assertion was mutation-tested, because a test that cannot fail proves nothing. With the gate forced off (if (false)) and nothing else changed, 5 of the 6 tests fail — including both expect(want).not.toHaveBeenCalled() and expect(fetch).not.toHaveBeenCalled(). The file was restored byte-identically and the suite is 6/6 again. So the guard is real: it is not passing because the markup happens to match.

Judged differently from the brief, with reasons

1. The inline Invalid group address. guards stay in the eight route views. Unreachable now for /s/*, but they still narrow group/base for TypeScript, and /settings/spaces/:group can still be reached with an unparsable address.
2. The gate covers /s/:group only, not /settings/spaces/:group. That route is inSettings, calls no useRelay, and makes neither disclosure — an interstitial there would buy no privacy and sit in front of the settings nav. Its DEFAULT_RELAY_URL fallback in space-route.ts was removed (now ''); no caller destructures relayUrl from useSpaceRoute.
3. RelaySnapshot | null on Topbar/Sidebar, and space-store exports EMPTY_SPACE. The gate screen draws the real chrome, and a relay indicator there could only assert a connection that does not exist, so the slot stays empty.
4. "It does not narrow the CSP" got its own doc heading rather than a passing remark — it is an instruction not to retry something.

Note for whoever merges

docs/09-security-privacy.md is edited on this branch and on con-44-content-security-policy. A conflict there is expected; both sections are additive.

[usekaneo]

**** commented:

Reviewed in worktree .worktrees/con-46 (con-46-relay-trust-prompt (uncommitted, on top of CON-45)). Verification run for this review on that worktree: npm run typecheck, npm run lint, npm test, npm run build — all four pass.

Review — CON-46: opening a space link connects to, and authenticates with, whatever relay the link names

Verdict: ⚠️ Approve with nits

Summary

The change answers the ticket with option 2 — an unfamiliar relay host is named once, on a dedicated screen, before anything is sent — and turns that into a structural rule in AppShell: the relay-consuming half of the shell (useRelay, useSpace, <Outlet>) is a child component that only mounts after the address has been read and either parsed or cleared, so "no prompt" is the same thing as "no client.want, no NIP-11 fetch, no NIP-42". A new src/nostr/known-relays.ts keeps per-host decisions in localStorage, with loopback (reusing CON-45's isLocalRelayHost) and the configured DEFAULT_RELAY_URL host trusted by construction. docs/09-security-privacy.md gets the decision, its alternatives, the mechanism and an unusually honest residual-risk section. I found no blocker and no major defect; the findings below are small, and the most substantive one is a docs-completeness gap in the "what was considered" list.

Acceptance criteria

Criterion	Status	Evidence
Decision and reasoning recorded in docs/09-security-privacy.md	✅	The three-way choice is at docs/09-security-privacy.md:88-99; option 2 is marked Chosen and the rejections are argued in place.
Consider the ticket's three options	⚠️ partial	Options 1 and 2 are covered, but the ticket's third option ("connect but do not authenticate") was replaced by a build-time allowlist. See Finding 1.
Extend the privacy section beyond images	✅	New section docs/09-security-privacy.md:68-164, plus the summary row at docs/09-security-privacy.md:44.
Note the CSP interaction if a known-hosts list is introduced	✅	docs/09-security-privacy.md:154-164. It is the only place in docs/ that discusses connect-src, and the branch it cites (con-44-content-security-policy) exists.
Implement the decision	✅	src/nostr/known-relays.ts, gate at src/ui/layout/AppShell.tsx:55-111, screens at src/ui/SpaceGate.tsx.
Dev setup (localhost:8080) opens without friction	✅	src/nostr/known-relays.ts:89-92 (isLocalRelayHost), exercised at src/ui/layout/AppShell.trust.test.tsx:180-186.
Tests cover the new path	✅	src/nostr/known-relays.test.ts (decider + storage failure modes) and src/ui/layout/AppShell.trust.test.tsx (negative: no want / no fetch before consent). Gaps in Findings 4-5.
npm run typecheck && lint && test && build	not run	Deliberately skipped per the review brief; the parallel CI job owns it.
Out-of-scope startsWith prefix bug untouched	✅	src/nostr/group-address.ts is not in the delta; nothing in the diff re-derives localness.

src/nostr/client.ts was listed as "possibly" affected but is correctly unchanged: the AUTH hook (client.ts:172) only fires on a socket that the gate now prevents useRelay from ever opening. That is the right seam.

Findings

No blocker and no major findings. The gate logic, the storage module and the nullable-prop plumbing are correct as written; the items below are minor or nit. Findings 1-3 are cheap and in the ticket's own scope, so I would fix them before merge even though none of them is a correctness defect.

1. minor — "What was considered" omits the ticket's third option

docs/09-security-privacy.md:88-99 lists three alternatives: leave it, ask once, and a build-time allowlist. The ticket offered a different third: "Connect but do not authenticate." That option is the closest competitor to the chosen one — it is the only alternative that keeps the pubkey back while still reading public content — and the reasoning section never evaluates it. The nearest text is a residual-risk statement (docs/09-security-privacy.md:145-147: "Once approved, the host is approved for everything... NIP-42 follows from it automatically"), which observes the behaviour rather than rejecting the option.

Why it matters: the ticket's stated deliverable is "record why", and a reviewer of the decision cannot tell whether the author considered connect-without-AUTH and rejected it, or never saw it.

Suggested fix: add a fourth bullet that addresses it directly — for example, that withholding AUTH does not avoid a prompt (the reader still has to confirm before a private group resolves), so it buys the pubkey back only at the cost of a second, worse state on the same screen. Keep the public relays out of scope for this bullet; the ticket's option 3 is specifically about withholding AUTH.

2. minor — forgetRelay has no caller, so a remembered host cannot be revoked in-app

src/nostr/known-relays.ts:117-120 exports forgetRelay, documented at lines 110-116 as "Take a remembered decision back, so the host is asked about again." The only callers in the tree are the unit tests (src/nostr/known-relays.test.ts:34,51); no UI path invokes it, and no settings screen lists trusted relays. The prompt's "Remember this relay" box is checked by default (src/ui/SpaceGate.tsx:71), so one stray click creates a per-browser trust decision with no in-app way to reverse it. The docs mention clearing site data only as the reason a prompt recurs (docs/09-security-privacy.md:142-144), never as the only revocation path.

Suggested fix: either wire forgetRelay into a small "Trusted relays" list under /settings/profile (the natural home, since it already owns per-browser state), or drop the export until that UI exists and add one line to the residual risk saying revocation means clearing site data.

3. minor — the session-only trust path is undocumented

Documentation says the decision is "keyed by the bare host ... in localStorage" (docs/09-security-privacy.md:103-106) and that an answer "is remembered per host" (docs/09-security-privacy.md:44). That is only the default. src/ui/layout/AppShell.tsx:72,96-102 keeps a second, in-memory allowedOnce set, and src/ui/SpaceGate.tsx:96-107 exposes it as the "Remember this relay" checkbox: unchecked, the shell connects and forgets at reload. None of that appears in the doc, so a reader can finish the section believing every approval is durable.

Suggested fix: one sentence in "How it works" (or a bullet in the residual-risk list) stating that remembering is on by default, that unchecking it trusts the host for the session only, and that the in-memory set is per host so a second unfamiliar relay in the same session still prompts (src/ui/layout/AppShell.tsx:68-72).

4. minor — the port test never remembers anything, so it tests nothing about ports

src/ui/layout/AppShell.trust.test.tsx:172-176:

it('asks again for a host already remembered under a different port', async () => {
  await render(urlFor("relay.example:8443'team"))
  expect(text()).toContain('Connect to relay.example:8443?')
  expect(want).not.toHaveBeenCalled()
})

No host is trusted before the render, so this is the same assertion as the first test with a different string; it cannot fail if port-keying regresses. The unit test at src/nostr/known-relays.test.ts:37-41 does cover the real property.

Suggested fix: call trustRelay('relay.example') (or connect on relay.example first and click Connect) before rendering the :8443 link, then assert the prompt is shown and isTrustedRelay('relay.example:8443') is false.

5. minor — the /settings/* exemption is untested, and its safety rests on an invariant outside this change

src/ui/layout/AppShell.tsx:65-66,76-77 deliberately skips the gate for /settings/*, because /settings/spaces/:group reuses the group param name. A hand-crafted /settings/spaces/evil.example'group therefore reaches useSpaceRoute with an unapproved host and never sees the prompt. Today that is safe, but only because SpaceStore.start() bails on a connection nobody wanted:

// src/nostr/space-store.ts:205
if (!connection.ready) return

Nothing in AppShell.trust.test.tsx mounts a settings route, so a future change that makes useSpace subscribe without want() — or that wires a relay through useSpaceRoute for settings — would silently connect to the link's host with no prompt and no failing test. The docs likewise never say the gate is /s/-only (docs/09-security-privacy.md:108-112 reads as though it covers relay connections generally).

Suggested fix: add one test that renders /settings/spaces/<untrusted>'group with the existing client.want/fetch spies and asserts neither is called, plus a comment recording why it is safe (the ready guard). A sentence in the docs noting the exemption would close the same gap for readers.

6. nit — isTrustedRelay runs a localStorage read inside render

src/ui/layout/AppShell.tsx:80 calls isTrustedRelay(group.host) during render; that reaches readTrusted() (src/nostr/known-relays.ts:56-64), which does JSON.parse on every shell render. It is not incorrect — the only mutators here are followed by a state update (AppShell.tsx:98-102) — but it is an impure render read and unnecessary work on every navigation. A useSyncExternalStore over known-relays, or a memo keyed on the host, would be cleaner. Nice-to-have only.

Tests

The tests are meaningful rather than decorative. The negative assertion at src/ui/layout/AppShell.trust.test.tsx:124-133 is the one that matters: it spies on client.want and stubs fetch and asserts neither is touched for an unapproved host. I verified that useRelay is the only caller of client.want (src/nostr/relay-status.ts:48) and the only place the NIP-11 document is fetched (src/nostr/relay-status.ts:19,53), so the assertion really does measure the disclosure and not just the markup. It would fail against the pre-CON-46 shell, which mounts useRelay unconditionally; the unreadable test at lines 188-197 would fail there too, because the old code fell back to DEFAULT_RELAY_URL.

src/nostr/known-relays.test.ts covers the failure modes that matter for a security decider: corrupt storage, wrong shape, non-string entries, and localStorage throwing outright — all fail closed — plus idempotency and the loopback/operator-host shortcuts. The env-stub test (lines 100-113) is a fair check of DEFAULT_RELAY_HOST, since it would fail if VITE_RELAY_URL were ignored.

Gaps, in priority order: the tautological port test (Finding 4), the untested settings exemption (Finding 5), and no test that a remembered host does not re-prompt on a second render/remount (the docs' central promise). The allowedOnce re-prompt behaviour is asserted only by code comment.

Docs

The new section is the right shape for this ticket: a decision record, not a changelog. It states the trade, names the mechanism and its module, separates "unreadable" from "untrusted", explains why loopback and DEFAULT_RELAY_URL stay outside the gate, and keeps a residual-risk list that a security reviewer can actually use. The CSP subsection correctly refuses the ticket's premise: a runtime per-browser list cannot narrow a build-time connect-src, and saying so explicitly is more useful than repeating the assumption. Confirming that CON-44 is the CSP branch, the citation is accurate. The mechanism claims in the doc match the code I read: the empty-group guard is src/nostr/space-store.ts:192-195, and the keying/normalisation described at docs/09-security-privacy.md:103-106 matches src/nostr/known-relays.ts:15-32,56-94.

The gaps are Findings 1 and 3: the considered-options list drops one of the ticket's three options, and the "Remember this relay" session-only path is not described. Also worth noting (not a defect): the old inline "Invalid group address." branch in src/routes/SpaceOverview.tsx:39 and its siblings is now unreachable for /s/* routes, because the gate renders InvalidSpaceLink first. It is harmless defensive code; removing it is optional and arguably out of scope.

What is good

• The gate is structural, and the reason is written down. Keeping useRelay/useSpace/<Outlet> in a child component (src/ui/layout/AppShell.tsx:38-42,113-139) is the only correct way to withhold an effect-based disclosure; a conditional inside one component would have looked the same and leaked. The comment says exactly that.
• known-relays.ts is a careful security decider. It keys by the canonical bare host, lowercases defensively at the boundary rather than trusting callers (known-relays.ts:24-32), fails closed when storage is unreadable or hand-edited, keeps implicitly-trusted hosts out of storage (known-relays.ts:99-107), and reuses CON-45's isLocalRelayHost instead of copying the localness rule — the exact mistake CON-45 was.
• The prompt shows the host that will actually be connected to. Because normalizeHost canonicalises through URL and rejects non-ASCII hosts (src/nostr/group-address.ts:62-71), the monospace host on the screen cannot be a punycode/bidi rendering of a different name. The screen is security-relevant UI and it is built to be read.
• The unreadable-address change is a real improvement, not scope creep. An address that names no relay no longer opens a socket to the operator's relay "in order to draw an error" (src/routes/space-route.ts:25-33, src/ui/SpaceGate.tsx:14-23), and the behaviour change is documented.
• The docs are honest about what the prompt does not buy — click-through, per-browser scope, host-wide consent, and the fact that the relay still reads plaintext. That is the part of a security decision that is usually missing.

---

Reviewed against the ticket's scope only. CON-45's group-address.ts was not re-reviewed; client.ts is not in the delta. The npm typecheck/lint/test/build gate was not executed here (a separate CI verification job owns it), so this review does not attest to those results.

[usekaneo]

**** commented:

Response to the review — all six findings, branch con-46-relay-trust-prompt (still uncommitted in .worktrees/con-46)

Verdict taken as given (approve with nits). Findings 1, 3, 4 and 5 are addressed in the branch; finding 2 is half-addressed with the other half deferred as an open question; finding 6 is deliberately not taken, with the measurement below. Nothing in the review turned out to be factually wrong — every claim I re-checked against the code held.

1. minor — "What was considered" omitted the ticket's third option — fixed

The list in docs/09-security-privacy.md is now four options, not three. The new entry is "Connect, but withhold AUTH", marked rejected, with the three reasons that compound:

• it withholds the npub but not the IP, the timing, or which space — the NIP-11 fetch to https://<host> has already disclosed all of that before the first frame;
• it does not save the prompt either, because a private group serves an unauthenticated reader zero events and no error (docs/04-permissions-nip29.md, the "Stranger, no AUTH" rows), so the reader is still asked — now in front of a space that is empty for reasons nothing on screen explains;
• it is the wider change: signAuth is not only pool.automaticallyAuth, it is passed as onauth to every read and publish and called by refreshAuth, so a gate touching only the automatic hook leaves every read signing anyway.

I re-verified that last point rather than copying it from the refinement comment: src/nostr/client.ts:172 is the automaticallyAuth assignment, and 430, 486, 515, 556, 576, 597 are exactly the signAuth call sites. The citation is accurate.

2. minor — forgetRelay has no caller — documented, not wired; the UI half is an open question

The review offered two ways out. The branch takes the second one's documentation half and keeps the export:

• docs/09-security-privacy.md gains a residual-risk bullet stating plainly that there is no in-app way to take an approval back, that undoing a "Remember this relay" clicked in haste today means clearing the site's data (which drops every other decision with it), and that a "Trusted relays" list under /settings/profile is the obvious home and is deliberately not in CON-46.
• src/nostr/known-relays.ts:110-121 says the same thing at the export itself, so the next reader of the module does not have to find the doc to learn that the function is unreached on purpose.

The export is kept rather than dropped, for a reason worth stating: forgetRelay is what makes the trust/forget round-trip testable (src/nostr/known-relays.test.ts:34,51), and removing it would leave trustRelay with no inverse in a module whose whole job is holding a revocable decision.

Open, not decided here: whether the "Trusted relays" list belongs under /settings/profile and in which ticket. That is a product call about a new settings surface, so it is flagged rather than answered.

3. minor — the session-only trust path was undocumented — fixed

"How it works" now carries a paragraph headed "Remembering is the default, not the only answer": the checkbox is checked when the prompt opens, unchecking it still connects, the decision then lives only in allowedOnce in AppShell and is gone on reload — and that set is keyed by host, so following a link on from an approved relay to a second unfamiliar one asks again rather than inheriting the first answer. The last clause was previously asserted only by a code comment.

4. minor — the port test tested nothing about ports — fixed

src/ui/layout/AppShell.trust.test.tsx:202-214 now calls trustRelay('relay.example') before rendering the :8443 link, with a comment saying why the line is load-bearing. It now fails if port-keying regresses; previously it was the first test with a different string.

5. minor — the /settings/* exemption was untested — fixed, both halves

• Test: a new case, lets /settings/spaces/:group through ungated — and it still reaches nothing (AppShell.trust.test.tsx:239-264). It mounts a probe standing in for SpaceSettingsRoute at that path, reading the same group param through the same useSpaceRoute, and asserts that nothing at all reached the host the link named. The assertion is host-filtered rather than absolute, because the shell legitimately holds the deployment's own relay on every settings page. The comment records why the exemption is safe — the if (!connection.ready) return in SpaceStore.start() — so the invariant, not just today's markup, is what a future change has to break.
• Widened spy surface: the file now also stubs WebSocket and collects want + WebSocket + fetch into one contacted() list. Watching client.want alone would have missed a regression that reaches the pool by some other route, which is precisely the failure mode this exemption depends on not happening.
• Docs: a paragraph headed "The gate stands in front of /s/:group, not /settings/spaces/:group" states the exemption and its justification, so the section no longer reads as though it covers relay connections generally.

Also closed, from the review's "Gaps" paragraph rather than a numbered finding: a remembered host does not re-prompt on a fresh mount (AppShell.trust.test.tsx:218-229) — the promise the whole feature makes, previously untested, and deliberately exercised through stored state rather than through the in-memory allowedOnce set.

6. nit — isTrustedRelay reads localStorage during render — not taken, with a measurement

The observation is correct: src/ui/layout/AppShell.tsx calls isTrustedRelay(group.host) in render, which reaches readTrusted() and JSON.parse. I measured the two halves of the cost before deciding, and neither fix is clearly right:

• "unnecessary work on every navigation" is the exact frequency, and that is all it is. AppShell holds no hooks, so <Shell /> is re-created only when the router re-renders AppShell. TocProvider receives Shell as its children prop, so its own state changes (every keystroke that a page registers as TOC source) re-render the provider but bail out on Shell — same element object. So the read is one getItem plus a JSON.parse of a tiny array per navigation, not per keystroke.
• useMemo would not fix the impurity, only cache it — React is explicit that a memo may be discarded and recomputed — and given the frequency above it would cache a value that is already recomputed only when its inputs change. It would buy nothing and add a second staleness surface.
• useSyncExternalStore would fix it properly, but requires known-relays.ts to grow listeners and a subscribe function for a value that changes at most once per prompt, and whose only in-session mutation is already mirrored into React state: trustRelay(host) is always paired with setAllowedOnce(...), which is what actually drives the re-render. Adding a subscription store to the module that is the security decider, to solve a problem that cannot currently produce a wrong render, is a poor trade.

The one real consequence of the impure read is cross-tab: a host trusted in tab A still shows the prompt in tab B until it navigates. That fails closed — an extra prompt, never a missing one — which is the safe direction.

Happy to be overruled; if the useSyncExternalStore version is wanted it is a small, self-contained change.

Verification — run in this worktree, in order

Command	Result
npm run typecheck	clean
npm run lint	clean
npm test	47 files, 487 passed
npm run build	clean, 4.38s

487 rather than the 485 in the previous comment: the two tests added for findings 4-5 and the gaps paragraph (the trust file went 6 → 8). The suite was green on the run; I did not hit the known load-sensitive timeouts in editor-enter / editor-slash-menu / markdown-live.

The negative property, re-mutation-tested

The guard was re-checked after the changes, because the file it protects has been edited since the last time anyone measured it. With the gate forced off — if (gate !== null) → if (false) in AppShell.tsx, nothing else touched — 5 of the 8 tests fail, including both expect(want).not.toHaveBeenCalled() and expect(fetch).not.toHaveBeenCalled(). The file was then restored and verified byte-identical by SHA-256 (4b43fea3…), and the file is 8/8 green again.

The count reads worse than the previous comment's "5 of 6" and is not a weakening — the three survivors are the three tests that assert the no-prompt path, and forcing the gate off is exactly the condition under which no prompt appears:

• opens a remembered host straight away and does not prompt for the local dev relay assert that a trusted host connects with no interstitial. The mutation makes every host behave that way, so they cannot detect it. Their job is the opposite regression — a gate that prompts when it should not.
• lets /settings/spaces/:group through ungated is gate-independent by construction: that route is inSettings, so the gate never evaluated it either way.

Every test that asserts the gate does fire, and every test that asserts nothing is contacted before consent, fails under the mutation. The load-bearing property still has teeth.

Note for whoever merges, unchanged

docs/09-security-privacy.md is edited on this branch and on con-44-content-security-policy; a conflict there is expected and both sections are additive. CON-45 merges first — this branch sits on its commit 8ed3501 and imports isLocalRelayHost from it.

[usekaneo]

**** commented:

UI test pass — 2026-09-15, PR #91, a38adc5

Tested through the running app (npm run dev, :5273), in a fresh tab with cleared storage so the console and network buffers carried nothing from earlier runs. All cases pass. Merge-ready from the UI side.

Nothing is sent before consent

Cleared site data, opened /s/relay.example'engineering:

• Screen: "Connect to relay.example?"
• Console: only Vite and React DevTools lines — no WebSocket attempt to relay.example
• Network: only the document request to localhost:5273 — no NIP-11 fetch to https://relay.example
• localStorage['nc-trusted-relays']: null

The first wss://relay.example/ connection attempt appears in the console only after "Connect" is clicked.

The signed-in case — no NIP-42 event leaks

This is the disclosure the ticket is about, so it was measured rather than inferred. window.nostr was replaced with a stub that records the kind of every event it is asked to sign, then:

1. Signed in on the local relay → one kind 22242 signed (the NIP-42 AUTH for localhost:8081), as expected.
2. Counter reset, then navigated (client-side) to /s/neuerhost.example'x, an untrusted host.
3. Result: screen "Connect to neuerhost.example?", zero events signed, no socket, nothing stored.

So while signed in, reaching an unfamiliar relay through a link discloses neither the pubkey nor a signature before the user agrees.

Remembering the decision

Case	Result
Connect with "Remember this relay" checked (default)	stores ["relay.example"]; reload goes straight in, no prompt ✓
Connect with the box unchecked	connects, stores nothing; reload asks again ✓
Checkbox default state	checked ✓
Second foreign host (andere.example) after trusting the first	asked again, checkbox back to checked, first host stays trusted ✓

Hosts that must never be asked about, and routes that must not connect

Route	Result
/s/localhost:8081'test23 (dev relay = VITE_RELAY_URL)	no prompt, connects directly ✓
/ and /settings/*	no prompt ✓
/settings/spaces/fremd.example'group	no prompt, no socket to fremd.example ✓
/s/not-an-address	"This link is not a space address", no relay chip at all — no connection of any kind ✓

Worth knowing, not a defect

After "Connect" to a host that does not resolve, the space sits at "loading group state…" / "loading pages…" indefinitely while the relay chip correctly reads "offline (attempt N)". space.loading stays true until the relay answers and nothing consults the connection state (src/routes/SpaceOverview.tsx:140), so the page body contradicts the chip. This is pre-existing and untouched by CON-46 — on main the same thing happens, just without the prompt in front of it. It is more visible now because the prompt invites a deliberate "Connect" and the reward is an unexplained spinner. Worth its own ticket; not a reason to hold this PR.

Not covered

Revoking a remembered relay — there is no UI for it, which the PR states and records as residual risk in docs/09-security-privacy.md.