[Standards] Burner JIDs and MIX [WAS A possible MIX approach: hiding multiple clients]

Sam Whited sam at samwhited.com
Tue Jan 10 15:28:29 UTC 2017


On Tue, Jan 10, 2017 at 9:23 AM, Kevin Smith <kevin.smith at isode.com> wrote:
> Except if it's the MIX issuing burners, isn't 'the server' in this case the
> MIX server? Which you very possibly can't route to from your client because
> it crosses an organisational boundary, and only S2S can get across?

Could be either; I've been saying the MIX service, but I suppose
you're right, it would have to be the server and the MIX service would
be configured to check that JIDs were issued by the service. This does
require some shared datastore or public key between them. Either way,
I don't think this adds substantial overhead.

> Except you need it tracked in your 'real' account, so clients know
> connection details for all your burner JIDs, and you need to be jumping
> through hoops as a client to do so each login.

Yes; I'm unsure how much work this would be for current clients. I
suspected that it would be relatively easy, but TBH I'm not sure.

> Well, you have to have the clients check too, because otherwise they'll try
> to join a room with their real JID and not be allowed because the room's
> semi-anonymous.

Fair.


> Sure, I think MIX's use of proxy JIDs here is exactly doing this better than
> MUC did :)
> My original proposal to simplify things was to not have semi-anonymous
> rooms, but people rapidly let me know that I was being an idiot and we need
> this functionality ;)

Same here; I didn't want this complexity when we first conceived MIX
in Washington, and still think that either way just makes things too
complicated (but as you said, I was rapidly overruled).

Steve just started a new thread about this; maybe we should take
discussion about other alternatives there.

—Sam




-- 
Sam Whited
pub 4096R/54083AE104EA7AD3


More information about the Standards mailing list