Add draft/bouncer-networks

[emersion]

This is based on the vendored soju.im/bouncer-networks extension.

• [ ] Consider using irc:// URLs instead of host/port attrs
• [ ] Consider adding a way for servers to advertise supported network attrs
• [ ] Consider adding an enabled attr
• [ ] Consider adding a way for network notifications to remove attributes (e.g. BOUNCER NETWORK b33f -host,-port)
• [ ] More attributes
• [ ] More errors

cc @DarthGandalf @itsonlybinary

[Herringway]

iirc there is a written spec for irc:// urls but I don't think it matches the de facto standard

[progval]

discussion here: https://github.com/ircdocs/modern-irc/issues/6

[emersion]

Well, I think we also don't want to allow all irc:// URLs. We probably only want to allow host/port and irc/ircs, nothing else (no user/password, no target, no query params, etc).

Additionally I'm not a fan of allowing irc:// (as opposed to ircs://). irc:// makes it extremely easy for clients to setup plain-text connections. In other words, setting up TLS requires extra effort (paying attention to use the ircs:// variant instead of the widely used irc:// variant). I'd rather have it the other way around (TLS by default, and explicit extra effort needed to setup plain-text connections).

[hhirtz]

Server implementations:

• soju

Client implementations:

• gamja
• senpai
• weechat (via a plugin)

[ItsOnlyBinary]

• Consider using irc:// URLs instead of host/port attrs seems this is just more parsing and no added benefit, currently all the needed data can be obtained using the same code as message-tags

• Consider adding a way for servers to advertise supported network attrs this could possibly be handy for custom attrs, could also include a bouncer name/type/version kinda thing if the client wanted to support special cases/features for a particular bouncer maybe a BOUNCER_VERSION= RPL_ISUPPORT

• Consider adding an enabled attr this could be useful

• Consider adding a way for network notifications to remove attributes (e.g. BOUNCER NETWORK b33f -host,-port) surely if bouncer-notify it could just resend the whole network configuration on changes, as most attributes would change not just be removed

• More attributes guess this falls under advertising supported attrs

• More errors not sure on what extra errors could be included I do think the error format should be changed to start with BOUNCER though so it makes it easier to quickly decide if its something that needs processing by the BOUNCER code or passing down the event queue. the current FAIL BOUNCER does not feel consistent, and just adds more complexity to the code having to check two params if the first one is FAIL

[emersion]

could also include a bouncer name/type/version kinda thing if the client wanted to support special cases/features for a particular bouncer

I'd prefer to avoid version checks, and instead use feature detection. ie. enable $feature the bouncer advertises kiwiirc.com/asdf instead of checking for BOUNCER_VERSION >= x.y.z.

surely if bouncer-notify it could just resend the whole network configuration on changes, as most attributes would change not just be removed

It depends how many attributes we'll end up with I guess. Sending all the data always may not scale well.

I do think the error format should be changed to start with BOUNCER though so it makes it easier to quickly decide if its something that needs processing by the BOUNCER code or passing down the event queue. the current FAIL BOUNCER does not feel consistent, and just adds more complexity to the code having to check two params if the first one is FAIL

Nack, the current spec uses standard replies.

[emersion]

It would also be nice to have a way for the bouncer to send a plain-text status message for each network. This would allow clients to show in their UI the reason why a network is disconnected.