[Standards] Addressing for IQs in MIX-CORE
kevin.smith at isode.com
Tue Jun 5 08:13:44 UTC 2018
On 4 Jun 2018, at 16:03, Dave Cridland <dave at cridland.net> wrote:
> On 4 June 2018 at 14:37, Kevin Smith <kevin.smith at isode.com> wrote:
>> On 4 Jun 2018, at 12:15, Dave Cridland <dave at cridland.net> wrote:
>> >> On 4 June 2018 at 11:37, Steve Kille <steve.kille at isode.com> wrote:
>> >> To support IQs in MIX-CORE, there needs to be an addressing and routing
>> >> scheme.
>> >> I am proposing that this uses a different scheme to messages from the
>> >> channel (this is Kev's variant 4).
>> >> The rationale for having a different scheme is that you want to be able to
>> >> distinguish from a stanza that comes from the channel, from a stanza (IQ)
>> >> that is relayed by the channel.
>> > I think that's a false dichotomy. <snip/>
>> I think calling out the language here might be a fair call (although I don’t find it too confusing), but I think the underlying dichotomy is still there. Some stanzas are sent in the context of fanout to potentially all participants, and some are sent to be distributed in private to a single participant.
> That's somewhat different - but even here, you're arguing to change the *from* address depending on where it's been sent *to*?
Both. When you send a PM/IQ to another user you send to user#channel at domain(/client-id), when the service forwards that it then comes from otheruser#channel at domain(/client-id). If you reply, you reply to otheruser#channel at domain(/client-id) and it is forwarded to user#channel at domain(/client-id). The same sort of NAT that MUC does, but with a different format (and less brokenness).
>> >> A message distributed by the channel would come from:
>> >> channel at domain/stable-participant-id
>> >> Bare JID is the channel, reflecting that the message comes from the channel.
>> >> An IQ message being relayed by the channel would come from:
>> >> stable-participant-id#channel at domain/resource
>> >> Bare JID reflects the sender, which will enable the receiver to clearly
>> >> distinguish that this is not coming from the channel.
>> >> We want to use this scheme for PMs (MIX-ANON), and here the difference
>> >> becomes more important. You want to clearly distinguish messages from the
>> >> channel from PMs, and this approach gives a framework to achieve this.
>> > So type='groupchat' is no longer enough?
>> Yes, that’s surprising isn’t it?
>> I came to this realisation a couple of days ago, not just that it’s no longer enough, but that it never was really adequate and definitely not ideal.
>> A few reasons:
>> * Elsewhere in XMPP, the ‘to’ alone is used to determine which entity receives a stanza (I’m terminating entities at the user, not each of their devices, for these purposes). That here the difference between sending to a whole group of people and a single person is predicated not on the address, but the message type, is cause for us to think twice.
> I'm not sure how the to address isn't still governing how receives the stanza. You're arguing for changing the from here, aren't you?
>> * I have seen multiple bugs from people who are not XMPP-naive in this area, because it’s very easy to slip when the to no longer gives you addressing (including security issues). This makes it easy to shoot yourself in the foot.
> Same - a message stanza from A to B has been sent from A to B. The type indicates who *else* has received this. No?
In the processing server while routing? Not really.
>> * Even where it doesn’t end up in a bug, I’ve seen bad UX resulting from this.
>> * Querying a MAM archive becomes ‘interesting’ when you want to query just room messages, or just PMs with a particular occupant
> This is an interesting and valid point, i think. I'm not convinced it's outweighing the address altering depending on the traffic used though.
Give it time :)
(It took me a while to come around to it, but once I thought through the various problems with using the same addressing for both models, it does make sense)
>> there are others, but this is a reasonable flavour, I think.
>> Now, one might assert that it’s not worth changing this in MUC, but in MIX where we have the chance to avoid all these issues it seems worth giving serious thought to alternatives.
> Absolutely - but I'd argue we want the addressing consistent irrespective of the traffic.
Is that not what this is aiming to do?
More information about the Standards