fix merge

pull/977/head
Matthew Hodgson 7 years ago
commit 95fe2c3d82

@ -432,8 +432,10 @@ The client should build a JSON query object as follows:
.. code:: json
{
"<user_id>": {},
...
"device_keys": {
"<user_id>": {},
[...]
}
}
Each member in the room should be included in the query. This is then

@ -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 arent 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. Its also how kfatehis [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. Its how the experimental [matrix-appservice-tg](https://github.com/matrix-org/matrix-appservice-tg) bridge works.
Going forwards were aiming for all bridges to be at least simple puppeted, if not double-puppeted.
@ -46,7 +46,7 @@ Going forwards were 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 double puppeted bridges, having done so for several networks. 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; [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

@ -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).
Loading…
Cancel
Save