feat: implement unified_session telemetry in ib stanzas#1057
feat: implement unified_session telemetry in ib stanzas#1057RafaelFernandesMotta wants to merge 12 commits into
Conversation
new features
|
sounds good |
purpshell
left a comment
There was a problem hiding this comment.
Didn't this request some sort of time skew from the server each time?
Might've gotten stored in localStorage
|
You're absolutely right. The JS function t() indeed uses Date.now() + WATimeUtils.getClockSkew(). In the current whatsmeow implementation, I couldn't find a publicly exported ServerTimeOffset. Should I use time.Now().UnixMilli() for now, or would you prefer that I expose the internal clock skew (calculated during handshake) to use it here? From my tests, the web client seems to store this skew in memory/localStorage to keep the unified_session ID in sync with the server's window I've analyzed the WATimeUtils module and confirmed that it uses a clock skew variable w (set via setClockSkew). Functions like unixTimeMs() calculate the timestamp as Date.now() - (w * 1000). Since whatsmeow calculates the server's time during the connection but doesn't seem to export it as a simple field like ServerTimeOffset, I'm currently using time.Now().UnixMilli(). Below is part of the original code.
|
|
Implement the time skew by actually getting the data from the server, make that part of the PR. |
…ation - Added serverTimeOffset to Client struct using atomic.Int64 for thread-safe access. - Implemented server time skew calculation by extracting the t attribute from the connection success node . - Integrated sendUnifiedSession into the pairing and connection flow - Ensured session ID generation matches official WhatsApp Web logic: (sync_time + 3 days) % 7 days
|
Done. I've implemented the server time skew synchronization by extracting the t attribute from the success node and storing it in an atomic.Int64 field. The unified_session ID now uses this offset to match the official client behavior |
purpshell
left a comment
There was a problem hiding this comment.
This should fix random "Syncing device" notifications on the main device as well. Testing needed ofc.
|
I deployed this branch to my production environment (I have 2k phones connected) yesterday and didn’t run into any issues. I’m not sure if it’s related, but before that some numbers were getting banned just by connecting to the application. After the deployment, I ran a few tests with completely fresh numbers and didn’t get any bans. Does anyone know if this could be related? |
Implements WhatsApp's unified_session telemetry feature to reduce detection of unofficial clients. This is an enterprise-grade implementation inspired by whatsmeow PR WhiskeySockets#1057 and Baileys PR WhiskeySockets#2294. Features: - UnifiedSessionManager class with circuit breaker protection - Server time synchronization for accurate session IDs - Rate limiting to prevent spam (1 minute between sends) - Prometheus metrics integration (unified_session_sent, errors) - Structured logging for debugging - Configurable via SocketConfig.enableUnifiedSession - Environment variable support (BAILEYS_UNIFIED_SESSION_ENABLED) Trigger points (matching official WhatsApp Web): - After successful login (CB:success) - After successful pairing (CB:iq,,pair-success) - When sending 'available' presence Implementation details: - Session ID algorithm: (now + serverOffset + 3days) % 7days - Time constants exported from Defaults/index.ts - Full test coverage (31 tests) References: - tulir/whatsmeow#1057 - WhiskeySockets#2294 - tulir/whatsmeow#810
Closes tulir#1057 (cherry picked from commit 8e7b838)
This PR implements the unified_session telemetry node sent via ib stanzas, which was observed in recent WhatsApp Web traffic.
Official clients send this time-based identifier to maintain session continuity and for fingerprinting. It is calculated based on the current timestamp with a specific offset and window: (now_ms + 3 days) % 7 days.
Adding this helps whatsmeow stay under the radar by reducing the differences in the connection handshake and activity heartbeat compared to a real browser.
Changes