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

Kevin Smith kevin.smith at isode.com
Tue Jan 10 15:23:31 UTC 2017

On 10/01/2017 15:16, Sam Whited wrote:
> On Tue, Jan 10, 2017 at 9:01 AM, Kevin Smith <kevin.smith at isode.com> wrote:
>> I think you'd need to build so much extra stuff on top of burner JIDs … that you end up with vastly more complexity than
>> proxy JIDs give you.
> I'm not so sure; you get a burner JID, you make a new connection to
> the server with it

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?

> , you use it as if it were a normal JID and
> everything interacts with it exactly the same as it would have done
> with a normal JID.
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.

>   The only real thing you have to implement is the
> rules that check if a JID is allowed or not on the server if you
> *only* want to allow burner JIDs, but that's a special case anyways
> (since you might as well leave it up to users whether or not to expose
> their real JIDs at this point).
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.
> That being said, I could also see this being true; there's a lot of
> room for complexity here. I'd like to experiment with some
> implementations and find out.

I think there might be a certain amount of optimism involved here in how 
much is needed to replace proxy JIDs with burners. By all means try to 
write up how burners would work :)
>> Proxy JIDs are very similar in complexity to how MUC currently works, where
>> you use a room-assigned (although client-requested) anonymising JID. I don't
>> think anyone has problems with dealing with these concepts for MUC, and I
>> don't think they will for MIX.
> I feel like this is one of the concepts that bothers me most about MUC
> (and causes many of my implementation headaches), probably second only
> to presence being tied to membership.
> I agree that they're similar levels of complexity, but I still think
> we can do better than MUC did in this regard, even if burner JIDs
> aren't that way.
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 ;)


More information about the Standards mailing list