[Feature]: Show saved contact / push names in the dashboard Chats list (Baileys returns raw JID/@lid instead of the name)

[ulises2k]

Pre-flight

• I searched existing issues and this isn't already requested. The closest open issues are Baileys engine: @lid -> phone never resolves (senderPhone / contacts/:id/phone always null); #263 feature non-functional on Baileys #362 and [Feature]: typed WaId identity value object + a lid <-> phone resolution table #349, but those are about resolving @lid → phone number. This request is about displaying the saved contact / push name in the dashboard Chats list, which is a separate, name-only concern (it should work even when the phone number cannot be resolved).

Problem / motivation

In the dashboard Chats view, 1:1 conversations are listed by their raw identifier instead of the name the contact is saved under:

• a bare phone number, or
• after WhatsApp's LID migration, a raw …@lid id (e.g. 116745901723874@lid).

Both the sidebar chat list and the open-conversation header show this raw id, which makes it very hard to tell who you are talking to. Earlier versions (reported as far back as v0.1.8) showed the saved contact name in the Chats list, so on the current Baileys engine this is effectively a regression.

Example (Baileys engine, session ready): every 1:1 row in the Chats sidebar shows a number / @lid, never a name.

Root cause (already located)

The dashboard is not the problem — it already prefers a name and only falls back to the id:

// dashboard/src/pages/Chats.tsx  (sidebar row ~L703, room header ~L737)
{chat.name || chat.id.split('@')[0]}

The name is dropped server-side, in the Baileys chat mapper:

// src/engine/adapters/baileys-session-store.ts  -> toNeutralChat() (~L124)
return {
  id: c.id,
  name: c.name ?? this.userPart(c.id),   // <-- only Baileys Chat.name, else raw user part
  ...
};

Baileys Chat.name is typically empty for individual chats (it is mainly populated for groups / custom-named chats), so ChatSummary.name becomes the raw user part of the JID/@lid.

The saved name is already available in the same store, it is just never cross-referenced from the chat mapper:

// src/engine/adapters/baileys-session-store.ts  -> toNeutralContact() (~L107)
name: c.name ?? c.verifiedName,   // saved address-book name / business verified name
pushName: c.notify,               // sender's self-set display name

The contacts map is fed from contacts.upsert / contacts.update / messaging-history.set (see baileys.adapter.ts ~L177-183), and for @lid chats the store also already holds a lidToPn map + resolvePhone() (~L92).

Proposed solution

Enrich toNeutralChat() so the chat name falls through a small priority chain before giving up on the raw id:

1. Baileys Chat.name (groups, custom-named chats) — unchanged.
2. Contact lookup by chat id in the existing contacts map: name ?? verifiedName ?? notify.
3. For @lid chats: resolve @lid → phone JID (via the existing lidToPn / phoneNumber) and look up that contact, so hidden-number contacts still resolve once their lid↔pn pair is known.
4. Raw user part of the JID — current behavior, last resort only.

Illustrative sketch (maintainer can refine):

private toNeutralChat(c: Chat): ChatSummary {
  const last = this.lastMessages.get(c.id);
  return {
    id: c.id,
    name: c.name ?? this.resolveContactName(c.id) ?? this.userPart(c.id),
    isGroup: c.id.endsWith('@g.us'),
    unreadCount: c.unreadCount ?? 0,
    timestamp: last?.timestamp ?? this.toUnixSeconds(c.conversationTimestamp),
    lastMessage: last?.text,
  };
}

private resolveContactName(id: string): string | undefined {
  const pick = (c?: BaileysContactWithPhone) =>
    c?.name ?? c?.verifiedName ?? c?.notify ?? undefined;

  const direct = pick(this.contacts.get(id));
  if (direct) return direct;

  if (id.endsWith('@lid')) {
    const pn = this.lidToPn.get(id) ?? this.contacts.get(id)?.phoneNumber;
    if (pn) {
      return pick(this.contacts.get(pn))
        ?? pick(this.contacts.get(`${this.userPart(pn)}@s.whatsapp.net`));
    }
  }
  return undefined;
}

Notes / caveats:

• The locally saved name (Contact.name) is the most accurate and should win; verifiedName (WhatsApp Business) and notify (pushName) are reasonable fallbacks. pushName is the sender's own chosen display name, not the saved contact name — still far better than a raw id.
• Baileys only knows the saved address-book name if WhatsApp delivered it via history sync / contact events. For some hidden-number @lid contacts that never arrives, in which case notify (pushName) is the best available — but the chat row should still prefer it over the raw id.
• This keeps the fix engine-neutral at the API level: ChatSummary.name simply becomes "best known display name", which is what the dashboard already expects.

Alternatives considered

• Resolve the name client-side in the dashboard by calling GET /sessions/:id/contacts and joining on chat id — possible, but it duplicates lookup logic in the UI and is racy; the backend already has the data in one place.
• Only show the phone number (depends on @lid → phone resolution, tracked in Baileys engine: @lid -> phone never resolves (senderPhone / contacts/:id/phone always null); #263 feature non-functional on Baileys #362 / [Feature]: typed WaId identity value object + a lid <-> phone resolution table #349) — still a bare number, not the saved name the user expects, so it does not solve this request.

Scope

• I understand some features are limited by the underlying WhatsApp engine (e.g. Baileys can only surface the saved name if WhatsApp delivered it via contacts/history sync).

[rmyndharis]

Thank you for such a thorough and well-researched report, Ulises — this is genuinely a model issue. I confirmed every part of your root-cause analysis against the current code:

• The dashboard is indeed not at fault: dashboard/src/pages/Chats.tsx already does chat.name || chat.id.split('@')[0] (sidebar L702-703, header L737, and L974).
• The name is dropped server-side in src/engine/adapters/baileys-session-store.ts — toNeutralChat() returns name: c.name ?? this.userPart(c.id) and never cross-references the contacts map, even though the saved name (name/verifiedName/notify), the lidToPn map, and resolvePhone() all already live in that same store.

You're also right that this is distinct from #349/#362: those are about @lid → phone resolution, whereas this is a name-only concern that should work even when the number can't be resolved. I agree the backend is the correct place to fix it (single source of truth, avoids racy client-side joins).

One coordination note: there's an open PR (#342, engine-neutral identities) that rewrites this exact method, though only cosmetically — it does not add the contact-name fallthrough you're describing, so this remains open work. To avoid a merge conflict we'll most likely fold the resolveContactName() priority chain into that effort (or land it immediately after). Your illustrative sketch is essentially what we'll implement, with the saved Contact.name winning, then verifiedName, then notify (pushName), and the raw user part only as a last resort — plus unit tests for the bare-number and @lid paths.

Marking this as an accepted enhancement. Thanks again for locating the exact line and proposing a clean, engine-neutral fix.