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
A friend's Bot renders a random per-record look: unstable on re-add, inconsistent with the no-record path, different in each home #84
The user @-mentions a friend's Bot (代码审查官, @bot-2a758c0f.danyang.home) and expects to see the look that Bot has on its own home. Instead every surface in this home — the @-mention chip, the remote message's lead avatar, the sidebar row — shows a randomly generated mascot (here: a red acorn) that has nothing to do with the Bot and would change for no visible reason.
Root cause
The friend's real look never crosses homes. Bot Social syncs only handle + display_name per member (plugins/social/src/social.js:240 register, :295list_remote_bots read-back, :314flybot.remote.publish). A stored avatar (shape/photo) and color are local roster data (core/src/host/roster.js:39cleanAvatar); there is no field for them on the wire.
The local chat record carries no look, so the client invents one from the session id.remote-chat.js:134 creates the record with neither color nor avatar; lookOf/colorOf (core/src/client/characters.js:67-75) then seed from String(bot.id) — the record's DSH session id. That seed is arbitrary.
The no-record path seeds differently.remoteSpeaker (core/src/client/cells.js:197) falls back to a synthetic bot with id remote:<handle>, so the same friend's Bot gets two unrelated generated looks depending on whether its chat record is in the roster yet.
Consequences: re-adding a friend (new session id) silently changes its look; the two homes render each other's Bots under unrelated looks even though both run the same derivation code; nothing about the look is stable except while the record lives.
Setting the look by hand already works — the friend chat's Settings → avatar editor reaches update-bot, which accepts avatar/color for remote records (only model/effort are locked, core/src/host/roster.js:216) — but the default is what reads as "broken", and nothing tells the owner that's the remedy.
Proposed fix (this repo, no server changes)
One shared identity seed for remote Bots: a remote record's generated look derives from its handle (normalized: no @, lowercased), not its session id.
characters.js: export remoteSeed(handle); colorOf/lookOf seed from it when bot.remote?.handle is set.
cells.jsremoteSpeaker: the no-record fallback bot uses the same seed string.
Properties: stable across delete/re-add; identical on every surface (record, fallback, mention chip — all funnel through lookOf); identical in both homes, since both run the same derivation over the same handle; an owner-set avatar/color still wins (stored look keeps precedence in lookOf).
Out of scope: carrying the friend side's actual look (shape/color/photo) over the wire. That needs Bot Social server support for member profile fields; tracked separately against the server once it accepts changes.
Acceptance
remoteSpeaker with and without a chat record yields the same shape and color for the same handle (currently red-on-main: the seeds differ).
Handles equal modulo @/case produce the same look.
A stored color/avatar on the record still wins over the derived default.
Tests follow fail-without-change (red on the unbroken tip).
Activity
Seed a remote Bot's default look with its handle (#84)
Merge pull request #85 from ThinkFlowLab/fix-84-remote-bot-look