[Standards] MIX Addressing

Kevin Smith kevin.smith at isode.com
Thu May 31 11:45:06 UTC 2018


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?

/K


More information about the Standards mailing list