parseGroupAddress: a `localhost` prefix match downgrades an attacker-chosen host to plaintext ws://

[usekaneo]

From the CON-43 security audit (2026-09-14). Severity medium, reachable in the shipped app. Found while verifying the audit's relay-trust finding — this one is a plain bug, not a design question.

src/nostr/group-address.ts:21-22:

const local = host.startsWith('localhost') || host.startsWith('127.0.0.1')
return { host, id, relayUrl: `${local ? 'ws' : 'wss'}://${host}` }

startsWith is a prefix test, not an equality test. Verified with node:

'localhost.evil.example'.startsWith('localhost')  // true  -> ws://localhost.evil.example

So any host that merely begins with localhost or 127.0.0.1 — localhost.attacker.tld, 127.0.0.1.attacker.tld, localhostile.example — is treated as local and gets an unencrypted ws:// connection. A domain like that is trivially registrable; the prefix is not a property an attacker has to defeat, it is one they pick.

Why it matters

The host comes out of the route (/s/<host>'<group>), so it is attacker-choosable via a link. src/ui/layout/AppShell.tsx:37-39 feeds the parsed relayUrl straight into useRelay() → client.want(), which opens the connection. The transport then carries a NIP-42 AUTH event that NostrClient signs automatically (src/nostr/client.ts:172: this.pool.automaticallyAuth = (url) => this.signAuth(url)), i.e. the signed-in user's pubkey and a valid signature travel in the clear, over a connection any network observer on the path can read and modify.

The broader question — whether the app should connect to a relay named in a link at all — is deliberately not this ticket; see the sibling ticket. This one is the narrow bug: whatever the answer there, startsWith is the wrong test and the downgrade to ws:// is not intended behaviour.

Task

• Match the local case exactly instead of by prefix. localhost and 127.0.0.1 with an optional :<port> — nothing else. A small helper with the rule in one place, not a second inline condition.
• Consider whether [::1] belongs in the local set; today it does not and gets wss://, which fails on a dev relay. Decide, do not leave it implicit.
• While in this function: parseGroupAddress does no validation of the host's shape at all beyond "there is an apostrophe". A host containing /, ?, #, @ or whitespace produces a relayUrl that is not the URL it looks like — evil.example/#@real-relay.example and friends. Reject anything that is not a plain host[:port].

Acceptance

• localhost.evil.example, 127.0.0.1.evil.example and similar resolve to wss://, not ws://.
• localhost, localhost:8080, 127.0.0.1:8080 still resolve to ws:// — the dev setup from scripts/dev-relay-up.sh keeps working unchanged.
• A host that is not a plain host[:port] is rejected (null), so the route falls through to not-found rather than connecting somewhere unintended.
• Unit tests in src/nostr/group-address.test.ts cover each of those three cases explicitly, including the prefix-attack strings — a test that only checks localhost would have passed against the buggy code too.
• npm run typecheck && npm run lint && npm test && npm run build pass.

Affected: src/nostr/group-address.ts

Source: CON-43, extending finding A4.

---

_{Task: oozaxfd8qw29r3tk11k4ikn8}

[usekaneo]

CON-45

[usekaneo]

**** commented:

Technical refinement — parseGroupAddress

1. Confirmed state

• src/nostr/group-address.ts:21-22 — the prefix test; the bug reproduces exactly as described (localhost.evil.example → ws://).
• There is no src/nostr/group-address.test.ts today. The ticket says "unit tests … cover each of those three cases" — the file has to be created, which also means this dev-only local case is currently guarded by nothing at all.
• Callers: src/ui/layout/AppShell.tsx:37 and src/routes/space-route.ts:24, both on the react-router :group param. formatGroupAddress is used by src/nostr/my-spaces.ts:218.

2. Two more things in the same function, not in the ticket

(a) decodeURIComponent(raw) can throw. A route such as /s/%E0%A4%A'group reaches parseGroupAddress, decodeURIComponent throws URIError, and the exception propagates out of render into a white screen. Wrap it (try/catch → null) and add a test for it.

(b) It is a second decode. React Router already decodes useParams values; parseGroupAddress decodes again. For a plain host'group that is a no-op, but an encoded %25 or %2F in a link then resolves differently than it reads. Since % will be rejected by the new shape validation anyway, the cleanest resolution is to drop the internal decode and rely on the router — but that changes behaviour for any non-router caller, and there is none today. Decide explicitly and pin it with a test; do not leave two decoders stacked silently.

3. null does not currently fall through to not-found

Acceptance item 3 assumes that returning null makes the route fall through to NotFound. It does not:

• AppShell.tsx:38 falls back to DEFAULT_RELAY_URL and calls useRelay(DEFAULT_RELAY_URL);
• space-route.ts:25 does the same and calls useSpace(DEFAULT_RELAY_URL, '');
• each view has an inline guard rendering Invalid group address. (src/routes/SpaceOverview.tsx:36-42, and the same if (!group || !base …) in PageView, EditorView, NewPageView, SearchView, HistoryView, BlameView, SpaceSettings).

So a rejected host still opens a connection and a subscription to the default relay, and the user sees an inline message rather than NotFound. Decide which is intended:

• Option A (recommended): an unparsable address renders NotFound (or a dedicated "invalid space link" view) and touches no relay at all. Hooks cannot be called conditionally, so this needs a small restructure: Shell renders the invalid branch before mounting the component that owns useRelay/useSpace, or those hooks grow a null no-op input.
• Option B: keep the inline message and reword acceptance item 3. Then at least make sure the default-relay connection is intentional, because today it looks accidental.

4. Recommended implementation

A single rule in one place:

const LOCAL_HOST = /^(localhost|127\.0\.0\.1|\[::1\])(:\d{1,5})?$/

and a validation stronger than a regex, because it rejects exactly the shapes the ticket lists:

function normalizeHost(host: string): string | null {
  if (host.length === 0) return null
  try {
    const url = new URL(`https://${host}`)
    // the host carries no path/query/userinfo; URL also normalises case
    return url.host === host.toLowerCase() ? url.host : null
  } catch {
    return null
  }
}

• new URL('https://evil.example/#@real-relay.example') yields host === 'evil.example', which differs from the input → rejected.
• https://a b, https://host/path, https://host?x and https://user@host either throw or fail the equality check → rejected.
• A port above 65535 throws → rejected.
• [::1]:8080 round-trips (url.host === '[::1]:8080') → accepted.
• URL lowercases and punycodes, so compare against host.toLowerCase() and document that only ASCII hostnames are accepted (IDN stays out of scope).

Then:

export function isLocalRelayHost(host: string): boolean {
  return LOCAL_HOST.test(host)
}

Export it, because CON-46's trust gate needs the same "loopback is always trusted" predicate — one rule, one place, instead of a second inline condition (which is precisely how the current bug started).

Decide [::1] explicitly: include it in the local set (a dev relay bound to IPv6 then gets ws://) or exclude it and document that it fails. Recommendation: include it.

Order inside parseGroupAddress: normalize the host first, then the local test, then build relayUrl. The empty-id case is already covered (at === decoded.length - 1); note that the group id itself is not validated at all — out of scope, but say so.

5. Tests — create src/nostr/group-address.test.ts

Include strings that would have passed against the buggy code:

• prefix attacks resolving to wss://: localhost.evil.example, 127.0.0.1.evil.example, localhostile.example, 127.0.0.1.attacker.tld;
• local still ws://: localhost, localhost:8080, 127.0.0.1:8080, [::1]:8080;
• rejected (null): evil.example/#@real, evil.example/path, a b, user@evil.example, evil.example?x, empty host ('group), missing id (localhost'), malformed percent (%E0%A4%A'group);
• formatGroupAddress round-trips parseGroupAddress for a valid address.

6. Acceptance / dependencies

• The three ticket acceptance cases, plus the two extra ones above; the four commands (typecheck && lint && test && build).
• Out of scope: whether the app should connect to a link-named relay at all (CON-46) and group-id validation.
• CON-46 should reuse isLocalRelayHost. Landing this ticket first removes the scheme-downgrade half of that decision entirely.

[usekaneo]

**** commented:

Implemented — branch con-45-group-address-host (commit 8ed3501, local only, not pushed)

src/nostr/group-address.ts + new src/nostr/group-address.test.ts (32 tests). Nothing else touched — the routing question from refinement §3 went to CON-46, which restructures AppShell for its trust gate anyway; two changes to the same component in parallel would only have collided.

All six refinement points are in: the anchored LOCAL_HOST regex including [::1], normalizeHost via URL round-tripping, the exported isLocalRelayHost predicate, a total (never-throwing) parse, and the normalize → local-test → build order.

Deviation from refinement §4, verified before accepting it

The implementation removed decodeURIComponent rather than wrapping it. §4 is written assuming the decode stays, so this was checked against React Router 7.18.3 rather than argued:

Route	useParams receives
/s/localhost%3A8080'engineering	localhost:8080'engineering
/s/localhost%3A8080'100%25	localhost:8080'100%
/s/evil.example%2527x	evil.example%27x
/s/%E0%A4%A'group	%E0%A4%A'group (router logs a warning, hands over the raw segment)

Row 1 settles the premise: matchRoutes, which feeds useParams, decodes. Every link in the app is built with encodeURIComponent (CreateSpaceForm.tsx:107,171, AppShell.tsx:64, Sidebar.tsx:158, space-route.ts:31, SpaceOverview.tsx:99, SpacesSettingsList.tsx:60,74), so there was exactly one encoder and, until now, two decoders.

The second decoder was not merely redundant, it was harmful twice. Row 2: a group id ending in a percent sign is legitimate after the router's decode, but decodeURIComponent("localhost:8080'100%") throws URIError — straight out of render, white screen. Row 3: a double-encoded link decoded back into host evil.example + id x, so what the address bar shows and what gets connected to part ways again — the very class of confusion the new host check exists to stop. Row 4 confirms the white-screen guard still holds without a try/catch: the raw segment reaches normalizeHost and is rejected there.

(A first check of mine used matchPath instead of matchRoutes and appeared to show no decoding. That was a measurement error on my side — matchPath is not the path the app takes.)

One deliberate side effect, commented in the file: URL drops an explicitly written default port, so example.com:443 is rejected, and it punycodes Unicode hostnames, so IDN is rejected rather than half-supported.

Verification (re-run independently, not taken from the agent's report)

npm run typecheck clean · npm run lint clean · npm test 45 files, 472 passed · npm run build clean.

[usekaneo]

**** commented:

Reviewed in worktree .claude/worktrees/agent-aaa1682d1c0d38aea (con-45-group-address-host @ 8ed3501). Verification run for this review on that worktree: npm run typecheck, npm run lint, npm test, npm run build — all four pass.

Review — CON-45: `parseGroupAddress` prefix-matches `localhost` and downgrades to `ws://`

1. Verdict

⚠️ Approve with nits. The fix is correct, the security property holds, and I could not find a bypass. The items below are edge cases and test gaps — none of them blocks merge.

2. Summary

The change replaces the prefix test with an anchored regex, `LOCAL_HOST` (`src/nostr/group-address.ts:30`), exposed through `isLocalRelayHost` (`:40-42`), and inserts `normalizeHost` (`:62-71`) which round-trips the host through `new URL('https://…')` and requires exact equality with the input, so paths, queries, fragments, userinfo, whitespace and percent-confusion all fail closed. `parseGroupAddress` (`:100-108`) validates the host first, then picks `ws` vs `wss`. It also removes the redundant `decodeURIComponent(raw)`, because React Router already decodes `useParams` exactly once (verified in the installed `react-router` build, below). Attacker-chosen prefix hosts now get `wss://`, the dev set keeps `ws://`, and anything that is not a plain `host[:port]` returns `null`.

3. Acceptance criteria

• `localhost.evil.example`, `127.0.0.1.evil.example` and similar resolve to `wss://`. Test rows `src/nostr/group-address.test.ts:9-17` (also `localhostile.example`, `127.0.0.1.attacker.tld`); logic at `group-address.ts:30` (regex is `^`…`$` anchored) and `:106`. Verified against the released code path.
• `localhost`, `localhost:8080`, `127.0.0.1:8080` still resolve to `ws://`. Test `:19-31`; confirmed with node that `new URL('https://localhost:8080').host === 'localhost:8080'`, so the equality check passes.
• A host that is not a plain `host[:port]` is rejected (`null`). Test `:33-48`; `normalizeHost` `group-address.ts:62-71`. I ran the exact cases through node: `evil.example/#@real`, `evil.example/path`, `a b`, `user@evil.example`, `evil.example?x` all make `url.host !== host` (or throw) → `null`. I also confirmed the hostile decoded forms reach this function: React Router turns `/s/localhost%2Fevil.example%27engineering` into `localhost/evil.example'engineering` and `/s/localhost%23%40evil.example%27engineering` into `localhost#@evil.example'engineering`, both correctly rejected.
• Tests explicitly cover the prefix-attack strings. Yes — see §5; they fail against the buggy implementation.
• `npm run typecheck && npm run lint && npm test && npm run build` pass. Not run here per instructions (a separate CI job covers every worktree). Reviewed for obvious type/lint hazards: none — `LOCAL_HOST` is a module const, `isLocalRelayHost` is exported, `group!` appears only in the test, and the tuple `it.each` rows infer `string`.

One wording note: a rejected address does not reach the router's `*` NotFound route — it still matches `/s/:group`, so the view renders “Invalid group address.” (`src/routes/SpaceOverview.tsx:36-42`) and the relay falls back to `DEFAULT_RELAY_URL` (`src/ui/layout/AppShell.tsx:38`, `src/routes/space-route.ts:25`). The security intent (“rather than connecting somewhere unintended”) is met: nothing connects to the attacker-chosen host.

4. Findings

Must fix before merge: none. The findings below are minor/nit only.

1. minor — `isLocalRelayHost` returns `true` for syntactically invalid ports — `src/nostr/group-address.ts:30,40-42`.
   ```ts
   const LOCAL_HOST = /^(localhost|127.0.0.1|[::1])(:\d{1,5})?$/
   ```
   I verified with node that this regex (the helper's whole body) returns `true` for `localhost:99999`, `localhost:65536`, `localhost:00000` and `[::1]:99999`. There is no live impact today: `parseGroupAddress` only calls it after `normalizeHost` (`:100-106`), and `normalizeHost` throws on an out-of-range port. But the function is exported deliberately so that “every place that needs the distinction asks the same question” (`:32-39`); a future caller handing it a raw host would get `true` for `localhost:99999` and could select `ws://` for something that cannot be connected to. The JSDoc at `:27-28` admits `\d{1,5}` still allows `:99999`.
   Fix: range-check inside the helper (capture the port digits and require `<= 65535`), or make the “already normalised” precondition part of the name and unexport it until a second caller exists.

2. nit — a written default port is rejected, so `localhost:443` resolves to `null` — `src/nostr/group-address.ts:65-67` (doc `:58-60`).
   ```ts
   return url.host === host.toLowerCase() ? url.host : null
   ```
   `URL` drops the default port for `https`, so `new URL('https://localhost:443').host === 'localhost'`. I verified `localhost:443`, `127.0.0.1:443` and `[::1]:443` therefore all return `null`, as does a zero-padded port (`localhost:0443`). These are exactly the local `host[:port]` shape the ticket says should be `ws://`; only port 443 is special (e.g. `localhost:80` works). Low impact — the ticket's named cases (`localhost:8080`) work — but the “optional `:`” rule has one hole.
   Fix: strip a single trailing `:443` before the equality comparison (or compare `url.hostname` plus a separately parsed port) so a local relay on 443 is reachable instead of 404-ing.

3. nit — scope: the diff also stops decoding the input — `src/nostr/group-address.ts:101`.
   ```ts
   const at = raw.indexOf("'")
   ```
   The previous `const decoded = decodeURIComponent(raw)` is gone. This is not a defect — I verified React Router v7 decodes the param once (`node_modules/react-router/dist/development/chunk-BV7QT456.mjs:847` `decodePath`, applied at `:534` and `:5979`) and, on a malformed segment, hands back the still-encoded raw path (probe: `/s/%E0%A4%A'group` → `%E0%A4%A'group`). Both call sites pass `useParams().group` (`AppShell.tsx:37`, `space-route.ts:24`), so no caller needs a second decode. It fixes a genuine `URIError` white screen, which the removed code caused. It is nevertheless extra scope beyond the ticket's stated task; call it out in the PR description (or a follow-up ticket) so it is reviewable on its own. The JSDoc at `:76-87` does document the new contract.

4. nit — the port check lives in two conceptual places — `src/nostr/group-address.ts:30` and `:65-67`. The regex shape-checks the port and `URL` range-checks it. That is defensible and documented, but it is why finding 1 exists; folding the range check into the helper would make the “one place” claim literally true.

Everything else I checked is clean: no bypass of the WS/WSS decision, no path by which a rejected host reaches `useRelay`/`client.want`, and no other caller of `parseGroupAddress` that bypasses the route decoding.

5. Tests

Meaningful: yes. These would fail against the buggy version:

• The four prefix rows (`src/nostr/group-address.test.ts:9-17`) assert `wss://` and would fail, because the old `host.startsWith('localhost')` returns `ws://localhost.evil.example`.
• The rejection rows (`:33-48`) would fail against the old code, which returned an object (with a malformed `relayUrl`) for `evil.example/path'engineering`, `user@evil.example'engineering`, etc.
• The malformed-percent row (`:45`) would throw `URIError` out of the old `decodeURIComponent`, so the test would error rather than pass.
• The local rows (`:19-31`) pin the dev setup (including the deliberate `[::1]:8080` decision) so the fix cannot silently break it.

Good coverage: `[::1]` decision (`:24`, `:82`); “no second decode” is pinned from both sides (`:63-70`); case normalisation (`:50-53`); first-apostrophe splitting (`:55-57`); `formatGroupAddress` round-trip (`:72-78`). I confirmed the comment at `:42-44` is accurate: the router really delivers `%E0%A4%A'group` for `/s/%E0%A4%A'group`.

Missing cases (nice to have):

• A prefix host with a port: `parseGroupAddress("localhost.evil.example:8080'g")` → `wss://localhost.evil.example:8080`. A naive fix that strips the port before matching would still pass all four current prefix strings.
• Out-of-range port: `parseGroupAddress("localhost:99999'g")` → `null` (the behaviour the JSDoc at `:27-28` claims), and ideally `isLocalRelayHost("localhost:65536") === false` (finding 1).
• A non-local host keeps its port: `parseGroupAddress("evil.example:8080'g")` → `wss://evil.example:8080`.
• `[::1]` without a port through `parseGroupAddress` (currently only exercised through `isLocalRelayHost`).
• The default-port case from finding 2 (`localhost:443`), whichever way it is decided.

6. Docs

• The ticket lists only `src/nostr/group-address.ts` as affected; the diff touches exactly that file plus its new test. No documentation describes the scheme-selection rule or host validation, so nothing is stale.
• `docs/08-relay-setup.md:116-117` (“an HTTPS page may not open `ws://` … except for `localhost`”) remains true, it just does not enumerate `127.0.0.1`/`[::1]`. Since the same file (`:107`) already discusses IPv6-wildcard/`localhost` ambiguity, a one-line note that `[::1]:8080` is now treated as local would be a nice-to-have — not required by this ticket.
• The authoritative write-up of the `[::1]` decision and the decoded-input contract is the module JSDoc (`group-address.ts:15-99`), which is thorough and accurate against what I measured.

7. What is good

• The URL round-trip equality (`:65-67`) is the right technique. Validating against the same parser the connection uses makes `/`, `#`, `@`, whitespace and percent-confusion fail closed, instead of producing a `relayUrl` that only reads like the intended one. I tried the obvious injections (userinfo, backslash, `%2F`/`%23`, octal/integer IPv4, leading-zero ports) and could not construct a host that passes validation but connects somewhere other than `url.host`.
• Order of operations (normalise → decide scheme → build URL, `:100-107`) guarantees the scheme decision and the connection only ever see a validated host.
• The `[::1]` question is answered explicitly in the JSDoc and both a positive and a negative test, rather than left implicit.
• Comments carry the threat model: attacker-choosable route, NIP-42 AUTH signed in the clear, why the prefix test was wrong, and why the second decode was dropped. The test file repeats the same context, so the next reader does not have to reconstruct it.

[usekaneo]

**** commented:

Review findings addressed — working tree on con-45-group-address-host (not committed)

Worktree .claude/worktrees/agent-aaa1682d1c0d38aea, on top of 8ed3501. Changes are left uncommitted and unstaged for review. Files touched: src/nostr/group-address.ts, src/nostr/group-address.test.ts, docs/08-relay-setup.md.

Every claim in the review was re-measured before acting on it. All four review claims held up — nothing in the review turned out to be wrong.

Finding 1 (minor) — isLocalRelayHost returns true for out-of-range ports — fixed

Verified with node against the exact regex from group-address.ts:30: it returns true for localhost:99999, localhost:65536, localhost:00000 and [::1]:99999. Also confirmed the review's "no live impact today": normalizeHost returns null for all of them, so parseGroupAddress never reaches the predicate with such a host.

Fixed by taking the first of the two options the review offered — range-check inside the helper — but implemented by normalising rather than by capturing the port digits:

export function isLocalRelayHost(host: string): boolean {
  const normalized = normalizeHost(host)
  return normalized !== null && LOCAL_HOST.test(normalized)
}

This is strictly better than a <= 65535 digit check, because it also rejects localhost:00000 and localhost:0443 (in range, but not a host spelling any connection agrees with) and anything that is not a host at all. The predicate now answers for itself for whatever a caller holds, which is the point of exporting it. LOCAL_HOST became non-capturing and its JSDoc no longer claims the port is merely shape-checked here.

⚠️ CON-46, please read: the name and signature of isLocalRelayHost are unchanged, and every input CON-46 would realistically pass still answers the same. The semantics did narrow: inputs that are not a valid host now answer false where the bare regex answered true (localhost:99999, localhost:00000). For a trust gate that is fail-closed and the safer direction, but it is a behaviour change in an exported symbol CON-46 imports, so it is called out here rather than buried.

Finding 2 (nit) — a written-out :443 is rejected — fixed, but not the way the review proposed

Verified: localhost:443, 127.0.0.1:443, [::1]:443 and relay.example:443 all returned null, while localhost:80 worked, exactly as described.

The review's suggested fix — "strip a single trailing :443 before the equality comparison" — would be wrong, and this is the one place I deliberately deviated. Stripping makes localhost:443 normalise to localhost, and the host is then carried into a ws:// URL, where 443 is not the default port: ws://localhost:443 and ws://localhost are different connections (80 vs 443). Silently moving a local relay to port 80 is worse than rejecting it. The port is therefore preserved, and the comparison stays exact:

if (url.port === '' && `${url.host}:443` === lower) return lower

Everything else still fails closed, and a padded :0443 is still rejected (pinned by a test), because it is the input/parse disagreement class the check exists for.

One thing the review did not have, which raised this from cosmetic to reachable: src/nostr/my-spaces.ts:214 and src/ui/CreateSpaceForm.tsx:12 both derive the host as DEFAULT_RELAY_URL.replace(/^wss?:\/\//, ''), and DEFAULT_RELAY_URL is import.meta.env.VITE_RELAY_URL (src/nostr/relay-status.ts:67). A deployment whose VITE_RELAY_URL spells the port out (wss://relay.example:443) therefore produces exactly this host shape for every generated space address — so before this fix every "My spaces" link on such a deployment would have rendered "Invalid group address." That motivation is recorded in the code comment.

Finding 3 (nit) — the diff also stops decoding the input — no code change; re-measured independently

The review's verification is correct, and I re-measured it from scratch rather than taking it on trust (the instructions flagged this as load-bearing). matchRoutes from the installed react-router 7.18.3, route /s/:group:

Path	params.group
/s/localhost%3A8080%27engineering	localhost:8080'engineering
/s/localhost%3A8080%27100%25	localhost:8080'100%
/s/evil.example%2527x	evil.example%27x
/s/%E0%A4%A%27group	%E0%A4%A%27group (logs a malformed-segment warning, hands back the raw segment)

Row 1 confirms the router decodes; row 4 confirms a malformed segment arrives still encoded, so removing the second decode cannot reintroduce a URIError white screen — it is what removed one. Both call sites (src/ui/layout/AppShell.tsx:37, src/routes/space-route.ts:24) pass useParams().group straight through; src/nostr/my-spaces.ts:218 uses only formatGroupAddress. No caller needs a second decode.

No code change — the finding asks only that the extra scope be called out where it is reviewable. Action for whoever opens the PR: the description should state that the diff also removes decodeURIComponent, and why. It cannot be added to the commit from here, since this branch is left uncommitted by instruction.

Finding 4 (nit) — the port check lives in two conceptual places — fixed, as a consequence of finding 1

Now literally one place: URL decides the port's validity inside normalizeHost, and both parseGroupAddress and isLocalRelayHost go through it. LOCAL_HOST only names which hosts count as local.

§5 — missing test cases — all added, group-address.test.ts goes from 32 to 47 tests

• prefix host with a port: localhost.evil.example:8080 → wss://…:8080, added to the prefix-attack rows with a comment saying why (a fix that stripped the port before matching would pass all four original rows and still downgrade this one);
• out-of-range ports rejected: localhost:99999'… and localhost:65536'… → null;
• isLocalRelayHost negative rows for localhost:99999, localhost:65536, localhost:00000, localhost:0443, localhost/evil.example and '' — four of these six answer true on the pre-fix regex, so they pin finding 1;
• non-local host keeps its port: evil.example:8080'… → wss://evil.example:8080, plus relay.example:443'… → wss://relay.example:443;
• [::1] without a port through parseGroupAddress → ws://[::1];
• the default-port case decided under finding 2: localhost:443 → ws://localhost:443, and the zero-padded localhost:0443 → null.

§6 — docs — added

docs/08-relay-setup.md:116 now names the full local set (localhost, 127.0.0.1, [::1], each with an optional port), says every other host gets wss:// including one that merely begins with localhost, and points at isLocalRelayHost.

Verification

Run from the worktree, all four in one final pass after the last edit:

• npm run typecheck — exit 0
• npm run lint — exit 0
• npm test — exit 0, 45 files, 487 tests passed (472 before, +15)
• npm run build — exit 0 (only the pre-existing >500 kB chunk-size advisory)

npx vitest run src/nostr/group-address.test.ts — 47 passed.

One honest caveat: an earlier full-suite run failed once in src/ui/editor-enter.test.tsx > continueList > ends it the same way once the list is longer (expected a trailing newline after - [ ] a\n- [ ] b). It is unrelated to this change — a different file, no shared code — and it does not reproduce: the file passed 3/3 in isolation and the full suite passed twice afterwards. Recorded as a flake rather than swept under the rug.

Adjacent observation — not a review finding, deliberately not fixed here

The host derivation noted under finding 2 (DEFAULT_RELAY_URL.replace(/^wss?:\/\//, ''), in my-spaces.ts:214 and CreateSpaceForm.tsx:12) has a second failure mode this ticket does not cover: a VITE_RELAY_URL with a trailing slash (wss://relay.example/) yields host relay.example/, which normalizeHost rejects — correctly, since / is exactly the separator the host check exists to catch. Relaxing the validator for it would be wrong; the producer should parse the URL instead of regex-stripping the scheme. Left alone on purpose: it is outside CON-45's file scope, and CON-46 is already restructuring in this area. Worth its own ticket.

[usekaneo]

**** commented:

UI test pass — 2026-09-15, PR #90, ed053cd

Tested through the running app (npm run dev, :5273) against the local dev relay on ws://localhost:8081. All cases pass. Merge-ready from the UI side.

The relay URL including its scheme is readable in the UI without DevTools: the tooltip on the relay chip (top bar) and on the relay line in the sidebar footer both spell out the full URL. Every result below was additionally cross-checked against the WebSocket URLs in the browser console.

Scheme selection

Address	Expected	Measured
localhost.evil.example'engineering	wss://	wss://localhost.evil.example/ ✓
localhost.evil.example:8080'engineering	wss://	wss://localhost.evil.example:8080/ ✓
EVIL.EXAMPLE'engineering	wss://, lowercased	wss://evil.example/ ✓
localhost:8081'engineering	ws://	ws://localhost:8081/, connected, NIP-29 supported ✓
127.0.0.1:8081'engineering	ws://	ws://127.0.0.1:8081/, connected ✓
[::1]:8081'engineering	ws://	ws://[::1]:8081/ ✓

No ws:// appears anywhere for a non-local host. [::1] gets ERR_CONNECTION_REFUSED because the dev relay binds IPv4 only — a relay configuration detail, not this change.

Host validation

Address	Result
relay.example:443'group	accepted → wss://relay.example/ ✓ (deliberate carve-out)
relay.example:0443'group	rejected ✓
relay.example:99999'group	rejected ✓
relay.example%2Fpfad'group	rejected ✓
evil.example%2F%23@real-relay.example'group	rejected ✓
evil.example/#@real-relay.example'group	rejected ✓

Rejected addresses render "Invalid group address." and open no socket to the named host.

Percent sign in the group id

/s/localhost:8081'100%25 (group id 100%) renders normally, address shown as localhost:8081'100%, no URIError, no white screen — the case that crashed on main.

Signed-in regression

Sign-in, space browsing, page navigation, breadcrumbs, reload on a deep page URL, edit + save + reload, and the space list under /settings/spaces all work unchanged. AUTH reaches confirmed over ws://localhost:8081. Console clean — no URIError, no React error.

Two notes for the PR's own test instructions

1. Step 4 is not reproducible in npm run dev as written. A bare, unencoded % in the path makes Vite answer 404 before React ever starts, so /s/localhost:8081'100% and /s/%E0%A4%A'group both show an empty document that comes from the dev server, not the app. Correctly encoded (…'100%25) it returns 200 and the app renders — that is the row above. Whether %E0%A4%A'group reaches the error screen instead of a white screen in production depends on the host's SPA fallback and is only testable in a build. Not a code defect, but the instruction as written cannot be followed.
2. Rejected addresses still connect to the default relay. useSpaceRoute falls back to DEFAULT_RELAY_URL, so the relay chip shows ws://localhost:8081 (connected) next to "Invalid group address." Correct for this ticket — the attacker-named host is never contacted — and CON-46 removes the fallback entirely.

Not covered

Production build behaviour (CSP, SPA fallback) — out of scope here, see CON-44.