whalibmob 5.9.0 → 5.9.2

package/lib/DeviceManager.js

@@ -45,8 +45,8 @@ function jidStrToObj(jidStr) {
     return { user, agent: 0, device, server, toString() { return self; } };
   }
   // @lid multi-device (e.g. "112713111982325:2@lid"): AD_JID with the domain in
-  // the agent byte — 1 for lid, matching Baileys' writeJid, which emits AD_JID
-  // with domainType whenever a device is present.
+  // the agent byte — 1 for lid. AD_JID with a domain type is the shape whenever
+  // a device is present.
   //
   // This previously packed the device into the user string as a JID_PAIR
   // ("112713111982325:2"), a workaround from when the encoder could not express
@@ -204,7 +204,7 @@ class DeviceManager {
   // It loads the on-disk device cache so the very first send after a process
   // restart is instant — no cold-start usync round-trip needed.
   //
-  // Files saved in session dir (baileys-compatible naming):
+  // Files saved in session dir:
   //   <phone>.device-cache.json                          ← combined cache (internal)
   //   device-list-447911234567@s.whatsapp.net.json       ← per-phone device IDs
   //   device-list-139471160877194@lid.json               ← per-LID device IDs
@@ -268,7 +268,7 @@ class DeviceManager {
         'utf8'
       );
 
-      // ── Individual device-list files (baileys-compatible) ──────────────────
+      // ── Individual device-list files ───────────────────────────────────────
       for (const [key, ids] of Object.entries(entries)) {
         let fileName;
         if (key.startsWith('lid:')) {
@@ -411,13 +411,12 @@ class DeviceManager {
     return jids.length > 0 ? jids : phones.map(p => makeDeviceJid(p, 0));
   }
 
-  // ─── USync executor (Baileys WAUSync, mobile-API transport) ─────────────────
+  // ─── USync executor (mobile-API transport) ──────────────────────────────────
   //
-  // Mirrors Baileys' socket.js `executeUSyncQuery`: it builds the <query> and
-  // <list> nodes from the USyncQuery protocols/users, sends the IQ, and parses
-  // the response through `usyncQuery.parseUSyncQueryResult`.  The difference is
-  // purely the transport — whalibmob talks the WhatsApp *mobile* protocol, not
-  // the web protocol — so three adaptations are applied:
+  // Builds the <query> and <list> nodes from the USyncQuery protocols/users,
+  // sends the IQ, and parses the response through
+  // `usyncQuery.parseUSyncQueryResult`. Talking the WhatsApp *mobile* protocol
+  // rather than the web one calls for three adaptations:
   //
   //   1. Nodes use whalibmob's BinaryNode (`description` field) instead of the
   //      web `{ tag }` object literals.
@@ -431,7 +430,7 @@ class DeviceManager {
   //     protocol → <user><contact>+phone</contact></user>.  The mobile server
   //     ignores the <user jid="..."> form for phone-based device discovery.
   //   • Discovery for an already-known routing JID (a LID) uses
-  //     USyncUser().withId(jid) → <user jid="..."> exactly like Baileys.
+  //     USyncUser().withId(jid) → <user jid="...">.
   async executeUSyncQuery(usyncQuery) {
     if (!usyncQuery || usyncQuery.protocols.length === 0) {
       throw new Error('USyncQuery must have at least one protocol');
@@ -464,9 +463,9 @@ class DeviceManager {
       return { user: (server === 'lid' && device > 0) ? raw : user, server, toString() { return str; } };
     };
 
-    // <user> nodes — jid attr is set only when the user has no phone (Baileys:
-    // `jid: !user.phone ? user.id : undefined`); phone users carry a <contact>
-    // child instead, produced by the contact protocol's getUserElement.
+    // <user> nodes — the jid attr is set only when the user has no phone; phone
+    // users carry a <contact> child instead, produced by the contact protocol's
+    // getUserElement.
     const userNodes = usyncQuery.users.map(user => {
       const children = usyncQuery.protocols
         .map(p => p.getUserElement(user))
@@ -535,9 +534,9 @@ class DeviceManager {
   //  Fix C — context and side_list must match _doContactUsync (the working format):
   //    context="interactive" + <side_list/> is REQUIRED. context="message" → server ignores IQ.
   async _doUsyncIq(phones) {
-    // Build the device-discovery query exactly as Baileys does — via USyncQuery
-    // and the device / LID / contact protocols — then run it through the
-    // mobile-API executor and parse it with the shared parseUSyncQueryResult.
+    // Build the device-discovery query via USyncQuery and the device / LID /
+    // contact protocols, then run it through the mobile-API executor and parse
+    // it with the shared parseUSyncQueryResult.
     //
     // Users are addressed by PHONE (USyncUser().withPhone → <contact>+phone</>)
     // because the WA *mobile* server silently drops usync IQs that address
@@ -626,9 +625,9 @@ class DeviceManager {
           for (const dev of deviceList) {
             const devId  = Number.isFinite(dev.id)       ? dev.id       : 0;
             const keyIdx = Number.isFinite(dev.keyIndex) ? dev.keyIndex : -1;
-            // Mirror Baileys extractDeviceJids: keep device 0 or non-zero
-            // devices that carry a valid key-index (otherwise the encrypt IQ
-            // returns a bad-request / empty bundle for that device).
+            // Keep device 0, and non-zero devices that carry a valid
+            // key-index — otherwise the encrypt IQ returns a bad-request or an
+            // empty bundle for that device.
             if (devId === 0 || keyIdx > 0) {
               this._dcAdd(cachePhone, devId);
             }
@@ -883,8 +882,8 @@ class DeviceManager {
   // expressed as <ourLid>:<device>@lid.
   //
   // Device 0 is excluded exactly as it is on the phone path: it is the device
-  // doing the sending, and both Baileys and whatsmeow skip the exact sender
-  // device when building participants.
+  // doing the sending, and the sender device is never one of its own
+  // participants.
   async ensureOwnLidDeviceSessions(lidUser, ownPhone, signalProto, allowPkmsg = true) {
     if (!lidUser) return [];
     const cacheKey = 'lid:' + lidUser;
@@ -977,7 +976,7 @@ class DeviceManager {
   async _doContactUsync(phones) {
     // Contact-only fallback (device/lid protocols omitted): the plain contact
     // query is the form the mobile server reliably answers when the richer
-    // device query times out.  Built via the shared Baileys USyncQuery builder.
+    // device query times out.  Built via the shared USyncQuery builder.
     const query = new USyncQuery()
       .withContext('interactive')
       .withContactProtocol();
@@ -1031,9 +1030,9 @@ class DeviceManager {
     const jidStr = typeof jid === 'string' ? jid : String(jid);
 
     // Discovery for an already-known routing JID (a LID) — addressed via
-    // USyncUser().withId(jid) → <user jid="...">, exactly as Baileys'
-    // getUSyncDevices does.  executeUSyncQuery encodes the jid attr as a
-    // JID object so the mobile binary encoder emits proper JID_PAIR bytes.
+    // USyncUser().withId(jid) → <user jid="...">.  executeUSyncQuery encodes
+    // the jid attr as a JID object so the mobile binary encoder emits proper
+    // JID_PAIR bytes.
     const query = new USyncQuery()
       .withContext('interactive')
       .withDeviceProtocol()

package/lib/MediaService.js

@@ -119,8 +119,8 @@ function decryptMedia(encryptedWithMac, mediaKey, keyName) {
 
 // Upload encrypted media, trying every CDN host in turn.
 //
-// refreshAuth (optional) mirrors Baileys' refreshMediaConn(true): when a host
-// answers but the upload yields no usable URL — the signature of an expired or
+// refreshAuth (optional): when a host answers but the upload yields no usable
+// URL — the signature of an expired or
 // rejected auth token — the auth is force-refreshed once and the hosts are
 // retried with the fresh credentials. Without this a token that expires between
 // the TTL check and the upload burns through every host and fails permanently

package/lib/MediaThumbnail.js

@@ -8,9 +8,8 @@
 // drawn, so the recipient gets the grey placeholder with a download arrow and
 // has to tap it before seeing anything.
 //
-// Baileys builds that preview by resizing the source to 32 pixels wide at JPEG
-// quality 50, and takes the original dimensions from the same decode. This does
-// the same, with the difference that none of it is mandatory:
+// The preview is the source resized to 32 pixels wide at JPEG quality 50, with
+// the original dimensions read from the same decode. None of it is mandatory:
 //
 //   • Dimensions are read straight out of the file header — JPEG, PNG, WebP,
 //     GIF and BMP — with no library at all.
@@ -31,8 +30,8 @@ const path = require('path');
 const crypto = require('crypto');
 const { execFile } = require('child_process');
 
-// Baileys' numbers — the preview is deliberately tiny, it is only ever shown
-// blurred behind the real image while that downloads.
+// The preview is deliberately tiny; it is only ever shown blurred behind the
+// real image while that downloads.
 const THUMB_WIDTH   = 32;
 const THUMB_QUALITY = 50;
 
@@ -358,8 +357,7 @@ async function videoThumbnail(input, opts) {
       } catch (_) {}
     }
 
-    // Same frame grab Baileys runs: first frame, scaled to the preview width
-    // with the aspect ratio kept.
+    // First frame, scaled to the preview width with the aspect ratio kept.
     const dest = tmpFile('.jpg');
     try {
       const ok = await run('ffmpeg', [

package/lib/auth-utils.js

@@ -2,8 +2,8 @@
 
 // ─── auth-utils.js ────────────────────────────────────────────────────────────
 //
-// Provides four utilities that mirror Baileys' auth-utils, adapted to
-// whalibmob's architecture (method-based SignalStore, Buffer key pairs, etc.):
+// Four utilities built around whalibmob's architecture (method-based
+// SignalStore, Buffer key pairs, etc.):
 //
 //  1. makeCacheableSignalKeyStore  — wraps SignalStore with NodeCache (5-min TTL)
 //                                   and a Mutex for all read/write operations
@@ -591,7 +591,6 @@ function addTransactionCapability(state, logger, opts) {
  * Returns the authenticated user's JID (phone@s.whatsapp.net) or throws
  * a descriptive error if the store is not yet fully authenticated.
  *
- * Equivalent to Baileys' assertMeId(creds) but for whalibmob's store format.
  * Use this anywhere we'd otherwise reach for `store.phoneNumber` directly,
  * to fail fast with a clear error instead of a silent null-reference crash.
  *
@@ -623,12 +622,12 @@ function assertMeId(store) {
  * Creates a fresh set of whalibmob auth credentials (key pairs, registration ID,
  * device identifiers) for a given phone number.
  *
- * Equivalent to Baileys' initAuthCreds() but returns whalibmob's store format
- * (Buffer key pairs, signedPreKey as { id, public, private, signature }).
+ * Returns whalibmob's store format (Buffer key pairs, signedPreKey as
+ * { id, public, private, signature }).
  *
- * Additional Baileys-compatible fields (nextPreKeyId, firstUnuploadedPreKeyId,
- * accountSyncCounter, accountSettings, advSecretKey, etc.) are appended so
- * code that was written against Baileys' credential shape works unchanged.
+ * A few extra fields (nextPreKeyId, firstUnuploadedPreKeyId, accountSyncCounter,
+ * accountSettings, advSecretKey, etc.) are appended for account sync and for
+ * application code that expects them.
  *
  * @param {string|number} phoneNumber — full international number (e.g. "40712345678")
  * @param {object}        options     — optional overrides:
@@ -643,9 +642,8 @@ function initAuthCreds(phoneNumber, options) {
   // Use whalibmob's own key-generation machinery (curve25519-js, proper prefixes)
   const store = createNewStore(phoneNumber);
 
-  // ── Extra Baileys-compatible fields ──────────────────────────────────────────
-  // These are not required by whalibmob internally but are commonly expected by
-  // application code that was originally written against Baileys.
+  // ── Extra credential fields ──────────────────────────────────────────────────
+  // Not required internally, but commonly expected by application code.
 
   /** Next pre-key ID to generate (monotonically increasing). */
   store.nextPreKeyId             = 1;
@@ -656,7 +654,7 @@ function initAuthCreds(phoneNumber, options) {
   /** Sync counter used in account-sync IQ stanzas. */
   store.accountSyncCounter       = 0;
 
-  /** Account-level settings mirroring Baileys' IAccountSettings shape. */
+  /** Account-level settings. */
   store.accountSettings          = { unarchiveChats: false };
 
   /** Processed history messages — used to avoid duplicate handling on reconnect. */
@@ -664,7 +662,7 @@ function initAuthCreds(phoneNumber, options) {
 
   /**
    * 32-byte random secret used for ADV (multi-device) poll encryption.
-   * Stored as a base64 string, consistent with Baileys' advSecretKey.
+   * Stored as a base64 string.
    */
   store.advSecretKey             = crypto.randomBytes(32).toString('base64');
 

package/lib/messages/MessageSender.js

@@ -43,8 +43,7 @@ function isGroupJid(jid) {
 
 // A Status/Story is posted as a message to status@broadcast, and it travels the
 // SenderKey path a group message does — one skmsg plus a distribution to every
-// recipient — not the 1:1 path. Baileys calls the pair isGroupOrStatus;
-// whatsmeow routes BroadcastServer into sendGroup for the same reason.
+// recipient — not the 1:1 path. A Status and a group are the same case here.
 const STATUS_BROADCAST_JID = 'status@broadcast';
 
 function isStatusBroadcast(jid) {
@@ -196,18 +195,14 @@ function adString(jid) {
   return `${user}.0:${device}@${server}`;
 }
 
-// Participant-list hash v2, as whatsmeow's participantListHashV2 computes it:
-// sort the AD strings, sha256 the concatenation, then base64 the FIRST SIX
-// BYTES of the digest — eight characters, prefixed "2:".
+// Participant-list hash v2: sort the AD strings, sha256 the concatenation, then
+// base64 the FIRST SIX BYTES of the digest — eight characters, prefixed "2:".
 //
-// This previously mirrored Baileys' generateParticipantHashV2, which hashes
-// plain JID strings and then takes the first six CHARACTERS of the base64 of
-// the whole digest. That produces a different, six-character value from
-// different input. Baileys never puts the result on the wire — it assigns it to
-// extraAttrs after the participant nodes are built, so nothing ever reads it —
-// which is why the discrepancy has gone unnoticed there. whalibmob did put it
-// on the wire, so every multi-device send carried a hash the server could not
-// match against its own view of the participant list.
+// This previously hashed plain JID strings and took the first six CHARACTERS of
+// the base64 of the whole digest, which is a different, six-character value over
+// different input. It goes on the wire, so every multi-device send carried a
+// hash the server could not match against its own view of the participant
+// list.
 function computePhash(jids) {
   const sorted = [...new Set(jids.map(adString))].sort();
   const hash   = crypto.createHash('sha256').update(sorted.join('')).digest();
@@ -341,7 +336,7 @@ class MessageSender {
       gifPlayback:       options.gifPlayback || false,
       contextInfo:       options.contextInfo
     }));
-    // whatsmeow labels a video with gifPlayback as mediatype "gif", not "video".
+    // A video with gifPlayback is labelled mediatype "gif", not "video".
     return this._sendMessage(toJid, msgId, vidBuf, 'media',
       { ...options, _mediaSubtype: options.gifPlayback ? 'gif' : 'video' });
   }
@@ -459,8 +454,8 @@ class MessageSender {
       selectableOptionsCount: selectableCount != null ? selectableCount : 0,
       messageSecret: opts.messageSecret || opts.encKey || null
     });
-    // whatsmeow's BuildPollCreation pairs the poll with a messageContextInfo
-    // holding the secret. It is a sibling field of the poll inside Message, not
+    // The poll has to be paired with a messageContextInfo holding the secret.
+    // It is a sibling field of the poll inside Message, not
     // part of the poll — a voter derives their vote key from this copy, so a
     // poll sent without it cannot be voted on.
     const pollBuf = Buffer.concat([
@@ -497,9 +492,9 @@ class MessageSender {
       contextInfo:   opts.contextInfo
     }));
     // A location is a plain message as far as the envelope is concerned.
-    // whatsmeow's getTypeFromMessage has only text, media, reaction and poll —
-    // LocationMessage is in none of the media cases, so it falls through to
-    // text. Sending type="location" hands the server a type it has no case for.
+    // The stanza types are text, media, reaction and poll — LocationMessage is
+    // in none of the media cases, so it is text. Sending type="location" hands
+    // the server a type it has no case for.
     return this._sendMessage(toJid, msgId, locBuf, 'text', opts);
   }
 
@@ -922,9 +917,8 @@ class MessageSender {
     const allowPkmsg = true;
 
     // ── Addressing family ─────────────────────────────────────────────────────
-    // Baileys 7.0.0-rc13 — the release that fixed ack 479 on LID addressing —
-    // derives the whole address family from the JID the caller passed, and
-    // never converts between the two:
+    // The whole address family comes from the JID the caller passed, and the
+    // two are never converted between:
     //
     //     const targetUserServer = isLid ? 'lid' : 's.whatsapp.net'
     //     const senderIdentity   = isLid && meLid ? <ourLid> : <ourPn>
@@ -939,9 +933,9 @@ class MessageSender {
     // The recipient's devices followed the caller's JID but ours were always
     // enumerated by phone, so a DM to an @lid went out with @lid recipient
     // entries and @s.whatsapp.net entries for our own linked devices in the same
-    // <participants> list. whatsmeow builds the pair as [to, ownID] with ownID
-    // switched to our LID for @lid destinations precisely to avoid that, and a
-    // participant list the server cannot reconcile is what comes back as 479.
+    // <participants> list. The pair has to be [to, ownID] with ownID switched to
+    // our LID for @lid destinations; a participant list the server cannot
+    // reconcile is what comes back as 479.
     const isLidTarget  = toJid.endsWith('@lid');
     const routingToJid = toJid;
     const ownLidUser   = this._client._myLid ? phoneFromJid(this._client._myLid) : null;
@@ -955,8 +949,7 @@ class MessageSender {
     }
 
     // Enumerate the recipient's devices and our own in parallel, both in the
-    // address family the destination JID dictates — Baileys does the same in one
-    // getUSyncDevices([senderIdentity, jid]) call.
+    // address family the destination JID dictates.
     let otherJids, ownLinkedJids, ownPrimaryJid;
     if (isLidTarget) {
       const lidUser = phoneFromJid(toJid);
@@ -981,8 +974,7 @@ class MessageSender {
       ownPrimaryJid = this._client._ownDeviceJid();
     }
 
-    // The device doing the sending is never one of its own recipients. Both
-    // Baileys ("Skipping exact sender device") and whatsmeow drop it explicitly.
+    // The device doing the sending is never one of its own recipients.
     const ownPrimaryAddr = adString(ownPrimaryJid);
     otherJids     = otherJids.filter(j => adString(j) !== ownPrimaryAddr);
     ownLinkedJids = ownLinkedJids.filter(j => adString(j) !== ownPrimaryAddr);
@@ -999,12 +991,12 @@ class MessageSender {
     // ─────────────────────────────────────────────────────────────────────────
 
     // The hash covers every device the server enumerates for this pair of users,
-    // our own primary included — whatsmeow hashes GetUserDevices([to, ownID]) in
-    // full and only skips the sending device when it encrypts. Excluding it here
-    // produced a hash over a different set than the server's.
+    // our own primary included — the sending device is skipped only when it
+    // comes to encrypting. Excluding it here produced a hash over a different
+    // set than the server's.
     //
-    // It is not put on the stanza: neither whatsmeow nor Baileys sends phash on a
-    // 1:1 message, only on a group one. It is carried inside the (encrypted)
+    // It is not put on the stanza: phash belongs on a group message, not a 1:1
+    // one. It is carried inside the (encrypted)
     // DeviceSentMessage for our own devices, and compared against the phash the
     // server echoes back on the ack so a drifted device cache gets flushed.
     const phash = computePhash([...otherJids, ownPrimaryJid, ...ownLinkedJids]);
@@ -1115,8 +1107,7 @@ class MessageSender {
 
     // The server echoes its own participant hash on the ack. A difference means
     // its device list for this chat is not the one we just fanned out to, so the
-    // cached list is stale — drop it and let the next send re-run usync, exactly
-    // as whatsmeow does when the hashes disagree.
+    // cached list is stale — drop it and let the next send re-run usync.
     if (dispatchResult && dispatchResult.phash && dispatchResult.phash !== phash) {
       _whaDbg('[DBG] PHASH_MISMATCH ours=' + phash + ' server=' + dispatchResult.phash +
         ' to=' + toJid + ' — flushing device cache');
@@ -1136,10 +1127,9 @@ class MessageSender {
     // Two targets never get one. WhatsApp's own announcement account
     // (0@s.whatsapp.net) and the bot numbers, including Meta AI, are not
     // contacts you can be "timelocked" against, and no real client issues to
-    // them — whatsmeow gates on shouldSendTCTokenInChatAction, Baileys on
-    // isBotOrPSA. Protocol messages (a revoke, an ephemeral-timer change) are
-    // out too: Baileys skips issuance for them because they are bookkeeping,
-    // not a reach-out. Attaching an existing token to them is still correct
+    // them. Protocol messages (a revoke, an ephemeral-timer change) are out
+    // too — they are bookkeeping, not a reach-out. Attaching an existing token
+    // to them is still correct
     // and still happens above — this only governs asking for a new one.
     const isProtocolMsg = !!(options && options._protocol);
     if (tcStore && isRegularTcTokenUser(tcJid) && !isProtocolMsg &&
@@ -1219,9 +1209,9 @@ class MessageSender {
     }
 
     // Determine addressing mode for this group (lid = modern groups, pn = legacy).
-    // A Status carries none: whatsmeow sets addressing_mode only for the group
-    // server, and its recipients are ordinary contacts, so everything below
-    // stays in phone space.
+    // A Status carries none: addressing_mode is set only for the group server,
+    // and a Status goes to ordinary contacts, so everything below stays in
+    // phone space.
     const groupAddressingMode = isStatus
       ? null
       : (this._client._groupAddressingMode.get(groupJid) || 'lid');
@@ -1258,9 +1248,8 @@ class MessageSender {
     // out of the member walk and put back through the own-device path below.
     // Left in, the walk enumerates our devices starting at device 0 — the very
     // device doing the sending — and it lands in <participants> as a recipient
-    // of our own SenderKey. Baileys skips the exact sender device explicitly
-    // ("Skipping exact sender device"), whatsmeow does the same with
-    // `jid == ownJID || jid == ownLID`.
+    // of our own SenderKey. The exact sender device has to be skipped, matched
+    // against both our phone JID and our LID.
     //
     // The phone branch already dropped us via `p !== ownPhone`; the LID branch
     // never did, so this only ever misfired on LID-addressed groups.
@@ -1313,10 +1302,10 @@ class MessageSender {
     ]);
 
     // Every device this group resolves to, our own primary included, deduped so
-    // a device reached through more than one path is counted once. whatsmeow
-    // hashes GetUserDevices(groupParticipants) in exactly this shape — the whole
-    // enumeration, sending device and all — and drops hosted endpoints first,
-    // since those are bot-side and never real participants.
+    // a device reached through more than one path is counted once. The hash
+    // covers the whole enumeration, sending device and all, with hosted
+    // endpoints dropped first since those are bot-side and never real
+    // participants.
     const isHostedJid = (jid) => {
       const s = String(jid);
       return s.endsWith('@hosted') || s.endsWith('@hosted.lid');
@@ -1334,14 +1323,14 @@ class MessageSender {
       [...memberDevices, ...lidDevices, ...ownTargets, ownSelfJid]
     )].filter(jid => !isHostedJid(jid));
 
-    // The participant hash the server checks the fan-out against. whatsmeow puts
-    // it on group stanzas (sendGroup sets node.Attrs["phash"]) and nowhere else;
-    // it is computed over the enumeration above, not over the encryption targets,
+    // The participant hash the server checks the fan-out against. It goes on
+    // group stanzas and nowhere else, and is computed over the enumeration
+    // above rather than over the encryption targets,
     // so the sending device counts here even though it is not a recipient.
     const phash = computePhash(enumeratedDevices);
 
-    // Targets to actually encrypt for: everything but the sending device. Both
-    // Baileys and whatsmeow skip it explicitly at this point and not before.
+    // Targets to actually encrypt for: everything but the sending device, and
+    // it is skipped at this point rather than earlier.
     // Only the device actually sending. On a companion link that is not the
     // account's phone — the phone is a peer that has to receive the SenderKey
     // like everyone else, so excluding the bare number here would leave the
@@ -1364,8 +1353,8 @@ class MessageSender {
 
     const skStore        = this._signal.senderKeyStore;
     const existingSkdmMap = skStore.getSKDMMap(groupJid);
-    // Same exclusions Baileys applies when choosing SenderKey recipients:
-    // hosted (bot-side) users and device 99, which is a server placeholder
+    // Exclusions when choosing SenderKey recipients: hosted (bot-side) users
+    // and device 99, which is a server placeholder
     // rather than a real endpoint, must never receive a distribution.
     const isSkdmEligible = (jid) => {
       const s = String(jid);
@@ -1408,10 +1397,10 @@ class MessageSender {
       msgContent.push(new BinaryNode('device-identity', {}, advBytes));
     }
     if (skdmEncrypted.length > 0) {
-      // Baileys applies the same extra attrs — mediatype included — to the
-      // SenderKey participant nodes as to the skmsg, so an image sent to a
-      // group carries mediatype on both. Passing null here left the SKDM
-      // <enc> nodes unlabelled.
+      // The same extra attrs — mediatype included — belong on the SenderKey
+      // 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));
     }
     const skmsgAttrs = { type: 'skmsg', v: '2' };
@@ -1429,10 +1418,9 @@ class MessageSender {
       _whaDbg('[DBG] REPORTING_TOKEN attached to=' + groupJid + ' id=' + msgId);
     }
 
-    // phash belongs on a group stanza and only on a group stanza — whatsmeow's
-    // sendGroup sets it, sendDM does not. It tells the server which device set we
-    // fanned out to; the server compares it against its own and echoes its hash
-    // back on the ack when they differ.
+    // phash belongs on a group stanza and only on a group stanza. It tells the
+    // server which device set we fanned out to; the server compares it against
+    // its own and echoes its hash back on the ack when they differ.
     const stanzaAttrs = {
       to: jidStrToObj(groupJid),
       id: msgId,
@@ -1464,9 +1452,9 @@ class MessageSender {
 
     // A hash on the ack that differs from ours means the server's participant
     // list for this group is not the one we just fanned out to, so some members
-    // did not get the message. whatsmeow drops its group cache on exactly this
-    // signal; the device lists behind the members are dropped too, so the next
-    // send re-runs group metadata and usync rather than repeating the miss.
+    // did not get the message. The group cache is dropped on exactly this
+    // signal, and the device lists behind the members with it, so the next send
+    // re-runs group metadata and usync rather than repeating the miss.
     if (dispatchResult && dispatchResult.phash && dispatchResult.phash !== phash) {
       _whaDbg('[DBG] GROUP_PHASH_MISMATCH ours=' + phash +
         ' server=' + dispatchResult.phash + ' group=' + groupJid +
@@ -1485,7 +1473,7 @@ class MessageSender {
 
   // ─── Dispatch and wait for ack ────────────────────────────────────────────
   //
-  // Error 463 recovery (mirrors Baileys messages-recv.js inFlight463Recoveries):
+  // Error 463 recovery:
   //   1. 463 ack arrives → issue privacy token via _issuePrivacyTokens
   //   2. Wait for token to be stored in _tcTokenStore
   //   3. Re-send the SAME message node with a new msgId — the tctoken node
@@ -1496,7 +1484,7 @@ class MessageSender {
   //
   // Uses a SEPARATE _inFlight463Recoveries Set (not shared with the proactive
   // _inFlightTcTokenIssuance) so 463 recovery and proactive issuance never
-  // block each other. Matches Baileys pattern exactly.
+  // block each other.
 
   _dispatchAndAck(node, msgId, _isRetry) {
     const self   = this;
@@ -1659,8 +1647,8 @@ class MessageSender {
       key:  { remoteJid: toJid, fromMe: !!fromMe, id: origMsgId }
     });
     const msgBuf = encodeMessage('protocol', revokePayload);
-    // ProtocolMessage is one of the explicit "text" cases in whatsmeow's
-    // getTypeFromMessage; there is no "protocol" stanza type.
+    // A ProtocolMessage travels as stanza type "text"; there is no "protocol"
+    // stanza type.
     // _protocol marks it for the tcToken issuance gate — see _sendDMMessage.
     return this._sendMessage(toJid, msgId, msgBuf, 'text',
       { ...opts, edit: editBit, _protocol: true });

package/lib/messages/ReportingToken.js

@@ -16,10 +16,9 @@
 // not change the token. REPORTING_FIELDS below is that subset, and it is the
 // part that has to match byte for byte or the token is worthless.
 //
-// Ported field-for-field from Baileys' reporting-utils. whatsmeow derives the
-// key from (ownID, to) where Baileys uses the destination JID for both halves;
-// the reference followed here is Baileys, and since the server only checks the
-// token when a report is actually filed, neither choice is observable on send.
+// The key is derived using the destination JID for both halves. Since the
+// server only checks the token when a report is actually filed, the choice is
+// not observable on send.
 
 const crypto     = require('crypto');
 const { hkdf }   = require('@noble/hashes/hkdf');
@@ -121,8 +120,7 @@ function encodeVarint(value) {
 // The result is sorted by field number, which is what makes the token
 // independent of the order the encoder happened to write the fields in.
 //
-// Returns null on malformed input — the caller then attaches no token, which is
-// the same thing Baileys does.
+// Returns null on malformed input — the caller then attaches no token.
 function extractReportingTokenContent(data, cfg) {
   const out = [];
   let i = 0;

package/lib/messages/TcTokenStore.js

@@ -3,16 +3,14 @@
 const fs   = require('fs');
 const path = require('path');
 
-// 7-day buckets, 4 buckets = ~28-day rolling window (matches Baileys tc-token-utils)
+// 7-day buckets, 4 buckets = ~28-day rolling window
 const TC_BUCKET_DURATION = 604800;
 const TC_NUM_BUCKETS     = 4;
-// whatsmeow prunes expired rows out of the token table at most once a day
-// (tcTokenDBPruneInterval). Ours is a JSON file, so the same cadence applies.
+// Expired rows are pruned out of the token store at most once a day; it is a
+// JSON file, so there is nothing to gain from doing it more often.
 const TC_PRUNE_INTERVAL_MS = 24 * 60 * 60 * 1000;
 
 // The two phone-number ranges WhatsApp uses for bots, including Meta AI.
-// Byte-for-byte the same expression in whatsmeow (botUserRegex) and in
-// Baileys (BOT_PHONE_REGEX).
 const BOT_USER_RE = /^1313555\d{4}$|^131655500\d{2}$/;
 
 function tcTokenExpired(timestamp) {
@@ -35,9 +33,8 @@ function shouldSendNewTcToken(senderTimestamp) {
 
 // Whether a JID is a real person we may hold a trusted-contact token for.
 //
-// whatsmeow gates issuance with shouldSendTCTokenInChatAction and Baileys gates
-// both issuance and storage with isRegularUser; the two agree on the rule:
-// a user address (phone or LID), not the PSA pseudo-contact 0@…, not a bot.
+// The rule is: a user address (phone or LID), not the PSA pseudo-contact 0@…,
+// and not a bot.
 // Without it we issue a privacy IQ to WhatsApp's own announcement account and
 // to Meta AI, which no real client ever does.
 function isRegularTcTokenUser(jid) {
@@ -78,10 +75,8 @@ class TcTokenStore {
 
   // Drop entries that are past the 28-day window on both counts.
   //
-  // whatsmeow runs DeleteExpiredPrivacyTokens against the same cutoff and lets
-  // its in-memory sender-timestamp map age out on the same boundary. An entry
-  // whose token has expired but whose senderTimestamp is still inside the
-  // window has to stay: that timestamp is what keeps us from re-issuing on
+  // An entry whose token has expired but whose senderTimestamp is still inside
+  // the window has to stay: that timestamp is what keeps us from re-issuing on
   // every single send.
   pruneExpired() {
     let removed = 0;
@@ -134,15 +129,14 @@ class TcTokenStore {
   }
 
   get(jid) {
-    // whatsmeow prunes from ensureTCToken, i.e. on the read path, rate-limited
-    // to once a day. Same here.
+    // Pruning happens on the read path, rate-limited to once a day.
     this._maybePrune();
     return this._map.get(normalizeJidForTcToken(jid)) || null;
   }
 
   // Returns true when the token was accepted.
   //
-  // Two rejections, both taken from Baileys' storeTcTokensFromIqResult:
+  // Two rejections:
   //  - a token with no timestamp is already expired by definition, so storing
   //    it only wastes a slot and guarantees a miss on the next send;
   //  - a token older than the one on file must never overwrite it. Token