[Standards] Addressing for IQs in MIX-CORE

Jonas Wielicki jonas at wielicki.name
Mon Jun 4 14:43:38 UTC 2018

On Montag, 4. Juni 2018 15:37:00 CEST Kevin Smith 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.
> >> 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 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. * 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
> 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.

I think this is a good point, and I’ve run into this quite a few times when 
implementing MUC. Branching on the message type where 'groupchat' is somehow 
special, but then again only if it does *not* come from the bare JID, and if 
it *does* come from the bare JID, you may be confused (but that happens, in 
fact). And non-groupchat messages from the bare JID have a different semantics 
than non-groupchat messages from the occupant JID (I’m only talking about MUC 
here). This is weird, and I think if MIX does away with that, that would not 
be too bad.

A random side note: I found another argument against the variant where the 
client resource is encoded together with the participant id in the resource: 
The client resource is -- in contrast to the channel name and participant id 
-- not under control of the MIX service. A client resource can be very long 
(although it probably isn’t right now), and that would break things. Combining 
the participant ID and channel name in the nodepart allows the MIX channel to 
control both parts to always fit in a nodepart (restricting the length of the 
channel name most likely).

kind regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180604/2f7769a8/attachment-0001.sig>

More information about the Standards mailing list