Repository navigation
Seed a remote Bot's default look with its handle (#84) - #85
Conversation
|
CI note: the |
A friend's Bot had no look of its own in this home: the chat record is created without color or avatar, so the client derived one from the record's session id — arbitrary per record, different from the no-record fallback in remoteSpeaker (which seeds remote:<handle>), changed by a delete/re-add, and unrelated between the two homes. Derive the default from the handle instead (normalized: no @, lower case) through one shared remoteSeed helper used by colorOf/lookOf and the remoteSpeaker fallback. One stable look per friend's Bot on every surface and in both homes; a color or avatar the owner sets on the record still wins. Carrying the friend side's real look over the wire needs Bot Social member-profile fields and stays out of scope (#84). Tests fail-without-change: the record-vs-fallback equality and the @/case normalization tests were red on the unfixed tip.
6fb41ef to
ccebfd3
Compare
|
Rebased onto |
Closes #84.
Problem
A friend's Bot (e.g. 代码审查官
@bot-2a758c0f.danyang.home) rendered with a randomly generated mascot: the chat record is created with no look (remote-chat.js), solookOf/colorOfseeded from the record's session id. That seed was arbitrary (per record), different fromremoteSpeaker's no-record fallback (remote:<handle>), changed on delete/re-add, and unrelated between the two homes.Fix
One shared seed: a remote Bot's generated look derives from its handle (normalized: no
@, lowercased), not its session id.characters.js: newremoteSeed(handle);lookSeed(bot)picks the handle for remote records, else the id.colorOf/lookOfseed from it.cells.jsremoteSpeaker: the no-record fallback bot uses the same seed string, so the record and fallback renders agree.mark.jsre-exportsremoteSeed.Every consumer (sidebar, header, message leads, @-mention chips, the mention CSS in
index.js) funnels throughlookOf, so one handle now yields one look everywhere — stable across re-add and identical in the friend's home, which runs the same derivation. Acolor/avatarthe owner sets on the record (friend chat → Settings → avatar editor;update-botalready accepts it for remote records) still wins.Out of scope (noted in the issue): carrying the friend side's actual look over the wire — that needs Bot Social server support for member profile fields.
Verification
Fail-without-change: the two new tests in
inbound-ui.test.js(record-vs-fallback look equality;@/case normalization + stored-look precedence) were red on the unfixed tip (e53bb70-tree, before commit), green after.Tip SHA:
6fb41ef3eaba6bba47138b4d74a68f88d665a02bRan at that tip:
npm test— 621 pass, 0 failnode scripts/build-client.mjs --check— client.js matches src/clientnode scripts/ds-bot-patches.mjs generate && check— 10 patches apply cleanly; core == ds-bot + patchesnpm run lint— 0 errors; 21 warnings, same count asmain(the one in a touched file,mark.js:71, is on a pre-existing line this PR does not modify); arch-docs OK (ds-bot-core.md invariant 9 added)Not run: smoke test (no
index.js/src/host/change), Desktop app, a real two-home check against Bot Social.