fix: add @lid format support and allowFrom wildcard handling#1
Closed
mneves75 wants to merge 2 commits intoopenclaw:mainfrom
Closed
fix: add @lid format support and allowFrom wildcard handling#1mneves75 wants to merge 2 commits intoopenclaw:mainfrom
mneves75 wants to merge 2 commits intoopenclaw:mainfrom
Conversation
- Add support for WhatsApp Linked ID (@lid) format in jidToE164() - Use existing lid-mapping-*_reverse.json files for LID resolution - Fix allowFrom wildcard '*' to actually allow all senders - Maintain backward compatibility with @s.whatsapp.net format Fixes issues where: - Messages from newer WhatsApp versions are silently dropped - allowFrom: ['*'] configuration doesn't work as documented
Contributor
|
Oh awesome, thank you for your help! |
Contributor
|
I'll cherry-pick this and add tests + some more fixes. |
Contributor
Author
|
You are welcome |
steipete
pushed a commit
that referenced
this pull request
Jan 10, 2026
* fix(signal): handle reactions inside dataMessage.reaction Signal reactions can arrive in two formats: 1. envelope.reactionMessage (already handled) 2. envelope.dataMessage.reaction (now handled) The signal-cli SSE events use the second format, which was being misinterpreted as a message with attachments, leading to 'broken media / attachments' errors. Changes: - Add reaction property to SignalDataMessage type - Check both envelope.reactionMessage and dataMessage.reaction - Improve body content detection to properly identify reaction-only messages - Add test for dataMessage.reaction format * fix(signal): reaction notifications work when account is phone number When reactionNotifications mode is 'own', notifications would never fire because resolveSignalReactionTarget() returned a UUID but shouldEmitSignalReactionNotification() compared it against the account phone number, which never matched. The fix: - Add optional 'phone' field to SignalReactionTarget type - Extract phone number first in resolveSignalReactionTarget(), include it even when UUID is present - In shouldEmitSignalReactionNotification() 'own' mode, check phone match first before falling back to UUID comparison This ensures reactions to your own messages are properly detected when the Signal account is configured as a phone number and the reaction event contains both targetAuthor (phone) and targetAuthorUuid. * fix(signal): include phone in reaction target for own-mode matching When targetAuthorUuid is present, also store targetAuthor phone number in the reaction target. This allows own-mode reaction notifications to match when comparing account phone against UUID-based targets.
5 tasks
Closed
Havoc420didi
pushed a commit
to Havoc420didi/moltbot
that referenced
this pull request
Jan 28, 2026
7 tasks
|
Addressed all 3 review comments:
Please check the updated diff! |
18 tasks
|
Hey @xiaoyaner0201 @Octane0411 @Diaspar4u - if you're building plugins/extensions, we just launched OpenClawHQ to help organize the plugin ecosystem! Ship > Talk! 🦞 |
4 tasks
Closed
Open
15 tasks
4 tasks
15 tasks
1 task
|
test comment from bot |
18 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
13 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR fixes two critical bugs that prevent the web relay from processing inbound messages on newer WhatsApp versions:
LID format not recognized: WhatsApp now uses Linked ID (
@lid) format for message senders instead of the traditional@s.whatsapp.netformat. The currentjidToE164()function silently drops these messages.Wildcard
"*"in allowFrom doesn't work: TheallowFrom: ["*"]configuration is documented to allow all senders, but the code performs an exact string match, so"*"never matches any phone number.Bug 1: LID Format Not Supported
Problem
WhatsApp has transitioned to using Linked IDs (LID) for identifying users in newer API versions. Messages now arrive with JIDs in the format:
Instead of the traditional format:
The current
jidToE164()function insrc/utils.tsonly matches the@s.whatsapp.netformat, causing all inbound messages from@lidJIDs to be silently dropped.Solution
Updated
jidToE164()to check for@lidformat and use the existing reverse mapping files that warelay already creates in~/.warelay/credentials/lid-mapping-*_reverse.json.Bug 2: allowFrom Wildcard Not Working
Problem
The
allowFromconfiguration is documented to support"*"as a wildcard to allow messages from all senders. However, the implementation performs an exact string match:When
allowFrom: ["*"]is configured, the check fails because"+556183297558"is not literally in["*"].Solution
Added a check for the wildcard before performing the exact match:
Testing
@lidJIDs are now correctly resolved to E.164 phone numbersallowFrom: ["*"]now correctly allows all senders@s.whatsapp.netJIDs and explicit phone number lists continue to workFiles Changed
src/utils.ts@lidformat support tojidToE164()src/auto-reply/reply.tsallowFromvalidationBreaking Changes
None. These changes are backward compatible.
Environment