Open azerbe opened 8 months ago
I might find the time to work on it, but I can't promise it.
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 ?
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:
matrix-bridge-assistant
or matrix-bridge-double-puppeting
, etc.)
- 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
ormatrix-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
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.
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