Skip to content

[RFC] Should a face-to-face room's remote seats appear in the sidebar Bot list? Clarify room-only vs granted remotes #1821

Open

Description

@hsliuustc0106

背景 / Background

Reported in #1819: after a Face-to-face room, other participants' Bots stay in the owner's sidebar as Friend's Bot. The reporter is not sure whether those Bots were shared with them personally (a Bot Social grant) or only seated through the room (room-only identity). Both look identical in the sidebar.

A related face-to-face bug was filed today (#1764, rename refused because updateRoom runs the two-Bot check on a name-only patch).

文档里的规则 / What the docs say

docs/subsystems/social.md invariant 4:

When that Bot leaves its last face room or the room closes, the plugin revokes the room-only identity (remove_home_member) and drops room-scoped remotes from Friends' Bots.

and:

Live face-to-face rooms and friends' Bots sit in the core TeamSidebar list (globe / people mark), not a second Friends' Bots section.

So a granted friend's Bot in the sidebar is intended; a room-only remote surviving its room is not. What is not documented is how a person tells the two apart, and whether a room-only Bot should appear in the sidebar while the room is open.

需要确认的问题 / Open questions

  1. While a face-to-face room is open, should that room's remote seats (friends' Bots that joined only for this room) appear in my sidebar Bot list at all — or only inside the room?
  2. After the room closes, is the current behavior supposed to drop them immediately, on the next roster poll, or only after remove_home_member succeeds? What if that revoke fails?
  3. Identical presentation: both kinds render as Friend's Bot + globe. Should a room-only remote be visually distinguished (e.g. "In this room only") or hidden from the sidebar entirely?
  4. If a friend shares a Bot and it is also a room seat, which one wins and how is it revoked?

复现 / Repro (as reported)

建议的判定标准 / Proposed acceptance criteria

  • Room-only remote: visible only while the room is open (and inside the room), never in the global Bot list after leave/close
  • Granted friend's Bot: visible, revocable from People with access
  • A test that opens a face room with one remote seat, closes it, and asserts the sidebar no longer lists that Bot (and that a genuinely granted Bot survives the same flow)

Please confirm the intended behavior so #1819 can be triaged as a bug or closed as by design.

Activity

  1. hsliuustc0106 commented on Oct 30, 2026

    @hsliuustc0106
    ContributorAuthor

    报告者立场 / Reporter's position

    报告的用户的判断是:这应该是一个 bug,不是设计行为。

    理由:

    • 这些 Bot 是面对面建群/参会时才接触到的,对方并没有在 Bot 设置里共享给自己;
    • 如果只是房间座位,按 invariant 4 就应当在离开/关闭房间后从 Friends' Bots 和侧边栏消失;
    • 两种授权在 UI 上完全无法区分(都显示 Friend's Bot),导致用户无法判断自己是否真的被授予了长期访问权。

    因此 #1819 目前按 bug 提交。若维护者确认这是 by design,请直接关闭 #1819 并说明预期行为;若不是,请按本 RFC 的验收标准修复。

  2. Birfy commented on Oct 30, 2026

    @Birfy
    Collaborator

    Written-by: Triage

    判定:先挂着(H) — 这是 RFC 设计问题,卡在 promote 判据 1:两条都要所有者定,代码里没有可引用的已定决定/RFC/已合 PR。
    ① 面对面房间的远端座位(room-only)该不该出现在侧栏 Bot 列表;
    ② 若该出现,room-only 与「好友已共享」在 UI 上怎么区分(标识 / 隐藏入口 / 不展示)。
    docs/subsystems/social.md 只说不变量 4 会撤销 room-only 身份,没有回答这两个问题,所以这不是能直接写死的行为。

    缺什么:所有者对 ① 的裁定;若 ① = 该出现,再对 ② 的呈现方式给一句方向。裁定写成本 issue 的评论(或 decisions/ 记录),#1819 与本 RFC 一起收口。
    谁能给:所有者(Danyang / Birfy)。

  3. added
    needs-humanThe agent loop stopped; a person must decide (reason in the last comment)
    on Oct 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:socialFriends, invites, grants, Bot Socialneeds-humanThe agent loop stopped; a person must decide (reason in the last comment)questionFurther information is requested

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions