[Standards] XEP-0045 MUC: am I still there?

Georg Lukas georg at op-co.de
Thu Apr 12 09:19:36 UTC 2018

* Florian Schmaus <flo at geekplace.eu> [2018-04-12 09:28]:
> A different approach would be to define an am-I-still-here IQ send to
> the bare MUC address:

Yes, this was one of my initial proposals in the October mail.

> Advantages I see here is
> - The MUC does not intercept IQs

This is not quite true. A MUC must intercept all IQs and redirect them
to some random client (or the bare JID) of the respective participant

>   - Hence it is not so easy to produce an implementation which would
>     leak MUC nicknames

I'm not sure how you arrived at that conclusion.

> - We sidestep the "IQ to MUC participant" problematic
> - We do not add  additional semantic to xep199 pings

the main disadvantage is: we need to give MUCs a feature indicating that
they support it. Clients need to query for that feature (additional
round-trip), and implement the self-ping dance anyway for MUCs that
don't. So while I agree with you that it's a cleaner approach, it adds
even more complexity to the clients, at least in the "short term" until
all MUC implementations have improved and been rolled out on the servers
out there.

> I think I would slightly favour this approach.

It surely is the better long-term approach, but as there seems to be
general consensus that MUC can't be fixed anyway and that MIX is Our
Savior, I'd like to go on with the self-ping hack. I'm convinced that it
provides the same client-side functionality at the same overhead (minus
one disco#info and minus obtaining your own nickname, but you should
know that anyway).

-------------- 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/20180412/2c461b79/attachment.sig>

More information about the Standards mailing list