Support Mautrix DoublePuppeting over AppService

[azerbe]

Is your feature request related to a problem? Please describe.

Mautrix Double Puppeting can be configured via an shared appservice (https://docs.mau.fi/bridges/general/double-puppeting.html#appservice-method-new). It's not available for all bridges, but at least the newer ones.

• [ ] mautrix-whatsapp
• [ ] mautrix-discord
• [ ] mautrix-gmessages
• [ ] mautrix-signal

Describe the solution you'd like Configure the available bridges to use an app-service instead of the shared-secret configuration.

Additional context The application service will provide some enhancements like

• no login required (from the bridge)
• timestamp massaging will work correctly
• no ratelimiting for double puppeted messages
• no confusing "fake" session-list

[azerbe]

I might find the time to work on it, but I can't promise it.

[pm-McFly]

Maybe I am going to fast when reading it all... But the appservice token seems to be already present (as well as the registration file) isn't it sufficient ?

e.g.: https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/724021cfde5479ca5ad2961e04568cd162b7d765/group_vars/matrix_servers#L756

[spantaleev]

The documentation says:

First create a new appservice registration file. Don't touch the bridge's main registration file, and make sure the ID and as/hs tokens are different (having multiple appservices with the same ID or as_token isn't allowed).

.. so it seems like the new double-puppeting appservice registration file is a different one than what the appservice we already install.

Moreover, the new one has a regex which makes it possible to impersonate any user on the domain (regex: '@.*:your\.domain'). The existing one for the bridge is limited to the puppets that the bridge creates: https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/7766db2a5fd18a4173f6b71416486b678b94073b/roles/custom/matrix-bridge-go-skype-bridge/defaults/main.yml#L136-L139

So it seems like we'll need to generate a new appservice file, specifically for double-puppeting.. and inject it into the homeserver. Injection is currently done using the matrix_homeserver_container_extra_arguments_auto and matrix_homeserver_app_service_config_files_auto variables: https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/7766db2a5fd18a4173f6b71416486b678b94073b/group_vars/matrix_servers#L66-L190

As the documentation says, we may generate only one such file and re-use it for all bridges which support it. The downsides of using a single common double-puppeting appservice registration file are that:

• we need to figure out which role should be responsible for managing this file. It may even be a new role (e.g. matrix-bridge-assistant or matrix-bridge-double-puppeting, etc.)
• the same powerful access token will be passed to all bridges. Unique tokens would probably be better, but.. in the end it's pretty much the same thing and is no worse than what we have now (the same shared secret auth token being passed to all bridges)

[pm-McFly]

• we need to figure out which role should be responsible for managing this file. It may even be a new role (e.g. matrix-bridge-assistant or matrix-bridge-double-puppeting, etc.)

On my previous installation I was creating one per bridge and never faced an issue. Sure though that each addition/removal of a bridge forced me to restart synapse...

I guess a reuse is more convenient on that part 🤔 Although, one per bridge could allow -maybe- a more fine access tuning