CAP proposal for external registration method `draft/external-reg`

[ValwareIRC]

Proposal: Server CAP for letting clients know in CAP * LS that the registration method is external to IRC (i.e. website).

This would come in especially handy for private networks where you can only connect after a successful SASL negotiation, but its uses go further than that.

Example server display

CAP * LS :draft/external-reg=https://valware.uk/register

Considerations This CAP should be visible as an client CAP but should not need to be REQuested by the client in order to work since it's just information.

The services package on the network who provide SASL MUST be responsible for setting this link. The manner of which would vary between IRCd implementations. For example on UnrealIRCd, in the prototype implementation ~~I'm going to make for this, Services will set with MD:~~ I've made for this sets it in this way:

Syntax ~~69L MD client 69L external-reg :https://valware.uk/register~~

MD client <sid> externalreglink :<link>

Example services setting MD client 69L externalreglink :https://valware.uk/register

This would allow servers to more easily let its user's clients know how to register on their network, should their registration method be external, possibilities for which would be client implementation-dependent. (For example, the client could open a new page in a browser, or even iFrame the target webpage for clients rendered in a browser)

[progval]

FWIW I think it is an interesting alternative to https://ircv3.net/specs/extensions/account-registration.html , that is much easier for clients and servers to implement, and is also more flexible.

I still prefer account-registration because it allows a more integrated experience by not depending switching to a browser as a long-term solution, though; and it's possible for servers to implement both if they wish to.

[slingamn]

From discussion with @emersion, here's what I think would be required to fold this into the existing draft/account-registration spec:

1. Add a new response, REGISTER VERIFICATION_URL. This is complementary to REGISTER VERIFICATION_REQUIRED; it indicates that the client must navigate to the indicated URL in a browser to proceed with registration. (The URL could have tokens in the query string, or not.)
2. Amendment: "Clients MUST accept VERIFY SUCCESS outside the context of a response to VERIFY, in the case where registration is completed out of band, e.g. on a website in response to REGISTER VERIFICATION_URL."
3. email-required continues to have its normal meaning in this context: the client must provide an email address to the server to initiate the registration process. Servers may send the email themselves, or may hand the address off the web service to send.

A caveat about point 2 is that in order to support this, server/services implementations would have to track the association between the unauthenticated client connection that initiated the registration attempt for an account name and the account name. I think this is not commonly tracked by existing implementations (current VERIFY and NS VERIFY parameters include the account name and the verification code both).

A related flow is to use draft/account-registration with the current REGISTER VERIFICATION_REQUIRED response, but instead of the email containing the verification code itself, it contains a URL of a web form, successful completion of which reveals the code (which is then submitted over IRC with the VERIFY command).

[ValwareIRC]

As per the discussion in-chat, here is concept code for draft/external-reg:

https://github.com/ValwareIRC/valware-unrealircd-mods/tree/main/cap-external-reg

[DanielOaks]

Cool, very fun! I probably wouldn't bother trying to fold this into the registration flow described in the draft/account-registration spec. It probably makes sense client-wise to keep this idea as simple as possible and just direct the user towards the browser for everything signup, then give the user a modal to put their account credentials into the client once they've signed up.

Verification provided by an external webpage seems like it'd be a decent separate task to tackle, but it also feels like a lot bigger of a task than just adding an informational cap with a url.

[ValwareIRC]

@DanielOaks

then give the user a modal to put their account credentials into the client once they've signed up.

I'll work on this with the concept code.

Verification provided by an external webpage seems like it'd be a decent separate task to tackle, but it also feels like a lot bigger of a task than just adding an informational cap with a url.

Please could you elaborate? Ideas are the best things ever =]

[awfulcooking]

• 'Server MAY leave connection open pending registration via the web page, and proceed once success or failure has been reported by the backend'
• 'Clients SHOULD play elevator music while the form is being filled out, accompanied by cute loading spinner gifs and cat pictures'