Instead of always bouncing, kills to a relay client are now handled as follows:
1) If the target and source networks are both in any killshare pool, relay the kill entirely
2) Otherwise, iterate over all channels the kill target is in:
3) If the killer has claim access in a channel, forward the KILL as a kick
4) Otherwise, bounce the kill (so far, silently)
TODO: kill messages are currently very cluttered, we should make our parser deliver more concise strings...
* GL|unreal has quit (Killed (chary.relay (KILL from GL/chary: Killed (GL (test)))))
Also, show a slightly different error when using the command with 'remote', since the clientbot client gets overridden to be the message sender.
This mirrors the fix in 1.x: commit 9578fd5ac3
This can cause channels to be inadvertently set modes that it shouldn't be on a relink (e.g. modes set by services DEFCON), since relay ignores modes from defined u-lines instead of bouncing them.
add_persistent_channels() is usable regardless of whether the service bot is ready, so we do not need to break if the remote copy of the service bot doesn't exist.
Closes#606.
- Make dynamic_channels per plugin as well as per network to work around relay-service conflicts (#265)
- Introduce ServiceBot.(add|remove)_persistent_channel() to add/remove persistent channels and optionally join/part them
- Introduce ServiceBot.part(), which checks remaining persistent channels list and parts a channel only if it is still not marked persistent
- Refactor automode to autojoin channels on ENDBURST instead of plugin load
- Refactor relay to manage persistent channels on join/part/(de)init, both locally (namespace 'relay_local') and remotely (namespace 'relay_remote')
This behaviour really isn't consistent across IRCds though...
- Unreal, Hybrid, and charybdis mangle messages at the server side to use the lowest prefix
- InspIRCd throws a "No such nick/channel" error
- Nefarious silently drops messages with multiple prefixes?
So far, this code only knows about changing prefixes while keeping mode characters as-is.
A complete but longer solution would be to actually go through irc.cmodes, but I don't
think doing so is necessary given how little STATUSMSG is actually used in production.
This is a very specific hack that shouldn't be extended across the protocol module spec. So far, all other protocol modules ignore the endburst_delay option anyways.
