[Standards] XEP-0369 Proxy JIDs and MIX

Sam Whited sam at samwhited.com
Tue Jan 10 15:23:13 UTC 2017


On Tue, Jan 10, 2017 at 6:11 AM, Steve Kille <steve.kille at isode.com> wrote:
> 1.    The driving requirement for Proxy JIDs is support of JID hidden
> channels.

Obviously I am more or less alone in this, but I do not see JID hidden
channels as a necessity and think we should just get rid of them. If
people want to hide their JID, they can use a burner JID (either the
speced kind, or just create a new one on some server, use it, and
throw it away).

I also do not see this changing, but I wanted to keep this opinion
voiced just in case.

> 2.   While burner JIDs may be helpful to provide a user with complete
> anonymity in a channel,  I think that channel administration
> needs access to the real JIDs.   It would not be acceptable to manage a
> public MUC and just have a stack of anonymous participants.  So use of
> client provided burner JIDs is not a viable approach to JID hidden channels.

If burner JIDs are allowed on some other server, this happens anyways.
It's not something you can prevent. However, if the MIX server
implements burner JIDs itself, then you already have a mapping of
real-jid to burner-jid that the admins can use to ban the underlying
real JID from creating new burner JIDs (because the server had to
issue the burner JID, so obviously it knows who it issued it too).
Maybe the MIX server disallowing all JIDs but its own burner JIDs
would be a more common scenario than I thought in the other thread
about this, which does add a tiny bit of extra complexity, but I still
think it keeps things simpler than using proxy JIDs. These are mostly
server-side implementation details that don't require extra protocol.

—Sam


More information about the Standards mailing list