[WIP] MSC3647: Bring Your Own Bridge - Decentralising Bridges #3647
Conversation
ShadowJonathan
changed the title
turt2live
added
application services
kind:feature
| the user's account. This can be done by having the user open a DM with the HB, send a | ||
| to_device message, or to send a dummy event in the bridge room. (each have tradeoffs and considerations) | ||
|
|
||
| Verifying a platform account is tricker, as the bridged chat platform may not follow an exact format |
There was a problem hiding this comment.
I'm worried about this step. A VB could easily bridge the wrong messages for a user, or just not bridge anything at all and effectively be a malicious actor in the room.
How can the HB trust that the VB really has access to a remote users account. Even if there is initial verification, what's the process to avoid a netsplit after the VB is compromised.
One of the advantages on a monolithic bridge architecture is you only need to trust the one bridge, in this model users need to trust bridges that third parties are providing.
There was a problem hiding this comment.
The line specifically was more about that making a generic process is hard to do between radically different platforms (slack, discord, IRC)
I guess for your specific concern, a HB can initiate a verification/challenge at any point in time, to re-verify a VB.
For this specific situation, the user has to trust the VB, and then the VB has to trust the HB (and vice versa), in this case the HB will have a "hands off" approach, and assumes that the user knows what they're doing to have the VB request the HB to yield bridging of their specific user to the VB.
The trade-off is that, yes, now users need to trust third-party bridges, but if the users already trust the HB, and the HB has verified the VBs have access to their respective users, then it's a pseudo-web-of-trust.
The only security problem (and I'll update this in the text) is that yes, any VB can assume control (either voluntary or not) of a particular user's accounts, and then deny bridging their messages properly.
| removal of the need for the AS API could move these bridges to remote spots, such as user-hosted | ||
| raspberry PIs, operating itself as a "normal" matrix user. | ||
|
|
||
| # Potential Issues |
There was a problem hiding this comment.
Another noteworthy downside is the added complexity. Bridging two chat protocols is already a really complex endeavor, with a lot of subtle bugs caused by nuanced differences between both platforms. It is also inherently stateful, keeping the bridge appservice in sync with both worlds is incredibly tricky.
Thus, I'd consider adding even more complexity and even more distributed state a bad idea.
Rendered
Preview: https://pr3647--matrix-org-previews.netlify.app