androidclient
androidclient copied to clipboard
kontalk
Support for XMPP MUC
Since kontalk is already an xmpp app, being able to join muc with kontalk will allow kontalk users to join muc without needing another xmpp app. This saves battery.
Despite it's a good thing for further XMPP integration, we would like to test out our new group chat protocol on the field and, if it will be a success (we believe it will), try to standarize it through a XEP proposal.
MUC has some important problems resulting from the main idea to be IRC-like: Non-persistent occupants, nicknames, a complex permission model with roles and affiliations, much traffic. And if you want to read further:
https://stackoverflow.com/a/25993070 https://community.igniterealtime.org/thread/48020 siacs/Conversations#1372
That's why we started our own solution, for having something that everybody really wants (ASAP). But after working on the customised protocol now and reading more about MUC and other XEPs I really have major doubts about ever making this an XEP: Implementing this client side only has at least two serious flaws:
- The list of receiver must be included in every messages. It obviously wont scale well for larger groups.
- No guarantee of consistency of the list of group members: This is by design if every group member can leave by his/her own.
I believe it will work (and work GOOD), but hopefully an new standard XEP together with server support will come out suitable for todays needs of (mobile) instant messaging.
Thanks Alex for describing the longer issue (I was typing from my phone).
Persistent occupants and nicks are possible with MUC. Really, any model you could want the MUC protocol can support, pretty much.
Persistency is possible with member-only rooms, right? I have to investigate how good this would fit here.
And we don't want nicknames but the JIDs. But this could also be solved with member lists.
@abika any kind of room can be persistent or not, independent of any other settings. Every room has a persistent members list even if it isn't members-only, which you can either use or not as you prefer.
If you don't want nicknames, then you could set the room to allow any participant to discover JIDs (instead of just admins) and then join the room with whatever roomnick (maybe a JID-escaped version of the full JID)
I spend some time now hoping to overcome the problems with MUC but it wasnt really successful:
- even in a members-only room its not possible for a 'member' to get the list of users with higher affiliation ('owner' and 'admin'). So it is always possible that there are users "in" the group chat we don't know about
- + the member list does not include the JIDs. Mapping nicknames to JIDs must be done with presence stanzas, which are only send if users joined the room.
- member list updates are not queued for offline members
- too much, unnecessary traffic: presence stanzas are send for every user, every time leaving/joining a room
- + on every server re-connect all rooms must be joined again and the member list (which might have changed) must be retrieved again
- room changes do not include the initiator. Showing update messages like "Alice added Bob to this group chat" are not possible
- message history: persistent membership is also not considered here. A request like "send me all messages I haven't received yet (while I was offline)" is not in the options. It can be simulated by saving the last disconnect time and requesting all messages until that datetime. But this will be fuzzy on undetected connection lost, specially happening with mobile devices
Altogether MUC simply has too many flaws for our use-case. I would even recommend closing this issue as it is not solvable.
BTW, Conversations MUC support has some of the same problems: Group members are only shown if they "in" the room. As soon as a client disconnects, the user is removed from the occupants list and information about the membership is lost.
even in a members-only room its not possible for a 'member' to get the list of users with higher affiliation
Not sure what you mean by this? Do you mean participants (those currently in the room) or members (those registered with the room). The latter certainly could be fetched by anyone from an XMPP MUC, but of course for privacy reasons certain users may not be allowed to fetch it. This is up to server / admin configuration, though, and the protocol fully supports fetching the list.
the member list does not include the JIDs
<iq
id='member3'
to='[email protected]'
type='get'>
<query xmlns='http://jabber.org/protocol/muc#admin'>
<item affiliation='member'/>
</query>
</iq>
<iq id='member3' type='result' to='[email protected]/Gajim-liberty' from='[email protected]'>
<query xmlns='http://jabber.org/protocol/muc#admin'>
<item jid='[email protected]' affiliation='member'/>
<item jid='[email protected]' affiliation='member'/>
<item jid='[email protected]' affiliation='member'/>
<item jid='[email protected]' affiliation='member'/>
</query>
</iq>
Seems to contain JIDs. The MUC needs to be set to allow your user to see JIDs (again, for privacy reasons this may be disallowed on some servers with some settings).
member list updates are not queued for offline members
Not sure what you mean by this. Would you not re-fetch the list when re-joining the room?
presence stanzas are send for every user, every time leaving/joining a room
How would you propose to know when a user has left/joined otherwise? I guess you could requery for the list next time a user looks at the UI? In which case you could use CSI to filter the presence queries.
message history
I believe MUC MAM gives you a lot more control that the current system. As you observe, getting history since datetime is already supported, however.
Conversations MUC support has some of the same problems: Group members are only shown if they "in" the room
... that sounds like a feature, no? Though certainly can be worked around by using membership lists instead (if MUC is configured to allow you to query it, see above)
Do you mean participants (those currently in the room) or members (those registered with the room).
Doesn't matter. For the request it's not important if the user has joined the room or not.
The latter certainly could be fetched by anyone from an XMPP MUC, but of course for privacy reasons certain users may not be allowed to fetch it. This is up to server / admin configuration, though, and the protocol fully supports fetching the list.
Hmm, no. https://xmpp.org/extensions/xep-0045.html#revokeadmin
If a non-owner attempts to view or modify the admin list, the service MUST deny the request and return a <forbidden/> error to the sender.
Seems to contain JIDs.
Yes, sorry. I meant it does not contain the nicknames for finding out which occupant sent a message.
Not sure what you mean by this. Would you not re-fetch the list when re-joining the room?
I have to. But fetching a long list on every re-connect which might didn't even change is not very efficient.
How would you propose to know when a user has left/joined otherwise?
I simply don't care. Its not important for the group chat. And presence information is already send for all roster contacts.
I meant it does not contain the nicknames for finding out which occupant sent a message.
Oh, right, because those can change.
the service MUST deny the request and return a
error to the sender
Interesting. That "MUST" is definitely one to talk about on the standards list... Since then you can only fetch admin in a "groupchat" style muc (where everyone should be owner). Seems like something the spec could maybe be changed.
Hi, what is the latest thinking on this? XEP-0369 doesn't seem to have progressed ?
