Self-invite possible

[mkg20001]

Steps to reproduce:

1. create new room
2. create invitation by pressing "invite member"
3. visit invitation link, accept invitation
4. create invitation by pressing "invite member"
5. visit invitation link, accept invitation
6. ...repeat 4. & 5.

There should be some checks to prevent the user from doing this

[sanity]

Issue Priority Assessment

Generated: 2026-02-18T22:02:24.429510777+00:00
Issue hash: 5b701c0d

Value Assessment

User Impact: At the moment the invitation modal only checks whether the invitation’s generated signing key already exists in the room (ui/src/components/room_list/receive_invitation_modal.rs:274-305), so there is nothing preventing a single person from repeatedly accepting new invitation links that all target the same room. Each of those accepts runs through the normal MembersV1::apply_delta path, where deduplication only skips entries that reuse an identical member.id() but every invite in this scenario gets a fresh key, so the room happily grows a new AuthorizedMember record each time (common/src/room_state/member.rs:96-140). A bad actor can therefore fill a room with throwaway identities, and once the max_members limit is reached the deterministic pruning logic removes whoever has the longest invite chain (common/src/room_state/member.rs:237-271), potentially evicting legitimate members that were already in the room while these duplicate invites keep stacking up.

Strategic Alignment: River’s core goal is to offer privacy-preserving, invite-only chat rooms where membership is governed by invite chains and owner-defined safeguards. Allowing unlimited self-invites dilutes that control, because the invite tree becomes noisy and the owner loses leverage over which identities occupy the limited membership slots—even though MembersV1::verify already enforces that no one can forge themselves as the owner or create circular chains (common/src/room_state/member.rs:31-67), it does not address the ability to keep generating clerical aliases from a single browser session. A fix would bring the UI logic back in line with the same sort of anti-abuse thinking that went into the membership verification checks and the trimmed invite chains, so each invite link truly represents a new person rather than a shuffling of the same operator’s identities.

Blocking Factor: There is no other feature that currently depends on this behavior, and the room synchronizer will happily process invitations even while this pattern is used, so it is not blocking ongoing work. Designers and other teams can continue to build on the existing invite/ban APIs because the underlying state machine already handles banning, max-members, and invite-chain verification (common/src/room_state/member.rs:137-306), which means addressing this issue is mostly about adding a guard to the acceptance path rather than refactoring the core state logic.

Urgency: This problem has no external time pressure and does not break the protocol or prevent rooms from functioning; it only affects how consequentially an individual user can abuse the invite UI. Because it is not security critical and no milestone is skating on this behavior, it can be scheduled after higher-impact items unless there’s a concrete abuse report driving a reprioritization.

Cost Assessment

Scope-wise this touches the invitation acceptance path that currently lives almost entirely inside ui/src/components/room_list/receive_invitation_modal.rs. The modal’s render_invitation_options/check_membership_status logic at receive_invitation_modal.rs:273-305 only compares the pending invite’s target key against the room’s known members, so it never catches the case where the current identity created that invitation itself. Preventing the self-invite loop means adding a new guard there (and probably in render_new_invitation at receive_invitation_modal.rs:386-438) to detect when inv.invitee.member.invited_by equals the calling user’s own MemberId, and short-circuit the Accept button. That new guard will have to talk to the same ROOMS map that feeds check_membership_status, and we also need to ensure the PendingInvites store in ui/src/invites.rs:10-64 carries enough metadata for the synchronizer to refuse a self-generated invite even if the UI is bypassed, so the change also ripples into the room_synchronizer/response_handler path that actually talks to Freenet.

The technical complexity is moderate because invited_by is stored as a hashed MemberId (see common/src/room_state/member.rs:508-541), so the UI will have to convert the current self_sk.verifying_key() into a MemberId before comparing, and ensure the comparison is stable even if the same user switches keys mid-flow. On the backend side, RoomSynchronizer::process_rooms is already iterating PENDING_INVITES (around room_synchronizer.rs:238-308) and sending GETs for every pending owner key, so we need to inject the same self-invite guard there before PendingRoomStatus is flipped to Subscribing. That involves threading the inviter identity through the pending join information, making sure it’s available when handle_get_response is deciding whether an invitation is for a pending join, and then silently dropping/clearing self-generated invites rather than sending them into the synchronizer loop.

The main risks are accidentally blocking legitimate invitations (for example if two devices share the same room identity and one legitimately created an invite for the other) and introducing UI/async races where a self-invite gets cleared but PendingInvites’ states still show Subscribing. Any change to the PendingRoomStatus lifecycle (see the status transitions in room_synchronizer.rs:220-308) needs to keep those states in sync with the WebAPI call, so we don’t leave invitations stuck in Subscribing. We also have to be careful that we don’t break the existing restore-access path (render_restore_access_option) when the owner genuinely regenerates their key; the guard must only trigger when the logged-in key is the inviter, not when the invite targets an existing member whose inviter happens to match.

Testing will require both unit-level and integration coverage. On the UI side we can add a helper unit test around the new membership check so that render_new_invitation disables Accept when invited_by == self, alongside the existing CLI invitation flow tests in cli/tests/invitation_flow_test.rs or cli/tests/message_flow.rs to simulate issuing an invite and trying to accept it with the same identity twice. It might also make sense to add a regression test that exercises room_synchronizer::process_rooms/handle_get_response with a mocked PendingInvites entry whose authorized_member.member.invited_by matches the requester, ensuring the invite is dropped before a GET is issued. Those tests are a little heavyweight because they touch CRDT merge logic, but they already exist for normal invite handling (cli/tests/invitation_flow_test.rs); extending one of them to cover the self-invite guard will give the confidence needed without having to spin up new infrastructure.

---

Generated by issue-prioritizer