Messages: cursor pagination, onlyMine, and viewing-preference feed modes #36

Activity

1. Adron

   added

   parityWeb/API feature-parity workWeb/API feature-parity work

   P1Table stakesTable stakes

   area:messagesArea: messagesArea: messages

   on Sep 15, 2026
2. Adron

   added a parent issue on Sep 15, 2026

   • Epic: Messages / Feed parity gaps (push, quote, tags, link previews, permalinks) #30
3. Adron commented on Sep 16, 2026

   

   Adron

   on Sep 16, 2026

   MemberAuthor

   More actions

   Two of the four feed modes have no server-side support — this needs a decision

   GET /api/user stores viewingPreference, and /help/settings documents four modes: My Messages / All Messages / Followers Only / Following Only. The server enum (from its own 400) is my_messages, all_messages, followers_only, following_only.

   But GET /api/messages accepts only limit, onlyMine, tag, cursor — and there is no /api/feed* path at all. Probed live 2026-09-16:

   ?viewingPreference=following_only  -> n=2  total=363     <- silently ignored
   ?viewingPreference=followers_only  -> n=2  total=363     <- silently ignored
   ?viewingPreference=my_messages     -> n=2  total=363     <- silently ignored
   ?onlyMine=true                     -> n=2  total=36      <- genuinely filters
   

   The parameter isn't rejected, it's ignored — total stays 363 regardless. So:

   Mode	Server support
   All Messages	✅ no parameter
   My Messages	✅ onlyMine=true (total drops 363 → 36)
   Followers Only	❌ none
   Following Only	❌ none

   Why I'm not guessing at this

   Client-side filtering is the only alternative and it's a bad one: it would mean fetching the follow graph, then paging the entire feed to find matching posts — many requests, wrong counts, and a "load more" that skips unpredictable amounts. That's worse than not offering the mode.

   What I'd suggest

   Implement the two modes that work (All / My), and render the other two as unavailable with a short explanation, rather than offering controls that silently do nothing — which is exactly the failure mode #47, #91 and #160 all turned out to be.

   The decision is yours: ship two modes now, or hold the whole selector until the server exposes a follow-scoped filter. If the web app implements Followers/Following Only, it's either doing it server-side through a route the spec doesn't document, or filtering client-side — worth checking before accepting this conclusion.

   Everything else in #36 (cursor pagination, onlyMine, messagesPerPage) is unblocked. Note Pagination.NextCursor and CursorPager<T> already exist in #130, and CurrentUser.EffectiveMessagesPerPage in #131.
4. Adron

   added

   questionFurther information is requestedFurther information is requested

   on Sep 16, 2026