Discourse currently has two bookmark features:

  1. you can bookmark a topic
  2. you can bookmark a post, including several posts in the same topic

The problem is that the footer control at the bottom of a topic only really deals with the first one. If you bookmarked a post 77 replies ago, the footer gives you no clean way to find it, edit it, or remove it. The data model knows the bookmark exists. The UI mostly shrugs.

I pulled current main and looked through the code path. The situation is a little worse than “missing feature”, because the codebase is split between two truths:

So the product is effectively saying “this is the bookmark control for the topic” while the implementation is saying “I meant the topic bookmark, singular, sorry about the rest.”

What the code is doing now

On the backend, the topic view already includes the user’s bookmarks for the topic, not just the topic bookmark itself. The TopicViewSerializer ships a bookmarks array and bookmarked becomes true if any bookmark exists in the topic.

That data comes from Bookmark.for_user_in_topic, which includes both:

So the server-side payload is already closer to the right model.

On the client side, the older controller logic in frontend/discourse/app/controllers/topic.js is also semi-aware of this. It tries to handle four states:

That last state is not a solution. It is the UI throwing up its hands.

The more important wrinkle is that the current footer no longer really uses that multi-state logic. In topic-footer-buttons.gjs, the bookmark button is rendered with TopicBookmarkManager, and that manager only looks for bookmarkable_type === "Topic".

So yes: the footer button is blind to post bookmarks in exactly the way users experience it.

The product mistake

The footer is trying to compress a collection management problem into a binary toggle.

That worked when “bookmark” basically meant one thing. It stops working when a topic can contain:

Once there can be a collection, the footer control cannot honestly remain a topic-only toggle.

My recommendation

The cleanest fix is to make the footer button mean:

bookmarks in this topic

Not merely:

is this topic itself bookmarked

That sounds tiny, but it changes the UI contract in the right way.

What that gives us

The UI I’d ship

The footer button should represent all bookmarks in this topic.

States:

The label should change with the state:

If any bookmark in the topic has a reminder, the icon should reflect that too. A count badge is even better. It tells the truth immediately.

2. A topic bookmarks drawer / sheet

When bookmarks exist, clicking the footer should open a compact manager.

Desktop: a drawer/popover.

Mobile: a bottom sheet.

Inside it:

Topic bookmark section

At the top:

That keeps the distinction real instead of flattening everything into anonymous bookmarks.

Post bookmarks section

List post bookmarks in topic order.

Each row should have:

That is the missing core interaction.

Bulk action at the bottom

A clearly destructive action:

That action can stay. It just should not masquerade as the main path.

What I would not ship

Not a smarter topic-only toggle

That still leaves buried post bookmarks stranded.

Not the current “more than one bookmark means maybe clear them all” flow

That is a failure mode, not a design.

Splitting the footer into “topic bookmark” and “post bookmarks” would technically solve the ambiguity, but it makes the main surface busier and weirder than necessary.

One button. Honest scope. Structured panel.

Implementation shape

I would keep the normal per-post bookmark UI exactly as it is.

The work is at the topic level:

  1. add a topic-scoped bookmarks endpoint or query path that returns richer bookmark rows
  2. reuse the existing topic/post bookmark serializers where possible
  3. replace the footer’s topic-only bookmark manager with a topic-scoped manager
  4. lazy-load row details instead of bloating the initial topic payload

The initial topic payload already carries enough to know that bookmarks exist. It does not need to ship every author, excerpt, and list-row detail up front.

Three interactive prototypes

I built three rough browser prototypes to test the feel.

1. Topic bookmarks drawer

This is the version I’d bet on.

Open prototype 1 — topic bookmarks drawer

This is narrower. It explores copy, count badges, icon changes, and what the menu should show for different state combinations.

Open prototype 2 — smart footer states

3. Timeline bookmark markers

This is not the primary fix. It is the nice second pass.

Once the topic-level bookmark model is coherent, timeline markers become useful rather than cryptic. This prototype explores bookmark ticks on the timeline plus previous/next bookmark navigation.

Open prototype 3 — timeline bookmark markers

My take after building the prototypes

Prototype 1 is the one.

It solves the actual problem without inventing a weird new mental model. The footer button stops lying. The collection becomes manageable. The topic bookmark still has a clear home. And “clear all” is still there for power users, just demoted to the level of danger it deserves.

Prototype 2 is useful as a supporting rule set.

Prototype 3 is nice garnish after the main interaction is fixed.

If I were doing this in core, I’d ship the drawer first, with a minimal but solid row design, then decide later whether timeline markers are worth the extra visual noise.

The short version is simple:

if a topic can contain several bookmarks, the footer control needs to manage a topic-scoped collection, not pretend everything is a single toggle.