[Standards] MIX Addressing

Kevin Smith kevin.smith at isode.com
Fri Jun 1 08:38:34 UTC 2018

On 1 Jun 2018, at 09:20, Jonas Wielicki <jonas at wielicki.name> wrote:
> On Freitag, 1. Juni 2018 09:29:15 CEST Kevin Smith wrote:
>>> So here’s a straw-man proposal, Variant 3 (because, creating many variants
>>> is what we’re good at!):
>>> An occupant is identified by an occupant-identifier. The occupant JID is
>>> occupant-identifier at mix-service. The channel to which a message belongs is
>>> identified with a payload item. Example message:
>>> <message type="groupchat"
>>>          from="4973d5d365f8 at mixservice.domain.example/client-resource"
>>>          to="user at other.example">
>>>   <mix channel="some-channel"/>
>>>   <body>...</body>
>>> </message>
>>> Advantages:
>>> - No re-write of resources needed (good for MIXes)
>>> - Bare JID refers to occupant identity (good for clients)
>>> - Servers can simply filter on message/mix/@channel (not perfect, but
>>> better than requiring a new JID processing function)
>>> - Opens up the possibility of re-using the same proxy JID for the same
>>> occupant across different channels (may be useful in some deployments, via
>>> MattJ)
>>> - No non-RFC6122-based operations required on JIDs.
>>> Disadvantages:
>>> - All (including 1:1) stanzas exchanged between occupants require the <mix
>>> channel="…"/> element for MIX channels to be able to easily route them
>>> - Entities filtering on MIX channel identity still need to know about MIX
>>> (and the <mix channel="…"/> element)
>>> - The namespace of MIX channel JIDs and occupant JIDs needs to be
>>> separated in some way. This can be achieved with a single bit, so a
>>> forced prefix on occupant JIDs (and a forbidden prefix on channel JIDs),
>>> such as "%", would work for that. (I’m not sure if we would have to
>>> standardize the method by which services do this split.)
>>> What do you folks think?
>> I don’t want to go as far as saying I hate it, but I certainly don’t like
>> it, I think it’s the worst of the three (now four) options. It completely
>> removes all context from the header, and you have to go snooping inside
>> every packet to work out where it’s really from (
>> because for almost all
>> processing concerns it’s the channel that’s regarded as the sender, not the
>> originator
> See, here’s where I disagree. In the client, the only processing which is 
> based on the channel is the first fanout to distribute it to the right 
> conversation window. Everything afterwards is very much concerned with the 
> occupant identity. I think that this is the discrepancy between server and 
> client concerns I was talking about.

I’m trying to think of how many things are concerned only with the occupant identity and not with the channel identity, vs only the channel identity and not the occupant identity.

For channel but not occupant, you’ve got the initial routing within the client, rendering it only has the occupant as a last minute detail (typically). Replying is almost always to the channel rather than the occupant.

For occupant but not channel you’ve got caps/avatar lookups, and you’ve got PMs.

Other things need both occupant and channel - once you’re at the stage of processing the stanza in the client that you’re concerned with both the channel and the occupant, I don’t think it’s a big difference between 1/2/4 for the client to do the splitting.

>> ). Now your archive will be completely broken without quite
>> excessive DPI on the MAM server, 
> This is a good point (selecting MAM from a MIX channel is now hard). I didn’t 
> consider this because my MAM workflow is a "sync everything" one, so I 
> wouldn’t care. However, I know that this isn’t the only workflow and a way to 
> select messages from a MIX channel is important.
> How would that work with Variant 1?

The user’s server (hosting MAM) would have to understand MIX and split the localpart. Not as bad as 3, but worse than 2 (for that component).

>> and your client’s internal routing is no
>> longer straightforwardly hierarchical based on the from.
> That would only be the case with Variant 2 anyways. I see the appeal of 
> hierarchical routing, but I’m not quite ready to let go of "equal bare JID 
> implies equal identity". This has been one of the things I looked forward to 
> most in MIX (as a client developer).

The thing there is that you can’t have 'equal bare JID implies equal identity’ in MIX, because there are two identities - 1 gives you 'equal bare JID implies equal originator identity’, while 2 gives you 'equal bare JID implies equal channel identity’. There are (significant) benefits to each. I’m currently weighing towards the latter being more useful for channel data, and the former for PM data, but there does have to be a trade-off made.

Can you give a concrete reason that you’re looking forward to 'equal bare JID implies equal (originator) identity’ (or repeat it, if I’ve missed it)?


More information about the Standards mailing list