"chat" command is incompatible with Prosody's mod_muc

[GoogleCodeExporter]

It is presently impossible to use gtalksms's "chat" command with chat rooms 
hosted by the Prosody XMPP server. As documented in 
<http://code.google.com/p/lxmppd/issues/detail?id=328>, Prosody is not 
compatible with smack's MultiUserChat.create(). This command requires the "room 
locking" behavior in XEP-0045, which prosody does not implement. Attempts to 
create() a chat room will fail, since even newly-created rooms manifest 
themselves as old, existing rooms.

In addition, Prosody's chat room configuration form (see Example 157 of 
http://xmpp.org/extensions/xep-0045.html#createroom-instant) does not implement 
all of the options that gtalksms attempts to set. Specifically, it does not 
implement:

muc#roomconfig_passwordprotectedroom : A password is used if and only if 
muc#roomconfig_roomsecret is not empty. This option is redundant, so it is not 
included in the configuration form.

and

muc#roomconfig_roomowners : This isn't included in the form for whatever 
reason. It is still possible to grant owner status with a muc#admin query as 
per Example 172 at <http://xmpp.org/extensions/xep-0045.html#grantowner>. It is 
also worth noting that muc#roomconfig_roomadmins doesn't exist in the form 
either.

This would cause gtalksms to raise an exception and fail when it can't find 
either of these options.

An alternate flow would be necessary in order to make gtalksms compatible with 
prosody. An example flow would be:
1. join the room
2. get the room's configuration form and attempt to set:
2.1. muc#roomconfig_membersonly. If this fails, then
2.2. muc#roomconfig_roomsecret. Then set muc#roomconfig_passwordprotectedroom, 
but only if it exists.
2.3. If neither of the above are present, error. 
3. submit form and wait for confirmation; error if it fails
4. ensure the list of users contains only gtalksms; exit with error if it does 
not
5. grant owner access to the controlling jid
6. send invite and start relaying messages

Are patches on this issue welcome?

Original issue reported on code.google.com by cbs...@gmail.com on 18 Apr 2013 at 7:36

[GoogleCodeExporter]

Patches are always welcome, but be aware that they get reviewed and usually the 
first version of patch has to be reworked. But that's perfectly normal and a 
healthy process. :) Thanks for your detailed problem description.

But on first though I think that this should be fixed on the XMPP library layer 
so that other apps benefit from it too. Plus I have to take a closer look on 
the problem first. I am not sure how to fix this elegant on library level and 
usually implementing workarounds for incomplete feature sets, where mandatory 
features are missing are a bad idea.

You are welcome to join to ##smack @ freenode, idle a bit and discuss this 
topic with us.

Original comment by fschm...@gmail.com on 19 Apr 2013 at 6:38

[GoogleCodeExporter]

Sure thing. If you'd like to do some of your own testing, it appears that 
conference.jabber.hot-chilli.net is a public Prosody MUC which will allow 
private, "members only" room creation.

A potential fix may involve generating a predictable error condition (maybe an 
exception) whenever MultiUserChat.create() manages to join a room that already 
exists. Some library-level room configuration routines might also help smooth 
over some of the problems I've discovered above.

Original comment by cbs...@gmail.com on 19 Apr 2013 at 8:31

[GoogleCodeExporter]

Issue 332 has been merged into this issue.

Original comment by Florent....@gmail.com on 1 Oct 2013 at 9:19

[GoogleCodeExporter]

Hello

Can you test the new release 4.4.1.
It might solve this issue

Thanks

Original comment by Florent....@gmail.com on 1 Oct 2013 at 9:30

[GoogleCodeExporter]

No, with version 4.4.1 I still get the "Error: MUC creation failed for ______: 
Creation failed - Missing acknowledge of room creation" when attempting to 
start a chat.

I am still using prosody (version 0.9.1-1~wheezy) as the server for gtalksms. 
As noted above, Prosody has some questionably standards-compliant behavior with 
regards to room creation.

Original comment by cbs...@gmail.com on 2 Oct 2013 at 12:09

[GoogleCodeExporter]

Which server can I use to avoid this error? How would I implement it?

Original comment by HoopahMa...@gmail.com on 14 Apr 2014 at 2:09

[GoogleCodeExporter]

A workaround might be to use MultiUserChat.join() if a MultiUserChat.create() 
failes on prosody.

Original comment by fschm...@gmail.com on 15 Apr 2014 at 6:20

[GoogleCodeExporter]

This one should work: conference.jwchat.org
Don't forget to check the setting forceMucServer.

I will check for the join method instead the create one.

Thanks

Original comment by Florent....@gmail.com on 15 Apr 2014 at 7:50

[GoogleCodeExporter]

Any news about this issue ? Thanks in advance !

Original comment by eclair...@gmail.com on 11 Jun 2014 at 6:28

[GoogleCodeExporter]

aSmack 4.0 comes with MultiUserChat.createOrJoin() which when used will fix 
this issue. So simply every replacing occurrence of MultiuserChat.create() with 
createOrJoin() will (should) fix the issue.

Original comment by fschm...@gmail.com on 10 Aug 2014 at 9:05

[GoogleCodeExporter]

Original comment by Florent....@gmail.com on 15 Aug 2014 at 2:46

• Changed state: Started

[GoogleCodeExporter]

This issue was closed by revision 69d509588ef3.

Original comment by yako...@gmail.com on 15 Aug 2014 at 2:52

• Changed state: Fixed

[GoogleCodeExporter]

Fixed in 4.4.5

Original comment by Florent....@gmail.com on 15 Aug 2014 at 7:18

• Changed state: FixedInBeta

[GoogleCodeExporter]

Released on Play Market as 5.0

Original comment by Florent....@gmail.com on 25 Oct 2014 at 6:23

• Changed state: Deployed