%kobit It may take less time as we already have some features on the backend prepared but it would be really nice to have this working.

Andrzej Wójcik wrote:

%kobit It may take less time as we already have some features on the backend prepared but it would be really nice to have this working.

+1

IMHO having MUC-light would be quite good "selling point" - a lot of people asks about "presence-less" muc and that solves it nicely. What's more, we already have initial implementation for MHB, so with "a little more push" we could have a complete solution.

Reference: https://xmpp.org/extensions/inbox/muc-light.html

OK, please go ahead with implementation.

We have encountered an issue here. We wanted to have MUC and MUC-Light on the same component so users of both technologies could exchange messages. However, it looks like it is not possible as MUC light specifies different result for disco#items query on the component bare JID. In the case of MUC, we get a list of rooms while in the case of MUC-Light we should get only a list of rooms in which we are participants. That is a major issue as those two specifications collide.

There are a few possible solutions:

1. Create a separate component for MUC light but use the same repository and create a bridge. This would allow occupants of MUC rooms to exchange messages with members of MUC-Light rooms, ie. by mapping room1@muc.example.com to room1@muclight.example.com. But with this solution, there would be no way to discover which room maps to which room (with except that we would know it).
2. Add support for registering nickname in the room. With this solution, we would allow a user to register a nickname in the room and mark with a registration form field that he wants to receive "notifications" when he is offline by messages sent to his bare JID. This way we would get notifications to work if XMPP server would trigger PUSH notifications on group chat messages sent to offline users bare jid.
3. Drop the idea a using MUC-Light a all and introduce support for registering nickname in the MUC room a nickname with checkbox that we want to receive notifications (as above), but instead of sending message to the users bare JID to send it directly to PUSH component (XMPP client would need to provide us with the address of its push component). _(This idea was suggested at XMPP Sprint in Dusseldorf - https://opkode.com/blog/xmpp-sprint-dusseldorf/)

I'm convinced to the second solution as XMPP server can handle this message (ie. filter the spam out) and the send proper push to the push components on behalf of the user. Moreover, it would simplify things a lot instead of adding additional complexity of having a separate component for MUC Light or handling PUSH notifications registration.

MUC Light would be the most "standard" way but support for MUC light on the client side is in Smack library (as an experimental extension) and in Mongoose client for Android, so it would still be limited.

%bmalkow %kobit %wojtek I'm holding this task and waiting for input from you on which way to take.

OK, let's go with suggested second approach.

Also, we would need support for MUC Light in our clients and libraries as well.

%kobit Using the second approach we are not implementing MUC Light at all but instead, we are creating an alternative with just simple registration form which can be easily wrapped in our clients. That would be clean and simple solution to implement for everyone.

Ah, right. So this means we are abandoning MUC light entirely?

It's shame the MUC light spec is made incompatible with MUC. It makes sense for them to coexist....

%kobit Yes, and yes it is a shame. I do not see any way to make them compatible and coexist, especially that MUC Light makes it impossible to join a room - you need to be invited (added to the room by the member).

Actually I'm not sure why MUC light prohibits discovery - it should work just fine with registration in MUC room. It seems that MUC light wanted more to model WhatsApp where there is no group discovery but rather anyone can create group and then add more people.

+1 for second approach - feels like mix of muc-light (i.e. permanent member of the room, even after disconnect/offline) with regular MUC. After reading up on 3 option I don't see benefits over (2).

%wojtek The only benefit of (3) is that it is possible to add support for MUC "offline" by adding support to MUC component and PUSH component, while in case of (2) you need support on the server side (users XMPP server).

Implementation is done and verified to work in the local standalone installation and in clustered version.