[Standards] XMPP Council Minutes 2018-06-06

Georg Lukas georg at op-co.de
Tue Jun 12 18:19:12 UTC 2018


Hi Sam,

thanks for taking the time to explain your position. I (mis)read your
earlier statement as a generic opposition to any changes to MUC, but
this is much more nuanced actually.

* Sam Whited <sam at samwhited.com> [2018-06-12 19:16]:
> The problem as I see it is that, no matter how simple this change is,
> it adds complexity for new and existing implementations.

The complexity isn't added by this change (except for adding another
element to disco#info), it is there already. Clients don't have a way to
check for this feature right now, so they need to implement whatever
workaround the authors come up with. Therefore, we are just better
documenting the situation (Maybe somebody can even provide a
recommendation for how to handle this uncertainity, which would be a
good addition at this place).

I voted for this change because it is the first of two steps to
eventually get rid of this complexity - first we create a postitive
indicator for the feature, then, after sufficient time has passed and
most implementations were updated, we can determine that clients can
rely on this indicator and get rid of the legacy fallback mechanism,
like we got rid of the old group-chat protocol (the one prior to GC1).
While yes, this is a breaking change, it won't matter much at the time.

> Assuming I already supported the voice request flow this just adds a
> shortcut I can take sometimes (which requires more logic in my
> client).

Or you just keep everything in place for the next N years.

> If I didn't support it but want to, it doesn't make it any easier to
> support because I likely have to implement such a workaround anyways.

Except that now the author is explicitly made aware of the situation,
instead of stumbling into a <not-implemented/> situation reported by a
small subset of their users.

> Also, let's take a step back, why are we doing this anyways? Is this a
> feature that's widely used? Is it something that is actually needed to
> fulfill some requirement for MUC, or are we just making changes for
> the sake of fixing mistakes even though they're not actually a
> problem?

I don't know how widely *this* feature is used, and can't answer that.
However I think there are multiple other places in MUC that needs to be
"fixed" in a similar way, so for me this is kind of a proxy issue.

Maybe the right next step would be to get rid of the invitation flow
completely instead? Or to generalize the data-form-in-message into
something that can be used for polls, bot dialogs etc.?

> Finally, let's think about how this affects the future. [MIX]

I was speaking of MUC in general, and don't have an answer regarding
this specific feature.

> However, having an "alternative" implies that something needs to be
> done to MUC, and I'm not sure that anything necessarily needs to be
> done to it right this moment unless there are more seriouos problems
> that can be addressed without breaking things.

You mean things like

- incorrect treatment of MUC-PM Carbons by almost all implementations,
- the weird interactions between user MAM, MUC messages and MUC-PMs (of
  which we will see more in the future, when there are more MAM client
  implementations),
- the mess that is caused by real-life connection issues meddling with
  your joined-ness in a MUC, playing leapfrog games with GC1.0, and the
  clumsy workaround dance that client developers need to dance[0],
- the legacy compatibility dance that a client needs to perform to match
  an incoming MUC reflection to a message sent by the user[1],
- the problems arising from some new MUC implementations sending
  presence from the bare MUC JID,
- the lack of reliability of direct/mediated MUC invitations because of
  imprecise MAM/Carbon rules?

Some of these can be addressed without breaking anything. Other changes,
like getting rid of GC1.0 will "break things" - or rather expose how
broken they are already. It might be painful sometimes, but I'm
committed to doing them anyway, because in the end it will benefit the
users and improve the reliability of XMPP.

<Attention, anecdote time>
Recently, I asked a Matrix user what they do when Matrix loses messages,
and their answer was: "that never happened". Maybe they were a lucky
person, and maybe Matrix is full of holes in their message DAG, but I
know for a fact that every time XMPP loses a message, it is also losing
credibility as a protocol and market share as an IM network(*).


Georg

[0] https://wiki.xmpp.org/web/XEP-Remarks/XEP-0045:_Multi-User_Chat#Am_I_still_there.3F

[1] https://wiki.xmpp.org/web/XEP-Remarks/XEP-0045:_Multi-User_Chat#Matching_Your_Reflected_Message

(*) Except for spam messages. XMPP is losing every time one of them is delivered.
-------------- 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/4d0064d9/attachment.sig>


More information about the Standards mailing list