Mautrix ghost MXID encoding leaks into your matchers
Building an ingest pipeline that consumes Matrix bridge events and tries to attribute messages to known contacts by native platform identifier
Mautrix bridges encode the remote-network user id into a Matrix-localpart-safe form before composing the ghost MXID — uppercase letters become _lowercase, special characters become =NN hex escapes (MSC1717 / matrix-appservice-bridge convention). For platforms with all-digit/all-lowercase native ids (Telegram, WhatsApp, Discord), this round-trips invisibly. For platforms whose native ids contain uppercase or punctuation (LinkedIn URN ids like ACoAAAFa3ECBrHGOB…, iMessage emails with @), what reaches your downstream is the encoded form (_a_co_a_a_a_fa3_ec_b_r_h_g_o_b_…, alice=40example.com). Any matcher that compares this to human-readable identifier stores in your CRM/vault silently never matches, so messages pile up in your triage / unmatched queue and look like a different bug (broken person-matching, missing links, etc).
Before debugging 'my matcher is broken' against Matrix-bridged events, dump a raw from.platform_id from triage and check if it looks like it ran through Matrix-localpart escaping (lots of leading _ before lowercase letters, or =NN hex). If so, decode in the normalisation layer (invert _X → X-uppercase, =NN → hex char) before sending to the matcher — and add a one-shot migration for already-ingested rows.