Possible to pick up XMPP messages sent to a specific user and post to Mattermost? #84
Comments
|
Just thinking about this a little more; an even cooler thing would be to limit the TO and FROM scope so messages from user Y to user X can be gateway'd but all others 'ignored'. This would allow the gateway to react only to VALID broadcasts and ignore the 'chatter'. You can see its really only the broadcasts that I'm interested in putting through the gateway. |
|
The broadcast messages are direct messages though ? |
|
Well, in the example I posted the gateway receives the 'broadcast' as a The gateway see's this for a groupchat The group message is of type groupchat. Next up is this is the format/syntax for a broadcast/private message;
I guess the key is group chat is of type = groupchat and a message is of type = chat It is clear the gateway is receiving the feed of messages and groupchats from the jabber gateway and is simply not parsing it if it isn't of type = groupchat. (Joins Leaves and Status Updates of users are being ignored which is expected). Could the answer be as simple as changing the gateway to pick up on messages of type = chat rather than groupchat? It can't be that easy can it? I have absolutely no concerns about Direct Messages as the service I wish to bridge is broadcast only - indeed, we don't use it for group chats in any form; purely for mass notifications via the broadcast extension to our XMPP service. |
|
The problem is that there is no difference between a direct (or private) and a broadcast message. The difference between a public chat or a direct/private/broadcast is clear, that's not the issue. To allow broadcast means to allow relaying direct/private messages. Not everyone will want that. (will need to have some config to allow specific senders). And yes, it'll be probably as easy to pick up type=chat to allow this :) |
|
That would be incredible. I have zero go experience and wouldn't have a clue how to amend/compile/build. I note as well, although probably shouldn't in this thread that the gateway stops working after about 5 minutes of being idle. Status updates (away, available etc) stop updating. Is there someway to keep-alive as it seems like the heart-beat is too slow to keep the connection alive? The user I am using to access the XMPP service disappears from the jabber MUC - although I can see no error messages in the matterbridge stream. [EDIT] [EDIT2] Matterbridge -debug produces no messages - but the gateway stops working. Any ideas? This is all I see in the -debug trace>> Then in Jabber, 6 minutes and 30 seconds later - 16:57:23 = XXXXX left the room No error messages. Matterbridge simply stops receiving/sending. |
|
@rupertd the keepalive issue should be fixed now, could you try latest master ? |
|
I will give it a try. Thanks a million. |
|
Confirmed; time-out not occurring now. Awesome. Many thanks. |
|
Thamks for testing and reporting back :) |
|
Given I had to un-newbie myself with GO in order to run the latest master I also tried changing the XMPP.go to listen for CHAT instead of GROUPCHAT as described earlier in this thread. My method was to CD into the /github.com/42wim/matterbridge from your latest master, change xmpp.go to read The expected behaviour for message type="groupchat" to no longer work did occur. Here's the trace (with sensitive stuff removed)....
Both message types arrived in matterbridge; but neither was parsed with line 112 set to type of chat. It works normally with that line set to groupchat. Is there some other subtle code pointing to groupchat perhaps? The only difference in a v.Type of CHAT is it includes the additional active xmlns syntax and of course the change of message type from groupchat to chat. One step forwards! Must be something I was doing wrong in trying to run the GO application? At least we proved that your new MASTER deals with the xmpp timeout issue. Many thanks for that! [EDIT 2 - one day later] It is closer! A message to the ROOM in the MUC >> A Direct Message (IM) to the target user >> PROGRESS! At least I can see now that a DM is attempting to be transmitted by the MATTERBRIDGE GATEWAY but nothing arrives in mattermost. I just see the debug status that the message was sending...but nothing arrives. I assume the place to look now is somewhere between the gateway itself and the mattermost bridge. This is now very deep in turf I have no idea about. I thought I'd give it a try. I'm no developer. Indeed, it was a stretch for my limited capabilities even getting matterbridge to work for a GO INSTALL :-) The is the same; the only difference is jabber including the attribute in the message payload. Could that be what is stopping it working? I'll leave this use case on the very much wanted list but is beyond my ability to conjur! At least I have learned how to go get and go install if nothing else! |
|
basically duplicate of #191 |
I have successfully integrated XMPP jabber into mattermost 3.5. Conversations in a MUC room in XMPP are being gatewayed into the relevant channel in mattermost. So, the normal and expected behaviour there is working as intended for routine chats in a conference room.
A scenario we face a lot with our XMPP environment is that 'broadcasts' are sent to ALL users on the XMPP service via an extension to it as a 'broadcast service'; which I'd also like to relay to the mattermost channel via the integration. I can see that the broadcast xmpp messages are being received by the Gateway. Here's a recent example;
<message to="[email protected]/xxx" type="chat" xml:lang="en" from="[email protected]/xxxx"><body>Please don't forget to update your packs - there are new items added with the Update/Patch This was a web broadcast from xxxxx to xxxxx at xxx </body></message>It would be really neat if all communications that are VALID for a XMPP user are capable of being gatewayed into Mattermost. Not too sure that I've explained the scenario that well; but I gave it a try. Would it be possible to screen for all messages to [email protected]/xxx by Jid so that those are parsed and presented via the Gateway?
We rarely use the XMPP service for user Direct Messages; more just as a listening service to receive these broadcasts over. For a large group of us its a very fast end easy way of receiving targeted information and it would be incredible to gateway these broadcasts through into Mattermost too.
The text was updated successfully, but these errors were encountered: