Element plans to make device verification mandatory in E2E-encrypted rooms in April, and this includes appservice devices. Thus, bridges (mautrix-signal in my example below) have started to offer support for verifying themselves as well as using MSC4190 to manage their devices and reset keys if needed.
Per the comment on the encryption.msc4190 option in mautrix's example configuration, this
Requires the homeserver to support MSC4190 and the device masquerading parts of MSC3202.
I have tried enabling said option for my bridge and am seeing one of two errors with Tuwunel 1.5.0, depending on whether there is state in the database(s) or I'm starting from scratch.
Current Behavior
When starting Tuwunel and the bridge without any existing data, we get the following logs:
Tuwunel:
2026-02-22T15:16:12.410461Z ERROR tuwunel_router::request: 400 Bad Request, _debug: true, method: POST, uri: /_matrix/client/v3/keys/upload?device_id=WVEL5RGSKZ&org.matrix.msc3202.device_id=WVEL5RGSKZ&user_id=%40signalbot%3A<domain>.<tld>
at src/router/request.rs:118 on tuwunel:worker ThreadId(3)
in tuwunel_router::request::request with id=6
in tuwunel_router::layers::router with method=POST path=/_matrix/client/v3/keys/upload
mautrix-signal:
2026-02-22T15:16:12.413Z FTL Failed to start bridge error="failed to start Matrix connector: failed to share device keys: M_UNKNOWN (HTTP 400): M_UNKNOWN: Device ID in keys uploaded does not match your own device ID"
and the bridge fails to start entirely.
When enabling the option in an existing deployment that did not have it enabled before, we get:
Tuwunel:
2026-02-22T15:42:40.503796Z ERROR tuwunel_router::request: 403 Forbidden, _debug: true, method: POST, uri: /_matrix/client/v3/keys/upload?device_id=mw1r9ymRFz&org.matrix.msc3202.device_id=mw1r9ymRFz&user_id=%40signalbot%3A<domain>.<tld>
at src/router/request.rs:118 on tuwunel:worker ThreadId(4)
in tuwunel_router::request::request with id=35
in tuwunel_router::layers::router with method=POST path=/_matrix/client/v3/keys/upload
mautrix-signal:
2026-02-22T15:42:40.508Z ERR Failed to share keys error="M_FORBIDDEN (HTTP 403): M_FORBIDDEN: user must be authenticated and device identified" component=crypto trace_id=15:42:40.407626
repeatedly. The bridge can also no longer send messages (but still receive them), complaining that
the bridge hasn't received the decryption keys
Alas, I am not very familiar with the internals of either MSC...
- The error about the device IDs not matching does sound like it may have to do with device masquerading / MSC3202.
- MSC4190 was already implemented in conduwuit but received further updates since then. The main addition appears to be that the endpoint for uploading cross-signing keys no longer requires interactive authentication, presumably so that appservices can upload new keys if needed (which is likely what this comment refers to). I don't think this is causing the issues above, although it may become problematic after a bridge database wipe if
self_sign is enabled.
Perhaps someone more familiar with Matrix appservices can chime in here. 🙂
Element plans to make device verification mandatory in E2E-encrypted rooms in April, and this includes appservice devices. Thus, bridges (mautrix-signal in my example below) have started to offer support for verifying themselves as well as using MSC4190 to manage their devices and reset keys if needed.
Per the comment on the
encryption.msc4190option in mautrix's example configuration, thisI have tried enabling said option for my bridge and am seeing one of two errors with Tuwunel 1.5.0, depending on whether there is state in the database(s) or I'm starting from scratch.
Current Behavior
When starting Tuwunel and the bridge without any existing data, we get the following logs:
Tuwunel:
mautrix-signal:
and the bridge fails to start entirely.
When enabling the option in an existing deployment that did not have it enabled before, we get:
Tuwunel:
mautrix-signal:
repeatedly. The bridge can also no longer send messages (but still receive them), complaining that
Alas, I am not very familiar with the internals of either MSC...
self_signis enabled.Perhaps someone more familiar with Matrix appservices can chime in here. 🙂