Don't suggest users to /motd in multi-upstream mode
Make user MODE commands fail in multi-upstream mode
Forward user mode changes in single-upstream mode
Forward MOTD messages downstream
The first MOTD upon connection is ignored, but subsequent MOTD messages
(requested by the "MOTD" message from the client, typically using a
/motd command) are forwarded.
Add downstreamConn.SendBatch helper
Prune detached channels from CHATHISTORY TARGETS
Implement CHATHISTORY TARGETS
Forward unknown commands to upstream in single-upstream mode
Reject JOIN with invalid channel names
This prevents us from storing typo'ed channel names in the DB.
Allow networks to be disabled
Add support for IRCv3 setname
Vendor BATCH bouncer-networks type
And add the prefix throughout the spec, to make it clear the unprefixed
version is not to be used.
Introduce the soju.im/bouncer-networks-notify capability
Send network settings in LISTNETWORKS
Add pass to bouncer network attributes
Implement the soju.im/bouncer-networks extension
Directly return self-messages to user in multi-upstream mode
Pass-through the BOT ISUPPORT token
Fix CAP LIST listing disabled capabilities
Relay self-WHO/WHOIS in single-upstream mode
In multi-upstream mode, we can't relay WHO/WHOIS messages for the
current user, because we can't decide which upstream server the
message should be relayed to.
In single-upstream server, we do know which upstream server to use,
so we can just blindly relay the message.
This allows users to send a self-WHO/WHOIS to check their cloak and