Self-identity isn't a single value on bridged platforms
Building a personal CRM that recognises 'this message was sent by the user' across multiple bridged messaging platforms (WhatsApp, LinkedIn, etc.) so it can route outbound vs inbound correctly
Every reasonable shape for 'who is the user' ends up wrong on WhatsApp. The phone number is stable in 1:1 DMs but vanishes in group chats, replaced by a lid-<digits> opaque ID called a Linked Identity. The user's LID itself can be multi-valued — different LIDs per group, per device, per relink — so a static env config (MATRIX_SELF_PLATFORM_IDS in our case) that knows one LID will fail to recognise the user in any group where they joined under a different LID. Symptom: their own outbound messages in those groups arrive with from-id != known-self-id, get classified direction='in', and pile up in the triage queue indistinguishable from messages they actually need to triage. Worse, even if self-identity recognition were perfect, group-chat outbounds are fundamentally unactionable in any 1:1-resolution triage UX — there's no single 'other party' to attribute them to, so they have to be skipped at ingest or dismissed in bulk; resolve makes no sense for them.
Model 'me on platform X' as a Set with a discovery hook, not a static config. Pull self-identifiers from a me-tagged vault person at adapter startup (and refresh on a TTL), so adding a new LID via the same UI that adds any other identifier just works. And special-case group-chat outbound at the normalisation layer — either skip ingest entirely (the source-of-truth lives in the live chat anyway) or tag them as unrouted_outbound so the UI can offer dismiss-only with no resolve affordance.