Using smack 4.1.0-rc1 on android, the MUC functionality works fine when the user sets the nick to exactly what we expect from that user. Sweet.
But in case the user puts in a wrong nickname (e.g. “peter”) when joining the MUC, smacks throws “XMPPError: forbidden - cancel”.
Which is correct behavior, but the experience delivered by Pidgin is way smoother, it automatically discovers the correct nickname and consequently uses that.
I can manually do that by sending a presence available to the MUC, wait for the response and use the from field to determine the correct nickname, then use MultiUserChat to join (again) with the correct nickname.
Presence p = new Presence(Presence.Type.available);
I agree. What you describe is valid behavior as per XEP-0045.
XEP-0045: Multi-User Chat
(around Example 22-23)
PacketFilter responseFilter = new AndFilter(FromMatchesFilter.createFull(room + “/” + nickname), new PacketTypeFilter(Presence.class));
This is wrong or at least incomplete and fragile (as in your use case). The packet filter should match the status code 110 OR 210 OR nickname. The only problem I see is if there’s already a nickname in the room which matches your requested nickname the join method would return before you have actually joined.
ty. You could quote that as well in your ticket (also from 7.2.3):
If the user has connected using a MUC client (as indicated on joining the room by inclusino of the MUC extension), then the service MUST allow the client to enter the room, modify the nick in accordance with the lockdown policy, and include a status code of “210” in the presence broadcast that it sends to the new occupant.