feat(dm): make 1:1 private rooms the DM surface, with zero-friction creation

[sanity]

Problem

DMs are carried inside ChatRoomStateV1 (common/src/room_state/direct_messages.rs). That was the right call for #230 Phase 1, but the shape has accumulated real costs, and several open issues are all symptoms of the same root cause rather than independent bugs:

• Official room stuck at 200/200 members: the DM exemption pins members forever #519 (closed): the official room hit 200/200 members because DM participants are exempt from inactivity pruning. 129 of 181 members existed solely because of a DM. Fixed by a global cap (fix(contract): bound direct_messages globally so DM-pinned members stop growing #524), which bounds the damage without removing the coupling.
• Purge envelopes still pin members forever, so the global DM cap only half-closes #519 #525: purge envelopes still pin members forever, so the global cap only half-closes Official room stuck at 200/200 members: the DM exemption pins members forever #519. That issue already names this direction as the successor: "The intended long-term direction is moving DMs out of the room contract into dedicated per-member contracts."
• perf: DM summary carries raw 64-byte Ed25519 signatures — 19.8 KB at the DM cap (deferred half of #571) #596: DirectMessagesSummary.message_signatures carries raw 64-byte signatures, 19.8 KB at the 300-DM cap, in every room summary, recomputed and byte-compared every anti-entropy cycle. Every peer's summary advertises every DM to every member, participant or not.
• Room contract merge can exceed core's 5s execution budget on large rooms — contract stops converging network-wide #422: room-contract merge cost scales with total state, and DM ciphertext is a large and unbounded-by-content contributor to it.
• feat(dm): no way to leave/block a DM — the UI ✕ is a local archive that un-hides on the next message #461: there is no way to leave or block a DM, architecturally — you receive DMs by subscribing to the room, so there is no per-DM subscription to cancel.
• Can't read your own sent DMs on a new node (sender plaintext is device-local only) #432 / Recover historical sent-DM plaintext stranded on an old delegate (outbound_dms migration gate) #435: senders cannot read their own sent DMs, so a device-local plaintext cache exists purely to work around the ECIES-to-recipient envelope.

Two costs that are not tracked anywhere yet:

• Metadata leak by design. Every co-member sees who DMed whom. That was an accepted tradeoff of the in-room approach and is documented as such, but it is a real privacy cost.
• Size limits are unprincipled. MAX_DM_CIPHERTEXT_BYTES = 32_768 is a hard-coded protocol constant with no recorded rationale, against a default max_message_size of 1000 bytes for ordinary room messages. There is no per-room or per-relationship knob because there is no per-relationship object to hang one on.

Underlying all of it: DMs have no home of their own, so they live in a shared object and every bound has to be global.

Approach: 1:1 private rooms become the DM surface

Rather than inventing a new contract type, use the one River already has. A DM conversation is a private two-member room.

What that gets us, without new protocol:

• Principled limits. A 1:1 room has its own Configuration, so message size is owner-tunable room config. The 32 KiB constant stops mattering.
• The bloat class disappears. DM data leaves community room state entirely: no member pinning, no DM signatures in the shared summary, no DM contribution to shared-room merge cost.
• Metadata privacy. Conversations are separate contracts, so co-members no longer see who is talking to whom.
• Features for free. Edits, replies, reactions, read state, private-room encryption and secret rotation. DMs have none of these today and each would have had to be rebuilt.
• Blocking becomes possible. A conversation is a subscription you can drop, which is what feat(dm): no way to leave/block a DM — the UI ✕ is a local archive that un-hides on the next message #461 needs.

In-room DMs are not deleted. They shrink to one job: carrying the invite. That path already exists (riverctl dm invite, invite_via_dm_picker_modal.rs, DirectMessageBody::Invite). An invite is small and bounded, so the per-message cap can drop to invite-sized and the per-pair cap to a handful.

The hard requirement: zero perceived friction

Creating a room currently feels like a process, and a DM must not. If "Message someone" walks a user through room creation, this redesign has failed regardless of how clean the protocol is. The bar is: click Message, type, send.

That means:

• Room name is derived from the two nicknames. Never prompted.
• Configuration comes from a DM preset. The edit-room modal is not in the path.
• The invitation is generated and delivered automatically over the in-room DM invite carrier.
• Acceptance is automatic when the invite comes from a co-member of a room you are both in. The trust basis already exists; they can already DM you today.
• These render in the existing DM rail (dm_rail_section.rs) as conversations, never in the room list as rooms.

Blocking must be designed in from the start rather than deferred (#461), because auto-accept without a block is a spam vector.

Open design decisions

1. Creation race. If both parties click Message simultaneously, two rooms are created. Options: deterministic "lower-sorted participant key creates", or first-mover-wins with the invite carrying the room key plus a tiebreak when two exist. Leaning toward the latter.
2. Ownership asymmetry. Whoever creates the room is owner and can configure and ban. For a 1:1 conversation that is odd and should be a deliberate choice, not inherited by default.
3. Subscription budget. See below. This is the one that could sink the design.
4. History does not migrate. room_owner_vk is inside the DM signed bytes (direct_messages.rs:338-360), so existing DM signatures are only valid within their original room. Lifting history into a new contract would require re-signing with senders' keys, which is impossible. This is a hard cutover. Given the accepted position when Official room stuck at 200/200 members: the DM exemption pins members forever #519 was closed (that some DM loss is tolerable for now), that is probably acceptable, but it should be a stated decision.
5. Per-room identity. MemberId is per-room, so the same person in two rooms is two unrelated identities. A DM room started from room A is a different relationship object than one started from room B, unless we deliberately unify.

Why not per-recipient inbox contracts

This was the obvious alternative and the original #234 design. Investigation says no, as the network stands today. Recording it so it is not re-proposed without the constraints being addressed.

Derived-key discovery works fine: ContractKey::from_params is a pure offline computation, so a client can compute an inbox key from (recipient_vk, room_owner_vk) with no prior pointer. The problem is retention.

• A zero-subscriber contract is the top eviction victim. When the recipient disconnects, remove_client_from_all_subscriptions drops the count to zero and the upstream lease lapses within minutes. The inbox then sits at (0, 0, stale) in victim_order() (ring/hosting/cache.rs:808-819), which is the first eviction slot on every holder simultaneously, since they all rank it identically. A sender's PUT does reset recency (implemented, put/op_ctx_task.rs:2503-2517), but recency is compared after subscriber count, so it only breaks ties among already-abandoned contracts. There is no TTL and no durability tier: freenet-core's hosting invariants state plainly that idle zero-demand contracts are meant to evaporate.
• Subscription ceilings. MAX_SUBSCRIPTIONS_PER_CLIENT = 50 per WebSocket connection, and core's own comment puts renewal capacity at roughly 40 concurrent. River already takes about two subscriptions per room (UI and chat-delegate separately), so a user in 20 rooms is near the ceiling before any DM subscriptions exist.
• Module cache is keyed per ContractKey, not per CodeHash (runtime/pool.rs:75), so N inboxes sharing one WASM consume N module slots. Gateways are already at effectively full occupancy (freenet-core#4877).

Note that constraints 2 and 3 apply to this proposal too. Every DM conversation is another room, and River takes ~2 subscriptions per room. This is the main risk to the whole approach and needs measurement before committing: how many concurrent DM conversations can a client actually hold? If the answer is small, we need River-side subscription budgeting (lazy subscribe on thread open, unsubscribe on close) regardless of which design wins.

For reference, freenet/mail already targets cross-context DMs with strict metadata privacy. #238 reverted #234 partly on that redundancy. Nothing here changes that: this proposal covers "message someone I share a room with", not general mail.

Correcting the record on #234

The revert (#238) is often summarized as per-pair inbox contracts having failed. They did not. #234 was never deployed: no WASM artifact, no legacy_delegates.toml entry, no on-network test, and Phases 2 and 3 were never written. The stated revert reasons were redundancy with freenet/mail and a judgment that member-to-member DMs belong in room state since they need membership-chain auth anyway. There is no field evidence against the inbox design; the reasons above are the actual technical case, and they come from how core's hosting model evolved after #234.

Interim work, independent of this redesign

These stand on their own and should not wait:

• DirectMessage::ciphertext: Vec<u8> has no serde_bytes, so CBOR encodes it as an array rather than a byte string, costing roughly 1.9x on all DM ciphertext in state and in every delta. Same class as the ed25519::Signature encoding trap already documented in .claude/rules/contract-summary-determinism.md. Verified by decoding common/tests/direct_messages_wire_format.hex.
• MAX_DM_CIPHERTEXT_BYTES should come down now. Under this proposal in-room DMs become invite carriers, and invites are small. The current value has no recorded justification and is far larger than anything the role requires.
• perf: DM summary carries raw 64-byte Ed25519 signatures — 19.8 KB at the DM cap (deferred half of #571) #596 (signature digest in the DM summary) applies to whatever DM state remains and is worth doing either way.

Both the cap change and the encoding change are room-contract WASM changes, so they need the migration ritual (.claude/rules/delegate-migration.md) and a republish.

Plan

1. Interim: lower the DM ciphertext cap, add serde_bytes, land perf: DM summary carries raw 64-byte Ed25519 signatures — 19.8 KB at the DM cap (deferred half of #571) #596. One WASM migration covering all three.
2. Measure the subscription ceiling against realistic DM conversation counts. This gates everything else.
3. DM preset + auto-derived room creation, no prompts.
4. Auto-invite over the existing invite carrier, auto-accept from co-members, plus blocking.
5. DM rail renders 1:1 rooms as conversations.
6. Shrink in-room DMs to invite-only once conversations have moved.

Related: #525, #596, #461, #432, #435, #422, #519, #524, #230, #234, #238.

[AI-assisted - Claude]

[sanity]

Issue Priority Assessment

Generated: 2026-08-14T01:22:58.397612834+00:00
Issue hash: 3b0e929e

Value Assessment

Assessment

The issue is fully relevant and accurately reflects current code. MAX_DM_CIPHERTEXT_BYTES = 32_768 at common/src/room_state/direct_messages.rs:147 remains unjustified and unchanged, the ciphertext field still lacks serde_bytes treatment, and DirectMessagesSummary.message_signatures (line 1391) is still a BTreeSet<SignatureBytes> of raw 64-byte signatures rather than a digest — confirming #596 (still open) is unaddressed. All three referenced companion issues (#525, #461, #596) remain open, so none of the "interim work" this issue calls out as prerequisite has landed, and the core architectural claim — DMs living in shared room state with no per-relationship object — still holds exactly as described.

User impact is real but currently contained rather than acute: the global cap from #524 bounds the worst symptom (#519's 200/200 member exhaustion), so the network isn't actively breaking today. But the underlying costs are structural and compound with adoption — every room's anti-entropy cycle pays the DM summary tax (#596), merge cost scales with DM ciphertext (#422), and users have no way to block a harasser (#461), which is a real trust/safety gap for a chat app being positioned for real usage. This is the kind of issue where impact grows with success rather than being visible now.

Strategically this is high-value: it's a root-cause consolidation of six open issues into one coherent design, which is exactly the kind of forcing function that prevents further point-fixes from compounding tech debt. It also correctly identifies that the previous inbox-contract approach (#234) failed for reasons tied to freenet-core's current hosting/eviction model (zero-subscriber contracts are top eviction victims, subscription ceilings, per-contract module cache) — reasoning that lines up with .claude/rules/hosting-invariants.md's settled subscriber-primary eviction design, so the analysis is technically sound and not stale.

This is a design/planning issue, not urgent in the CI-blocking sense, but it is a blocking factor for the "interim work" items (cap reduction, serde_bytes, #596) since those are explicitly WASM migrations that should land together per this issue's own plan — meaning smaller companion issues are likely waiting on this one's direction being decided rather than being picked off independently. Given the scope (subscription-budget measurement is called out as possibly "sinking the design"), this needs a design decision/spike before implementation, not an immediate code fix.

Cost Assessment

Cost Assessment: Issue #610 (1:1 private rooms as DM surface)

Relevance: Fully actionable, no drift. The dependencies it names (private-room encryption/secret-rotation, member_info healing, DM invite carrier via DirectMessageBody::Invite, the DM rail) all still exist as described. This issue is itself a design doc written after real investigation (the per-recipient-inbox rejection is grounded in current victim_order() hosting code), so the approach doesn't need rethinking — but it explicitly punts several open decisions (creation-race handling, ownership asymmetry, per-room identity unification) that would need to be resolved as part of implementation, not just coding against a spec.

Scope: Large. Current DM-specific code is ~12,700 lines across common/src/room_state/direct_messages.rs (1,548 lines) + dm_body.rs, ~3,100 lines of dedicated DM tests, ui/src/components/direct_messages/ (dm_thread_modal.rs at 2,271 lines, invite_via_dm_picker_modal.rs), ui/src/components/room_list/dm_rail_section.rs (2,398 lines), and cli/src/commands/dm.rs (2,152 lines), plus touch points in chat_delegate.rs, subscription.rs, room_synchronizer.rs, member_info_modal.rs, and configuration.rs. The plan itself is staged into 6 phases (interim cap/encoding fix, subscription-ceiling measurement, DM preset, auto-invite/auto-accept, rail rewiring, in-room DM shrink) — this is not a single PR, it's an epic on the scale of the hosting-invariants redesign already tracked elsewhere in this repo.

Complexity: High, concentrated in a few spots. Private-room machinery (ECIES sealing, secret rotation, member_info heal) is reusable but has a documented history of subtle bugs (#110, #251, #295, #304) — any new DM-room bootstrap path has to correctly re-wire into all of those call sites, which is exactly the kind of thing that's silently gotten missed before in this codebase (see the "manually-mirrored telemetry counters" and "manually-inlined originator side effects" bug-prevention patterns). The genuinely new, unprecedented work is auto-accept-on-invite (private rooms today require an explicit async accept step — this issue wants zero-friction, click-type-send) plus the creation-race resolution (issue explicitly flags this as unresolved design, leaning toward first-mover-wins with a tiebreak) — both are new protocol-adjacent logic, not reuse. DM history migration is a hard, explicit one-way cutover (old DM signatures are bound to the origin room and can't be re-signed), so that part is scoped as "accept the loss," which reduces migration cost but is a product/data decision that needs explicit user sign-off, not just an engineering call.

External dependencies: None requiring third parties, but there is a real non-code gating step the issue itself calls out: step 2 of the plan is "measure the subscription ceiling against realistic DM conversation counts" against live network behavior (MAX_SUBSCRIPTIONS_PER_CLIENT = 50, ~2 subscriptions/room in River). This requires production/staging telemetry or a live multi-peer test before the design can be trusted — the issue explicitly says this "gates everything else" and "could sink the design." That's a real blocking dependency on measurement infrastructure and possibly waiting on telemetry accumulation, not just a coding task.

Risk: High for a redesign of this size — it touches contract state (WASM, requiring the full delegate/contract migration ritual per .claude/rules/delegate-migration.md), room-contract summary determinism, the DM rail (already the subject of a documented archive-timing bug class, #526), and CLI parity. Multiple WASM migrations are needed (the interim cap/encoding change alone is one; the full redesign is likely several more), each requiring the add-migration → sync-wasm → publish ritual with real risk of user data loss if mishandled.

Testing effort: Substantial. Needs new simulation/integration coverage for auto-accept race conditions, creation-race dedup, per-room identity unification (or lack thereof), and blocking — none of which have existing test scaffolding since they're new behaviors, not modifications to tested ones. The existing ~3,100 lines of DM tests would need to be significantly rewritten rather than reused, since they test in-room DM semantics that this issue proposes retiring.

Overall: This is a multi-month epic, not a single PR — best decomposed via the issue's own 6-phase plan, with phase 1 (interim cap/encoding fix + #596) being cheap and low-risk, and phase 2 (subscription-ceiling measurement) being a hard gate that should be done and evaluated before committing further engineering effort to phases 3-6.

---

Generated by issue-prioritizer

[sanity]

🤖 Automated ranking by Torvan. Not a maintainer's assessment of this issue.

Measure	Score
Value	0.797
Cost	0.997
Priority	189 of 593

Value and cost run 0 to 1 across the 593 open issues in the freenet repositories: value 1.00 is the most valuable, cost 0.00 the cheapest. Issues are compared against each other rather than scored in isolation. The queue alternates between the most valuable work and the best value for the effort, so neither expensive-but-important nor cheap-and-quick work crowds the other out.

Ranked 2026-08-31, and liable to change. Adding information here, whether that is scope, a reproduction, or a correction to this assessment, causes the issue to be reassessed and this comment updated.