[Standards] MIX Addressing

Jonas Wielicki jonas at wielicki.name
Thu May 31 19:12:59 UTC 2018


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. I 
would very much like to have that in MIX. This is one of the issues with 
overloading the resource.

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).

kind regards,
Jonas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180531/fb4def91/attachment.sig>


More information about the Standards mailing list