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 <keyvanfatehi@gmail.com>

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