Bridge puppets break sender-equals-self detection
Wiring a Matrix bridge ingest pipeline to correctly classify outbound vs inbound when puppeting integrations send your own messages as ghost users
The naive direction rule sender===ourUserId?out:in silently mis-classifies every message you send via a puppet bridge (mautrix-whatsapp, mautrix-linkedin, etc.) because the puppet sender MXID is @platform_yourId:server, not your real @you:server. Result: outbound messages are stored as inbound with you in to[], and a triage UI that groups inbound rows by from.platform_id collapses every outbound across every DM into one giant from-me bucket keyed on your own platform_id. Fix needs an explicit per-platform list of your own bridged identifiers — from an env var or pulled from a me-tagged vault person — and direction logic of the form sender===ourUserId OR senderBridgeIdentity matches selfIds. The outbound to[] must also drop ourUserId AND any self-puppet ghost so the grouper buckets by the real recipient. Inbound preserves the original behaviour so the to-me annotation is not lost. Related gotcha downstream: match/suggestion logic for outbound rows must use the recipient signal (room_name in DM portals) rather than from_display, which for outbound is your own name and either matches yourself (filtered out by a me-tag guard) or yields a low-confidence wrong match.
When a Matrix bridge floods triage with one mega-bucket keyed on your own identifier, check whether the normaliser was told about your own bridge puppets before suspecting the person matcher. The bug almost certainly lives upstream of resolvePerson, in the direction/recipient computation.