design: should a member's read position be public in a room? (read receipts)

[sanity]

Question

Should a member's last-read position be visible to other people in a River room, the way Matrix and WhatsApp show read receipts? And if so, should the room owner control whether reads are public?

Raised by @sanity on 2026-07-23 alongside the jump-to-unread request (#459). Filing the analysis so the decision is recorded rather than re-litigated later.

Recommendation: keep read position private, and do not add public receipts

Five reasons, roughly in order of weight.

1. The reference class is group chat, and group chat does not do this

Read receipts are a one-to-one and small-group messenger feature. The closest analogs to River have never had them:

	Resume reading	Public receipts
Slack	Unread divider, jump to first unread, mark as unread, Catch Up	None
Discord	Red "New Messages" line, Mark As Read, unread dot separate from mention badge	None
IRC / IRCv3	The original last-read line, synced across devices (read-marker spec)	None, explicitly private-only
Matrix / Element	m.fully_read marker, jump to first unread	m.read, avatar stack
WhatsApp, iMessage, Signal, Telegram	Badge count	Yes

Every system in the top group invested in the resume-reading side instead. River is community chat, so that is the group it belongs to.

2. Matrix separates the two concepts, and deliberately keeps receipts out of persistent history

Matrix is the one system that does both, and it is worth being precise about how. m.fully_read is a private bookmark; m.read is a public receipt. They are distinct object types in the client-server API. Receipts are delivered as ephemeral data (EDUs) and never enter the room's persistent event DAG. The rationale appears in MSC2285: EDUs "have no reference point in the DAG, meaning servers won't agree on whether the EDU is authorised". High-frequency, low-stakes UI state does not justify permanent, federated, cryptographically-ordered history.

River has no ephemeral channel. Contract state is the only transport we have. So a River implementation would land in exactly the place Matrix refused to put it, and would be strictly worse along every axis: permanently stored, individually signed, replicated to every subscriber, CRDT-merged on every change, and in a public room readable by anyone holding the room key, including hosting peers who are not members of the room at all. Matrix receipts are at least scoped to member-facing homeservers.

3. The client cost lands on three axes simultaneously

PR #458 (merged 2026-07-23) fixed mobile jank traced to an O(history) use_memo re-running over the whole message list on every ROOMS mutation. Receipts in contract state would re-create that pressure from a different direction:

• State churn. Every member's read-position update is a contract state change, broadcast to all subscribers, mutating ROOMS on every client and re-running every subscribed memo. The mutation rate would scale with the number of people actively reading, which is the worst possible scaling for the pathology we just fixed.
• Viewport tracking. Publishing your own position accurately requires knowing which messages are actually on screen. River currently has one IntersectionObserver, on a bottom sentinel (ui/src/components/conversation.rs:1160-1220). Per-message observers on mobile are a real cost.
• Render. Showing who read up to a given point needs a members-by-message index rebuilt whenever any receipt changes. max_members defaults to 200 (common/src/room_state/configuration.rs).

Plus the network cost: each read update is a signed CRDT delta broadcast to every subscriber, immediately after the 0.2.105 work on update-broadcast load.

4. Owner-controlled receipts have no real precedent, and could not be enforced here

I could not find a consumer app where a specific group's creator toggles receipts for that group's members. The closest real example is Microsoft Teams, where an IT administrator sets an org-wide messaging policy to "User controlled", "On for everyone" or "Off for everyone", and users cannot override the latter two (Microsoft support). That is tenant-level and server-enforced, which is a different thing from a room owner's preference.

More importantly, River could not enforce such a flag. Room state is public and clients are user-controlled, so a modified client can publish receipts against the owner's setting, or withhold them despite it. The flag would be advisory, which is the weakest possible form for a privacy control: it looks like a guarantee and is not one.

5. The social cost is documented, and the industry response has been to add opt-outs

Survey research on read receipts (Lynden and Rasmussen, Copenhagen, n=108) reports social anxiety, senders over-checking, receivers avoiding opening messages, and roughly a third of respondents reporting feeling ignored. Every platform's response has been to add escape hatches: the Signal, WhatsApp and iMessage toggles, and Matrix's private-receipt MSC. None have added more receipts.

Worth noting that WhatsApp groups always show receipts with no per-member opt-out, and that is the specific case people complain about. Owner-mandated receipts would have the same shape.

The real gap is cross-device, and it should be solved privately

The limitation users actually hit is not that others cannot see their position. It is that they lose their own position when moving between devices.

Delegate secrets live on the node, not the device (delegates/chat-delegate/, origin-partitioned key/value store). Two devices pointed at the same gateway share the marker; two local nodes do not. So read on your phone against a local node, open your laptop against a different node, and you start over.

Matrix hit this exact problem and answered it without publishing anything: MSC2285 added m.read.private, a receipt that syncs your own unread state across your own devices and never reaches other users.

The River equivalent is the mergeable private delegate data direction @sanity floated on 2026-07-05: let delegates optionally expose a merge operation so private data folds together across a user's peers. A last-read pointer is close to an ideal pilot for that:

• The payload is a few bytes.
• The merge is "take the further position", a max over a total order, so it is a join-semilattice and trivially commutative. No conflict handling, no ordering subtleties.
• It has an obvious correctness test and a visible user benefit.

That is a much gentler first case than secrets with key and DEK reconciliation across replicas.

If we decide to build receipts anyway

Feasibility is not the constraint. MemberInfoV1 (common/src/room_state/member_info.rs) is already exactly the required pattern: each member writes a self-signed entry, one record per member, higher version wins with a signature tiebreak, entries pruned when the member is pruned, BTreeMap summaries for deterministic anti-entropy. A LastReadV1 would mirror it almost line for line. That ease is the risk, not the argument in favour.

If we do it, the constraints that follow from the above:

• Per-member opt-in, not owner-mandated. Owner-mandated is the WhatsApp-groups design that draws the complaints.
• Coarse resolution. Something like "active today" rather than a per-message position, which cuts both the churn and the social pressure.
• Off the message hot path, so a receipt update never triggers a full conversation re-render.
• Set expectations honestly in the UI: in a public room this is world-readable, not room-readable.

Caveats on the evidence

• Telegram's current small-group receipt threshold is unconfirmed. Secondary sources disagree (50 at launch, later 100), and I could not find an official statement. The 7-day expiry is confirmed.
• The "WhatsApp groups always show receipts" claim rests on secondary sources; WhatsApp's own FAQ page was not reachable during this survey.
• I have not audited how much of a private room's state River encrypts. That would change the exposure story for private rooms specifically, though not for public ones.

Related: #459 (the resume-reading feature this came from), #446, #70

[AI-assisted - Claude]

[sanity]

Issue Priority Assessment

Generated: 2026-07-24T12:39:30.904196638+00:00
Issue hash: 3053878f

Value Assessment

This confirms last_read_message_id already exists as a purely local, client-side field (used for unread-count/title purposes), with no wire-format or contract-state presence — consistent with the issue's premise that read position is currently private. Nothing in the current codebase publishes this to other members, so the issue's factual basis holds.

Now the assessment.

This is a design/policy issue, not a bug report, and the code is consistent with its premise: last_read_message_id (ui/src/room_data.rs:53) is purely local UI state used for unread counts and the document title (ui/src/components/app/document_title.rs), with no analog in common/src/room_state/ or any wire-format type — read position is not currently transmitted to the contract or other members. So the issue is factually accurate and not obsolete; it's a "should we build X" record, not a stale bug.

Impact-wise, this issue itself changes nothing for users — it's pre-emptive design documentation authored by Claude to head off future re-litigation, prompted by a tangential mention in #459 (jump-to-unread), not a user complaint or observed pain point. No one has asked for read receipts; the issue exists to record a "don't build this" decision. That makes its user impact essentially zero today, and the value is entirely in cost-avoidance: preventing a future contributor from proposing public receipts and re-deriving (or skipping) this analysis, particularly the load-bearing point that River has no ephemeral/EDU-style channel the way Matrix does, so any receipt implementation would sit permanently in signed, replicated ChatRoomStateV1, directly re-triggering the exact state-churn/re-render pathology PR #458 just fixed for the message list.

Strategically this is well-aligned in spirit (protecting privacy defaults, avoiding contract-state bloat) but is not on any roadmap and blocks nothing — no other issue or PR depends on this being decided. There's no urgency: nobody is currently implementing receipts, and the recommendation (do nothing, keep private) requires no code change to enact. The one actionable idea buried in it — a mergeable private delegate value for cross-device last-read sync — is speculative future work, not something ready to build, and per the repo's high-bar-for-prompt-changes-style caution against speculative additions, shouldn't be started without a concrete ask. Net: this is a low-priority, zero-urgency "decision record" issue worth keeping open as reference documentation, but not worth active engineering time; it could reasonably be closed as resolved-by-recommendation or converted into a pinned design note rather than tracked as actionable work.

Cost Assessment

This issue is a design memo recommending against building the feature, so its immediate "cost" is near zero — it's a decision record, not an implementation ticket. There's no code change required to close it as-is; it just needs to stay linked from #459/#446/#70 so the rejection isn't relitigated.

If the recommendation is later reversed and public receipts (or the private cross-device "last-read" merge) are actually built, cost differs sharply by which path is chosen. The private cross-device marker (the one the issue actually endorses) is the cheaper path: it needs a new delegate-side merge primitive (mergeable private data, which doesn't exist yet — delegates/chat-delegate/ currently has no join-semilattice merge concept) plus river-core support in river_core::key_derivation/chat_delegate wire types, but avoids all contract-state changes, migration entries, and public verification — no MemberInfoV1-style authorized struct, no new Summary/Delta, no WASM key change. It's a small, greenfield mechanism, moderate complexity mainly because the delegate merge concept is new infrastructure, not because the read-marker logic itself is hard.

If instead public per-member read receipts were built (the option the issue argues against), cost would be substantial and match the issue's own analysis: a new LastReadV1 sub-state mirroring common/src/room_state/member_info.rs (1444 lines, self-signed entries, version+signature tiebreak, pruning on member removal), wired into ChatRoomStateV1's ComposableState with a BTreeMap-backed Summary (per contract-summary-determinism.md), which changes the room-contract WASM and therefore requires the full delegate/room-contract migration ritual (add-migration, add-room-contract-migration, sync-wasm, republish both UI and riverctl). Client-side it would add per-message IntersectionObservers (today there's exactly one, on the bottom sentinel, ui/src/components/conversation.rs:1160-1220) and a members-by-message index rebuilt on every receipt change — real risk of reintroducing the O(history) re-render jank PR #458 just fixed, so it would need the same perf discipline (avoid use_memo over full history, respect Dioxus signal-safety rules for mutation batching). Testing would need contract state tests (signature/version/pruning), a determinism regression test for the new Summary, and Playwright coverage for render/perf on mobile.

No external dependencies (no third-party signups or approvals) either way — this is pure in-repo design/engineering cost. Given the issue explicitly recommends the low-cost path and flags the high-cost path as undesirable, the realistic near-term cost is: trivial (close/track as a decision record) unless someone overrides the recommendation.

---

Generated by issue-prioritizer