whalibmob 5.17.0 → 5.18.0

package/lib/Client.js

@@ -3433,6 +3433,19 @@ class WhalibmobClient extends EventEmitter {
       const isLid     = fromJid.endsWith('@lid');
       const mappedPn  = isLid && this._lidToPn ? this._lidToPn.get(fromUser) : null;
       const fromPhone = isLid ? mappedPn : fromUser;
+      // Before throwing the cache away: the notification says what changed and
+      // carries the hash of the list it should produce. Apply it, check the
+      // hash, and if it matches there is nothing to invalidate and nothing to
+      // ask usync about — see DeviceManager.verifyDeviceDelta().
+      if (fromPhone && this._devMgr) {
+        const delta = this._parseDeviceDelta(node);
+        if (delta && this._devMgr.verifyDeviceDelta(fromPhone, delta.changes, delta.hash)) {
+          _whaDbg('[DBG] NOTIF_DEVICES delta verified for ' + fromPhone +
+            ' — cache kept, no usync needed');
+          return;
+        }
+      }
+
       if (fromUser && this._devMgr) {
         this._devMgr._dcDel(isLid ? [fromUser, 'lid:' + fromUser] : [fromUser]);
         if (mappedPn) this._devMgr._dcDel([mappedPn]);
@@ -3484,6 +3497,54 @@ class WhalibmobClient extends EventEmitter {
     }
   }
 
+  /**
+   * Read a `devices` notification as a change plus the hash it should produce.
+   *
+   *   <notification type="devices" from="…">
+   *     <add device_hash="2:…"><device jid="40711111111:3@s.whatsapp.net"/></add>
+   *   </notification>
+   *
+   * Children are `add`, `remove`, or `update`. Only the first two say something
+   * that can be applied; `update` does not name what it changed, so it is
+   * treated as unreadable here and the caller falls back to invalidating.
+   *
+   * All children must agree on the hash — the server sends one per child, and a
+   * notification carrying two different ones is describing intermediate states
+   * this cannot reconstruct.
+   *
+   * @returns {{changes: Array<{tag, deviceId}>, hash: string}|null}
+   */
+  _parseDeviceDelta(node) {
+    if (!node || !Array.isArray(node.content)) return null;
+
+    const changes = [];
+    let hash = null;
+
+    for (const child of node.content) {
+      if (!child || !child.description) continue;
+      const tag = child.description;
+      if (tag !== 'add' && tag !== 'remove') return null;   // 'update' and friends
+
+      const childHash = child.attrs && child.attrs.device_hash;
+      if (!childHash) return null;
+      if (hash === null) hash = String(childHash);
+      else if (hash !== String(childHash)) return null;     // disagreeing children
+
+      const deviceNode = findChild(child, 'device');
+      const jid = deviceNode && deviceNode.attrs && deviceNode.attrs.jid;
+      if (!jid) return null;
+
+      const raw    = String(jid).split('@')[0];
+      const colon  = raw.indexOf(':');
+      const device = colon >= 0 ? parseInt(raw.slice(colon + 1), 10) : 0;
+      if (!Number.isFinite(device)) return null;
+
+      changes.push({ tag, deviceId: device });
+    }
+
+    return changes.length && hash ? { changes, hash } : null;
+  }
+
   _processDeviceUpdate(devicesNode) {
     // Called from _handleNotification(type='account_sync') and type='devices'.
     // Rebuilds the device cache for the affected phones from the server-provided list.

package/lib/DeviceManager.js

@@ -1178,6 +1178,78 @@ class DeviceManager {
   }
 
   // ─── Invalidate cached device list (used on phash mismatch / 421 retry) ───
+  /**
+   * Apply a device-list change and check the result against the server's own
+   * hash of what the list should now be.
+   *
+   * A `devices` notification says what changed — one device added, one removed —
+   * and carries `device_hash`, the participant hash of the list the server
+   * believes we should end up with. That hash is the thing worth having: it
+   * turns "I applied the change, probably correctly" into something checkable.
+   *
+   * So the change is applied to the cached list, the hash of the result is
+   * computed, and the two are compared. Equal, and the cache is provably right
+   * and is kept. Different, and the cache is wrong in some way this side cannot
+   * see, so it is thrown away and the next send asks usync for the whole list.
+   *
+   * That second branch is exactly what this did for every notification before —
+   * drop everything, ask again. Which is safe, and costs a round trip each time
+   * somebody opens WhatsApp Web. This keeps the cache when it can prove it is
+   * right, and falls back to the old behaviour when it cannot.
+   *
+   * Safe by construction: if this hash were computed differently from the
+   * server's, nothing would ever match and every notification would take the
+   * fallback — which is where it started.
+   *
+   * @param   {string} phone        digits, the cache key
+   * @param   {Array<{tag: string, deviceId: number}>} changes
+   * @param   {string} serverHash   the notification's device_hash
+   * @returns {boolean} whether the result verified and the cache was kept
+   */
+  verifyDeviceDelta(phone, changes, serverHash) {
+    if (!phone || !serverHash || !Array.isArray(changes) || !changes.length) return false;
+
+    // No baseline means there is nothing to apply a change to. Caching just the
+    // one device named in the notification would make a list of one look
+    // authoritative, which is how a recipient's other devices stop being
+    // written to.
+    const cached = this._dcGet(phone);
+    if (!cached || !cached.length) return false;
+
+    const next = new Set(cached);
+    for (const { tag, deviceId } of changes) {
+      if (!Number.isFinite(deviceId)) return false;
+      if (tag === 'add')         next.add(deviceId);
+      else if (tag === 'remove') next.delete(deviceId);
+      else return false;   // 'update' and anything unknown: do not guess
+    }
+
+    const ids  = [...next].sort((a, b) => a - b);
+    const jids = ids.map(d => makeDeviceJid(phone, d));
+
+    let ours;
+    try {
+      // Lazily required: MessageSender requires this file, so taking it at the
+      // top would close the cycle before either module finishes loading.
+      const { computePhash } = require('./messages/MessageSender');
+      ours = computePhash(jids);
+    } catch (_) {
+      return false;
+    }
+
+    if (ours !== String(serverHash)) {
+      _whaDbg('[DBG] DEV_HASH mismatch for ' + phone + ' ours=' + ours +
+        ' server=' + serverHash + ' — dropping cache');
+      this._dcDel([phone]);
+      return false;
+    }
+
+    this._dcSet(phone, ids);
+    _whaDbg('[DBG] DEV_HASH verified for ' + phone + ' ids=[' + ids.join(',') +
+      '] hash=' + ours);
+    return true;
+  }
+
   clearCache(phones) {
     if (!phones || phones.length === 0) {
       this._dcFlush();
@@ -1187,10 +1259,13 @@ class DeviceManager {
   }
 
   // ─── Build participants node ───────────────────────────────────────────────
-  static buildParticipantsNode(encryptedList, mediaSubtype) {
+  static buildParticipantsNode(encryptedList, mediaSubtype, decryptFail) {
     const toNodes = encryptedList.map(({ jid, type, ciphertext }) => {
       const encAttrs = { type, v: '2' };
       if (mediaSubtype) encAttrs.mediatype = mediaSubtype;
+      // What the recipient shows if this payload will not decrypt — see
+      // resolveDecryptFail() in MessageSender.
+      if (decryptFail) encAttrs['decrypt-fail'] = decryptFail;
       // Always encode the jid as a binary JID object (JID_PAIR / AD_JID) so the
       // server can route the per-device enc payload to the correct Signal session.
       // Raw UTF-8 strings are silently dropped for @lid recipients.

package/lib/messages/MessageSender.js

@@ -124,6 +124,35 @@ function _getCurve() {
 // Build ADVSignedDeviceIdentity for our primary iOS device.
 // Returns Buffer of encoded proto WITH accountSignatureKey included.
 // Result is cached in store.advIdentity so we only build it once per registration.
+// What the recipient's client should do when one of our payloads will not
+// decrypt for them.
+//
+// The attribute rides on the <enc> node and is read on the other side, not by
+// the server. Absent, a failure draws the "Waiting for this message" placeholder
+// in their chat. `hide` draws nothing at all.
+//
+// That placeholder is right for a real message — the person can see something
+// arrived and ask for it again. It is nonsense for the three kinds below, which
+// are invisible operations on a message that is already there: a reaction that
+// will not decrypt is a heart that never appears, not a message to wait for, and
+// a failed revoke or edit would leave a ghost bubble referring to nothing.
+//
+// The rule is the reference clients' rule, narrowed to what this library sends:
+//
+//   reaction   sendReaction()                   → stanza type 'reaction'
+//   edit       editMessage()                    → edit bit '1'
+//   revoke     deleteMessage(forEveryone: true) → edit bit '7' or '8'
+//
+// Everything else gets nothing, which is the same as saying "show it".
+function resolveDecryptFail(mediaType, options) {
+  if (mediaType === 'reaction') return 'hide';
+  // Any edit bit: 1 is an edit, 7 and 8 are the two revoke forms. The reference
+  // client keys off the presence of the attribute rather than its value, and so
+  // does this.
+  if (options && options.edit) return 'hide';
+  return null;
+}
+
 function _buildOrGetAdvIdentity(store) {
   // Only ever return an identity the server actually issued.
   //
@@ -909,6 +938,7 @@ class MessageSender {
     const ownPhone       = String(this._store.phoneNumber);
     const ownMainJid     = `${ownPhone}@s.whatsapp.net`;
     const mediaSubtype   = options._mediaSubtype || null;
+    const decryptFail    = resolveDecryptFail(mediaType, options);
 
     // For primary iOS devices (registered via SMS), advIdentity is never set
     // because the server only sends device-identity for linked secondary devices.
@@ -1040,7 +1070,8 @@ class MessageSender {
       // Always use <participants><to jid=...><enc> structure — required by MD protocol.
       // Old iOS non-MD used direct <enc> in <message>, but the WhatsApp server now
       // enforces the MD participants wrapper even for single-device sends.
-      const participantsNode = DeviceManager.buildParticipantsNode(encryptedList, mediaSubtype);
+      const participantsNode = DeviceManager.buildParticipantsNode(
+        encryptedList, mediaSubtype, decryptFail);
       msgContent = [...devIdNodes, participantsNode];
     }
 
@@ -1159,6 +1190,7 @@ class MessageSender {
     const ownPhone     = String(this._store.phoneNumber);
     const ownJid       = `${ownPhone}@s.whatsapp.net`;
     const mediaSubtype = options._mediaSubtype || null;
+    const decryptFail  = resolveDecryptFail(mediaType, options);
 
     const isStatus = isStatusBroadcast(groupJid);
 
@@ -1405,10 +1437,17 @@ class MessageSender {
       // participant nodes as on the skmsg, so an image sent to a group carries
       // mediatype on both. Passing null here left the SKDM <enc> nodes
       // unlabelled.
-      msgContent.push(DeviceManager.buildParticipantsNode(skdmEncrypted, mediaSubtype));
+      msgContent.push(DeviceManager.buildParticipantsNode(
+        skdmEncrypted, mediaSubtype, decryptFail));
     }
     const skmsgAttrs = { type: 'skmsg', v: '2' };
     if (mediaSubtype) skmsgAttrs.mediatype = mediaSubtype;
+    // On the skmsg too, and that is where it matters most in a group: the
+    // participant nodes carry the sender-key distribution, but the reaction
+    // itself travels in here. The two reference clients disagree — one sets it
+    // on both, the other only on the participant nodes — and the one that sets
+    // both is the one whose reasoning holds up.
+    if (decryptFail) skmsgAttrs['decrypt-fail'] = decryptFail;
     msgContent.push(new BinaryNode('enc', skmsgAttrs, Buffer.isBuffer(skmsgCiphertext) ? skmsgCiphertext : Buffer.from(skmsgCiphertext)));
 
     // Same reporting token a direct message carries. A poll posted to a group

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "whalibmob",
-  "version": "5.17.0",
+  "version": "5.18.0",
   "description": "WhatsApp library for interaction with WhatsApp Mobile API and web ",
   "author": "Kunboruto20",
   "main": "index.js",