Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
IRCv3 3.1 base extensions + away-notify #27
This is an implementation of IRCv3 with capability negotiation support + base extensions + away-notify.
irc-api is modified to allow for providing capability negotiators and there are a number of negotiators implemented by default.
The CompositeNegotiator may be provided with a list of capabilities, which will all be negotiated, and a host interface to which will be called back with the negotiation result.
This implementation assumes that the client application is the primary user of IRCv3's features and therefore irc-api does not do the actual negotiation. This way you can add capabilities to negotiate for even if irc-api does not support these. If these capabilities extend existing IRC commands, you may need to add support to irc-api, however for any new commands and features, you can just handle those in the client application itself. (In a previous commit, an UnknownMessage message type was added, so you are able to handle messages not known by irc-api.)
Additionally, irc-api is modified to handle multiple prefixes in NAMES / WHO messages. Therefore, if 'multi-prefix' extension is enabled, irc-api will be able to make use of the extra information. Most notably, by providing all relevant IRC user modes, instead of just the one that was communicated.
Lastly, an AwayMessage type is created and handling of these messages is provided. If 'away-notify' is negotiated and supported by IRC server, then enabling this, will allow irc-api to transparently handle Away-messages and notify listeners via the onAwayMessage event. For irc-api there is nothing to do apart from routing the message to listeners via the correct event.
With this PR, there is support for IRCv3 3.1 base extensions + away-notify at the very least. Other extensions may work out-of-the-box as most of them need to be handled by the client application anyway, but the lower bound is IRCv3 3.1 so far.
Let me know what you think. Any feedback is welcome.