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

Steve Kille steve.kille at isode.com
Fri Jan 6 16:24:01 UTC 2017


Sam,

A key problem with this is the JIDs then become anonymous to the channel management.

Having a situation where channel participants do not know who is in a channel is fine.    I think that in many situations, it will be beneficial for administration to know real JIDs.   Would you really want to have the XSF Room/Channel full of burner JIDs?         Consider if I try to join the channel with a burner JID and nick of "Sam Whited".    

Clearly one cannot prevent someone from joining a channel using a burner JID.

However,  it feels wrong to me to force users to do this as the only "JID hidden" mechanism.


Steve



> -----Original Message-----
> From: Standards [mailto:standards-bounces at xmpp.org] On Behalf Of Sam
> Whited
> Sent: 06 January 2017 16:16
> To: XMPP Standards
> Subject: Re: [Standards] Burner JIDs and MIX [WAS A possible MIX approach:
> hiding multiple clients]
> 
> 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).
> 
> —Sam
> 
> --
> Sam Whited
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________



More information about the Standards mailing list