search

matrix-org / matrix-appservice-bridge

Bridging infrastructure for Application Services
Apache License 2.0
153 stars 73 forks source link

Double puppeting #325

Open JohnStarich opened 3 years ago

JohnStarich commented 3 years ago

Apologies if this has been requested before. I searched around various issue boards and the code, but didn't see mention of double-puppeting.

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

It appears double-puppeting is not supported today (through my limited experience), though "single" puppeting works from Matrix -> bridged service.

Describe the solution you'd like

Double-puppeting means this is done in both directions of the bridge. This is the most preferred way of implementing a Matrix bridge. – matrix.org/bridges

I tend to agree with the matrix.org docs. It'd be fantastic to support double-puppeting for the appservice bridges out there.

I'm using the Slack bridge today, so it'd be great to have a seamless experience between Matrix and Slack.

Describe alternatives you've considered

The current "single" puppeting solution works, but it invites what are essentially duplicate users to the same room. From a Matrix perspective it is cluttered, but it's also confusing to users not accustomed to bridges.

I can pitch in to help with this too, if needed 🙂

Half-Shot commented 3 years ago

Puppeting a Matrix user account (Remote -> Matrix) currently requires storing the user's own access token and using their homeserver to send messages to the Matrix room. While some bridges support this, we tend to shy away from this approach as currently Matrix only has an all-or-nothing approach to access control.

Giving the bridge access to your account means that it can access every endpoint you can, which is all the worse if you have have extra permissions (e.g Synapse allows you to set some users as "admins" which means they can hit the admin API)

With this in mind, we've so far deemed it a bit too dangerous to hold whole access tokens.

All is not lost though. If https://github.com/matrix-org/matrix-doc/issues/2889 can be solved then we could support an oauth-style system where a user gives limited access to an account so that the bridge may send messages. If that could be solved then I believe this library would very much be in favour of supporting this.

JohnStarich commented 3 years ago

@Half-Shot Great point. Restricting bot access to one's account seems like a good first step. That way there's no need to back-pedal once an oauth solution is available.

I'll follow along on https://github.com/matrix-org/matrix-doc/issues/2889, thanks!