DEV Community: Rajat Ghate

WhatsApp's LID migration broke my bot's @mention detection

Rajat Ghate — Sat, 17 Oct 2026 10:29:00 +0000

I built a WhatsApp group bot that only answers when it is @mentioned. It worked
perfectly in my test group. Then I added it to a second group and it went
completely silent — no error, no warning, no failed assertion. It received every
message and replied to none of them.

The cause is a migration WhatsApp has been rolling out through 2025 and 2026, and
the thing that makes it painful is that the broken version works on your machine.

What changed

Historically every WhatsApp participant was identified by a JID — a Jabber ID —
which embedded their phone number:

919876543210@s.whatsapp.net

WhatsApp is now also issuing a LID (commonly expanded as "Link ID"; you will
also see "linked identity" and "linked device identifier" — the naming is not
consistent even in WhatsApp's own ecosystem). It looks like this:

275551234567890@lid

A LID is assigned per account, not per group, and it is stable: the same person
has the same LID everywhere. It exists so that phone numbers can be hidden —
in Communities, in groups where an admin has enabled Hide phone numbers, and
increasingly by default as WhatsApp moves away from phone numbers as the visible
identifier.

For a bot author, the consequence is small to describe and large to deal with:

The same person, in the same group, can reach your code as either string — and you do not get to choose which one you receive.

Why mention detection breaks silently

Almost every WhatsApp bot tutorial contains some version of this:

const mentions = msg.message?.extendedTextMessage?.contextInfo?.mentionedJid ?? [];
if (mentions.includes(sock.user.id)) {
  await reply(msg);
}

That is a string comparison between two strings that are both correct and are
never equal.

There is no exception to catch. The mention array is populated, your identity is
populated, the comparison returns false, and the bot concludes it was not
addressed. In the logs this is indistinguishable from an ordinary message that
nobody mentioned the bot in.

It also has an unusually cruel failure profile:

Your test group probably shows phone numbers, so everything arrives as a JID and the bug never appears.
It is intermittent across groups, because the privacy setting is per group.
It can change under you, when an admin enables number hiding on a group that worked yesterday.

Two open Baileys issues track the surrounding mess — #1718
on @lid not resolving to a real number, and openclaw #23029
on exactly this mention-detection failure for reply-to-bot.

The fix that looks right and isn't

The instinct is to normalise inward: take the LID, resolve it to a phone number,
compare phone numbers. Several forks and wrapper packages offer a lidToJid() of
some kind.

I would avoid building on that, for two reasons.

**You would be depending on a mapping you don't control. LID exists precisely so that the phone number need not be disclosed, so resolution is something WhatsApp may or may not give you — and it is least likely to in exactly the groups where LIDs show up. Building on it means building on the thing the feature was designed to prevent.

You do not need it. You are not trying to learn who someone is. You are
answering a much smaller question: is this me? And for that, you already hold
both of your own identities.

The fix that works

Baileys exposes both forms of your own identity on sock.user — id and lid.
So rather than converting the incoming value, reduce both sides to a canonical
form and compare against both of your keys.

The normaliser is deliberately boring. Strip the domain, strip the device suffix,
keep the digits:

/**
 *   "919876543210:12@s.whatsapp.net" -> "919876543210"
 *   "275551234567890@lid"            -> "275551234567890"
 *   "+91 98765 43210"                -> "919876543210"
 */
export function normaliseId(raw: string | null | undefined): string | null {
  if (!raw) return null;
  const localPart   = raw.split('@')[0] ?? '';
  const withoutDevice = localPart.split(':')[0] ?? '';
  const digits = withoutDevice.replace(/\D/gu, '');
  return digits.length > 0 ? digits : null;
}

The :12 matters. WhatsApp appends a device suffix on multi-device accounts, so
even two JIDs for the same person are not reliably equal as strings.

Then collect every form of your own identity once:

export function identityKeys(identity: { id: string; lid?: string }): readonly string[] {
  return [normaliseId(identity.id), normaliseId(identity.lid)]
    .filter((key): key is string => key !== null);
}

And the check becomes a set membership test rather than an equality test:

const keys = identityKeys(botIdentity);

for (const mention of message.mentions) {
  const normalised = normaliseId(mention);
  if (normalised !== null && keys.includes(normalised)) {
    return 'explicit_mention';
  }
}

Note what this does not do: it never tries to discover the phone number behind
a LID. It compares two identifiers you were already given.

The second trap: replying to the bot

Swipe-replying to a bot's message is, to a user, obviously addressing it. Many
bots treat it as an implicit mention — and that path breaks the same way, because
the quoted message's sender also arrives as a LID.

The robust answer is to not use an identifier at all. You already know which
messages you sent, because you stored them. Look the quoted message up by id
and check whether it was yours:

Two checks, in order of confidence — and the second one is immune to the whole
problem by construction, which is a good argument for keeping it even after the
first is fixed. If you also support a text fallback such as /^@?bot\b/i, put it
last; it is the one most likely to fire by accident.

Record which check fired. When a bot answers something it shouldn't have, "it
matched the text pattern" is a bug report; "it decided to reply" is a mystery.

Testing something you cannot reproduce on demand

You cannot flip WhatsApp's privacy setting from a test. What you can do is stop
treating the payload shape as something only the network produces.

Keep the identifier logic in its own module with no WhatsApp dependency — it takes
strings and returns strings — and give it both shapes directly:

test('matches a mention that arrives as a LID', () => {
  const identity = { id: '919000000001@s.whatsapp.net', lid: '275551234567890@lid' };

  // The same bot, mentioned in each of the two forms.
  for (const mention of ['919000000001@s.whatsapp.net', '275551234567890@lid']) {
    assert.equal(detectMention({ identity, message: messageWith(mention) }), 'explicit_mention');
  }
});

test('ignores a device suffix', () => {
  // Multi-device accounts append :<device>, so even two JIDs need normalising.
  assert.equal(normaliseId('919000000001:12@s.whatsapp.net'), '919000000001');
});

This is the part I would actually argue for. The LID problem is not hard once you
understand it — perhaps thirty lines. It is hard to find, and it is hard to be
confident you have fixed it, because the environment that triggers it is not under
your control. Pulling the decision into a pure function is what converts "I think
this works now" into something you can assert.

What else carries an identifier

Mention arrays are where this is usually noticed first, but the same shape change
reaches anything that names a participant:

participant on a group message — who sent it
the quoted message's sender in contextInfo
group metadata participant lists, including admin checks
any allowlist, blocklist or "is this the owner?" comparison you have written

If you have an owner check that compares a configured phone number against an
incoming identifier, it will fail the same way — and failing open or closed
there matters a good deal more than a missed reply.

The takeaway

Treat a WhatsApp identifier the way you would treat a user-supplied email address:
never compare it raw, normalise it at the boundary, and keep the normalisation in
one tested place.

The deeper point is that this was never really a string-comparison bug. It was an
assumption — that a person has one address — that was true for years, quietly
stopped being true, and was never written down anywhere in my code. The fix was
small. Noticing was the expensive part.

References

Can you make a GitHub Pages site private?

Rajat Ghate — Mon, 14 Sep 2026 08:21:04 +0000

I ran into something recently while setting up a GitHub Pages site that I thought would be pretty straightforward.

I had a private repository and wanted the website generated from it to be private too. Basically, I didn't want anyone else to be able to open the Pages URL.

So I went looking for the setting that would let me do that.

I couldn't find it.

At first, I thought I was just missing something in the repository settings. But after digging through the GitHub Pages documentation, I realized the problem wasn't that I couldn't find the setting.

For most GitHub plans, that setting simply doesn't exist.

And the reason this is confusing is that there are actually two different things you can mean by “private.”

Private repository ≠ private website

A private repository controls who can see your source code.

A private website controls who can actually open the published website.

Those aren't the same thing.

This is probably the part that's easiest to get wrong. If your repository is private, it's natural to assume that anything you publish from it will also be private.

Unfortunately, that's not how GitHub Pages works.

Two different kinds of private: a private repository still produces a public site

What happens with different GitHub plans?

The exact options depend on the type of GitHub account you're using, but the basic situation looks like

Plan	Pages from a private repo?	Can the site itself be private?
Free (personal)	No	No
Pro (personal)	Yes	No
Team (organization)	Yes	No
Enterprise Cloud (organization)	Yes	Yes, with some restrictions

On the Free plan, there's an extra catch: if you're using GitHub Free, the repository has to be public to use Pages.

The Pro plan is where this can get a little misleading.

You can keep your repository private and publish the site from it, which sounds like it solves the problem.

It doesn't.

Your code is private, but the website is still public.

Anyone who has the URL can open it. They don't need access to your repository or your GitHub account.

So when can a GitHub Pages site actually be private?

GitHub does support access-controlled Pages sites, but there are some fairly specific requirements.

The private-site option is available with GitHub Enterprise Cloud, and it applies to certain project sites published from private or internal repositories owned by an organization.

It isn't something you can enable on a personal GitHub account just by upgrading from Free to Pro.

So if you're using GitHub as an individual developer and you're thinking:

“I'll just make the repository private, and that should protect the website.”

Don't rely on that.

Why doesn't GitHub just give us a private/public switch?

This is where it helps to separate GitHub repositories from GitHub Pages.

Pages is primarily a static-site hosting service. You give it your generated files, and GitHub serves those files as a website.

A private website needs something else as well: access control.

When somebody requests a page, something needs to figure out:

Who is this person?
Are they allowed to see this site?
Should they be asked to log in?
What should happen if they aren't authorized?
That's a different problem from simply serving static files.

GitHub does provide this kind of access control in its Enterprise offering, but regular GitHub Pages sites aren't designed to work as a private, authenticated website.

The part I'd be careful about

The distinction doesn't really matter if you're hosting a personal portfolio or a public project.

It matters a lot if you're using Pages for something that shouldn't be public.

For example, imagine you have:

internal documentation
a staging version of a website
a client project that hasn't been released yet
test data
internal tools
configuration files that you accidentally include in the build
You put all of that in a private repository.

Then you enable GitHub Pages.

The repository can remain private while the resulting website is publicly accessible.

That's the part I think is worth remembering.

Don't treat GitHub Pages as private just because the repository is private.

And don't assume that an obscure URL is enough protection either. If something is genuinely sensitive, it shouldn't depend on nobody discovering the URL.

What should you use instead?

If you actually need a website where only certain people can access it, there are a few better options.

Cloudflare Pages + Cloudflare Access

This is probably the first option I'd look at for a small project.

You can deploy the static site normally and put Cloudflare Access in front of it. Access can require users to authenticate before they reach the site.

For example, you can allow specific email addresses or an entire email domain.

That gives you the thing GitHub Pages is missing here: an actual access-control layer in front of the site.

Vercel or Netlify

If you're already using Vercel or Netlify, their protection and preview features can also make sense.

The exact features available depend on the plan, so I'd check the current pricing and feature list before choosing one specifically for authentication.

Host it yourself

You can also keep it simple and host the site yourself.

A small VPS with nginx and basic authentication is enough for many internal sites. It requires more setup and maintenance, but at least you have direct control over how access is handled.

Or just don't deploy it

This is an option that's easy to overlook.

If the site is something you're only using yourself, you might not need to put it on the internet at all.

Most static-site generators can run a local development server, so you can just run the site on your machine when you need it.

Sometimes that's the simplest solution.

The thing I wish I'd known earlier

The main takeaway for me was pretty simple:

A private GitHub repository and a private GitHub Pages website are two separate things.

Making the repository private protects your source code.

It doesn't automatically protect the website generated from that repository.

So before putting something on GitHub Pages, ask yourself which one you're actually trying to protect.

If you only need to hide the source code, a private repository may be enough.

If you need to restrict who can access the website itself, you'll need a service that provides authentication/access control or GitHub Enterprise Cloud under the specific Pages setup that supports it.

That distinction is easy to miss, and it's much better to find it out before you've accidentally published something you meant to keep private.