Several improvements to the account-registration spec.#595
Conversation
|
If all happy, will merge next week. |
| presence signifies that the server supports account registration. | ||
|
|
||
| The client MUST enable the `draft/account-registration` capability before using | ||
| the `REGISTER` and `VERIFY` commands defined by this specification. |
There was a problem hiding this comment.
Why? I can understand for during the connection flow, this makes sense, but typing /register and its parameters are user-intuitive to type and it doesn't make sense to gate this behind the cap. Many servers already implement aliases that forward /REGISTER to NickServ automatically, too, existing by default in UnrealIRCd even.
There was a problem hiding this comment.
The command already has different semantics than existing nickserv REGISTER commands, both in the arguments it accepts and the replies from the server. A user sending REGISTER without client support will likely not see the server's repliees in their client, and that's with assuming they already guessed the proper argument order and values.
There was a problem hiding this comment.
This requirement only limits this specification, UnrealIRCd is free to still provide its existing /REGISTER behaviour if the user does not have the account registration capability.
| * `email-required` - if present, registrations require a valid email address | ||
| to process | ||
|
|
||
| * `max-password-length=<num>` - if present, passwords are restricted to a |
There was a problem hiding this comment.
What is the benefit of capping password lengths?
There was a problem hiding this comment.
This exposes a feature of existing services implementations. The limit is generally large (e.g. Anope uses 50 characters) but there still has to be some kind of limit to prevent abuse.
See #555 for the rationale.
Closes #555.