Project

General

Profile

Mediated invitations to members-only MUC rooms

Jay Cothran
Added almost 5 years ago

Hello,

I have a couple of questions related to mediated invitations to members-only MUC rooms:

1) I noticed in the "doInvite" function of the "MediatedInvitationModule", that the invited contact is automatically added to the room's member list as is suggested in paragraph 7.8.2 of XEP-0045. However, in the "doDecline" function, the invited contact is not removed from the room's member list if the invitation is formally declined. Wouldn't it make sense to remove the contact from the room's member list if they decline the invitation?

2) For my application it is necessary that mediated invitation messages (and decline messages) be eventually delivered to the intended recipient even if they are offline at the time the message was originally sent. It seems that the OfflineMessages component (with possibly the help of the MessageAmp component) have the necessary functionality to accomplish this. But I don't see how to make the connection between failed delivery of the mediated invitation and decline messages and the offline message components. Any suggestions on how to do this would be greatly appreciated.

Thanks, Jay


Replies (31)

(1)
Avatar?id=6098&size=32x32

Added by Bartosz Małkowski TigaseTeam almost 5 years ago

1)

Hard to say. In basic scenario yes - it makes sense. But look at this: what if one of member use this mechanism to ping someone (X) who is already member of member-only room, but he not joined? X is busy and he press "decline". Then automatically he will be removed from members list.

To do it better we should redesign invitations: MUC will not add affiliation on doInvite() but adds invitation data to separate db table, and when invitation will be confirmed then MUC will set affiliation.

(1)
Avatar?id=6098&size=32x32

Added by Bartosz Małkowski TigaseTeam almost 5 years ago

2)

Our OfflineMessages ignores messages with no . So simply you can add any with human readable message about invitation, or you can update filters in OfflineMessages.

(1)

Added by Jay Cothran almost 5 years ago

1)

My concern is more with the other side of the coin. Let's say that X is invited to join the room and declines. Now the members of the room might not realize that X is still a member of the room (and XEP-0045 says access by members to the member list is optional.) So at some later time the members may introduce confidential material into the room thinking that it won't be seen by X. But since X is still a member of the room, X can enter the room at any time and retrieve the room history. Since one of the main reasons for members-only rooms is privacy, this seems to be a big hole.

(1)

Added by Jay Cothran almost 5 years ago

2)

I constructed the following mediated invitation message with an added as you suggested:

<message to="7241_90691118324532@muc.xps570win8" xmlns="jabber:client">
    <body>Some extra invite text</body>
    <x xmlns="http://jabber.org/protocol/muc#user">
        <invite to="836504-7241@xps570win8">
            <reason>Join my room!</reason>
        </invite>
    </x>
</message>

This invite is delivered correctly if the invited contact is online when the invite is sent. However, if the invited contact is offline when the message is sent, it is still not being delivered when the contact comes back online.

(1)
Avatar?id=6098&size=32x32

Added by Bartosz Małkowski TigaseTeam almost 5 years ago

I made some changes in MUC code. Now it should forward from invitations.

Added by Jay Cothran almost 5 years ago

Thanks for making these changes! What version of the server do I need to be able to run the latest MUC snapshot?

(1)
Avatar?id=6098&size=32x32

Added by Bartosz Małkowski TigaseTeam almost 5 years ago

It should works with any 5.3 snapshot.

Added by Jay Cothran almost 5 years ago

I am having difficulty building the latest tigase-muc snapshot. I have built the server (Tigase-5.3.0-SNAPSHOT-b3527) and PubSub (tigase-pubsub-3.0.1-SNAPSHOT). I have attached a copy of the console log.

Are there other steps I need to do?

Thanks, Jay

TigaseMUCBuild.txt (3.23 KB) TigaseMUCBuild.txt tigase-muc build log
(1)
Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam almost 5 years ago

First build the server:

kobit@devel tmp $ rm -rf server

kobit@devel tmp $ git clone https://repository.tigase.org/git/tigase-server.git server
Cloning into 'server'...
remote: Counting objects: 35579, done.
remote: Compressing objects: 100% (8073/8073), done.
remote: Total 35579 (delta 23872), reused 32790 (delta 21714)
Receiving objects: 100% (35579/35579), 30.27 MiB | 257.00 KiB/s, done.
Resolving deltas: 100% (23872/23872), done.
Checking connectivity... done.

kobit@devel tmp $ cd server

## !! Make sure you are in devel branch....
kobit@devel server $ git checkout devel
Branch devel set up to track remote branch devel from origin.
Switched to a new branch 'devel'

kobit@devel server $ mvn clean install
# ...
[INFO] Installing tigase/tigase-server/5.3.0-SNAPSHOT/tigase-server-5.3.0-SNAPSHOT.jar
[INFO] Writing OBR metadata
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 11.385s
[INFO] Finished at: Sat May 24 12:24:30 PDT 2014
[INFO] Final Memory: 30M/175M
[INFO] ------------------------------------------------------------------------

Then build the muc:

kobit@devel tigase $ rm -rf muc

kobit@devel tigase $ git clone https://repository.tigase.org/git/tigase-muc.git muc
Cloning into 'muc'...
remote: Counting objects: 3621, done.
remote: Compressing objects: 100% (2900/2900), done.
remote: Total 3621 (delta 1691), reused 217 (delta 115)
Receiving objects: 100% (3621/3621), 608.92 KiB | 221.00 KiB/s, done.
Resolving deltas: 100% (1691/1691), done.
Checking connectivity... done.

kobit@devel tigase $ cd muc

## !! Make sure you are in devel branch....
kobit@devel muc $ git checkout devel
Branch devel set up to track remote branch devel from origin.
Switched to a new branch 'devel'

kobit@devel muc $ mvn clean package
# ...
[INFO] Building jar: /Users/kobit/Dropbox (Tigase)/projects/tigase/muc/target/tigase-muc-2.3.0-SNAPSHOT-sources.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 5.906s
[INFO] Finished at: Sat May 24 12:20:19 PDT 2014
[INFO] Final Memory: 23M/123M
[INFO] ------------------------------------------------------------------------

Added by Jay Cothran almost 5 years ago

Thank you for your quick response. I managed to get the server built with the new MUC and PubSub snapshots. Unfortunately it looks like the changes that Bartosz made to the MUC did not resolve my problem. The mediated invites are still not being stored and forwarded. I have attached the "tigase-console" log and the "tigase.log.0" log from my test. Line numbers of note in the "tigase.log.0" log:

1529 First user (906911-7241) begins logon

2041 User sends mediated invite to user 836504-7241 who is offline

2096 Final processing of mediated invite by [message-archive-xep-0136, amp, message-carbons]

2098 User 906911-7241 sends unavailable presence to begin logoff

2278 User BOSH session terminated

2279 User 836504-7241 begins logon

2513 User is connected

2518 User sends iq query for server version, server disco#info, and amp disco#info

2669 User 836504-7241 sends unavailable presence to begin logoff

I noticed that between line 2082 and line 2083 the extra fragment is stripped out, apparently by MUC. I don't see any indication that the message is being stored for offline delivery.

Avatar?id=6098&size=32x32

Added by Bartosz Małkowski TigaseTeam almost 5 years ago

I apologize!

By mistake I commited changes to "master" branch instead of "devel" branch.

I'm sorry for misleading!

Now this commit is in "Devel" branch! (And in "master").

(1)

Added by Jay Cothran almost 5 years ago

No problem! These things are bound to happen sometimes. I built the "master" branch and tried it out. First the good news. The mediated invite messages are being forwarded nicely to the intended recipient. Good work! Now the bad news. The decline messages are not being forwarded back to the original user who sent the invite. I am getting better at understanding the Tigase logs and I believe these two log entries tell the story:

2014-05-26 19:30:42.165 [in_2-message-router]  MessageRouter.processPacket()  FINEST:   1. Packet will be processed by: muc@xps570ubuntu, from=sess-man@xps570ubuntu, to=null, DATA=<message from="836504-7241@xps570ubuntu/tigase-2" id="1" to="7241_90691170654662@muc.xps570ubuntu" xmlns="jabber:client"><body>Some extra decline text</body><x xmlns="http://jabber.org/protocol/muc#user"><decline to="906911-7241@xps570ubuntu"><reason>No reason given</reason></decline></x></message>, SIZE=299, XMLNS=jabber:client, PRIORITY=NORMAL, PERMISSION=AUTH, TYPE=null

2014-05-26 19:30:42.244 [in_7-message-router]  MessageRouter.processPacket()  FINEST:   Processing packet: from=null, to=null, DATA=<message from="7241_90691170654662@muc.xps570ubuntu" to="906911-7241@xps570ubuntu" xmlns="jabber:client"><x xmlns="http://jabber.org/protocol/muc#user"><decline from="836504-7241@xps570ubuntu/tigase-2"><reason>No reason given</reason></decline></x></message>, SIZE=258, XMLNS=jabber:client, PRIORITY=NORMAL, PERMISSION=NONE, TYPE=null

Note in the first log entry when the packet is routed by the session manager to the MUC the extra fragment is in the packet. In the next entry when the MUC is processing the packet, the fragment is missing. The packet goes on to be processed by message-archive-xep-0136, amp, and message-carbons, but not by msgoffline.

(1)
Avatar?id=6098&size=32x32

Added by Bartosz Małkowski TigaseTeam almost 5 years ago

Question: Decline message isn't delivered to original sender when original sender is offline? The same problem what we had with invite message (I didn't added code to copy in decline message)?

(1)

Added by Jay Cothran almost 5 years ago

Yes, this is exactly the same issue with the decline messages that you addressed with the invite messages. I didn't realize that your solution was a one-off just for invite messages (I didn't look at the new code.) I guess this is a good time for me to mention that there will almost certainly be additional messages that will have the same issue. In particular, for my application, I will need the functionality of section 7.10 of XEP-0045, "Registering with a Room". If no one else is working on that, I will (attempt) to do it myself. There are at least two messages in that section that will need to be delivered offline. This brings up the question: shouldn't it be possible to use AMP to cause all these messages to be stored if they can't be delivered? Unfortunately I have not had any success at all attempting to use AMP with MUC. I will open another thread regarding AMP with MUC when I have done more testing. Should that thread be here or in the server forum?

(1)

Added by Wojciech Kapcia TigaseTeam almost 5 years ago

Jay Cothran wrote:

This brings up the question: shouldn't it be possible to use AMP to cause all these messages to be stored if they can't be delivered? Unfortunately I have not had any success at all attempting to use AMP with MUC. I will open another thread regarding AMP with MUC when I have done more testing.

We had a discussion about that and were going to suggest that it may be better to change how AMP handles storing messages and enable more slack rules that would enable storing for example invites. Right now we are limiting what is being saved to only store 'concrete' messages. Nevertheless it may still be implemented as an option disabled by default.

Which in turn brings us to the question - what exactly would you want to store there?

Should that thread be here or in the server forum?

As AMP is part of server then tigase-server project's forum would be the best for that.

Added by Jay Cothran almost 5 years ago

Could you please clarify what you mean by "concrete" messages? The short answer to your question is that ALL messages need to be reliably delivered by the server. My application is a mobile app. Mobile connections are intermittent and unreliable. Additionally, iOS in particular may unload an app from memory if the user switches away for even an instant causing the connection to be closed. Transactional workflows, such as "Registering with a Room", must be able to be completed reliably. Currently the server doesn't even send a failure message back to the originating client if it doesn't deliver or store a message. I had the same problem during my tests of AMP. In some of my tests AMP generated an error message which was not delivered back to the sender. I'm not picking on Tigase here. I had very similar problems with ejabberd. That's one reason I'm working with Tigase now. I believe the work being done by XSF to extend XMPP for use in the "Internet of Things" (XEP-0323 - XEP-0326) represents a huge opportunity. But these types of applications require absolutely reliable delivery. This is a chance for Tigase to differentiate itself.

(1)

Added by Jay Cothran almost 5 years ago

After further thought, it would seem that the easiest first step would be to open up full AMP processing to all stanzas. AMP already touches every stanza anyway. If a client doesn't want to make use of that capability, then just don't include AMP processing elements in the stanzas.

(1)
Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam almost 5 years ago

Jay Cothran wrote:

After further thought, it would seem that the easiest first step would be to open up full AMP processing to all stanzas. AMP already touches every stanza anyway. If a client doesn't want to make use of that capability, then just don't include AMP processing elements in the stanzas.

AMP does not touch every stanza. Only stanzas with AMP payload. Actually only messages with AMP payload.

Added by Jay Cothran almost 5 years ago

My mistake. I was confusing AMP Component with amp plugin.

(1)
Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam almost 5 years ago

It doesn't matter. Neither the AMP component or AMP plugin touches every stanza. There is a part of amp plugin which has the same logic as Message plugin but the AMP logic is only fired up when there is an amp payload.

(1)

Added by Jay Cothran almost 5 years ago

I just looked through the MessageAmp plugin code. It is currently requesting/processing "presence" and "message" stanzas. What are the issues with having the MessageAmp plugin process "iq" stanzas as well and pass them to AMP if they contain "amp" processing rules?

(1)
Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam almost 5 years ago

There is no "issue" with it. Processing IQ stanzas was not necessary, needed or even useful, so the plugin does not process them. For performance reasons we make our code to do less than more whenever possible.

(1)

Added by Jay Cothran almost 5 years ago

I think the people who are developing new clients are the ones in the best position to say what features are useful or not.

(1)

Added by Wojciech Kapcia TigaseTeam almost 5 years ago

Jay Cothran wrote:

I think the people who are developing new clients are the ones in the best position to say what features are useful or not.

That is correct and we are listening to all feedback, but prior to that we have to make decisions how to implement features to offer best compatibility matched with best performance.

Please keep in mind that by default XEP-0079 should be applicable to <message/> stanzas but because our implementation also handles offline messages it was specified to handle also presence messages. It is clear that previously and even currently our logic doesn't store all messages (vide invitations) but we are assessing those request and add them if needed and with good rationale; this is to avoid storing absolutely all stanzas, which as Artur said - makes little to no sense - imagine storing all presence changes (in some cases this may be useful, but it's out of scope of the standard/extensions) or all IQ ping requests/responses (et al.).

Back to the original topic of storing MUC related stanzas - you've said:

The short answer to your question is that ALL messages (…)

which doesn't really answer the question. Please note above and list all MUC use cases for which you think that server should store all stanzas addressed to offline user and then deliver them later.

Btw. I think that in terms of delivery reliability XEP-0198: Stream Management looks like a better fit.

Added by Jay Cothran almost 5 years ago

First of all let me say that I appreciate the time and effort that the Tigase team has put in trying to understand and respond to the needs of my app. As you know, I am new to Tigase and still learning the server and how to effectively communicate with the team. I realize, of course, that you have limited resources and sometimes conflicting requirements that need to be weighed against each other. Again, I appreciate your patience.

A little bit of an overview might be helpful. My app makes extensive use of persistent, non-public, members-only MUC rooms, which can be called "closed" rooms for short. This type of room has somewhat different workflow and use-case scenarios than the more common "instant" rooms and even persistent, "open" rooms. At a high-level, communication in a "closed" room can be thought of as a combination of "chat" and "e-mail". That is, there is significant asynchronous communication between users who may not be "in" the room at the same time. This holds true for workflow too, such as room invitations and registering with the room. These all need to be able to be accomplished asynchronously.

Let me clarify my comment that all stanzas need to be delivered. What I should have said was that all stanzas (excluding presence for now) need to be handled to resolution. By that I mean that either the intended action of the stanza is carried out or a notification is returned to the sender indicating that it was not possible to carry out the requested action. As an example, as the MUC implementation currently stands, if a user declines an invitation to join a room and the intended recipient of the decline message is offline, the server does not inform the sender that the decline message could not be delivered. The decline message just disappears. I have had some similar experiences with AMP. It seems that AMP often does not send back error messages to the sender when it is unable to process an AMP request.

So, specifically what MUC related stanzas need to be stored for offline delivery? Initially, certainly invitations and declines (note that these are both message stanzas) and all stanzas involved in the "Registering with a Room" workflow (XEP-0045, sections 7.10 and 9.9). Other scenarios that I can see are, for example, granting moderator or admin role for a room. For a "closed" room these might occur when the "grantee" is actually not in the room (for instance, I'm leaving on vacation and want to make someone else the admin of a particular room while I am gone. They might not actually be in the room when I do that.) Since XEP-0045 specifies that notifications for these types of role changes are done via presence stanzas, this might be a case where presence needs to be stored for offline delivery. It seems almost certain that there are enough use-cases that a general purpose solution, probably using AMP, is more efficient than implementing one-off solutions on a case-by-case basis.

Regarding reliable delivery, I took a closer look at XEP-0198. Even discounting the overhead of additional traffic that XEP-0198 implies (which is probably not a good fit for mobile apps) it really does not address the kind of "end-to-end" delivery reliability that I had in mind. This is more closely addressed in XEP-0184, "Message Delivery Receipts", although some features of XEP-0022, "Message Events" would be quite useful in this regard (unfortunately XEP-0022 has been deprecated.) I noted with interest that the Introduction of XEP-0184 says that similar functionality might be achieved by extending AMP with a "receipt" condition, although that would probably not be as easy as it sounds.

Thanks all!

Jay

(1-25/31)