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

Kevin Smith kevin.smith at isode.com
Sat Jun 2 11:46:05 UTC 2018

> On 2 Jun 2018, at 11:44, Florian Schmaus <flo at geekplace.eu> wrote:
> On 02.06.2018 10:25, Steve Kille 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  .
> And 'stable-participant-id' being a random unique string or the MIX
> nickname (xep369 § 7.1.4)?

It’s a stable identifier, determined by the service. (I don’t want to say it couldn’t be a nick, because technically you could have a service that guaranteed lifetime uniqueness of nicks and used those, but it is generally not the nick)

> I think I'm currently in the
> - messages from channel at service/nick
> - IQs to/from and presence from channel at service/nick/client-id
>  (where client-id is a random unique string not containing '/')
> camp.

That’s option 2, except that it has to be a stable ID, not nick (and that some IQs are just /user-id not /user-id/client-id, e.g. vcard)

> But the discussion about all those variations gets confusing quickly.
> How about creating a Wiki page with lists all currently suggested
> variants and its pros and cons?
>> 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.
> Extending IQs is possible (just not by putting the extension elements as
> direct child elements to <iq/>, see for example how RSM does it), but it
> feels like a bad design if we used that in this case.



More information about the Standards mailing list