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@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@domain > and this in turn can have resources hanging off it as > user#channel@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@domain/user and channel@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@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@domain[/resource] (or similar), > with the resource missed off for bare-JID traffic, where > ‘user%channel@domain’ as the proxy JID is the user’s identifier used > everywhere. 2) Drop proxy JIDs, use channel@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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
