[Standards] Group chat protocol
andrew.nenakhov at redsolution.ru
Wed Jun 6 06:50:29 UTC 2018
ср, 6 июн. 2018 г. в 11:08, JC Brand <lists at opkode.com>:
> Is this an extension/modification of XEP-0045, or is this a completely different groupchat
Completely different. XEP-0045 is beyond repair.
> > * 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
Unlike XEP-0045, there is no such thing as 'user no longer in the
room'. Avatar is fetched once a user subscribes to a groupchat.
Unless his server becomes unavailable immediately, we can fetch his
avatar and store it on a groupchat server.
> 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.
Messages are stored in an archive with unique JID or UUID assigned to
user. Server implementation might allow or prohobit different
users occupying same username. Correct avatar is sent with each
message. We're debating internally what to do with messages in
One approach is to store them with avatar/username so that when loaded
from archive they'll always bear nick and avatar that was attached to
it when it was sent. Another approach is to store them in archive with
just a sender JID and load it with current nick-avatar. Personally I'm
the former approach, but might concede this point since I don't think
it's too imporant, because client should be able to display user's id
and messages belonging
to this user.
> What approach? The "centralized message archive" or the whole "group chat" protocol?
> It's not clear to me what exactly is compatible with existing clients and
> servers, only fetching archived messages?
Group chat. Clients that are unable to work with groupchat archive
will be unable to fetch it's history prior to joining groupchat, all
will be stored only on their local server archive (0313). Also they'll
see all messages to be incoming from one jid, but formatted like:
Hello everyone, I joined brand new group chat
Hi there o/
Works almost seamless for clients that do not display sender jid every
time (bubbled ones), slightly worse with those that always display
name inline, like Gajim.
> 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.
Ge0rg's crusade to save 0045 is commendable, but is as hopeless as any
crusade after the 4th one. As I said earlier, it's beyond repair.
We were thinking many years about this, did several custom
implementations of groupchat for some of our customers that addressed
some 0045 flaws, and this undertaking of ours was taken only after
exploring available options.
Директор ООО "Редсолюшн" (Челябинск)
More information about the Standards