WEBIRC command clarification for bouncers

[Kufat]

It might be worthwhile to address bouncers in the spec for the WEBIRC command. My thoughts would be something like the following:

• A bouncer that chooses to support the WEBIRC command and which has exactly one client connection for a given IRC session MUST pass that client's IP/hostname in the WEBIRC command, as any other gateway would.
• A bouncer with multiple client connections MUST pass one IP/hostname associated with an active client connection. It SHOULD be either the connection most recently established or most recently active (i.e. the current connection over which which a command was most recently transmitted.)
• A bouncer which currently has no client connections (e.g. one which is reconnecting to the IRC server after a loss of connectivity, while the user is not currently connected) MUST pass one IP/hostname which was recently used by a client. It SHOULD be either the connection most recently disconnected or most recently active (i.e. the one which most recently transmitted a command other than QUIT.)

I'm not overly concerned about the SHOULDs and would be happy to defer to anyone who has a strong opinion on that. My goal is to have the standard provide official guidance to BNC services like IRCCloud on how they can implement WEBIRC, in a way that doesn't necessitate adding any new arguments that would require code changes in IRC daemons.

[DanielOaks]

I feel like this'd fit in a non-normative guidance section. What's networks feelings of something like the above advice for account-based bncs? I had a case where a network requested that our bnc service randomly generate an IP for each account and send that mostly-consistent address rather than doing the most-recent-ip system described above. I imagine that might've been an outlier but confirming what networks think on this / the direction that bnc services out there are getting generally would be good either way.

[jwheare]

I think this is way out of scope for ircv3. Network agreements with hosted bouncer services are a policy decision between those parties, not a protocol decision.

[SadieCat]

Bouncers are out of scope for WEBIRC support given that not showing user IPs is the entire point of using them.

[DarthGandalf]

A bouncer supporting the WEBIRC command which has exactly one client connection for a given IRC session MUST pass that client's IP/hostname in the WEBIRC command, as any other gateway would.

No way.

Bouncers which are not associated with the network are just clients from server's point of view, and shouldn't expose the real client's IP. For many people that's the reason for using a bouncer.

And bouncers which are run by the network's administration (which is pretty much prerequisite for the server to trust the contents of WEBIRC command received from the bouncer) can be configured by the said administration to send whatever WEBIRC command they want.

the entire point of using them

Not the entire. There are other benefits too.

[Kufat]

Bouncers which are not associated with the network are just clients from server's point of view, and shouldn't expose the real client's IP. For many people that's the reason for using a bouncer.

Yeah; I'm not suggesting that bouncers be mandated to pass through a client's IP. The suggestion was more "if you want to support WEBIRC on your bouncer, this is how you should do it." I've updated the issue accordingly.

The suggestion that it be non-normative guidance sounds good to me.

And bouncers which are run by the network's administration (which is pretty much prerequisite for the server to trust the contents of WEBIRC command received from the bouncer) can be configured by the said administration to send whatever WEBIRC command they want.

This wasn't aimed at someone running a personal bouncer, or even small shell and BNC providers. I was thinking in terms of lage-scale services like Mibbit (which currently uses WEBIRC, and which I trust to report accurate client IPs) if they ever add bouncer functionality and IRCCloud (which has said that part of the reason they don't support WEBIRC is because a user may not always be connected to IRCCloud at the time IRCCloud is connecting to a server.)

[jwheare]

part of the reason they don't support WEBIRC is because a user may not always be connected to IRCCloud at the time IRCCloud is connecting to a server

The primary reason is that consistent ids are a better way to identify users and can just as easily be used for bans. There is no need for IRCCloud to support WEBIRC. Not leaking IP addresses is a side benefit.

[Kufat]

Perhaps I misinterpreted your recent tweet, then; it sounded as though the specifics of using WEBIRC with no client currently attached were a substantial part of why IRCCloud hadn't implemented it. I apologize for any misunderstanding on my part.

In any event, while that conversation was the immediate inspiration for this suggestion, it wasn't aimed at IRCCloud in particular.

[prawnsalad]

I've thought about WEBIRC in kiwibnc in the past and ultimately decided it wasn't a good idea. As @jwheare mentioned, using it as some form of identifier is better done using idents or hostnames depending on the BNC service.

The case of deciding which client IP (when there are multiple clients or multiple IPs the client connected from) is sent to the network differs between different networks and opers that I've spoken to. Then from a users perspective they may be using the BNC as a way to hide their IP in the first place. I don't think it's even worth a comment on recommending a way to implement this due to all the different ways possible.

There is currently nothing stopping a BNC provider and network agreeing on what IP should be sent to the network so if a network requires some non-usual WEBIRC function then that's perfectly fine as is already.