[Standards] XMPP Council Minutes 2018-06-06

Georg Lukas georg at op-co.de
Tue Jun 12 16:08:50 UTC 2018


* Sam Whited <sam at samwhited.com> [2018-06-12 17:03]:
> I'm generally opposed right now, and think changes to MUC likely do
> more harm than good, but don't let that stop us from discussing it.

Okay, let's discuss it. I see three potential (non-exclusive) approaches
here:

1) improve the documentation and discoverability of the currently
   defined / deployed behavior by doing small changes to 0045

2) improve MUC by introducing new behavior into 0045

3) create a new groupchat protocol that doesn't repeat any of MUC's
   errors (i.e. something like MIX)

Depending on how long you think the transition between "all groupchats
are MUCs" to "all groupchats are MIXes" will take(*), it makes sense to
assign different priorities to those approaches. Being a professional
pessimist, I'm putting my effort into 1 and 2, mostly.

In my eyes, even 1 makes sense to do, even if the immediate benefits are
small, because there is no other way to evolve the status quo. We might
even learn one thing or another from it for the bright MIX future. Both
1 and 2 will have some side effects, and they leave a trace of "might
not be supported by earlier implementations". On the other hand, there
is no other alternative to improve on the existing protocol.

The PR in question qualifies as 1 and *maybe* a bit of 2, and with an
according compatibility note I really don't see how it is *harming* MUC.
On the other hand, I see benefits in improving the protocol, as it is
not going to go away soon. I'm also not sure what the alternatives are,
regarding 0045. Accept it with all of its shortcomings and move it to
Final to reflect that? Deprecate it without an alternative? Only
implement new features which can be unambiguously identified by a
biconditional feature flag in disco#info?

(*) if we end up with MIX services implementing a MUC API for legacy
clients, this might be a Very Long Time.


Georg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180612/008e7a35/attachment.sig>


More information about the Standards mailing list