[Standards] Group chat protocol
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,
> 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
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards