The problem
Inside a space, the app's own views and the page slugs share one URL namespace:
/s/:group/new NewPageView
/s/:group/search SearchView
/s/:group/archive ArchiveView (added in CON-11)
/s/:group/:slug PageView
React Router matches the static segments first. So a page titled "Archive", "Search" or "New" — all three normalise to exactly those slugs — is created successfully, is published to the relay, appears in the sidebar tree, and its own URL then opens the app view instead of the page. From the outside it looks like a redirect. The page is still there and still in the search; it just has no address any more.
Verified with the real normaliser (normalizeSlug, src/nostr/kinds.ts):
"Archive" -> "archive"
"Search" -> "search"
"New" -> "new"
This is not new with the archive. new and search have had it since the routes were added; CON-11 only made it easy to run into, and "Archive" is a plausible page title in a wiki in a way that "New" is not.
Why reserving the words is not enough
The obvious fix — refuse those titles in the editor — does not hold here. A slug arrives from the relay: any member, on any Nostr client, can publish a 1818 revision with d=archive. Our editor refusing the title cannot prevent that, and the page would then be permanently invisible in Akasha with nothing in the UI explaining why. Any fix has to work without the writer cooperating.
Suggested direction (not decided)
Move the app's own views behind a prefix that a slug can never produce:
/s/:group/~new
/s/:group/~search
/s/:group/~archive
normalizeSlug keeps only letters, numbers, combining marks and -, so no slug can ever begin with ~ (or _). That closes the hole by construction, for every future app route as well, and frees every page title again.
Costs to weigh:
- Existing
/s/:group/new and /s/:group/search links break. Redirecting them is not an option: a redirect route for those words would be a static segment in the page namespace again, which is the thing being removed.
- App URLs get slightly uglier. Page URLs — the ones people actually share — are untouched.
Alternatives worth a look before committing: a /p/ prefix on pages instead (worse: changes every shared page URL), or keeping a reserved-word list plus a rendered explanation for pages that already carry one (does not fix reachability).
Scope
- One place that owns the prefix, and the ~9 call sites that build these URLs (
Sidebar.tsx, Topbar.tsx, SpaceOverview.tsx, PageView.tsx).
- A test pinning the invariant:
normalizeSlug can never return a string starting with the prefix.
docs/06-ui-information-architecture.md — the routing table and the reasoning.
Found
2026-09-17, while testing CON-11 in the browser. CON-11 itself is left as it is; this is deliberately separate because it touches routes that have nothing to do with archiving.
Task: cj1dcsjj0th2k8t5ff1ld57q
The problem
Inside a space, the app's own views and the page slugs share one URL namespace:
React Router matches the static segments first. So a page titled "Archive", "Search" or "New" — all three normalise to exactly those slugs — is created successfully, is published to the relay, appears in the sidebar tree, and its own URL then opens the app view instead of the page. From the outside it looks like a redirect. The page is still there and still in the search; it just has no address any more.
Verified with the real normaliser (
normalizeSlug,src/nostr/kinds.ts):This is not new with the archive.
newandsearchhave had it since the routes were added; CON-11 only made it easy to run into, and "Archive" is a plausible page title in a wiki in a way that "New" is not.Why reserving the words is not enough
The obvious fix — refuse those titles in the editor — does not hold here. A slug arrives from the relay: any member, on any Nostr client, can publish a
1818revision withd=archive. Our editor refusing the title cannot prevent that, and the page would then be permanently invisible in Akasha with nothing in the UI explaining why. Any fix has to work without the writer cooperating.Suggested direction (not decided)
Move the app's own views behind a prefix that a slug can never produce:
normalizeSlugkeeps only letters, numbers, combining marks and-, so no slug can ever begin with~(or_). That closes the hole by construction, for every future app route as well, and frees every page title again.Costs to weigh:
/s/:group/newand/s/:group/searchlinks break. Redirecting them is not an option: a redirect route for those words would be a static segment in the page namespace again, which is the thing being removed.Alternatives worth a look before committing: a
/p/prefix on pages instead (worse: changes every shared page URL), or keeping a reserved-word list plus a rendered explanation for pages that already carry one (does not fix reachability).Scope
Sidebar.tsx,Topbar.tsx,SpaceOverview.tsx,PageView.tsx).normalizeSlugcan never return a string starting with the prefix.docs/06-ui-information-architecture.md— the routing table and the reasoning.Found
2026-09-17, while testing CON-11 in the browser. CON-11 itself is left as it is; this is deliberately separate because it touches routes that have nothing to do with archiving.
Task: cj1dcsjj0th2k8t5ff1ld57q