jcbrandHello, is there a way to check whether a nickname is available *before* joining a MUC?
XEP-0045 has a section on discovering whether you've already registerd a nick for yourself in the MUC, but I don't see anything about checking whether a particular nick is available.
pep.that would mean having access to the participant list before joining?
pep.in a way
Ge0rGjcbrand: what's the issue with trying to join with a nickname you want to use?
jcbrandGe0rG: there is no issue, I want users of a particular service that is built on XMPP to be able to check availability of a nickname before actually joining with that nickname.
jcbrandpep. I don't think you need the participant list. Could be as simple as sending an IQ to a MUC and asking whether a particular nick is taken or not
Ge0rGjcbrand: that's a kind of access to the occupant list. You could enumerate nicknames that way ;)
jcbrandWhich you maybe don't want in some cases, but in others you don't mind whether someone can enumerate the nicknames
jcbrandit's a feature 🙂
jcbrandAlso, if the service tells you that a nick is not available, it might also be due to other reasons, not that it's taken✎
jcbrandAlso, if the service tells you that a nick is not available, it might also be due to other reasons, not neccessarily that it's taken ✏
jcbrandAlso, if the service tells you that a nick is not available, it might also be due to other reasons, not necessarily that it's taken ✏
pep.in a world where presence is moot, like the xep you just published, can you not just attempt a join?
pep.(it's your xep right?)
jcbrandYou still get all the presence stanzas initially when you join✎
jcbrandYou still get all the presence stanzas initially when you join for the firs ttime ✏
jcbrandYou still get all the presence stanzas initially when you join for the first time ✏
pep.sure, but you know right away if the nick is available or not
pep.you get an error otherwise
jonas’also you have a "lock" on the nickname at that point
jonas’which is good, because someone could steal your nickname between you checking via the IQ and you actually joining
pep.right, also that
jcbrandVery unlikely and not something worth worrying about IMO
jcbrandI think the value of being able to check outweighs that concern in my case
pep.I'm saying you already have the tools to check
jcbrandNot before you join the room
jonas’jcbrand, could you do nickname registration?
pep.joining the room is just a technical detail
pep.you don't have to show it in the UI right away
jonas’pep., it’s not, it discloses the join attempt to everyone and also distributes traffic✎
jcbrandpep. it's a detail that complicates the code and causes unnecessary traffic
jonas’pep., it’s not, it discloses the join attempt to everyone and also causes traffic ✏
pep.jonas’: if the goal is to join anyway..
jonas’you also have to leave the room if the user decides to pick a different nickname after the check and deal with all the stanzas you get after joining
jcbrandjonas’ AFAIK you can only register a nick *after* joining the MUC
jonas’pep., in my mind, there’s a "pick your username" form where a green tickmark appears when you move focus away from the nickname field. The user could still change the nickname later (before joining) or abort the process.
jcbrandYes, I didn't say that the goal is to join anyway
jcbrandYou might decide not to join because a particular nick is taken already
pep.that's an issue only if the nick isn't already taken
pep.others wouldn't know you tried to join if the nick is already taken as you get an error
jcbrandjonas’ what you describe is roughly what I'm after. I think making it possible to allow nick registration without joining a MUC is the solution
jonas’jcbrand, you still have to un-register the nickname if the user aborts the flow in some way
jcbranduh yeah of course...
jonas’maybe by expiring all nickname registrations which never joined after 5 minutes or something like that
pep."of course" :p
jcbrandSeems a bit kludgy
pep."oops the user quit the client"
jonas’(and also explicitly un-registering when the user changes their choice)
jonas’jcbrand, not really. having a control loop which does cleanup of (expected and unexpected) error cases is a good thing™
jcbrandI think something like nick registration, but that simply indicates availability is preferable. Could be a new XEP, and if people hate it I might then just do it for this one use-case