Inbound new messages UX

[iduartgomez]

When you "refresh" (load) state after reconnecting or when you get new inbound messages, they might come out of order. This is fine and an expected outcome of the network, but it means that is easy to miss new messages.

A suggestion would be:

• when you get a fresh state after reconnecting to the network, separate clearly old from new messages (until you scroll down or interact), to see what is "new" from your last state
• when updates come in, they should be appended to bottom independently on their timestamp
  • an alternative would sorting them always by timestamp, but highlighting the "new" messages, until somehow user action acknoledges them (scrolling down, autoscrolling, any clicks, etc.)

[sanity]

Issue Priority Assessment

Generated: 2026-02-18T22:02:04.536110671+00:00
Issue hash: a1b0b477

Value Assessment

River’s clients sort every displayable message strictly by the timestamp stored in the room state before it reaches the UI, so when a refresh or delta brings in new messages their placement is determined only by MessagesV1::apply_delta’s sort, not by when the user actually saw them. In practice self.messages is re‑sorted and then streamed through display_messages() and group_messages() in ui/src/components/conversation.rs, so a brand‑new message that arrived after you lost connectivity can land somewhere in the middle of the view instead of at the bottom. Any participant who reconnects or relies on the “refresh state” pathway can therefore easily miss those messages unless they already happen to scroll, which makes it a widespread UX issue for busy rooms and undermines the expectation that “new” means “newly arrived.”

Fixing that mismatch lines up with River’s decentralised chat goals: the synchronizer already detects fresh content during refreshes (see RoomSynchronizer::update_room_state and refresh_all_rooms around ui/src/components/app/freenet_api/room_synchronizer.rs:703-840), but the message list never marks that new content as separate from the bulk history that just got re‑fetched. Highlighting or cornering new items until the user scrolls down would complement the existing logic and help deliver the reliable state awareness that River’s multi‑peer sync is supposed to provide, especially since refreshes are intentional actions when the node was offline.

This is a UI/UX refinement rather than a blocking architectural dependency—nothing else in the stack waits on it, and the synchronizer already persists the merged state regardless of how it is ornamented in the view. The notification path that triggers after with_mut returns (same file, lines 703-770) means the system already knows when messages are new; it just isn’t surfaced in the conversation pane yet.

There doesn’t appear to be an external deadline for this change, so it can be treated as medium‑priority UX work rather than a rush fix; it should land before a release that emphasises reconnection reliability, but there’s no time‑sensitive blocking.

Cost Assessment

The change will span the UI display logic plus the pieces that feed it. Conversation currently calculates its timeline from room_state.recent_messages inside message_groups (ui/src/components/conversation.rs:455), and MessageGroupComponent simply renders that sorted stream, so any notion of “new” versus “old” must either be injected into this memo or layered on top of it. The source-of-truth messages come from RoomData (ui/src/room_data.rs:33), so tracking the boundary between what the user last saw and the freshly loaded batch will require extra metadata there (similar to the existing last_read_message_id). That metadata must be set when the synchronizer merges data, so the network stack will also be touched: deltas come through RoomSynchronizer::apply_delta (ui/src/components/app/freenet_api/room_synchronizer.rs:41), while full refreshes after reconnect are handled inside handle_get_response (ui/src/components/app/freenet_api/response_handler/get_response.rs:144). Both pathways will need to flag which message IDs were present before the reconnect versus those that arrived afterward so the view can delimit them.

Delivering the suggested UX—drawing a visible separator, appending new deltas at the bottom regardless of timestamp, and clearing the marker when the user scrolls—hits some tricky technical points. MessagesV1::apply_delta currently enforces a deterministic chronological ordering (common/src/room_state/message.rs:168), so you can’t simply change the stored order without risking CRDT convergence and breaking notify_new_messages/document-title unread counts. To keep the canonical order intact while still showing new entries at the bottom, the UI will need a secondary arrival timestamp or a “new message set” derived from RoomData, and Conversation’s use_memo will have to consume that to decorate the rendered groups. This new state also has to respond to user interaction: the existing is_at_bottom hook (ui/src/components/conversation.rs:501) and last_chat_element tracking determine auto-scrolling, so you’ll need to replay those signals as part of acknowledging the separator when the user scrolls, clicks, or otherwise “reads” the incoming batch.

Because the user-visible list is directly driven by the room state, there is a palpable regression risk. Any mistake in how the separator metadata is stored or cleared could desynchronize the highlight from the actual messages that the synchronizer notifies about, causing the UI to show stale markers or to suppress real notifications (which rely on notify_new_messages being fed the delta from RoomSynchronizer). Messing with the order would also influence how edits/deletes and reactions propagate, since RoomMessageBody actions use deterministic ordering for replay. The scroll/auto-scroll logic already depends on updates to the memoized groups and the MessageGroupComponent’s onmounted hooks (ui/src/components/conversation.rs:720), so adding new UI state there introduces more paths where is_at_bottom can be mis-set and the view might not jump to (or stay at) the newest content.

Testing will need to cover both the data and the UI. On the data side, you’d want regression tests that new metadata is correctly set by both the delta (RoomSynchronizer::apply_delta) and full refresh (handle_get_response) flows, so the distinction between “old” and “new” messages survives reconnection scenarios. On the UI side, you’ll need to simulate scroll/interaction sequences to confirm that the separator/highlight appears for freshly merged messages and disappears after autoscroll or user action; that likely means exercising the Conversation component (and possibly the MessageGroupComponent’s onmounted scroll logic) in a dx serve session or a targeted integration test. Because the change touches how incoming batches are treated, it’s also worth doing a quick manual sync test to ensure notifications, document title counts, and auto-scroll behavior remain aligned with the new “new message” state.

---

Generated by issue-prioritizer