[Standards] MUC-PMs or direct messages in non-anon rooms (XEP-0045)

Georg Lukas georg at op-co.de
Wed Aug 5 15:47:19 UTC 2020


Hi,

MUC-PMs are prone to errors, have weird interactions with Carbons, MAM
and other specs and require the recipient to be in the room at the time
of delivery. While I don't want to abolish them altogether, there is a
compelling IM use case for direct messages to replace PMs: non-anonymous
MUCs (which have gained significant popularity in times of OMEMO).

Late last year, I tried to sneak in normative language into XEP-0045 to
RECOMMEND this behavior:

> Private messages are meant to hide a user's real JID from occupants
> they are talking to. In non-anonymous rooms, a client SHOULD NOT
> resort to private messages, but instead make use of direct messages to
> the other occupant's real bare JID. However, if the user knows the
> other JID for other reasons, e.g.  because they are a room admin,
> private messages SHOULD be used anyway.

https://github.com/xsf/xeps/pull/854

However, Council was not amused by the strict wording:
https://mail.jabber.org/pipermail/standards/2019-November/036630.html

One of the problems brought up was that direct messages might be
blocked, whereas PMs will pass through because of the previous directed
presence to the MUC. I'm not sure if there is a(n easy) way to solve
this problem, but I still think it's worth discouraging IM clients from
sending PMs in non-anonymous MUCs.

I've seen it multiple times that users were confused why a "chat with
ge0rg" opened from a MUC is different from a "chat with ge0rg" opened
from the roster. It would be great to unify those.

Are there any other corner cases that need to be considered?

Is it worth trying to get this as a normative change, or rather as
informative guidance for IM client developers?


Kind regards

Georg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200805/77e44a31/attachment.sig>


More information about the Standards mailing list