[Standards] Group chat protocol
lists at opkode.com
Wed Jun 6 06:08:20 UTC 2018
On Sun, Jun 03, 2018 at 07:30:48PM +0500, Ненахов Андрей wrote:
> To whom it may concern, we're working on group chat solution for XMPP.
> It is quite a simple solution that we feel is good enough to counter most
> issues of XEP-0045.
Is this an extension/modification of XEP-0045, or is this a completely different groupchat
> It is quite simple:
> * Group chat is listed in a roster, we use standard xmpp subscription to
> join-leave group chats
As with MIX.
> * Clients can differentiate group chat contacts from regular contacts in
> their rosters by a specially formatted presence.
> * Sending messages to group chat is done by sending messages to group
> chat JID
> * Group chat server resends messages to everyone but sender with
> special formatting, that includes unique message ID, sender nickname,
> sender JID, avatar hash.
This would be a very helpful improvement. I added support for showing avatars
in MUCs recently and ran into these issues:
1. Can't fetch avatars when the user is no longer in the room
2. Can't know for sure whether archived messages sent from a particular nickname
is from the same user who currently has that nickname, so when you fetch the
avatar, you might be getting the wrong one.
> For older clients, we provide a plaintext
> body that starts with nickname:\n before actual message.
> This way allows a client to display everything they need without
> fetching data from a list of group chat members. Avatar hash is also a
> filename so avatar can be retrieved from a server when needed.
> * Non-anonymous groups transmit real user JID, semi-anonymous transmit
> JID assigned to this user for identification purposes.
> * Nicknames and avatars are retrieved from user's vCard when he joins
> the group. Can be redefined later by user
> * No private messages support. XMPP is already a protocol for private
> messaging. In non-anonymous groups users can contact each other
> directly. In semi-anonymous groups, users can send a special message
> (via group) to other users that would disclose their real JID to the
> user they want to talk to. If the recipient accepts he can add him to
> his personal roster and chat privately.
> * Clients can fetch a list of group chat members and turn on/off
> receiving updates. We imagine users of big groups of 300+ users don't
> really want to receive presence data all the time, but might want to
> open a list of participants and see who's online.
> Group chat also provides a centralized message archive, so members can
> fetch chat history directly from group chat server.
> Advantages of this approach:
What approach? The "centralized message archive" or the whole "group chat" protocol?
> * Simple
> * Compatible with existing clients
> * Compatible with existing servers
> * Easy to implement in any XMPP client
It's not clear to me what exactly is compatible with existing clients and
servers, only fetching archived messages?
> Parts of it are already implemented (we run it on modified ejabberd), we
> already use it for internal communications. It is also already supported
> in a web version of Xabber. I expect a mid-July release with support in
> Web, Android and iOS versions of Xabber. Most likely we'll also make a
> Gajim plugin, but a bit later and maybe not fully featured.
> Admin stuff is not yet done. Most likely will be somewhat akin to Telegram
> group chats model. Admins can be granted rights by owners and other
> admins, users can be restricted by admins.
> Anyone interested to try it can connect with me
> xmpp:andrew.nenakhov at redsolution.com, I'll invite you to existing
> groupchat we made. Best way to try is to connect using development
> version of Xabber, https://web.xabber.com/develop/
> For now, it's limited (and sometimes breaks ;) ) and you can only join
> already created group chats, I think we'll also add permissions for
> anyone to create group chats on our server.
> Documentation for all of this is now in a somewhat inconsistent state (and
> is also in Russian), we changed a number of things from our original plan
> and our proto-protocol spec is now already outdated at some places, I plan
> to fix it next week and translate to English.
> Important notice. I fully understand that it is almost inevitable that
> we'll now receive a very big share of criticism from people who won't like
> this and that and how we do everything wrong. We will release support for
> this protocol in our clients and server no matter what because we need it
> for our product and we can't wait until this MIX enormity somehow settles
> down. Thus said, we're very open to constructive feedback, and since this
> functionality is in very active development we might consider changing
> some things.
I'd prefer further enhancements to be added to XEP-0045 or in a way that's
compatible with XEP-0045, like dropping GC 1.0 and adding support for the
"am-I-still-connected" IQ (or presence?) that Ge0rg suggested last year as well
as some of the things mentioned here.
More information about the Standards