On 5 Aug 2020, at 16:47, Georg Lukas <ge...@op-co.de> wrote: > > 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?
I would love to be able to tell clients that they should use real JIDs when available, but with the current state that would break things (as we found out when we made that change (I note that the change is still in, although it has broken things. Jury’s out on whether to revert it). I think that if we were to add a little ‘deanonymising’ protocol exchange, that might be enough to detect the situations where it’ll fail, so a client could fall back to PMs. The ones off the top of my head (of which I’ve seen (1) in the wild), although I suspect there are others: 1) The other user may not allow messages from users they don’t share presence with. So things will bounce. 2) The user may not be able to route to the other user’s server, only through the MUC (unusual but not impossible either in odd network failures, or trunking configurations). 3) A malicious MUC might cause a user to send messages somewhere they shouldn’t by advertising the wrong real JID. How much this is an imagined threat, I’m not sure, but e.g. causing audit logging of someone trying to send messages somewhere they shouldn’t might get people in hot water. I agree this is a problem worth solving. I believe the issues (at least the first) are significant enough that telling people to do it anyway is insufficient. /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
