support attaching multiple TCP connections to the same nick / registration

[slingamn]

jwheare points out that this more or less means making the server act as a bouncer. Basically:

1. Config setting like allow-multiple-connections
2. If enabled, a second connection/registration for the same nick is allowed
3. Implementation: the connection gets shoved into the same old Client object; any time we would send to the client's socket, we instead send to all the sockets
4. Caps are whatever the original session negotiated
5. Client commands can probably still only execute on a single goroutine, since we want client commands executing in a well-defined order. (Do we though?) (If we do, this is finally a good use case for channels: the client goroutine can wait on a chan ircmsg.IrcMessage that multiple reader goroutines can send to)
6. Ping timeout and QUIT remove a socket, not the whole client; the client is only removed once all its sockets are gone. (In the sequel, we introduce a configurable "sticky" mode, for use with persistent history, where the client is not removed even when all its sockets are gone; PRIVMSG go straight to persistent history instead.)

[slingamn]

Leaning towards fully concurrent execution, i.e., a separate command execution goroutine per TCP connection. Right now, client command execution can take "as long as necessary"; as long as we're not holding a mutex or using a lot of CPU, the client goroutine can block on whatever (up to the ping timeout) without harming anything. This is relevant in the persistent history case where we may want to do slow writes to a remote datastore. If all connections share a command execution goroutine, they can starve each other.

Also, very little of the client's state is explicitly goroutine-local and unsynchronized: just fields like registered and resumeDetails, which are irrelevant after registration (and you should only be able to attach a second connection once the first is registered).

[slingamn]

If the original connection is secure, then you can't attach a new insecure connection.

[slingamn]

This will interact badly with Tor. You shouldn't be able to attach regular connections to a Tor connection or vice versa.

[DanielOaks]

I am interested in this. However, it comes with lots of issues and lots of things that we will need to consider. This should be a capability or something similar, I really don't want to surprise clients by unexpectedly enabling bouncer-like multiple connection stuff on them without the client realising.

I'm very unsure of this being in master, and if it is it shouldn't be enabled by default imo. What sorts of trouble does this solve for users, and how does whatever solution we go with for this solve the problem in such a way that regular users are going to be able to use it and not get confused or something similar?

[slingamn]

What sorts of trouble does this solve for users, and how does whatever solution we go with for this solve the problem in such a way that regular users are going to be able to use it and not get confused or something similar?

The big picture is that this is part of "Slack mode" (along with persistent history and a "sticky mode" where the server always maintains a client object per account, even when 0 TCP connections are attached to it).

The little picture is: imagine a user who is not a veteran IRC user, but is coming from a non-IRC system. To this user, this behavior is not confusing --- nicknames are confusing. A separate identity per TCP connection is a weirdly exposed implementation detail.

Another way of putting it: IRC doesn't work well without a bouncer, but bouncers are hard to use, so we should have a mode of operation where the server acts as a bouncer.

I'd like this to work with legacy clients that don't have the cap, but we should definitely discuss more about how to avoid confusion. An initial proposal:

1. Two config booleans, one to allow this at all and one to allow it by default (both default to false, as usual)
2. Users can opt in (if "allowed" is true and "default" is false) by negotiating a cap
3. Users can opt in (if "allowed" is true and "default" is false) by setting a profile option with nickserv
4. Users can opt out (if "allowed" is true and "default" is true) by setting a profile option with nickserv

[DanielOaks]

Ahhh, I see. Yeah after thinking and tossing this around a bit more (especially thinking about it more like just having bouncer functionality in the IRCd itself, a take it seems like jw came up with), I'm fine with this being a part of the server.

So with those two config booleans, I like that, but: I reckon we can just let it be 'allowed' all the time. Unless there's specifically cases where we believe the code's fragile and want to let people disable it for that reason, it should just be supported out-of-the-box and advertised as a capability as proposed. The default config boolean's a great thing to have though, for sure.

[DanielOaks]

Noted by @slingamn, the updated resume spec will be integrating the BRB command, which allows clients to basically ask the server "Yo can you sever this connection for a short amount of time so I can <perform updates/etc/whatever> and then come back and RESUME?" Since this change involves allowing more than one connection per open client session, makes sense to also handle the case of zero clients being connected to a session.

[slingamn]

I think almost all our service-related functionality can be disabled by the operator, and there are cases where it might be useful to disable this as well (a deployment with bad clients that get confused, or the need to mitigate a security vulnerability), so I feel like we should probably include a complete off switch for this.

[DanielOaks]

Yeah that's fair. I'd go for being available out of the box, but the default flag being false.

[slingamn]

note: dan suggests that we advertise znc.in/self-message

[slingamn]

This is basically complete as of #458; #466 has one follow-up, and we can file separate tickets for other action items.