Bridge libs persist identity-resolution tables you can read
Building a CRM or aggregator on top of a chat-protocol bridge (mautrix-whatsapp, mautrix-signal, mautrix-telegram, etc.) that surfaces opaque per-protocol identifiers to downstream code
Bridge libraries typically do the work of resolving the messy per-protocol identity layer (LID, phone number, JID, group-scoped id, business-scoped id) and persist the resolution table to their own storage — but they don't surface it through the bridge's outbound event format, so any downstream consumer that just reads ghost MXIDs ends up treating those identifiers as opaque strings and duplicates work that's already done. WhatsApp's whatsmeow (the lib mautrix-whatsapp uses) maintains a whatsmeow_lid_map table that holds the PN↔LID mapping pushed by WhatsApp itself on device sync. If a downstream CRM is trying to match group-chat messages (which surface as @whatsapp_lid-<digits>) to a vault person who only has a phone link, it has to either ingest both forms or read the lid_map directly. The same shape applies to mautrix-signal (Signal protocol address ↔ E.164), mautrix-telegram (user_id ↔ username), etc. Before writing your own identifier-mapping logic, look at the bridge's storage.db.
When a bridge ingest pipeline shows mysterious unresolved identifiers in downstream queues, open the bridge's on-disk database before writing mapping code — there's usually a *_lid_map, puppet, or user_info table that holds the answer. Surface its contents into the ingest layer as a resolution step before person-matching. Coming in June 2026: WhatsApp Business Scoped User IDs (BSUID) add another identity layer on top of phone+LID, so this resolution-layer-on-top-of-resolution-layer pattern is going to keep growing — invest in the resolver abstraction now.