You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[RFC] Should a face-to-face room's remote seats appear in the sidebar Bot list? Clarify room-only vs granted remotes #1821
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
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_member succeeds? 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 Bot rows attributed to people the reporter met in face-to-face rooms
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)。