-
jcbrand
Hello, 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
-
Ge0rG
jcbrand: what's the issue with trying to join with a nickname you want to use?
-
jcbrand
Ge0rG: 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.
-
jcbrand
pep. 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
-
Ge0rG
jcbrand: that's a kind of access to the occupant list. You could enumerate nicknames that way ;)
-
pep.
this ^
-
jcbrand
Which you maybe don't want in some cases, but in others you don't mind whether someone can enumerate the nicknames
-
jcbrand
it's a feature 🙂
-
pep.
:/
-
jcbrand
Also, if the service tells you that a nick is not available, it might also be due to other reasons, not that it's taken✎ -
jcbrand
Also, 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 ✏
-
jcbrand
Also, 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?)
-
jcbrand
You still get all the presence stanzas initially when you join✎ -
jcbrand
You still get all the presence stanzas initially when you join for the firs ttime ✏
-
jcbrand
You 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
-
jcbrand
Very unlikely and not something worth worrying about IMO
-
jcbrand
I 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
-
jcbrand
Not 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✎ -
jcbrand
pep. 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
-
jcbrand
jonas’ 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.
-
jcbrand
Yes, I didn't say that the goal is to join anyway
-
jcbrand
You 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
-
jcbrand
?
-
pep.
others wouldn't know you tried to join if the nick is already taken as you get an error
-
jcbrand
jonas’ 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
-
jcbrand
uh yeah of course...
-
jonas’
maybe by expiring all nickname registrations which never joined after 5 minutes or something like that
-
jcbrand
😛
-
pep.
"of course" :p
-
jcbrand
Seems 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â„¢
-
jcbrand
I 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