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

Kevin Smith kevin.smith at isode.com
Sat Jun 2 11:48:25 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.
> There is no issue with messages from MIX, as there is no reason to encode
> the sender's resource.   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.
> We can do the same with presence.   Just have presence come from
> channel at domain/stable-participant-id.   This feels clean.   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.
> 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.
> Thoughts?

Bringing this back around, what does this give us in practical terms over e.g. variant 4?

As well as the assorted barriers earlier in the thread, it still has the PM-addressing-ambiguity issues of variant 2.


More information about the Standards mailing list