[Standards] A possible MIX approach: hiding multiple clients

Steve Kille steve.kille at isode.com
Fri Jan 6 07:50:21 UTC 2017


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


Steve






More information about the Standards mailing list