Skip to content

Tags: tagging posts, autocomplete, trending and tag-filtered feeds #27

Description

@Adron

What the web app has

Messages carry tags. POST /api/messages accepts a tags[] array, GET /api/messages
accepts a tag query parameter to filter the feed, and two discovery endpoints back the UI:

Endpoint Purpose
GET /api/tags/autocomplete Tags on public messages matching a case-insensitive literal prefix
GET /api/tags/trending Most-used tags across public messages within a trailing window

AI's Suggest tags action also feeds this.

What Android has

Nothing. tags is absent from CreateMessageRequest, neither /api/tags/* endpoint is called,
and the feed cannot be filtered by tag.

Done when

A user can tag a post from Android with autocomplete, tap a tag to see that tag's feed, and browse
trending tags.


Filed from the parity review of feature/parity-wip @ 14d7795 against interlinedlist.com (OpenAPI /api/openapi.json, 233 paths) and the public help centre.

Activity

  1. added
    epicA feature area tracked as a parent issue
    parityClosing a gap against interlinedlist.com
    P1Big hole in a shipped feature
    area:messagesSocial messages feed & composer
    on Sep 15, 2026
  2. Adron commented on Sep 16, 2026

    @Adron
    MemberAuthor

    All three sub-issues are done, so closing this epic.

    Three things this epic established that are worth keeping:

    GET /api/tags/autocomplete takes q, not prefix — the issue text assumed otherwise.

    Tags are not hashtag-shaped. Real tags on the live account include "life is short, o brave girl" and "light rail", so nothing splits on whitespace and the tag query value is URL-encoded exactly once.

    The tag feed shares the feed implementation, which forced a real fix: the main feed and a tag feed routinely contain the same message, and a message row cannot hold two positions, so feed membership moved to a feed_entry join table. Without that the second feed to load would silently have stolen rows from the first.

    Also: GET /api/tags/trending has no window metadata in its response (window is a request parameter) and silently rewrites an unrecognised window to week rather than rejecting it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P1Big hole in a shipped featurearea:messagesSocial messages feed & composerepicA feature area tracked as a parent issueparityClosing a gap against interlinedlist.com

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions