[Standards] MIX Addressing

Kevin Smith kevin.smith at isode.com
Fri Jun 1 07:21:45 UTC 2018

On 31 May 2018, at 20:12, Jonas Wielicki <jonas at wielicki.name> wrote:
> On Donnerstag, 31. Mai 2018 13:45:06 CEST Kevin Smith wrote:
>> We’ve had some discussions recently about whether presence should come from
>> the channel’s JID, the user’s proxy JID, or be encoded in pubsub. Similarly
>> whether messages should be coming from the channel’s JID or the user’s
>> proxy JID. I think the argument that things should come from the user’s
>> in-channel JID rather than the channel’s is reasonable - this is also what
>> happens already in MUC and is familiar.
>> The reason for the proxy JIDs is that we need a stable identifier for the
>> user in the channel, and we need it to be addressable per client. In MUC we
>> don’t have this, we have room at server/nick, which is not stable for the
>> user, which makes several things unpleasant, nor is it unique for a client
>> (no resource), which makes routing (e.g. iq, which has to be to go to a
>> unique client) and other issues annoying.
>> This means that we want a routable address that encodes up to four pieces of
>> information:
>> The channel’s domain
>> The channel’s identifier (I don’t want to use ‘name’, because that’s
>> confusing - I mean the bit that in MUC would be the node of the JID). The
>> user’s stable identifier
>> A thing representing a resource of the user (Although not necessarily the
>> exact resource they’re using)
>> I shall call these ‘domain’, ‘channel’, ‘user’, ‘resource’ respectively,
>> because I’m tremendously creative.
>> The current approach is to have a unique ‘proxy JID’ per user:
>> user#channel at domain
>> and this in turn can have resources hanging off it as
>> user#channel at domain/resource1, etc.
>> This is not the most elegant thing in the world (and some people have
>> objected to having proxy JIDs at all), and has implications for e.g.
>> servers that block messages from anyone that isn’t in your roster or
>> receiving directed presence.
>> We could alternatively encode it as
>> channel at domain/user and channel at domain/user/resource (Note carefully that
>> user is *not* nick, so this doesn’t fall into the issues of MUC stability,
>> and it allows encoding resources, so doesn’t fall into the MUC issues of
>> routing).
>> Then there are no more proxy JIDs, everything is hanging off channel at domain,
>> much like people are familiar with from MUC but without (as far as I can
>> see at the moment) those issues of conflating nick with both user and
>> client identity.
>> I think if we want routability we need to choose one of these two things:
>> 1) Stick with proxy JIDs and user%channel at domain[/resource] (or similar),
>> with the resource missed off for bare-JID traffic, where
>> ‘user%channel at domain’ as the proxy JID is the user’s identifier used
>> everywhere. 2) Drop proxy JIDs, use channel at domain/user[/resource] and then
>> ‘user’ is just a string identifier for the user, of whatever format (as
>> long as it doesn’t contain ‘/‘).
>> What are people’s thoughts here?Are there any advantages of (1) over (2), or
>> vice versa?
> I very much prefer the semantics of (1). The reason is that about everywhere 
> (except MUC) you can assume that equal bare JID implies equal identity.

Ah, but it’s more complicated than that.

In most of XMPP you have the concept that identity (of the sender) = routing (of a reply) = context (e.g. the chat window in your client, or the entity you need queries for in your MAM archive). If you receive a normal 1:1 chat message, the from on the stanza (less the resource) shows you the identity of the sender (it’s just them), the routing to reply to them (it’s just them) and the context of the messages (the chat with that person). With MUC or MIX you now have this changed.

For MUC currently:
Identity of the sender: full JID (although this is broken, as we know, by the conflating of identity/nick etc. in MUC)
Routing of a reply (type=gc): bare JID
Routing of a reply (type=chat, sent through channel): full JID
Context (type=gc): bare JID
Context (type=chat, sent through the channel): full JID

With option 1 (encode channel and user into node):
Identity of the sender: bare JID
Routing a reply (type=gc): strip the user out of the localpart and then it’s the remaining bare JID
Routing a reply (type=chat, sent through channel): bare JID
Context (type=gc): strip the user out of the localpart and then it’s the remaining bare JID
Context (type=chat, sent through the channel): bare JID

With option 2 (encode user and resource into resource):
Identity of the sender: full JID
Routing a reply (type=gc): bare JID
Routing a reply (type=chat, sent through channel): full JID
Context (type=gc): bare JID
Context (type=chat, sent through the channel): full JID

So, yes, option 1 gives you that the identity of the sender is the bare JID, and this is desirable. It also loses the idea that the context of the messages for channel messages is the bare JID and this makes client architecture harder and (possibly more importantly, and I hadn’t really thought about this enough before) breaks querying for messages in a channel in personal MAM. Your client comes online, you want to show unread messages so you query your archive for the last messages in the room since the ID and … get nothing. For this model to work we need to encode special MIX logic into MAM to be able to collate based on splitting the localpart (which is do-able, not pretending otherwise, and we do need to have complexity somewhere, although I’d rather not split it across many entities).

The cleanest option in terms of keeping identity, routing and context straight might actually be that messages from the channel (type=gc), presence, etc. all come from option 2, while if you send PMs they come from option 1. That way replying is always ‘right’, you can do a mapping between the two (but don’t need to), and you don’t have the unpleasant issue that archive queries get screwey because you’re overloading what the context/routing is based on message type.

> I  would very much like to have that in MIX.

Wouldn’t we all :)

> This is one of the issues with 
> overloading the resource.

Indeed, but hopefully I’ve managed to explain (some of) the compromises that must be made, we can’t have our cake and eat it when we need to encode four addressing parts into three slots in the JID. Having enumerated some of the issues in the semi-tables above, I’m now leaning towards ‘option 4’ being the best (option 2 for channel messages, option 1 for PMs).

> The variant (1) will still require to do parsing of the node part to determine 
> which MIX a message is from, which is also not ideal. However, the 
> distribution of messages to different (local) MIX endpoints (read: 
> conversation windows) needs to be done anyways and can be done in a central 
> place.
> On the other hand, working with JIDs as means to compare identities is spread 
> throughout all the code (think: using JIDs as cache keys e.g. for avatars).

There are, of course, two identities - the identity of the sender, and the identity of the chat location (what I’ve been calling the context, above), and other than the example you give (avatars), it’s very often the latter that you more need.


More information about the Standards mailing list