Wa users/wa usernames and phonenames

[alexander-pyrforos]

Description

Added phone, lid/jid, name of user in message header and API responces

Type of Change

New feature

[rmyndharis]

Thanks for this, @alexander-pyrforos — the core idea here is spot-on, and there are a couple of genuinely good fixes in here. Wanted to call those out before the change requests.

What's right:

• Resolving the sender via author instead of the group JID is fundamentally correct. The previous behavior (enriching against the group contact) was a real bug, and the new test (resolves group message sender contact via author, not group JID) nails the intent.
• The LID-number detection (contactId.endsWith('@lid') && merged.number === contactId.replace(/@lid$/,'')) is precise — it correctly distinguishes "number is empty" from "number got filled with LID digits". Good eye.
• The dashboard senderInfo resolver is thorough (pushName · name · phone, with sensible LID/JID fallbacks).

Requesting changes for the reasons below — happy to help work through any of them.

---

🛑 The + prefix breaks the lid_mappings reverse lookup (silent regression)

resolveContactPhone now returns +628999 (with +), but that value flows into the persisted lid→phone table:

// session.service.ts — resolveSenderPhone()
incoming.senderPhone = await this.resolveSenderPhone(id, incoming.author ?? incoming.from);
// ...
void this.lidMappingStore?.remember(userPart(contactId), phone, sessionId) // phone = "+628999"

But a different writer of the same table writes bare digits:

// baileys-session-store.ts — when a contacts.upsert carries a lid→pn mapping
void this.lidStore?.remember(userPart(lidJid), userPart(pnJid), this.sessionId) // "628999"

And the reverse-lookup reader (the message from filter) keys on bare digits:

// message.service.ts — resolveJidCandidates()
const phone = userPart(value);                       // "628999"
for (const lid of this.lidMappingStore.lidsForPhone(phone)) { ... }  // looks up key "628999"

So after this change, lid→phone rows written via the inline path get stored under phoneToLids["+628999"], while every reader looks up "628999" — a silent miss. The from filter for LID senders quietly stops matching.

The remember(...) test update in session.service.spec.ts ('628111222333' → '+628111222333') makes the test pass but doesn't fix the downstream reader.

Suggested direction: pick one canonical format for lid_mappings.phone and hold it everywhere. The column is documented as "E.164 phone digits" and the Baileys session store writes bare digits, so the cleanest path is to keep the engine-boundary contract as bare digits (matching the existing IncomingMessage.senderPhone / MessageContact.number docs) and add the + only at the presentation layer (dashboard display / an API DTO field) if you want E.164 there. If you do want + to be the new standard, it needs a coordinated migration: baileys-session-store.resolvePhone, userPart consumers, the from-filter reader, a CHANGELOG BREAKING entry, and tests for the reverse-lookup path — otherwise it's a partial migration.

🛑 IncomingMessage.senderPhone contract change is undocumented

The interface documents senderPhone as "Best-effort phone number (MSISDN digits of the sender)" (whatsapp-engine.interface.ts:98), and MessageContact.number as *"Phone digits, best-effort". Webhook consumers and SDK users persist/compare these values. Changing the format to include +` is a silent breaking change for them — no CHANGELOG note, no major bump, no flag.

If + is the intended new shape, let's make that explicit in the interface docs, the CHANGELOG, and ideally gate it or call it out in the migration guide.

🔁 Contact enrichment is duplicated between the live and history handlers

The LID-number-fix + resolveContactPhone fallback block (~40 lines) is pasted near-identically in the live message handler (whatsapp-web-js.adapter.ts:~466) and the getChatHistory handler (:~1618). Worth extracting into a small helper like resolveSenderContact(msg) so the two paths can't drift apart.

🎨 Formatting nits (will trip the Prettier/format CI gate)

• this.client.on('message', ...) indentation drifted from 4→5 spaces (adapter.ts:458) — looks like an accidental re-indent.
• The className={\message-bubble ...`}block inChats.tsx` lost its alignment.
• New .css files are missing a trailing newline.

Minor, but worth a npm run format pass before re-push.

---

Thanks again for tackling the group-sender resolution — that part is a real improvement. Once the phone-format consistency is sorted, this is in good shape.