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

Sam Whited sam at samwhited.com
Tue Jan 10 15:16:04 UTC 2017

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, 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. 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).

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.

> 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.


Sam Whited
pub 4096R/54083AE104EA7AD3

More information about the Standards mailing list