[Standards] XMPP Council Minutes 2018-06-06

Jonas Wielicki 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
> documentation.

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
> idea.

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 
Historical XEP).


kind regards & thanks all,
Jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180613/777d28a1/attachment.sig>


More information about the Standards mailing list