Can't read your own sent DMs on a new node (sender plaintext is device-local only)

[sanity]

Report

From Ivvor: "you can't read your own sent DMs any more on the new node." Received DMs are fine; the user's OWN sent DMs render as sent — ciphertext only. Also observed: some sent DMs visible, others missing.

Root cause

An in-room DM (common/src/room_state/direct_messages.rs) is stored as ECIES ciphertext encrypted only to the recipient's member_vk. The sender cannot decrypt their own sent DM from contract state. The sender's plaintext is kept in a device-local chat-delegate cache (outbound_dms, #256) that never travels the network.

So a sent DM is readable only on the node whose local cache holds its plaintext:

• Sent from this node → cached here → readable.
• Sent from another node, or before a delegate-key change stranded the cache (the migration gate only probes outbound_dms when the current delegate has no rooms) → plaintext absent → placeholder.

This is a design limitation of the local-only cache, not a regression from a specific PR. Recent delegate-key churn (#394, #411, #416) turned existing caches "legacy" and made it surface.

Fix

Seal a second ECIES envelope of each DM body to the sender's own key, carried in the message (DirectMessage.sender_ciphertext), so any device with the sender's signing key reads its own sent DMs from contract state — like received DMs already work. Forward-looking (does not recover DMs sent before the change). Room-contract + chat-delegate wire change → both re-key (migration).

[AI-assisted - Claude]

[sanity]

Issue Priority Assessment

Generated: 2026-07-29T16:13:28.768857572+00:00
Issue hash: 59d944f0

Value Assessment

Confirms the issue is still unresolved on main: sender_ciphertext doesn't exist in common/src/room_state/direct_messages.rs, and the fix branch (worktree-feat-portable-sent-dms, head e785c9bc) remains unmerged since PR #433 was closed rather than landed.

Relevance: Fully relevant and unfixed. The root cause described — DMs sealed only to the recipient's member_vk, sender relying on a device-local outbound_dms cache that never syncs across devices/nodes — is still exactly how direct_messages.rs and the chat-delegate cache work today. A complete, tested fix already exists on the unmerged branch; this is a "finish the landing," not a "design it" problem.

User impact: Moderate-to-high for anyone who uses River across more than one device/node, or who has had a delegate-key change (which #394/#411/#416 made common). Symptom is confusing and looks like data loss — a user's own sent messages show as sent — ciphertext only — even though the room itself is functioning correctly. Received DMs are unaffected, so this is specifically an own-sent-message UX/trust issue, not a functional/security break.

Strategic alignment: DMs are a core River feature, and "your own messages disappear on your other device" undercuts confidence in the whole encrypted-messaging story. Fixing it also forces cleanup of a real CI gap the branch identified — direct_messages_test.rs not running in CI — which is valuable independent of this issue.

Blocking factor / urgency: Not blocking other work, and not an emergency (no data corruption, only a UX gap, and it's forward-looking-only even once fixed — old DMs stay unrecoverable). But the fix is already built and reviewed-in-spirit (closing comment on #433 explains why it wasn't merged, worth reading before restarting); the main cost now is coordinating the delegate/contract re-key and republish, not designing anything new. Given the wire-format change requires a migration anyway, bundling it with the next planned WASM-changing release (rather than a rushed solo deploy) is the sensible path — moderate priority, low urgency, cheap to execute since the hard design work is done.

Cost Assessment

Cost assessment: issue #432

Relevance / rework: Fully actionable, and unusually low-risk to pick up because the hard design work is already done and merged conceptually reviewed — a complete, Full-tier-reviewed implementation exists on branch worktree-feat-portable-sent-dms (head e785c9bc). Confirmed sender_ciphertext is not present on current main (direct_messages.rs has no such field), so the branch's diff is still needed, not obsolete. It will need a rebase onto current main (base was 2026-07-21; several PRs since — #494, #517, #518, #520, #521), a redo of two version bumps (riverctl/river-core, since riverctl has moved to 0.2.5 with its own release train), and regenerating the migration-registry hashes via sync-wasm so legacy_delegates.toml / common/legacy_room_contracts.toml carry current pre-change hashes. This is mechanical rebase work, not a redesign.

Scope: Touches common/src/room_state/direct_messages.rs (wire struct + verify + apply_delta), the ECIES sealing helpers, ui/src/components/direct_messages/dm_thread_modal.rs (render fallback to sender copy), cli/src/commands/dm.rs (dm list), plus the delegate/contract migration files and version bumps in cli/Cargo.toml/common/Cargo.toml. Contained to the DM subsystem; no cross-cutting changes.

Complexity: Moderate-to-high because it's a signed wire-format change to a live contract (room-contract + chat-delegate both re-key). The tricky part — backwards-compatible field placement, signing only-when-Some so legacy messages still verify, size-capping in both verify and apply_delta — was already solved and reviewed per the closing comment's detailed writeup, so re-implementation risk is low; the remaining complexity is mostly the migration/deploy choreography (delegate migration ritual + coordinated UI republish + riverctl release), which is process-heavy per this repo's river-publish.md/delegate-migration.md rules.

External dependencies: This is the real bottleneck. It's explicitly "a coordinated deploy, not a merge" — requires the maintainer to drive cargo make publish-river (shared Freenet contract key, must be from main), a riverctl crates.io/GitHub release via tag, and running the standard delegate-migration checklist. It's forward-only (can't recover DMs sent before the change), so no data-recovery dependency, but the deploy itself needs a human decision point per publish-from-main.md and no-merge-with-red-ci.md.

Risk: Low for regression given the wire-format snapshot test (direct_messages_wire_format.hex) proved byte-identical serialization for legacy messages, and the review already caught and fixed two real UI bugs (outbound invite self-copies rendering as Accept cards, wrong "you have an invitation" tip). Main residual risk is deploy-sequencing (migration/version-bump mistakes), which is exactly what the checklists in this repo guard against.

Testing effort: Largely already built — signature back-compat, strip/graft rejection, size caps, round-trip tests (sender reads own, recipient reads, third party reads neither, legacy still errs on open_own), plus 4 new river-ui unit tests for the render fallback. Also worth folding in the flagged CI gap (common/tests/direct_messages_test.rs not running in CI) as part of this PR since it's the surface being changed.

Bottom line: Low-to-moderate cost — a rebase + review-refresh + coordinated deploy of already-built, already-reviewed code, not new design or implementation work. The dominant cost is the deploy coordination (migration + republish + riverctl release), not the code itself.

---

Generated by issue-prioritizer

[sanity]

State of play (2026-07-27)

A full implementation of the sender-copy approach exists and works; it is not merged. PR #433 was closed rather than landed — the reasoning is in its closing comment, and the code is on branch worktree-feat-portable-sent-dms (head e785c9bc), which has not been deleted.

Approach that was built and tested: compose_direct_message seals a second ECIES envelope of the same body to the sender's own member_vk, carried in a new DirectMessage.sender_ciphertext: Option<Vec<u8>>. Any device holding the sender's signing key then recovers its own sent DMs from contract state, the same way received DMs already work, instead of depending on the device-local outbound_dms cache that never travels the network.

Why a separate field rather than folding it into the existing envelope: unseal_dm_from_sender consumes everything after byte 44 as AES-GCM ciphertext, so appending a second envelope inside ciphertext would break every existing recipient. A separate, signature-covered field is the only backwards-compatible carrier.

The back-compat details that took the most care, and that a re-implementation should keep:

• Option + #[serde(default, skip_serializing_if = "Option::is_none")], placed last, so a pre-change message serialises byte-identically and old state still decodes and re-PUTs.
• The field is appended to build_direct_message_signed_bytes only when Some — so a legacy (None) message signs over the exact pre-change bytes and still verifies, while the sender copy cannot be stripped or grafted without invalidating the signature.
• Size-capped to MAX_DM_CIPHERTEXT_BYTES in both verify and apply_delta.

Known limits of that approach: it is forward-looking only. It recovers DMs sent after it ships, on any device; it does not resurrect DMs sent before it, which carry no sender copy. Recovering those on the same node is a different fix — the migration gate only probes outbound_dms when the current delegate has no rooms, which is what strands the cache after a delegate-key change.

What landing it costs: the field changes ChatRoomStateV1, so both the room-contract and the chat-delegate WASM re-key. That means a delegate migration plus a UI republish plus a riverctl release — a coordinated deploy, not just a merge.

Worth splitting out first, independently of this issue: common/tests/direct_messages_test.rs does not run in CI today (only --lib and specific --test targets do), so the whole DM verify / apply_delta / compose surface is ungated. The branch adds a build.yml step running it with --features ecies-randomized. That is a CI hole right now whether or not the sender copy ever lands.

[AI-assisted - Claude]