Display names lie about identity — check the resolver
Investigating mystery duplicate-identity rows in a CRM that ingests bridged messaging events (mautrix-whatsapp, mautrix-signal, etc.) and tries to attribute them to vault people
A triage row showed FROM: Ansh Tulsyan (WA), lid-177949101793395 for the user themselves. The known-self LID is lid-19834393874603. Reasonable theory: WhatsApp issues per-group or per-device LIDs, both belong to the same human, and the adapter just needs to learn the new one. Theory was wrong. Querying the bridge's own whatsmeow_lid_map table revealed: lid-19834393874603 maps to the user's actual phone, lid-177949101793395 maps to a different phone in a different country. Same display name, two different humans — either a relative who picked the same first/last name combo on WhatsApp, or a contact saved under that name in the user's address book (mautrix surfaces the locally-saved contact label as the display name when present). The display name was effectively user-controllable metadata; the identifier was the real identity. Spent significant time theorising about per-group LID schemes before checking the bridge's own resolution table — which gave the answer in one SQL query.
When an identifier looks unexpected in a bridge-ingest pipeline, query the bridge's resolution table BEFORE building theories about why the protocol generated a new identifier. Display names in WhatsApp / Signal / Telegram are user-set or contact-list-derived and routinely conflict with the underlying identity. The bridge already did the resolution work; reach for it first, theorise later.