search

saqura / xmppwb

XMPP Webhook Bridge [Archived]
MIT License
73 stars 8 forks source link

Automate bridge creation #9

Closed rasos closed 5 years ago

rasos commented 8 years ago

The xmppwb bridge is a great tool to involve some xmpp users, channels and rooms e.g. in Rocket.Chat. However, it needs manual configuration in bridge.conf

I would like to start a discussion, which steps, scripts and elements would be needed, to automatically generate a bridge.conf file and sync all users, conversations and channels to a jabber server, so that people could simply choose, either to use an xmpp client or (in our case) Rocket.Chat. This is also a requirement discussed here: https://github.com/RocketChat/Rocket.Chat/issues/404

  1. Syncing user accounts is probably the easiest part, if done through a common directory service, such as LDAP. So each Rocket.Chat user can also login with the same account at ejabberd using a preferred native client, such as Conversations for Android.
  2. Maintaining the bridges would require queries using e.g. a REST API: https://rocket.chat/docs/developer-guides/rest-api/ and populate that to the bridge.conf file (or a simple database in future).
  3. Much more tricky would be definitely the other way round: When an xmpp user invites a user to a MUC and the user accepts, trigger to add the same user in the corresponding room in Rocket.Chat.
saqura commented 8 years ago

Regarding configuration: I am planning to add another more flexible way of configuration into xmppwb so that more customization is possible without going through the abstraction of the current YAML config file. I am thinking about configuration through a python script which can include custom code that hooks into events like webhook reception. This allows things like custom webhook formats where the python script extracts the relevant fields and passes them back to xmppwb.

Regarding "deeper" integration with Rocket.Chat and RocketChat/Rocket.Chat#404: I have thought about what level of integration is possible when I started working on xmppwb, but the Rocket.Chat Webhook and REST APIs are not designed for basically mirroring and syncing the whole state with a different architecture like XMPP. Some concepts like syncing who is online in a Rocket.Chat room and the corresponding XMPP MUC would require the Rocket.Chat core itself to handle the XMPP connections (to connect Rocket.Chat users as XMPP dummy users to the MUC and the other way round etc.), as I think that even using Meteor DDP would not provide enough control. Furthermore, not all concepts translate one-to-one from Rocket.Chat to XMPP.

Some things like mirroring direct messages between XMPP users to the Rocket.Chat UI would require Rocket.Chat itself to be the XMPP server in order to extract the conversations (which would be a rather hacky solution). At this point it would have been easier to use XMPP as the core in the first place and design Rocket.Chat as an XMPP web client.

I tried to be clear about the level of integration that xmppwb provides when I announced it in RocketChat/Rocket.Chat#404, and I also agree with the comments by @benlangfeld in that thread.

Regarding your three points specifically: Your first point is probably possible without any changes to Rocket.Chat or xmppwb the way you described.

For your second point, you could write a script that queries the list of rooms from the Rocket.Chat REST API and generates an xmppwb config file that contains corresponding bridges. You could use a Rocket.Chat outgoing webhook that listens on all public channels and use that for each bridge so that you don't have to manually create a webhook for each channel. With the configuration improvements I have in mind it could then be possible to filter the webhook messages depending on the channel they came from. However, incoming Rocket.Chat webhooks have to be directed to a specific channel, so this would be a problem.

Your third point is an example of an XMPP<->Rocket.Chat integration that I think is too "deep" to accomplish externally.

In any case, xmppwb is designed to be a general webhook<->XMPP bridge. So instead of features specifically tailored to Rocket.Chat I think it is better to add features that are of general use, like the configuration changes I mentioned. These can then of course be used in personal configurations to better bridge to e.g. Rocket.Chat.