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

Kevin Smith kevin.smith at isode.com
Tue Jan 10 15:01:25 UTC 2017


On 06/01/2017 16:15, Sam Whited wrote:
> On Fri, Jan 6, 2017 at 10:10 AM, Steve Kille <steve.kille at isode.com> wrote:
>> I don't object to this, but I can't see how it makes much difference to MIX. What impact is there besides following the rules for generating random JIDs?
> Using this removes the need for semi-anonymous channels
> and proxy JIDs, which will simplify the MIX spec a lot. It shifts the
> decision about whether or not a user is
> anonymous from the MIX service to the user since they can decide
> whether or not to use a burner JID before joining any channels
> (although the MIX service would still be able to enforce that a room
> be anonymous by only allowing in JIDs issued by its own burner JID
> service).
>

I think you'd need to build so much extra stuff on top of burner JIDs 
(e.g., exposing real JIDs to admins, configuration so only your own 
burners can be admitted, users' clients checking if a room needs them to 
register a burner, and then registering it, and then joining the 
channel, working out how this all interacts with PAM, working out how 
this interacts with MAM, ensuring activation of burner JIDs 'just works' 
on login without additional steps, defining ways to bind burners into 
the same stream as all other traffic, to name just a few of of them) 
that you end up with vastly more complexity than proxy JIDs give you.

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.

/K


More information about the Standards mailing list