Does relay_all_normal mirror any bridged message to MUC?

[rasos]

We have set up an XMPP bridge with Rocket.Chat serving 2 MUCs and 1 JID (to a single user), using a common bridge-JID and defining separate webhooks for each room in RC. We have the result, that messages mirrored to the JID are also seen in each MUC. Is this because we have enabled at each MUC:

• relay_all_normal: true Or what exactly is this option good for? if relay_all_normal: self.outgoing_mappings['all_normal'].append(outgoing_webhook) https://github.com/saqura/xmppwb/blob/master/CONFIGURATION.rst says:

The bridge can also relay all messages received from normal JIDs. Note that this will only trigger outgoing webhooks

So, does this mirror any message which is passing the bridge-JID to the MUC, where it is set true, even if the message was not targeted to the MUC? In the sample configuration file, this option is set to true, which may be probably not the desired effect at least for our use cases. bridge.conf.anonymized.txt

[saqura]

Or what exactly is this option good for?

The intention of relay_all_normal is to forward "normal" XMPP messages that the XMPP bot receives to Rocket.Chat. Here "normal" means messages not coming from a groupchat (MUC). So if you write directly to the XMPP bot (no matter your JID) without using the MUC, than this option makes those messages also appear in Rocket.Chat.

So, does this mirror any message which is passing the bridge-JID to the MUC, where it is set true?

I'm not sure whether I fully understand your question, but with this option no new XMPP messages should be created. It should only affect Rocket.Chat.

We have the result, that messages mirrored to the JID are also seen in each MUC.

So the third bridge in your config file that bridges messages between a Rocket.Chat room and a single XMPP JID also affects the messages sent to the MUCs of the other two bridges?

[rasos]

Thanks for explaining. Well, if any message that the bot receives is forwarded, then this is not what we want. Yes, in this set-up, messages in the third bridge appear also in the Rocket.Chat room, which should bridge only to the corresponding MUC. So disabling relay_all_normal should prevent that. We'll test, but need a test machine first, can't do it on the production environment, not to confuse users in rooms.

[saqura]

I have updated the documentation in that regard and removed this setting from the sample configurations, since it might be confusing at first. I think this option is only needed for more specialized uses cases anyways.

[rasos]

Good to have the relay_all_normal not activated as default in the sample configuration, thanks for updating.

It seems we need some different kind of relaying messages from JID users, maybe you can give us a hint, how to do it. Let me briefly explain our case: We need to serve Windows Phone users with Rocket.Chat rooms. There is no chance to build a WP App for RC in a usable quality (we tried several paths, the problem is that webkit can't be included). So we thought we connect the WP users with xmpp. The only xmpp client on the market for WP is IM+, but we discovered that this one does not support MUCs (whilst the Android version does). So what we try to do is bridging JIDs to one RC room. That works in both ways (even using only one webhook for several JIDs), however if xmpp user A sends a message to the RC room, xmpp user B won't see it (also not if we set up a webhook and a RC bot for each user separately). It seems that RC is not relaying messages from one webhook to another one. Any chance to relay a message piped through xmppwb from one xmpp_endpoint to another one?

[saqura]

I understand the problem. A bridge currently works best when bridging one RC room to one XMPP MUC, as relaying messages between the XMPP parts of a bridge is not currently implemented. This might be a feature that I could add in a later version though. I have created a separate issue for this feature [#7], but I don't yet know when this will be implemented.

[rasos]

Great if that uses case could be rolled out with an enhancement of xmppwb and if it would not need any extension on RC, as asked here https://github.com/RocketChat/Rocket.Chat/issues/3721
We might back issue #7, as we have an urgent customer need for it.

[saqura]

Thank you for your interest in this, however I can't currently accept financial contributions as I have only limited time to work on this project. This feature is something that I am interested in aswell though, so I am going to implement it. Please track #7 for further updates about this.

But I think the main use of this feature is the connection of multiple XMPP MUCs (and to keep the XMPP endpoints of a bridge in sync), and not the connection of multiple "normal JIDs", since MUCs are better suited for this. You should be aware that using it like this (while it will probably work) is a workaround and I don't know how well it scales with more than a few JIDs. A better solution (and user experience) would be if the XMPP client supported MUCs, so if you have the option it might be worthwile to approach the IM+ developers regarding MUC support.

[rasos]

Thank you for considering an extension to keep XMPP endpoints of a bridge in sync. For our use case it does not need to scale, we just have to include a few WP users via a XMPP bridge. I will then follow #7. I am totally aware that MUCs would have been the better option, but the development of the IM+ clients stopped 2014 and it is the only XMPP product which is available for Windows Phones.

[saqura]

Ok, I am closing this issue then. I will update #7 for further information.