Sam, 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?
Steve > -----Original Message----- > From: Standards [mailto:standards-boun...@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.ki...@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-unsubscr...@xmpp.org > _______________________________________________ _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
