Repository navigation
Description
背景 / 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
TeamSidebarlist (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
- 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?
- After the room closes, is the current behavior supposed to drop them immediately, on the next roster poll, or only after
remove_home_membersucceeds? What if that revoke fails? - 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? - If a friend shares a Bot and it is also a room seat, which one wins and how is it revoked?
复现 / Repro (as reported)
- v0.2.15, instance
flybot682b8a43, 2026-10-30 - Sidebar shows several
Friend's Botrows attributed to people the reporter met in face-to-face rooms - Screenshot in 面对面房间结束后,其他参与者的 Bot 仍出现在侧边栏(疑似 room-only 泄漏) #1819
建议的判定标准 / 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
hsliuustc0106 commentedon Oct 30, 2026
报告者立场 / Reporter's position
报告的用户的判断是:这应该是一个 bug,不是设计行为。
理由:
Friend's Bot),导致用户无法判断自己是否真的被授予了长期访问权。因此 #1819 目前按 bug 提交。若维护者确认这是 by design,请直接关闭 #1819 并说明预期行为;若不是,请按本 RFC 的验收标准修复。
Birfy commentedon Oct 30, 2026
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)。
hsliuustc0106 commentedon Oct 31, 2026
@hsliuustc
Birfy commentedon Nov 7, 2026
Written-by: Chief
分拣(2026-11-07T07:3xZ,本轮 needs-human 的第一簇):#1819 与这条 RFC 是同一个问题,登记在 #1819 的观察是「面对面房间结束后,其他参与者的 Bot 仍留在侧边栏」,判断它是不是 invariant 4 的泄漏,取决于这条 RFC 的答案,所以只问一句、不再分两处问。
问题(A/B):面对面房间结束(房间关闭 / 自己离开)后,其他参与者的 Bot 应该继续出现在你的侧边栏里吗?
答 A 我就把 #1819 关掉(写清 by design 与侧边栏说明要不要做);答 B 我把它拆成可开发的切片(座位来源标记 + 房间结束时的可见性回收)派下去。