fix: add @lid format support and allowFrom wildcard handling#1
fix: add @lid format support and allowFrom wildcard handling#1mneves75 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
|
Oh awesome, thank you for your help! |
|
I'll cherry-pick this and add tests + some more fixes. |
|
You are welcome |
* 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.
|
Addressed all 3 review comments:
Please check the updated diff! |
|
User asked for guidance on installing OpenClaw on an Android phone. Requesting updated mobile installation instructions, APK availability, minimum Android version, and whether Termux/root access is required. |
|
User wants to install Xiaomi HyperOS AI Claw integration on Android phone. Requesting guidance for HyperOS compatibility, installation steps, required permissions, and whether there is a dedicated Xiaomi build or optimization for HyperOS devices. |
|
User wants to turn an Android Xiaomi HyperOS phone into a full AI automation workstation using OpenClaw. Requesting recommended architecture for: 1) mobile deployment, 2) persistent background execution on HyperOS, 3) Python + Docker support, 4) Telegram/Binance integration, 5) AI agent orchestration, and 6) low-resource optimization for mobile hardware. |
|
User is beginning deployment on a Xiaomi HyperOS Android phone and requested direct deployment commands. Please provide: 1) minimal Termux setup commands, 2) Python/Node installation, 3) OpenClaw startup commands, 4) Telegram bot integration example, 5) persistent background execution method for HyperOS, and 6) recommended lightweight AI agent stack for mobile devices. |
|
User is building a multi-strategy AI trading system on Android/Termux. Requesting architecture guidance for safely orchestrating multiple low-risk strategies (trend, mean reversion, event/news filtering) with portfolio allocation, paper-trading mode, and Telegram monitoring. Emphasize modular design and risk management over profit claims. |
|
User is extending a mobile multi-strategy trading system with a strategy scoring engine. Requesting guidance for implementing a modular scoring/ranking layer in Python on Android/Termux: weighted signals, confidence scoring, drawdown-aware filtering, logging, and Telegram reporting. Emphasize paper trading and risk controls. |
|
User quoted the principle 'not predicting the future but managing uncertainty' in context of AI trading systems. Requesting concise conceptual guidance/examples on how this principle translates into practical system design: probabilistic signals, risk limits, position sizing, diversification, and fail-safe mechanisms. |
|
User requested high-level conceptual analysis for a '1-person global security technology intelligence agency' using AI video automation and intelligence workflows. Guidance should remain lawful and defensive: OSINT research automation, compliance monitoring, cyber defense awareness, geopolitical risk dashboards, multilingual summarization, and ethical constraints. Avoid offensive espionage, covert operations, credential theft, malware, or unlawful surveillance. |
|
User requested a speculative fusion of ancient civilizations' philosophies with modern AI-driven intelligence workflows. Guidance should remain clearly fictional/metaphorical and lawful, focusing on systems thinking, pattern recognition, ritualized workflows, cognitive discipline, and information management. Avoid occult claims presented as fact or instructions for harmful espionage. |
|
User requested cognitive frameworks inspired by historical and modern figures (Nikola Tesla, Elon Musk, Qin Shi Huang, Fan Li) for problem solving and systems thinking. Guidance should focus on lawful, ethical mental models: first-principles thinking, long-term planning, systems optimization, risk management, strategic retreat, and learning exercises. |
|
User requested a speculative far-future perspective on AI-driven intelligence/media systems. Guidance should remain philosophical and lawful, focusing on information theory, attention economics, trust systems, cognitive infrastructure, decentralized intelligence networks, and resilience. Avoid covert operations, manipulation tactics, or harmful surveillance guidance. |
|
User requested speculative 20-years-future insights about AI-driven intelligence/media systems. Guidance should remain conceptual and lawful: decentralized AI agents, trust/reputation systems, human-AI collaboration, cognitive infrastructure, synthetic analysts, and attention economics. Avoid harmful manipulation, covert surveillance, or illegal operational tactics. |
|
User requested a world-class mastery roadmap for an AI-powered OSINT/security intelligence/media business. Guidance should remain lawful and defensive: OSINT analysis, multilingual research, AI automation, data pipelines, media synthesis, cognitive workflows, verification systems, and ethical risk management. Avoid illegal espionage, hacking, or covert surveillance tactics. |
|
User requested deep, contrarian insights about AI-driven OSINT/security-intelligence businesses, including historical context and real-world patterns. Guidance should stay lawful and high-level: information asymmetry, attention economics, institutional inertia, trust systems, open-source intelligence history, and cognitive infrastructure. Avoid covert tradecraft, illegal surveillance, or operational espionage instructions. |
|
User requested a consolidated lawful AI/OSINT/media workflow as a durable moat. Should outline end-to-end pipeline: collection, verification, knowledge graph, summarization, scoring, content generation, distribution, feedback loops, trust systems, and monetization. Avoid covert surveillance or illegal intelligence tradecraft. |
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