From 94565933c25bf3f1ec9cc6e91e7d45a6a1706893 Mon Sep 17 00:00:00 2001 From: Keyvan Fatehi Date: Tue, 28 Mar 2017 10:49:55 -0700 Subject: [PATCH 1/2] Tempering the sales pitch of puppetted bridges. Folks are getting confused. The article sells the puppeted bridge concept a little too hard and needs to temper it with the reality that most networks people want to bridge (Facebook, Hangouts) suffer from the fact that there is no means of representation for non-puppeted users. Relevant discussions: * https://matrix.to/#/!ChuQQIVJvwyJujhNIG:synapse.keyvan.pw/$149063160814JjbEL:gruenhage.xyz * https://matrix.to/#/!svJUttHBtRMdXmEhEy:matrix.org/$149072185910105qOwCB:synapse.keyvan.pw Signed-off-by: Keyvan Fatehi --- supporting-docs/guides/2017-03-11-types-of-bridging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/supporting-docs/guides/2017-03-11-types-of-bridging.md b/supporting-docs/guides/2017-03-11-types-of-bridging.md index dc02e6ff..8f3dd938 100644 --- a/supporting-docs/guides/2017-03-11-types-of-bridging.md +++ b/supporting-docs/guides/2017-03-11-types-of-bridging.md @@ -46,7 +46,7 @@ Going forwards we’re aiming for all bridges to be at least simple puppeted, if A simple ‘puppeted bridge’ allows the Matrix user to control their account on their remote network. However, ideally this puppeting should work in both directions, so if the user logs into (say) their native telegram client and starts conversations, sends messages etc, these should be reflected back into Matrix as if the user had done them there. This requires the bridge to be able to puppet the Matrix side of the bridge on behalf of the user. -This is the holy-grail of bridging; [matrix-puppet-bridge](https://github.com/matrix-hacks/matrix-puppet-bridge) is a community project that tries to facilitate development of two-way puppeted bridges, having done so for [several networks](https://github.com/matrix-hacks/matrix-puppet-bridge#examples). The main obstacle is working out an elegant way of having the bridge auth with Matrix as the matrix user (which requires some kind of scoped access_token delegation). +This is the holy-grail of bridging, but it is elusive and difficult to achieve. Third party clients to walled gardens are typically reverse-engineered, fragile, and only allow puppeting through login, and no capability of representing other users. [matrix-puppet-bridge](https://github.com/matrix-hacks/matrix-puppet-bridge) is a community project that tries to facilitate development of two-way puppeted bridges, having done so, without a "relaybot" feature, for [several networks](https://github.com/matrix-hacks/matrix-puppet-bridge#examples). However, this type of bridge does not necessarily solve the problem of relaying communication between two disparate third party networks. For example, a Facebook user cannot talk to a Hangouts user and vice versa because practically speaking the puppeted accounts cannot impersonate or represent anyone except themselves. This can be solved using a hybrid solution in which a relay bot is used, but suffers issues already discussed above. In addition to this, we need to work out a more elegant way of having the bridge auth with Matrix as the matrix user (which requires some kind of scoped access_token delegation). ### Server-to-server bridging From 35605b4c1db1f432caa274b0b104dc426ae97170 Mon Sep 17 00:00:00 2001 From: Keyvan Fatehi Date: Sat, 1 Apr 2017 08:44:01 -0700 Subject: [PATCH 2/2] Improvements to the "types of bridging" guide Signed-off-by: Keyvan Fatehi --- supporting-docs/guides/2017-03-11-types-of-bridging.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/supporting-docs/guides/2017-03-11-types-of-bridging.md b/supporting-docs/guides/2017-03-11-types-of-bridging.md index 8f3dd938..91565bc0 100644 --- a/supporting-docs/guides/2017-03-11-types-of-bridging.md +++ b/supporting-docs/guides/2017-03-11-types-of-bridging.md @@ -46,7 +46,15 @@ Going forwards we’re aiming for all bridges to be at least simple puppeted, if A simple ‘puppeted bridge’ allows the Matrix user to control their account on their remote network. However, ideally this puppeting should work in both directions, so if the user logs into (say) their native telegram client and starts conversations, sends messages etc, these should be reflected back into Matrix as if the user had done them there. This requires the bridge to be able to puppet the Matrix side of the bridge on behalf of the user. -This is the holy-grail of bridging, but it is elusive and difficult to achieve. Third party clients to walled gardens are typically reverse-engineered, fragile, and only allow puppeting through login, and no capability of representing other users. [matrix-puppet-bridge](https://github.com/matrix-hacks/matrix-puppet-bridge) is a community project that tries to facilitate development of two-way puppeted bridges, having done so, without a "relaybot" feature, for [several networks](https://github.com/matrix-hacks/matrix-puppet-bridge#examples). However, this type of bridge does not necessarily solve the problem of relaying communication between two disparate third party networks. For example, a Facebook user cannot talk to a Hangouts user and vice versa because practically speaking the puppeted accounts cannot impersonate or represent anyone except themselves. This can be solved using a hybrid solution in which a relay bot is used, but suffers issues already discussed above. In addition to this, we need to work out a more elegant way of having the bridge auth with Matrix as the matrix user (which requires some kind of scoped access_token delegation). +This is the holy-grail of bridging because both the Matrix account and the third party account are accurately represented on their respective networks, with all user metadata intact. This is in contrast to a relaybot which would appear as a separate user from whom it represents. + +Several obstacles exist to the proper implementation of double-puppeted bridges. On the Matrix side, we need an elegant way of having the bridge auth with Matrix as the matrix user (which requires some kind of scoped access_token delegation). On the third-party network, unique problems exist depending on the limitations of that particular network network. For example, many third party networks will lack the ability to represent other Matrix users than the one being puppeted (see hybrid relaybot). + +[matrix-puppet-bridge](https://github.com/matrix-hacks/matrix-puppet-bridge) is a community project that tries to facilitate development of double-puppeted bridges, having done so, without a bridgebot feature, for [several networks](https://github.com/matrix-hacks/matrix-puppet-bridge#examples). A downside to their approach is the assumption that an individual will run the bridge on their own homeserver, thus working around the problem of sharing auth credentials on a shared homeserver. + +### Hybrid Relaybot Puppet Bridge + +This type of bridge is a combination single or double puppet bridge which tries to solve the problem of representing other users by means of the bridgebot technique. [matrix-appservice-gitter](https://github.com/matrix-org/matrix-appservice-gitter) works in this way. ### Server-to-server bridging