Never hardcode page sort names: they become community-configurable in pkc-js#73 #86

Summary

The hooks treat page sort names as a closed, known-at-build-time set. Sort names are about to become community-configurable in pkc-js (see pkcprotocol/pkc-js#73), so every hardcoded sort name is a future breakage. This issue asks for the hooks to stop assuming they know the full set of sort names, and to degrade gracefully when a community publishes a sort they have never heard of, or omits one they expect.

The rule

Never hardcode a page sort name, and never validate a sort name against a fixed list. A community decides which sorts it generates. The set is discoverable at runtime from the record (the keys of posts.pages / posts.pageCids, and replies.pages / replies.pageCids), and it can differ per community and change over time. Any sort name the hooks embed in a constant, a Set, a switch, or a default value is a guess about someone else's configuration.

Where this bites today (as published in 0.1.28)

1. Closed allowlists that assert. src/lib/validator.ts defines feedSortTypes and repliesSortTypes as Sets of literal names, and validateFeedSortType / validateUseFeedArguments / validateRepliesSortType / validateUseRepliesArguments assert membership. Passing a community's custom sort name to useFeed or useReplies throws rather than degrading. This is the hard blocker: once pkc-js#73 lands, a board with a custom sort cannot be rendered by these hooks at all.

2. Hardcoded defaults. sortType || 'hot' in src/hooks/feeds/feeds.ts and src/lib/feed-sort-type.ts, and sortType || 'best' in src/hooks/replies.ts. A community that does not generate hot or best gets an empty feed with no diagnostic. The correct default is "whatever sort the community actually preloaded", which is discoverable rather than assumed.

3. Name-matched scoring. src/stores/feeds/feed-sorter.ts branches on sortType.match('hot') and sortType.match('best') to pick a client-side scoring function. Substring matching on a name means a community sort called hottest or bestOfWeek silently gets the wrong algorithm.

4. Name-derived sort selection. deriveFeedSortType in src/lib/feed-sort-type.ts builds sort names by string concatenation (`top${time}`, `controversial${time}`) and special-cases topAll / controversialAll. This assumes a naming convention that custom sorts will not follow. pkc-js#73 is also likely to make timeframes more flexible than the current fixed Hour|Day|Week|Month|Year|All set, which breaks the concatenation entirely.

5. Interchangeability assumptions. src/stores/replies/utils.ts treats topAll and best as substitutable. That happens to be true for the current built-ins and will not be true in general.

Related: the allowlist is already wrong

feedSortTypes includes controversialHour through controversialAll, but pkc-js does not generate any controversial sort. POSTS_SORT_TYPES in src/pages/util.ts has no controversial entry, and controversialScore is defined but unreferenced. So the hooks today accept six sort names that no community produces, and the failure mode is a silently empty feed. This is the same class of bug in the opposite direction, and it shows the allowlist is not actually tracking reality.

Related: existing TODOs asking exactly this

There are already four copies of the same open question in the codebase, all asking what to do when the requested sort is absent:

• src/stores/feeds/utils.ts
• src/stores/communities-pages/communities-pages-store.ts (two occurrences)
• src/stores/replies-pages/replies-pages-store.ts (two occurrences)
• src/stores/replies/utils.ts

should we try to use another sort type by default, like 'hot', or should we just ignore it?

Resolving this issue should answer that question once, in one place, rather than leaving it inline six times.

Proposed direction

1. Drop the allowlists. Accept any non-empty string as a sort name. Keep validating the type (string), not the value.
2. Discover the available sorts from the community record instead of from a constant, and expose them so an app can render its sort tabs from what the community actually publishes.
3. Default to the community's preloaded sort, not to a literal. pkc-js publishes exactly one preloaded sort, so the preloaded sort name is derivable from the record; getSortTypeFromPage in src/stores/replies-pages/utils.ts already does a version of this.
4. Define one fallback policy for "requested sort is not published by this community", apply it in all six TODO sites, and make it observable to the app rather than silent. A clear signal that the sort is unavailable is better than a feed that renders empty or renders a different sort under the requested label.
5. Look up client-side scoring by exact name in a registry, never by substring match, and treat an unknown name as "no client-side scoring available" rather than falling through to a built-in algorithm.
6. Stop building sort names by string concatenation. Timeframe handling should key off data the community publishes, not off a naming convention.

Sequencing

pkc-js#73 is backward compatible: a community that does not configure settings.pages still generates exactly the sorts it generates today, so nothing breaks the moment it lands. But no app can use a custom sort until the hooks stop asserting on the allowlist. This work should follow pkc-js#73 and land before any board configures a custom sort.