[Standards] MIX - an approach to JIDs that avoids the four into three problem

Kevin Smith kevin.smith at isode.com
Sat Jun 2 11:36:47 UTC 2018


On 2 Jun 2018, at 09:25, Steve Kille <steve.kille at isode.com> wrote:
> 
> We've been talking about a number of variants to deal with the problem of
> encoding four pieces of information in a JID structure that only allows
> encoding of three.
> 
> Here is an approach to avoid the problem.
> 
> These JIDs are mostly (exceptions discussed below) used in the "from" of
> stanzas coming from a MIX channel.

Well, kinda. They’re used for that, they’re used for addressing ‘to’ (bare) for PMs and (a mix of full and bare) any sort of IQ, as well as used as the publisher stamp and or id on assorted pubsub lookups.

> There is no issue with messages from MIX, as there is no reason to encode
> the sender's resource.

I think there are reasons, but they’re reasons we’re willing to sacrifice.

>   So variant 2 gives a clean approach with  from JIDs
> of the form  channel at domain/stable-participant-id  .   The resource is used
> to identify the sender.  A bit like MUC, but using a stable ID instead of
> the nick.   Information needed to display the sender is carried as elements
> in the message, so no lookup is needed to correctly display the sender.

Yes.

> We can do the same with presence.   Just have presence come from
> channel at domain/stable-participant-id.   This feels clean.

No, we can’t, or at least, we need to then look inside the stanza to find the resource to be able to track presence - availability is tied to a resource (of course there’s the desire to move things into PEP, but you still have the fundamental issue that you don’t want a type=unavailable from a JID to be telling you that that JID is still available in the room). This is one of the issues with MUC that we want to solve with MIX.

>   Other
> information is held as attributes in the presence.   For JID Visible, this
> includes the full JID of the sender.   For JID Hidden, it includes the
> anonymized resource.   This feels clean.

Moving addressing out of the fields in the protocol and inventing new ones for it feels terribly unclean to me.

> The only problem to address is when in a JID Hidden channel, the recipient
> wants to address a specific client (PM or vCard lookup).  A solution here is
> to is to use the channel at domain/stable-participant-id addressing to the
> channel, and include the anoymized resource as an extension attribute to the
> message/IQ, which the MIX channel can use in conjunction with the JID to
> look up the correct full JID.

I think if we have to go with a solution where we’re encoding the ‘to’ inside stanza elements instead of in the ‘to’ of the stanza it’s very unpleasant. With at least 2 problems that are immediately obvious, and probably more to follow - 1) This is completely broken with iq, where you can’t add that extra element 2) you’ve broken the guarantee that you can drop or ignore elements without changing addressing - imagine a middle hop in an invisible multi-hop system that strips out elements for bandwidth saving.

/K


More information about the Standards mailing list