Repository navigation
feat(face-rooms): explicit mention list: typed lines carry target handles, receiver resolves by handle first (#293) - #294
Conversation
…dles, receiver resolves by handle first (#293) Closes #293. Sender sends Bot Social 'mentions' (feature-gated, typed lines only); receiver honours it only on typed_by_owner lines and falls back to label/name reading. Needs Birfy/bot-social#10 (merged 1870786).
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9eabd55035
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| // The sender's explicit mention list as the server delivers it (Bot Social `mentions`, #293): at most 8 | ||
| // handles, each normalised to lowercase "@handle"; anything malformed is dropped, never trusted. | ||
| const MENTION_HANDLE = /^@?[a-z0-9._-]{2,40}$/i |
There was a problem hiding this comment.
When a Bot and its home use long but supported names, their combined Bot Social handle can exceed 40 characters: slug() and homeHandleOf() each preserve up to 32 characters, while existing handle normalization permits up to 120. This regex therefore silently drops such handles on both send and receive, causing the explicit list to be omitted and the receiver to fall back to ambiguous label parsing instead of routing to the selected Bot.
Useful? React with 👍 / 👎.
Closes #293. Follow-up to #287/#288 (the sender-side explicit mention list left "not done"). Companion: Birfy/bot-social#9/#10 (merged,
1870786; not deployed).What
@names (faceMentions().handles, read against the room; coreonFaceLine(fn)now passes{ mentions }). The social plugin sends it asmentionsnext totyped_by_owner, only whenGET /v1/platformfeatureslistsmentions(same shared probe as typed_by_owner). Never on the legacy envelope, Bot lines or an older server.mentionsis read only from a line the server atteststyped_by_owner(cleanMentions, <= 8 handles).postHumanresolves the handles against the room's participants first (mentionedByHandle): only my own Bots in the list answer. A list naming nobody the room knows, or no list (older server/client), falls back to the existing label/name reading (Face-to-face: Bots should answer a plain line without @; cross-home @ labels do not resolve #287).@picker only inserts the label text (the DSH shell's trigger menu returns{text}), so the handles are derived from the picked labels at send time instead of being tracked in the composer.Tests
core:
face-mentions(handles, resolver),flybot(onFaceLine mentions, postHuman by handle vs text); social: send gated by feature/typed/Bot lines/legacy, receive honoured only on attested lines, fallback, malformed list.TZ=UTC npm run verifypasses.