[Standards] A possible MIX approach: hiding multiple clients

Kevin Smith kevin.smith at isode.com
Fri Jan 6 10:09:32 UTC 2017


On 6 Jan 2017, at 10:01, Kevin Smith <kevin.smith at isode.com> wrote:
> 
>> 
>> On 6 Jan 2017, at 07:50, Steve Kille <steve.kille at isode.com> wrote:
>> 
>> 
>> The recent discussion on the difficulty of proxy JIDs has triggered me to
>> write up a more radical idea I have had floating around.
>> 
>> For the most part, a MIX channel deals with users (not clients).   Messages
>> are sent out to each user.  The MIX Proxy (possible new name "MIX
>> Intermediate Server") distributes message and presence to clients.
>> 
>> The place where multiple clients comes through is in presence, where each
>> client shows presence.
>> 
>> The radical change is to make MIX presence "per user" (at least for JID
>> Hidden channels).    This seems quite natural to the recipient.   I really
>> don't care how many clients a channel member is running and what their
>> status is.
>> 
>> If we make this change, we can simply get rid of proxy JID.   The user is
>> represented in the channel by the Nick.
>> 
>> There are two downsides to this.
>> 
>> The first is "Nick Stability".   If a user changes their Nick,  a
>> participant in a JID Hidden channel cannot distinguish this from user
>> leaving and a new one joining.   I don't think this is a big deal
>> operationally, but there might be scenarios where this is a problem.
>> 
>> The second relates to the fact that channel members cannot see multiple
>> clients for a user.    This has upsides too, but may remove flexibility.    
>> 
>> The MIX Intermediate Server will need to set "unified presence".   This is
>> will  sometimes be convenient for channel members, but could be confusing
>> (consider status flapping between two clients).   It feels awkward and messy
>> for the MIX Intermediate Server to work out what to set.
>> 
>> It prevents the channel participant from choosing clients (e.g., by looking
>> at CAPS capability).     However for a JID Hidden channel, it seems that in
>> many ways trying to hide the JID and expose multiple clients is a bad thing.
>> 
>> We could work this so that for JID Hidden channels,  the MIX intermediate
>> server MUST provide unified presence.   For JID visible channels, you can
>> simply share full JIDs.
>> 
>> This is quite radical, but I think this idea has legs
> 
> This is the MUC model, which is one of the broken bits of MUC we need to get rid of!

That ‘short’ version was meant to go just to Steve rather than be noise on the list, but I’m incompetent. Apologies.

Some more reasons that removing the proxy JID is problematic:

1) As noted, you need to be able to get caps for clients to do various things with them. Much of XMPP fails without caps/disco.
2) Nicks are mutable, while you want the proxy JID not to be - both for nick change (noted) and re-use/impersonation
3) If we do this for JID-Hidden only, we end up with very different code paths for clients for the types of MIXs
4) Merging presence becomes a nuisance (not a problem servers face at the moment, while clients already have ways of dealing with merging presence, for better or worse).
5) We’re more susceptible (I think) to stale presence issues
6) Probably others

I’ve noted before at summits that I think the multiple-presence thing in XMPP is getting to be a nuisance for typical chat systems, but I don’t think MIX is the place we want to address this. I think we’d need to address it somewhere in core and have the same behaviour for roster and MIX (and wherever else).

/K


More information about the Standards mailing list