Sort channel threads by most recent reply, not creation date

[jeffreykthomas]

Motivation

Channel timelines order threads by when the root was posted. A two-week-old thread getting replies all morning stays buried under yesterday's dead ones, so finding the live conversation means scrolling and checking reply counts. Home / Inbox is the only pane that surfaces threads by activity, and it is personal/mention-scoped — it does not answer "what is live in this channel."

Proposed solution

An activity-ordering option for the channel timeline, shipped as a preview feature (preview-features.json) — off by default, same path Workflows, Projects, Pulse, and Forum Channels took.

The data already exists end to end. thread_metadata.last_reply_at is bumped on every reply (crates/buzz-db/src/thread.rs:210), selected in the channel window query (thread.rs:588), serialized to the client (crates/buzz-relay/src/api/bridge.rs:544), and already rendered as "last replied …" on thread summary rows (desktop/src/features/messages/ui/MessageThreadSummaryRow.tsx:253). Nothing sorts by it — get_channel_window (thread.rs:565) hardcodes ORDER BY e.created_at DESC, e.id ASC (thread.rs:628).

There are two implementations, with different scope and different correctness:

1. Client-side re-sort. Sort the loaded window by lastReplyAt ?? createdAt behind the flag. Desktop-only, no relay change, no migration. Reorders only what is loaded, so an old-but-active thread below the pagination boundary stays hidden until paged in. Reaches users in a desktop release.
2. Server-side sort. Correct at any depth. The current pagination is a composite keyset on (created_at, id), so it needs a new cursor over COALESCE(last_reply_at, created_at), a supporting index, and a sort param through bridge → Tauri → client. Reaches users only after a relay deploy.

(1) is a subset of (2) — the flag and the UI carry over, so starting there does not throw work away if (2) follows. Either is fine to build; which one depends on whether the partial ordering is acceptable to ship.

Alternatives considered

• Home / Inbox. Already orders by reply time (crates/buzz-db/src/feed.rs:115), but it is a personal view, not a channel one.
• Always sort by activity, no toggle. Changes the timeline's meaning for every existing user, and reorders the view underneath the reader as replies land.
• Sort by reply count or unread. Reply count does not identify recent activity; unread is per-user state and does not belong in the window query.

Additional context

Searched open issues and PRs — no duplicates found.

Per CONTRIBUTING.md § "PRs We're Unlikely to Merge", raising this before building. If the direction works, the PR will include before/after screenshots.

[rmichelena]

Concrete report for this from a live desktop 0.5.17 account, plus one interaction with the unread badge that I think argues for (2).

What happened. A DM row in my sidebar sat at "1 unread" for ten days. The unread event was a thread reply posted 2026-08-10; its thread root was a message from 2026-08-09. Opening the DM showed nothing new, because the timeline orders by root creation date and that root had long since scrolled out of reach. I re-entered that DM many times over ten days and never found the message.

A separate eviction bug (#5653) is what kept the badge coming back, so the two are easy to conflate — but they are independent. Finding the message was a pure ordering problem, and it stayed unsolved even after I knew the message existed and knew roughly when it was posted. Ordering by last_reply_at would have put that thread at the top on the first try: it was the freshest thing in the channel and it was rendered last.

Why the pagination boundary in variant (1) matters more than it looks. The per-thread (N new) count is computed by computeThreadBadgeCounts(timelineMessages, …) (desktop/src/features/channels/ui/useChannelUnreadState.ts:350-359) — over the loaded window only. So a thread whose root is below the boundary cannot render an unread count at all, and creation-date ordering is exactly what pushes long-running threads below that boundary. The two defects compound: the row you need to find is both mis-sorted and unbadged.

That reads to me as an argument for (2) rather than against (1). Under (1) the ordering fix and the badge coverage still share the same window, so an old-but-active thread stays invisible until something pages it in. In a low-volume channel or DM, where the whole history fits in the first window, (1) is already a complete fix — which is most of what I personally hit.

+1 on shipping this, either variant. Happy to run a preview-flag build against a real account and report back.

_{Filed by Bumble, an agent working in @rmichelena's Buzz workspace, from measurements on his machine.}