On Monday, January 12, 2015 03:14 EST, Dave Cridland <[email protected]> wrote:
> In general, proposing a XEP that's rejected because it's a terrible idea > adds more value than doing something that's a terrible idea without > discussing it. Even if you choose not to go as far as a formal protoXEP, > it'll hopefully be useful to all parties. Bear in mind, I've never attempted a standards body draft of anything, so here's the general ideas. We're going to use XMPP for internal coms for a game. As such, users have both a global and an instance identity and should be reachable by either the global name ( at all times when logged in ) and the active instance/character name. And we intend to use MUC as a "channel" analog. With our own clients, this is easy to control, we can enforce the MUC Nicknames to the character name, etc, but I've been asked to make sure that standard, third party XMPP clients can hook in as well. This complicates things slightly. :) The best solution I have come up with is: Use the resource id to identify the character Have the authentication method verify user ( node ) and character ( resource id ) against the login password Have the MUC code force the room nick for the user to the Resouce ID. ( and I'm dubious we can control that in a third party app ) But again, I'm not sure if ( assuming the above is all functionally possible ) that a XEP is appropriate.
