Simon Ser

Another use-case is when logging in with an account created via `draft/account-registration` but which hasn't been verified yet. The server can send `REGISTER VERIFICATION_REQUIRED` instead, and then clients can appropriately...

@jwheare pointed out that we can't just break the spec. I agree, I'll try to find a better way to move this forward. Maybe we should have sasl-3.3 with this...

I don't think the bouncer spec solves any of this. The bouncer spec is just for configuring networks, with my implementation the join channels + SASL details + account registration...

FWIW, soju now intentionally breaks the spec and sends `RPL_SASLSUCESS` without `RPL_LOGGEDIN`. I haven't found a cleaner way to indicate that SASL suceeded but didn't result in any user login.

Another use-case for this: the ANONYMOUS SASL mechanism.

> Highlights aren't just nick mentions, there's no command to tell a server what highlight patterns the user cares about, and clients all have different functionality when it comes to...

Maybe it's a good idea, but I'm personally not interested in that, and I don't think it's a requirement for specifications that allow querying highlights. In other words, I don't...

Yes, I was definitely planning on having a vendored extension for this feature.

It would be nice to elaborate on the use-case of this spec. `WHO` flags (in particular the `*` flag) already provides a way to check whether someone is an operator....

> It's a blessing as a bot author. Instead of maintaining WHO state, and sending one-off WHO requests, we can check for this tag synchronously when processing commands. Okay, so...