You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Part of #27 — Tags: tagging posts, autocomplete, trending and tag-filtered feeds
Tapping a tag on a message card opens a feed filtered to that tag via the tag query
parameter.
The tag feed is a normal paged feed — it should share the feed implementation (including the
cursor-pagination work) rather than forking it.
Deep-link support so a tag URL from elsewhere opens the right screen.
Tests: tap → filtered query; paging works on the filtered feed.
Filed from the parity review of feature/parity-wip @ 14d7795 against interlinedlist.com (OpenAPI /api/openapi.json, 233 paths) and the public help centre.
Implemented in #122 (branch issue/29-tag-feed). Closing here — review and any follow-up happens on the PR.
The "share the feed implementation rather than forking it" requirement drove the interesting part. Sharing the ViewModel and repository was easy; the Room cache was not. The main feed and a tag feed routinely contain the same message, and a message row cannot hold two positions — so with feedOrder on the message, the second feed to load would have silently stolen rows from the first. Feed membership now lives in a feed_entry(feedKey, messageId, position) join table over shared message rows.
The deep-link URL was established, not guessed./tag/lists, /tags/lists, /tags, /explore and /trending all 404, and /messages is Direct Messages rather than the feed. The web's own tag chip (found in its JS chunk) links to "/?tag=".concat(encodeURIComponent(e)), and https://interlinedlist.com/?tag=lists does serve a filtered feed. So the canonical form is https://interlinedlist.com/?tag=<encoded>.
One product decision for you: an Android intent filter cannot match on a query string, so catching /?tag=… means registering https://interlinedlist.com/ — which also claims plain homepage links. They land on the app's normal start destination showing the same feed, so nothing breaks, but it is a wider claim than the feature strictly needs. Say if you would rather not claim it.
Activity
Adron commentedon Sep 16, 2026
Implemented in #122 (branch
issue/29-tag-feed). Closing here — review and any follow-up happens on the PR.The "share the feed implementation rather than forking it" requirement drove the interesting part. Sharing the ViewModel and repository was easy; the Room cache was not. The main feed and a tag feed routinely contain the same message, and a message row cannot hold two positions — so with
feedOrderon the message, the second feed to load would have silently stolen rows from the first. Feed membership now lives in afeed_entry(feedKey, messageId, position)join table over shared message rows.The deep-link URL was established, not guessed.
/tag/lists,/tags/lists,/tags,/exploreand/trendingall 404, and/messagesis Direct Messages rather than the feed. The web's own tag chip (found in its JS chunk) links to"/?tag=".concat(encodeURIComponent(e)), andhttps://interlinedlist.com/?tag=listsdoes serve a filtered feed. So the canonical form ishttps://interlinedlist.com/?tag=<encoded>.One product decision for you: an Android intent filter cannot match on a query string, so catching
/?tag=…means registeringhttps://interlinedlist.com/— which also claims plain homepage links. They land on the app's normal start destination showing the same feed, so nothing breaks, but it is a wider claim than the feature strictly needs. Say if you would rather not claim it.merge: #29 tag-filtered feed (PR #122)
merge: #89 blog email subscription (PR #127)