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

Steve Kille steve.kille at isode.com
Fri Jan 6 16:10:45 UTC 2017


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?


> -----Original Message-----
> From: Standards [mailto:standards-bounces at xmpp.org] On Behalf Of Sam
> Whited
> Sent: 06 January 2017 16:06
> To: XMPP Standards
> Subject: [Standards] Burner JIDs and MIX [WAS A possible MIX approach:
> hiding multiple clients]
> On Fri, Jan 6, 2017 at 1:50 AM, Steve Kille <steve.kille at isode.com> wrote:
> > The radical change is to make MIX presence "per user" (at least for
> > JID Hidden channels).
> I would like to propose an alternative based on XEP-0383: Burner JIDs [1].
> If the MIX service itself were to provide burner JIDs a few simple rules could
> be enforced by the MIX service to make them work. Burner JIDs alocated by
> the MIX service:
>   1. MUST have a 1:1 mapping with a real JID
>   2. SHOULD NOT expire (although one might envision a situation where a
> user starts getting spam to their burner JID so they want to copy over their
> roster to a new one to rotate it; this sort of thing could also be described in
> the MIX spec if desirable, or maybe the user really does just want a different
> proxy JID each time: either way, I suppose that's a matter of server policy
> and/or user choice).
> This means that users are authenticated using their normal account, and are
> authorized to use the MIX service by virtue of having been assigned a burner
> JID.
> The only real downsides I see to this are that rooms will not show up in a
> users normal roster (although this could be solved easily by clients in the UI,
> which may even be good because it would mean they don't show up in
> clients that don't support MIX), and that it requires a separate connection to
> the server for each burner JID in use (if you wanted a different one per
> room, that could get expensive). I'm sure we could solve this by multiplexing
> multiple sessions over one TCP connection though, and that's a problem that
> can be addressed later if it ever becomes an issue.
> Thoughts?
> —Sam
> [1]: https://xmpp.org/extensions/xep-0383.html
> --
> 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