Add a protocol for connecting multi-user clients

[Lyude]

A very large issue with IRC networks is the presence of multi-user bouncers. They are, and always have been a major pain to moderate. An operator needs to put trust in the person running the bouncer that when they ask for a user to be removed, that that user is removed. This is a very risky way of handling network politics, and most of time is more trouble then it's worth. So here's the solution: multi-user clients. A single client, in this case a bouncer, connects to an IRC network, and multiplexes each IRC session on it through the same connection. Each user has their own ID, and the server marks every IRC message with this ID, instead of the user's nickname. This has some huge benefits:

• An operator can ban a user's ID from the bouncer connection, allowing them to quickly remove a user without harming any of the others.
• No trust has to be put into the bouncer. With banned users, the ircd can simply choose to ignore messages coming from their IDs.
• No more clone exemptions need to be made.

We may want to require every user ID to register with the ircd, before actually being allowed to connect through the multiplexed IRC connection.This could possibly be done through the registration of a nickname. This also prevents a malicious attacker from hijacking a bouncer, and attempting to connect as many UIDs as possible.

[Xe]

I really like this idea. Some shower thoughts:

1. This should be a ratbox-style client CAP that can only be set pre-connection of a client, and when set denies the use of NICK and USER as a normal client would register with.
2. The server could use IRCv3 message tags to identify incoming and outgoing messages to the correct clients. This could really be as simple as:

<< @source=THEBIRD PRIVMSG #elemental-ircd :Why hello there
>> @target=R00DBADF00D :Xena!oper@yolo-swag.com PRIVMSG #elemental-ircd :Why hello there

1. Another thing to consider is the protocol for creating identifiers and allowing or denying them based on network configuration. I think that the pragmatic solution would be to allow both. Allow a sort of 'open registration' of manyclient id's and also allow an authoritative mode so that networks could allow and deny id's from being registered.
2. I think that the identifiers should be set as client METADATA and should be assigned by the server as a RFC 4122 compliant universally unique identifier.

---

I think that the next step for this should be creating a spec and starting on experimental implementations. I want to see this as part of version 7.0.

[Xe]

There has been some concern about this being able to be easily abused for flooding. Maybe it would be best for this to be a purely whitelisted thing such as the existing OperServ CLONES command family instead of allowing open registration at all. This should be able to be set and controlled from services however. Maybe a combination of an ENCAP command, a client command for opers (who don't use services compatible with this feature) and making modules for a few popular services packages would be a good idea for this.

[dequis]

Why isn't this in the ircv3 issue tracker?

[Lyude]

@dequis we have our reasons :3

[Lyude]

Also this was brought up during me and Xena talking. Instead of simply ignoring messages from banned user IDs, it may be better to outright disable connections from a bouncer if it tries to avoid banned user IDs, and require manual intervention from an operator to reenable the connection. This means if there's potentially a bouncer that's been hijacked, it can't continue to flood the server.

[dequis]

Well, if you can figure out a server-only solution, that's cool, but the original description of this ticket sounded like you'd need to have this implemented in znc etc.

[Xe]

The idea is to make a specification that defines policy implementations as well as frameworks for the mechanism to follow. Later support for znc et. al would be a plus for getting it to be used but wouldn't be in the scope of the basic implementation in my opinion.

[Xe]

Hmm

Maybe the lines being sent could depend on if it is a message that more than one client over that connection needs to worry about.

Say you have 5 people on the server and they are all in #foo. You could have the ircd only send one line to #foo and the bouncer would figure it out from there. Or if it is absolutely for one person you could have it send a tag-recipient message.

[Xe]

This might be out of scope for 7.0.