userip-tag and userhost-tag

[syzop]

In UnrealIRCd we implemented the following about 6 months ago. Credit for the idea does not go to me but to @westor7. I am just wondering if there is interest in the IRCv3 group of making this an official tag rather than a vendor tag like it is now.

We have the unrealircd.org/userip tag which adds user@ip information when the user has sufficient privileges to see such information (in our case, currently: user is IRCOp).
Similarly, we have the unrealircd.org/userhost tag which adds user@realhost information.
As we all know, the displayed host and IP may differ from the current active host (cloaking, vhost, etc).
Both tags are only sent if the recipient both 1) has sufficient privileges, and 2) has message-tags enabled.

The end result is something like this:
@unrealircd.org/userhost=~x@localhost;unrealircd.org/[email protected];time=etc. :client!~x@Mask-4E7B8307 JOIN :#test

Why not alter the source for IRCOps

Perhaps on first sight one may wonder why we don't just alter the :nick!user@host source of messages sent to IRCOps. There are, in fact, a number of problems with that:

1. This propagates to things such as automated ban scripts exposing the real host while this was not intended. It is better for a script maker to make a thoughtful decision to use the real host (say $realhost) or IP (say $ip) instead of the displayed host (say $host).
2. IRCOps would loose visibility of the host that all non-IRCOps see
3. It does not solve the problem of showing IP's. You can only show one host, so not both resolved host and IP at the same time. (The only time when this is not a problem is if the host did not resolve, of course)
4. Complicating server code (subjective, but intrusive in my case)

When can this be useful?

This could be useful to trusted bots/scripts that may take action on the users with real host / real IPs. I suppose it could also be useful to trusted bots/scripts that log channel activity for legal or compliance reasons, but that may be a bit far fetched.
I totally admit the use case is not very broad, it is in fact limited. But I could see some use and that is why I implemented it. Also important for me, in my case it didn't clutter the source code and is self-contained, all the adding of this information is done automagically. It is also only sent to a limited number of people (IRCOps) so not wasting much overall server bandwidth.

Feedback

Let me know what you think. If there is no interest because it is too small of a use case or other reasons, then no problem, then it just stays a vendor tag.

[Robby-]

I actually came up with this (*) idea in 2017 and made an issue about it in the inspircd repository because I have a need for this for our non-opered bots (and non-opered staff) to still be able to do their jobs properly.

Edit: (*) Not exactly THIS idea with tags, but, yeah.

[syzop]

@Robby- Yeah, sending real hosts or IPs to certain groups has come up once in a while before. I even have a closed feature suggestion from 2003 about it. In MS Exchange (IRCX) it already showed realhost to chanops, so years before that. I think it was in Exchange 5.5 already but it could also have been Exchange 2000. (Side note: exposing uncloaked hosts to normal chanops is something I really disliked, and I think I misread the 2003 suggestion which was actually about ircops)

Anyway, you have read about the downsides and complexity that makes altering the message source highly unfavorable. I see you mention the same downsides and call it opening a can of worms, which is entirely correct.
Thing is, with tags it is possible to communicate this information in a good way. As for who gets to see it, I think that is up to the server software and server configuration.

[edk0]

Why do the tags repeat the username? I'd have thought it cleaner just to send the host or IP.

[jobe1986]

I have to say I agree with @edk0 on this, if we really need to include the username it should be a separate tag so as to not repeat the username more then once. Otherwise it just becomes repeated data taking up message space.

[syzop]

Sure, we can scratch the username part and change the tag names accordingly, like to ip and realhost. I don't mind.

[genius3000]

I've added a non-official InspIRCd implementation of this to the inspircd-contrib repo. I took the comments here into consideration and went with the names ip and realhost as well as not sending the user@ part.

[slingamn]

Oragono sends this information to privileged users in the WHOIS response, using the 338 RPL_WHOISACTUALLY numeric. (The modern numerics registry says this is also implemented by ircu and bahamut.) The parameters are:

<client> <nick> <user@real_hostname> <real_ip> :Actual user@host, Actual IP

I have no strong feelings about the present proposal; I'm really just mentioning 338 for completeness.

[slingamn]

Inspircd and Unreal appear to use 378 RPL_WHOISHOST for this purpose? But the data is carried in a freeform final parameter.

[westor7]

Does this needs anything else?

I think ip and realhost seems nice to finish and merge this as mentioned here #418 (comment)

[jesopo]

this appears to be quite similiar to solanum-ircd/solanum#13

solanum.chat/realhost cap which adds:

• solanum.chat/ip msg tag which shows either a non-vhost user's IP to everyone or shows vhost user's IP to opers
• solanum.chat/realhost msg tag to show hostname behind a vhost to opers

[jwheare]

Is there consensus on this across unreal, inspircd, solanum and oragono?

[DanielOaks]

We don't have an implementation but would be happy to implement a standardised version of this.

[slingamn]

I prefer the solanum design where you have to explicitly request a (new) CAP to get these.

[slingamn]

This issue came up in a new context (adding a new server tag to PRIVMSG that indicates the channel operator status of the poster), so I wanted to get my thoughts down on it: I think that in general, new server tags should require the client to explicitly request a new CAP. Rationale:

1. "Explicit is better than implicit"
2. The performance burden of requesting a new CAP should be negligible (it doesn't have to impose an additional RTT; I think most client implementations have not fully explored the possibilities for optimizing the latency of the existing CAP negotiation process; see discussion on ergo.chat/abbreviated-handshake ergochat/ergo#1420). In contrast, the bandwidth costs of sending an unwanted (or uninterpretable) tag on each message, over the lifetime of the connection, may be substantial. So it makes sense for the server to have this information, so it can make the appropriate performance tradeoff (e.g., between caching a uniform serialized line and saving bandwidth). The bandwidth cost may also be relevant to clients, although the guarantees are weaker there (since message-tags indicates the client's willingness to receive any server tags).
3. With regard to realip/realhost specifically: it simplifies server implementations if all the information needed to compose the serialized line (starting from a deserialized representation of the line's data) is contained in the CAP set, rather than in other properties of the client (in this case operator status) edit: @k4bek4be points out that this reasoning is confused
4. Also with regard to realip/realhost specifically: this data is sensitive, so clients may not want to receive it (consider, e.g., a hypothetical future client that logs messages including their server tags).

[SadieCat]

Inspircd and Unreal appear to use 378 RPL_WHOISHOST for this purpose? But the data is carried in a freeform final parameter.

This has been changed in master.

[jwheare]

Anyone want to turn this into a spec PR?

[syzop]

Sorry for not checking in, didn't realize this sparked a lot more interest by now :D. I suppose I would be willing to make a PR for a spec like this, yeah.

[SadieCat]

@syzop If you're interested in submitting a spec for this I would support it.

[syzop]

Ok great, then I'll work on that. Expect something in July / August.

[SadieCat]

@syzop Any updates on this?

[syzop]

I was enthusiastic and had good intentions but... long story short: I'm sorry I let you down. I keep forgetting or postponing this. I think it's better if someone else works on this. So I don't keep delaying this for no good reason.