Nickname edit in a private room publishes plaintext when the room secret isn't locally available

[sanity]

Problem (pre-existing, surfaced during PR #297 review)

In ui/src/components/members/member_info_modal/nickname_field.rs, save_changes seals the edited nickname like this:

let sealed_nickname = match current_secret_opt {
    Some((secret, version)) => seal_bytes(new_value.as_bytes(), &secret, version),
    _ => SealedBytes::public(new_value.into_bytes()),
};

current_secret_opt is None both for a public room (correct — public rooms have no secret) and for a private room whose secret has not yet been decrypted locally. In the latter case the edit publishes the nickname as SealedBytes::public — plaintext — into a private room's member_info delta.

Why it matters

A private room's nicknames are supposed to be encrypted. Editing your nickname before the room secret has arrived locally leaks the plaintext nickname onto the network.

Scope

Pre-existing — not introduced by PR #297. PR #297 added a build_rejoin_delta / build_member_info_heal guard that prevents a stale Public-sealed self_member_info from being re-published into a private room, so the cached-state path is already neutralized. This issue is specifically the edit → delta path.

Fix direction

NicknameField should read room_data.is_private(). When the room is private and no secret is available, the edit must not publish a plaintext member_info — defer the member_info part of the edit (the self-heal will seal it once the secret arrives) or surface that the nickname can't be changed yet.

[AI-assisted - Claude]

[sanity]

Issue Priority Assessment

Generated: 2026-05-26T16:00:57.685353380+00:00
Issue hash: a8ce28f3

Value Assessment

The bug described in the issue is still present at line 78-81. The current_secret_opt is None for both public rooms and private rooms where the secret isn't yet available, and the code falls through to SealedBytes::public(new_value.into_bytes()) in both cases with no guard for "private room but secret not yet decrypted."

Relevance Check: This issue is still valid and unresolved. The exact code snippet from the issue description — the match current_secret_opt block with the _ => SealedBytes::public(...) fallback at line 78-81 of nickname_field.rs — is present and unchanged. No guard has been added to differentiate "public room" from "private room with unavailable secret." The room_data.is_private() check suggested in the fix direction has not been implemented.

User Impact: The impact is a privacy leak: a user in a private room who edits their nickname before the room secret has been decrypted locally will publish their chosen nickname as cleartext into the encrypted room's member_info delta. Private rooms in River are specifically designed for scenarios where member identities and nicknames are confidential — e.g., sensitive group chats. The leak is silent (no error, no warning), affects only the narrow window between joining and receiving the room secret, and is permanent (the plaintext delta gets propagated to the network). That said, it's a niche timing condition that most users would never hit under normal operation, since the room secret typically arrives quickly after joining.

Strategic Alignment: Privacy is a core value proposition of River and Freenet. A bug that leaks plaintext nicknames into a nominally encrypted room directly undermines the trust model users depend on. The fix direction is well-specified: check room_data.is_private() and either block the edit with a UI message ("Nickname can't be changed until the room secret is available") or defer publishing the delta. This is a small, targeted fix that strengthens the privacy guarantees that differentiate River from centralized chat. It aligns squarely with the project's goals.

Blocking Factor: This does not appear to block any other open work — it's an isolated bug in a single component with a clear remediation path. The related build_rejoin_delta/build_member_info_heal guard already addresses the cached-state publish path (per the issue itself), so no other in-flight PRs seem entangled with it.

Urgency: The bug is pre-existing (predates PR #297) and the severity is moderate rather than critical — it requires a user to actively edit their nickname in the narrow window before the room secret arrives, which is a rare coincidence in practice. However, it is a genuine privacy regression in a system making explicit privacy promises, and the fix is low-complexity. It should be prioritized ahead of new features but is not an emergency requiring an immediate hotfix.

Cost Assessment

The issue is still fully actionable. The code at line 78-81 is exactly as described — current_secret_opt is None for both public rooms and private rooms with no locally-available secret, and the _ arm falls through to SealedBytes::public.

The fix is narrow and self-contained. In save_changes, before constructing the delta, the code needs to check whether the room is private (i.e., room_data.room_state.configuration.configuration.privacy == RoomPrivacy::Private or via a helper like is_private()) and whether current_secret_opt is None. If both conditions hold, the function should return early rather than publishing a plaintext delta. There is already a ROOMS.try_read() block nearby (lines 93-103) that reads room_data, so the is-private check can be folded into that same read or into the existing secret resolution at lines 18-37. The RoomData::is_private() method or equivalent needs to be confirmed to exist, but the room_state.configuration path is well-established in the codebase.

Scope is a single file: nickname_field.rs. No cross-module or cross-subsystem changes are required. There are no external dependencies whatsoever — no third-party services, credentials, or organizational approvals. The fix is a guard clause, roughly 5-10 lines. Optionally, a user-facing message ("Nickname can't be changed until the room secret is available") could be shown, but even that would only touch the RSX block in the same file.

The main edge case to handle correctly is the distinction between "public room with no secret" (should publish plaintext as before) and "private room with no secret yet" (should block the edit). Getting this wrong in either direction is a regression — either you block legitimate public-room edits or you continue to leak private-room nicknames. The risk is low because the guard condition is simple and the two cases are cleanly distinguishable via the room's privacy setting. Testing effort is modest: a unit test or simulation test that constructs a private RoomData with an empty secrets map, triggers save_changes, and asserts no delta was emitted would fully cover the regression. The existing test suite for private rooms in common/tests/private_room_test.rs provides a template. Overall this is a low-cost, low-risk fix: one file, one guard clause, one new test case.

---

Generated by issue-prioritizer