[Standards] XMPP Council Minutes 2018-06-06
jonas at wielicki.name
Wed Jun 13 07:10:52 UTC 2018
First of all, thanks to Georg for making Sam clarify his position, which I
misread similarly. Thanks to Sam for clarifying, this makes *much* more sense
now. I think you two rehashes the key parts. I’d like to chime in as a
developer who recently implemented support for the MUC voice request flow in a
client library and as the author of the proposed change.
On Dienstag, 12. Juni 2018 20:34:26 CEST Sam Whited wrote:
> On Tue, Jun 12, 2018, at 13:19, Georg Lukas wrote:
> > 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).
> > …
> > 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.
> Documenting seems like the thing to do here then; especially if whatever
> workarounds people are using right now could be a part of this
Okay. I don’t actually know how a MUC implementation behaves when the voice
request flow is used without support. I heard that you get a <not-acceptable/>
back for trying to send a (non-groupchat) message to the bare MUC JID. This
might be worth documenting after investigating whether this is true.
I am still in favour of a disco#info feature. I would personally make my
client depend on that disco#info feature. Full stop. I think the voice request
flow is used rarely enough (if at all) to allow it being not available unless
the server explicitly announces support.
> > Maybe the right next step would be to get rid of the invitation flow
> > completely instead?
I assume that Georg meant the "voice request", not the "invitation" flow.
> I wouldn't mind this, I don't like all of MUCs complicated IRC-like
> features. Unfortunately, I suspect that we can't at this point. I'd be
> curious to know how the community and other council members feel about this
I would be totally fine with cutting out the voice request flow out of '45
into a separate XEP, or dropping it altogether. It is a weird bit of protocol
which, even with the disco#info feature, is not reliable: the MUC service has
no way to know that any of the moderators will be able to handle the voice
request form. So even *if* the service announces that feature, the client will
have to provide a UX flow which makes it clear that the voice request may be
handled in +infty time (i.e.: not at all, because no moderator supports that
feature). This makes it pretty useless / prone to extremely horrible UX. I
think this may be one of the things which work in a closed system (like
Ephemeral Messages), but don’t make too much sense in generic IM clients.
I only realized this after making the pull request, and I fully understand if
Council rejected the suggestion based on this argument and suggests to remove
the voice request flow altogether (possibly by cutting it out into a
kind regards & thanks all,
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards