[Standards] Group chat protocol
andrew.nenakhov at redsolution.ru
Tue Jun 5 19:28:23 UTC 2018
пн, 4 июн. 2018 г. в 16:10, Dave Cridland <dave at cridland.net>:
> (Same as '45?)
Problems with 0045 come not from it's message format, but from it's attempt
to be just like IRC, but over XMPP.
>> - 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.
Well, it's only purpose to provice backwards compatibility. So far biggest
issues might come from rtl languages. And we put it as 'Server MAY add
sender nickname:\n before body' in docs, not MUST
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.
It depends on protocol implementation. Server may assign some randomly
generated names like NiceTuba88 and random image as avatar. Clients may
send nicknames and avatars right on joining conferences. Not too hard and
actually not too important. There are some issues with UX of joining
conferences and having to enter new nickname/provide an additional avatar,
so in our clients we'd rather opt for default behavior of sharing current
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).
Just register a spare JID. It won't work only in anonimous group chats with
restricted access (where someone knows your real JID anyway since you were
invited there). If access to anonymous group chat is public, registering a
spare JID takes... like a minute?
> * 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.
Not that we don't plan to implement some form of messaging between group
chat entities. Quite the opposite, we do, and inviting to chat telling your
own JID is exactly it. Likewise we plan to do some kind of interface for
bots&stuff, eventually. What we plan to restrict is chat between users,
because it drags a whole slew of problems: users will next want to have a
message archive for PMs, next they'll want e2e in PMs, you get the picture.
Taken to the extreme group chat will become a quazi-XMPP server, with
rosters, presences, message archives, pubsub nodes and privacy lists.
> 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 use-cases.
Of course private protocol is quicker to design. And with all due respect,
XMPP community is already 10 years late to the party, with no end in sight.
The main hurdle is attempt to serve everyone's needs. Like those very
narrow privacy-related border cases that almost always can be circumvented
at the exepense of users who are affected by them. But while catering to
these few we still don't have a viable solution for 95% of users who simply
want to chat in groups, and care not about sharing their real usernames,
avatars, phones and birthdays in their vCards. XMPP was on the rise up to
~2008 but since that time has lost all it's steam and utterly failed to
compete with the likes of WhatsApp, Viber, Telegram and Slack - despite
having a potential to become as indispensable as email is today. We need to
move faster if we want XMPP to succeed.
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.
To be honest, it is exactly our plan. As one prominent member of XMPP
community once said, it's ok if you start a marketing campaign and get
people to implement it.
Директор ООО "Редсолюшн" (Челябинск)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards