[Standards] XEP-0045 MUC: am I still there?
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
> 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...
Size: 833 bytes
Desc: not available
More information about the Standards