From 012aa8fba4e8cfe63e15fc97dff15941c5e7b107 Mon Sep 17 00:00:00 2001 From: Keyvan Fatehi Date: Sat, 11 Mar 2017 13:57:08 -0800 Subject: [PATCH 1/4] fixes * Moved matrix-puppet-bridge out of one-way and into two-way * Fixed server to server heading --- supporting-docs/guides/2017-03-11-types-of-bridging.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) 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 22b61289..d79ff13c 100644 --- a/supporting-docs/guides/2017-03-11-types-of-bridging.md +++ b/supporting-docs/guides/2017-03-11-types-of-bridging.md @@ -38,7 +38,7 @@ Some remote systems support the idea of injecting messages from ‘fake’ or This is a richer form of bridging, where the bridge logs into the remote service as if it were a real 3rd party client for that service. As a result, the Matrix user has to already have a valid account on the remote system. In exchange, the Matrix user ‘puppets’ their remote user, such that other users on the remote system aren’t even aware they are speaking to a user via Matrix. The full semantics of the remote system are available to the bridge to expose into Matrix. However, the bridge has to handle the authentication process to log the user into the remote bridge. -This is essentially how the current [matrix-appservice-irc](https://github.com/matrix-org/matrix-appservice-irc) bridge works (if you configure it to log into the remote IRC network as your ‘real’ IRC nickname). [matrix-appservice-gitter](https://github.com/matrix-org/matrix-appservice-gitter) is being extended to support both puppeted and bridgebot-based operation. It’s also how kfatehi’s [puppeting bridges](https://github.com/matrix-hacks) work for iMessage, Facebook Messenger, Slack etc, and how the experimental [matrix-appservice-tg](https://github.com/matrix-org/matrix-appservice-tg) bridge works. +This is essentially how the current [matrix-appservice-irc](https://github.com/matrix-org/matrix-appservice-irc) bridge works (if you configure it to log into the remote IRC network as your ‘real’ IRC nickname). [matrix-appservice-gitter](https://github.com/matrix-org/matrix-appservice-gitter) is being extended to support both puppeted and bridgebot-based operation. It’s how the experimental [matrix-appservice-tg](https://github.com/matrix-org/matrix-appservice-tg) bridge works. Going forwards we’re aiming for all bridges to be at least one-way puppeted, if not two-way. @@ -46,8 +46,10 @@ Going forwards we’re aiming for all bridges to be at least one-way puppeted, i 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; we’re not aware of any who have implemented this yet. The main blocker 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). -Server-to-server bridging +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). + +### Server-to-server bridging + Some remote protocols (IRC, XMPP, SIP, SMTP, NNTP, GnuSocial etc) support federation - either open or closed. The most elegant way of bridging to these protocols would be to have the bridge participate in the federation as a server, directly bridging the entire namespace into Matrix. We’re not aware of anyone who’s done this yet. From b314b308129e6f20896b7f309d64d8084787efc8 Mon Sep 17 00:00:00 2001 From: turt2live Date: Sat, 11 Mar 2017 16:49:49 -0700 Subject: [PATCH 2/4] Add matrix-appservice-instagram --- .../2017-02-23-matrix-appservice-instagram.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 supporting-docs/projects/2017-02-23-matrix-appservice-instagram.md diff --git a/supporting-docs/projects/2017-02-23-matrix-appservice-instagram.md b/supporting-docs/projects/2017-02-23-matrix-appservice-instagram.md new file mode 100644 index 00000000..ae931980 --- /dev/null +++ b/supporting-docs/projects/2017-02-23-matrix-appservice-instagram.md @@ -0,0 +1,14 @@ +--- +layout: project +title: matrix-appservice-instagram +categories: projects as +description: Bridges Instagram to Matrix +author: Travis Ralston +maturity: Alpha +--- + +# {{ page.title }} + +This is a Node.js application that bridges Instagram to Matrix. The project is still in early development and is not intended for production use (yet). + +The source (and more information) can be found on [GitHub](https://github.com/turt2live/matrix-appservice-instagram). From 9304d6d71d2e0d5fdd6012a4a27b9c5f4e092613 Mon Sep 17 00:00:00 2001 From: Andreas Zwinkau Date: Tue, 14 Mar 2017 21:57:25 +0100 Subject: [PATCH 3/4] Fix device keys query Omitting the "device_keys" wrap results in an empty response. --- supporting-docs/guides/2016-10-18-e2e_implementation.rst | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/supporting-docs/guides/2016-10-18-e2e_implementation.rst b/supporting-docs/guides/2016-10-18-e2e_implementation.rst index 39a51d3f..fdb2c69c 100644 --- a/supporting-docs/guides/2016-10-18-e2e_implementation.rst +++ b/supporting-docs/guides/2016-10-18-e2e_implementation.rst @@ -432,8 +432,10 @@ The client should build a JSON query object as follows: .. code:: json { - "": {}, - ... + "device_keys": { + "": {}, + [...] + } } Each member in the room should be included in the query. This is then From 550884931564d8e6455a853c6d0b1185cca2c41c Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Wed, 15 Mar 2017 01:52:33 +0000 Subject: [PATCH 4/4] fix merge --- supporting-docs/guides/2017-03-11-types-of-bridging.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) 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 d79ff13c..dc02e6ff 100644 --- a/supporting-docs/guides/2017-03-11-types-of-bridging.md +++ b/supporting-docs/guides/2017-03-11-types-of-bridging.md @@ -34,17 +34,17 @@ The simplest way to exchange messages with a remote network is to have the bridg Some remote systems support the idea of injecting messages from ‘fake’ or ‘virtual’ users, which can be used to represent the Matrix-side users as unique entities in the remote network. For instance, Slack’s inbound webhooks lets remote bots be created on demand, letting Matrix users be shown cosmetically correctly in the timeline as virtual users. However, the resulting virtual users aren’t real users on the remote system, so don’t have presence/profile and can’t be tab-completed or direct-messaged etc. They also have no way to receive typing notifs or other richer info which may not be available via bot APIs. This is how the current [matrix-appservice-slack](https://github.com/matrix-org/matrix-appservice-slack) bridge works. -### One-way puppeted bridge +### Simple puppeted bridge This is a richer form of bridging, where the bridge logs into the remote service as if it were a real 3rd party client for that service. As a result, the Matrix user has to already have a valid account on the remote system. In exchange, the Matrix user ‘puppets’ their remote user, such that other users on the remote system aren’t even aware they are speaking to a user via Matrix. The full semantics of the remote system are available to the bridge to expose into Matrix. However, the bridge has to handle the authentication process to log the user into the remote bridge. This is essentially how the current [matrix-appservice-irc](https://github.com/matrix-org/matrix-appservice-irc) bridge works (if you configure it to log into the remote IRC network as your ‘real’ IRC nickname). [matrix-appservice-gitter](https://github.com/matrix-org/matrix-appservice-gitter) is being extended to support both puppeted and bridgebot-based operation. It’s how the experimental [matrix-appservice-tg](https://github.com/matrix-org/matrix-appservice-tg) bridge works. -Going forwards we’re aiming for all bridges to be at least one-way puppeted, if not two-way. +Going forwards we’re aiming for all bridges to be at least simple puppeted, if not double-puppeted. -### Two-way puppeted bridge +### Double-puppeted bridge -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. +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).