Room with Unknown and corrupt member

[Ivvvor]

I created a test room and invited myself to the room from another node instance. The invite was accepted but the member name came up as 'Unknown'. The user can send messages but if the user's name is selected in the active members list an error used to come up, 'Member information is missing or corrupted' but this no longer happens. Now the username is just unselectable.

[sanity]

Issue Priority Assessment

Generated: 2026-03-12T22:32:46.978438891+00:00
Issue hash: 4e9f292a

Value Assessment

The UI still treats a missing AuthorizedMemberInfo as “Unknown” and even surfaces an error page when you try to open the modal, so the exact failure the issue describes still exists. In ui/src/components/members.rs:199 the member list only falls back to "Unknown" when it can’t find or decrypt a nickname, and ui/src/components/members/member_info_modal.rs:61 still aborts with “Member information is missing or corrupted” whenever that lookup fails. Nothing in the surrounding code prevents the modal from showing, so the old error (or no click target at all if the event is never fired) can still surface whenever the contract state lacks a matching member_info. At the state level, ChatRoomStateV1::post_apply_cleanup clips member_info entries down to the authors and their invite chains (common/src/room_state.rs:85), which means any peer that never posted or whose entry was never re-added can easily end up with no nickname data at all. There’s no guard in the contract or delegate that re-populates that data for “remote” nodes, so the broken flow is still live.

Because an invited member shows up without an identifiable nickname and their info can’t be inspected, the room owner (or any peer who wants to ban/mute/investigate) loses critical context. The MemberList and MemberInfoModal UI are the only places that expose inviter chains, nicknames, updates, and ban buttons, so when a cross-node invite ends up in this state those controls are unusable. That undermines the decentralization goal of River, because part of the core experience is to tell who is in your room and enforce policies without relying on a single node’s data; when multi-node invites leave entries dangling as “Unknown,” the UI can’t even show who invited them or what their nickname should be, which is a credibility hit for the project’s core chat/identity story.

This bug doesn’t currently block any other feature—the room still works, messaging works, and the owner can continue normal work—but it does interfere with cross-node onboarding flows that the project explicitly supports, and it leaves a puzzling error message (or an unclickable entry) in the UI whenever you import from another node. There’s no deadline tied to it, but it would be good to resolve this sooner rather than later so that every node in the network can see accurate membership metadata and the ban/inspect tooling remains reliable during collaborative testing.

Cost Assessment

The behavior described in Issue #139 still shows up in the current code: MemberList builds its names solely from room_state.member_info, falling back to the literal “Unknown” whenever an entry is absent or can’t be decrypted (ui/src/components/members.rs:186-210), and MemberInfoModal explicitly rejects clicks when it cannot find an AuthorizedMemberInfo for the selected member (ui/src/components/members/member_info_modal.rs:58-76). Nothing in the recent codebase auto-populates the missing member info for an invitee, so the UI still renders an “Unknown” entry that either shows an error or can’t be opened, exactly as the issue describes.

Fixing this will touch several moving parts. The GET handler for invitations currently saves the freshly signed nickname in room_data.self_member_info but never writes it into the shared ChatRoomStateV1 (ui/src/components/app/freenet_api/response_handler/get_response.rs:158-238), so remote peers never learn the new nickname. The only place member_info gets published is inside the send-message path, and even there member_info_delta is only included when the sender is being re-added (ui/src/components/conversation.rs:1015-1097). Addressing the issue therefore likely requires updating the GET response flow to emit a small delta that publishes the invitee’s MemberInfo (and possibly accompanying MembersDelta if the member wasn’t already in the state), or else extending the message-send path so it always syncs the latest self_member_info when an entry is missing. That means touching response_handler/get_response.rs, conversation.rs, and possibly room_data.rs (the place that captures self_member_info at ui/src/room_data.rs:254-306), so at least three subsystems must coordinate CRDT merges, signature verification, and secret handling.

There is moderate technical complexity here because any delta that introduces a member info record must be signed by the member (not the owner), respect the private-room sealing logic, and avoid triggering the very pruning that caused the member to rejoin. The NicknameField component already encrypts, signs, and applies such deltas (ui/src/components/members/member_info_modal/nickname_field.rs:33-150), so any new code path must reuse that pattern to ensure member_info.member_id, version, and signature stay valid; missteps could cause the contract’s verify() to reject the state. Testing therefore cannot be purely unit-level: the scenario requires spinning up two nodes (local mode or e2e) so you can invite a new node, accept the invite, and confirm that the member list and modal now show the nickname instead of “Unknown”. You’d also want to re-run cargo make test/cargo make test-room-contract because the change touches state merge logic.

There are no external dependencies beyond the existing build/test workflow—no certificates or third-party approvals are needed—but the change carries some risk. Publishing a new member_info delta on join could accidentally reintroduce unauthorized data if the wrong key is used, and it must preserve backwards compatibility with the contract’s verify/merge logic (common/src/room_state/member_info.rs enforces that the signature must come from the member’s verifying key). To mitigate that risk, the change should tread carefully around the existing AuthorizedMemberInfo creation path and the apply_delta/merge invocation, and the new behavior should be covered by the same tests or a small integration test that exercises invite acceptance plus nickname resolution.

---

Generated by issue-prioritizer