[Standards] MIX Proxy Jids are People Too

Kevin Smith kevin.smith at isode.com
Thu May 24 16:31:47 UTC 2018

On 24 May 2018, at 16:52, Dave Cridland <dave at cridland.net> wrote:
> So the crux of my discussions about MIX proxy jids and stanza types with Steve is that, as much as possible, messages should be carried in message stanzas that behave normally, and presence should be carried in presence stanzas that also may be treated as much as possible like any other presence stanza.
> For example, if my client chooses to block (or simply ignore) traffic from a given proxy-jid, it should just work. No additions to MIX are needed, nor any additions to my home server.
> That's not to say that entities are forbidden from handling a request to block an occupant in some special manner - but the fact it might just work is very appealing to me.
> This doesn't just apply for naive clients and servers - all of which must have some MIX knowledge, after all. It applies within those servers to limit the areas of the codebase which require the MIX knowledge.
> To my mind, any proposal to deviate from "normal" XMPP requires quite a compelling argument behind it.

One such argument is that it resolves the weirdness we’ve got in MUC where currently a message from an occupant JID could be ‘from’ two different entities. It could be a PM from the user, or it could be a message from the MUC room posted by the user (this depends whether your mental model is that you are posting into a room, or the room is a relay, I realise). 

If you get a message and you want to reply to it, what JID do you send it to? Whatever it’s from, right? Unless it’s from a MIX, in which case you have to change from the proxy JID to the room JID, under your suggested model.

Either model breaks the normal XMPP model - sending from the bare JID breaks it in the way you note, sending from the proxy JID breaks the expectation that to reply to a stanza you flip the to/from.

I can potentially be swayed on this, but I don’t think that sending from the channel is obviously a more significant deviation than sending from the proxy JID.


More information about the Standards mailing list