Implementation feedback for the draft/account-registration specification

[SadieCat]

I've implemented both the server (InspIRCd) and services (Anope) side of this specification and I have some implementation feedback:

• Unlike the SASL specification the draft/account-registration specification doesn't mention whether the capability needs to be requested before the commands can be used. This should probably be required so the server knows to hold the connection until services responds like with SASL.

• REGISTER allows the user to specify * for their current nickname but VERIFY does not. This should probably be also allowed for consistency.

• There's currently no way for the server to communicate password restrictions to clients. We should probably at the very least expose the minimum and maximum password length. This would make it a lot easier for clients that perform automatic registration.

• The registration specification currently hardcodes the use of email as the the contact method. It would be good if we could make this more generic so implementations could implement alternate contact methods.

• Is the before-connect key actually needed? It feels like a better route would be for the capability to only advertised when the user has the ability to register an account. Implementations that do not allow account registration before connection registrations could advertise its availability with CAP NEW to fully connected users.

[slingamn]

+1 to suggestions 1, 2, and 3.

re. 4, see history on #435 and #276: the ACC spec supported multiple verification mechanisms, but was felt to be too complex, especially given the lack of alternative mechanisms that were attractive to operators. Do we have any candidates for alternative verification mechanisms at this time?

Suggestion 5 seems like a significant increase in implementation complexity. What is the potential benefit here?

[emersion]

To me, (5) is actually a decrease in implementation complexity. Before, clients had to show the registration UI if the cap was advertised and add an extra condition based on the before-connect key and the current registration state. With the suggested change, clients only need to care about the presence of the cap.

[slingamn]

That's a good point. I guess it shifts complexity from the client to the server, and I have a bias :-)

[slingamn]

From #ircv3, @SadieCat is interested in supporting Fediverse DM and SMS as verification mechanisms in Anope.