ref: cacbd4894902833fff024e2e51d7d0ec42ad5926 soju/downstream.go -rw-r--r-- 59.4 KiB
Don't suggest users to /motd in multi-upstream mode
Make user MODE commands fail in multi-upstream mode

References: https://todo.sr.ht/~emersion/soju/20
Forward user mode changes in single-upstream mode

References: https://todo.sr.ht/~emersion/soju/20
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

References: https://github.com/ircv3/ircv3-specifications/pull/450
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

References: https://todo.sr.ht/~emersion/soju/41
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

References: https://github.com/ircv3/ircv3-specifications/pull/439
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
other information.