[Standards] Group chat protocol

Dave Cridland dave at cridland.net
Mon Jun 4 11:09:25 UTC 2018

On 3 June 2018 at 15:30, Ненахов Андрей <andrew.nenakhov at redsolution.ru>

> 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.
> It is quite simple:
>    - Group chat is listed in a roster, we use standard xmpp subscription
>    to join-leave group chats
> So you're thinking that a presence subscription to a groupchat should
equate to a groupchat message subscription (but not, as I understand
things, a groupchat presence subscription)?

That sounds pretty horrible, but I see why you've done it.

>    - Clients can differentiate group chat contacts from regular contacts
>    in their rosters by a specially formatted presence.
> I think that's the case with '45. Seems fine, as long as you're "specially
formattng" by just plonking in an extension element.

>    - Sending messages to group chat is done by sending messages to group
>    chat JID
> (Same as '45?)

>    - Group chat server resends messages to everyone but sender with
>    special formatting, that includes unique message ID, sender nickname,
>    sender JID, avatar hash. 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.
> I'm fine with stuffing data into the messages, in general terms. I worry
about putting routing info in, but I can live with it. Stuffing data into
the text is very horrible.

>    - 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
> I'd be a little concerned with that approach in anonymous rooms, but I
think that the general principle of the service pulling information from
the endpoint for relay is fine.

>    - 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.
> Yeah, that's definitely something I disagree with.

I see two problems immediately:

* Sometimes, anonymous users are anonymous because they want to interact,
even in PM, without disclosing their identity. This is particularly true -
I think - in e-health cases (though ask Winfried Tilanus about that).
* Sometimes, occpuants of a groupchat can be services (bots and other
things) which really benefit from knowing the context of the interaction -
ie, which room this is.

So I think having PMs is useful - this is unfortunate, because otherwise a
"decloak" is indeed much cleaner and simpler to implement.

>    - 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.
> Seems fine. I think this is in MIX too.

> Group chat also provides a centralized message archive, so members can
> fetch chat history directly from group chat server.
> Advantages of this approach:
>    - Simple
>    - Compatible with existing clients
>    - Compatible with existing servers
>    - Easy to implement in any XMPP client
> 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@
> 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.


The problem with standardisation is that it takes time. It takes time
because we have lots of discussions. The discussions hopefully are the
route to a solid, flexible protocol.

A private protocol is quicker to design, and will work fine for your narrow

Where I *will* start to argue very hard against you is where you start to
put this into other software and essentially try to standardise it through
the back door.

> --
> Ненахов Андрей
> Директор ООО "Редсолюшн" (Челябинск)
> (351) 750-50-04
> http://www.redsolution.ru
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180604/a27a8b82/attachment.html>

More information about the Standards mailing list