Allow requesting IRCv3 extended-join capability

[Fusl]

trafficstars

Standard IRC JOIN messages look like this:

:nick!ident@host JOIN #channelname

IRCv3 JOIN messages look like this:

:nick!ident@host JOIN #channelname * :Fusl

or

:nick!ident@host JOIN #channelname authenticated-username :Fusl

message.args[1] will be the authenticated username and message.args[2] the real name.

[coveralls]

Coverage decreased (-0.4%) to 93.995% when pulling f0b3ae1ad153d2e41ed0d7974fd82000a71f1caa on Fusl:patch-1 into d4708e5b65580f78d3cb75e6cd3f915a1796541a on Throne3d:master.

[Throne3d]

I'm a little confused about the motivation behind this PR - without account-notify, won't extended-join do very little to modify the experience as a user of the library? (Edit to add: I recognize it adds the authenticated username and real name to the JOIN messages, but isn't this already available in the bot config and/or the welcome event?) I'm okay accepting it anyway, it just seems like it won't be very useful.

I'd like this code to interact well with a CAP NAK response, so that if we request extended-join, and get told that it's not supported, we still successfully respond with CAP END. I'm happy if this is emitted as an error at the same time.

Could you also add some tests for this? Primarily, ensure that:

• it requests the capability when enabled and SASL is disabled, and responds with CAP END if it receives a response
• it does not request the capability when disabled
• with SASL enabled, it requests both sasl and extended-join, then waits for a SASL-related CAP response before sending CAP END

(I'm okay with, for now, assuming the responses come in a timely and ordered fashion, and accordingly that we won't enter a state where we have a response for sasl but not for extended-join for a prolonged amount of time - this could cause weirdness where we respond with CAP END and extended-join fails to get registered, but it seems unlikely to happen. Ideally, if any future capability negotiation is added to this library, the system will be refactored.)

Thanks for your contribution!

[Fusl]

I'm a little confused about the motivation behind this PR - without account-notify, won't extended-join do very little to modify the experience as a user of the library?

I have a bot that automatically voices users and voices them immediately when they are authenticated: https://github.com/opennic/irc-bot-openvoice/blob/master/openvoice.js#L121

[tritium21]

@Throne3d The information that is already on the bot config or the welcome message is the bot's authenticated name, etc. The extended join message also adds authenticated names for all other users who join a channel.

[Throne3d]

@tritium21 Yeah, I had misunderstood that in my first comment, but the response from @Fusl clarified it for me. I believe the rest of my message still stands, though – specifically, interacting well around CAP NAK and adding tests for it (as well as my more specific line-by-line comments).

[Throne3d]

Any chance you'll get to the requested changes soon?