Feature to log/notify of incoming CTCP requests, including those with custom replies #256

New Issue

2026-10-05T04:08:06+02:00

adam commented

2026-10-05 04:08:06 +02:00

ZNC as it stands appears to offer no way for clients to know if e.g. a CTCP VERSION has been sent to them if the VERSION reply is overridden and handled by ZNC itself. Many IRC users, including myself, like to know when our clients are being interrogated, even if the "client" is ZNC.

Whether as a core function or a module, CTCP requests handled by ZNC ought to notify connected clients and/or the log and/or the channel buffer if the user wishes, on a per-network basis at the very least. This is not forwarding the requests themselves, but rather inserting a line in the chat as some popular IRC clients (e.g. X-Chat) do.

This notification/logging should include all common CTCP requests (VERSION, PING, INFO, etc.)—no incoming CTCP request should be filtered by default. (For my purposes, filtering is undesirable, but in the future someone may wish to define which CTCP types are notified to clients/logs.)

ZNC as it stands appears to offer no way for clients to know if e.g. a `CTCP VERSION` has been sent to them if the `VERSION` reply is overridden and handled by ZNC itself. Many IRC users, including myself, like to know when our clients are being interrogated, even if the "client" is ZNC. Whether as a core function or a module, CTCP requests handled by ZNC ought to notify connected clients and/or the log and/or the channel buffer if the user wishes, on a per-network basis at the very least. This is not forwarding the requests themselves, but rather inserting a line in the chat as some popular IRC clients (e.g. X-Chat) do. This notification/logging should include all common CTCP requests (`VERSION`, `PING`, `INFO`, etc.)—no incoming CTCP request should be filtered by default. (For my purposes, filtering is undesirable, but in the future someone may wish to define which CTCP types are notified to clients/logs.)

adam closed this issue

2026-10-05 04:08:06 +02:00

adam commented

2026-10-05 04:08:07 +02:00

This would also be nice when whole channels are versioned so ops using ZNC could see when it happens and take action like set mode +C.

This would also be nice when whole channels are versioned so ops using ZNC could see when it happens and take action like set mode +C.

adam commented

2026-10-05 04:08:07 +02:00

I wrote this module [raw] if anyone is still interested in the issue. It doesn't exactly do as described (I don't know how to access existing custom CTCP's) but still does the trick, provided you are content with adding the CTCP replies to listen for yourself.

It possibly has some flaws; no warrenty, yo.

(20:09:29) <*ctcp_notifier> Replying to CTCP VERSION by name (name!~ident@host) to #znc.
(20:09:29) [name:#znc VERSION]

that said, considering I wrote the module, I'm all in favour of this issue being in the core of ZNC.

Note: the main concern for this when I proposed it on IRC was that the client would also respond. Which is why I used PutModule.

I wrote [this module](https://github.com/Zarthus/Code-Snippets/blob/master/c%2B%2B/znc-modules/ctcp_notifier.cpp) [[raw]](https://raw.githubusercontent.com/Zarthus/Code-Snippets/master/c++/znc-modules/ctcp_notifier.cpp) if anyone is still interested in the issue. It doesn't exactly do as described (I don't know how to access existing custom CTCP's) but still does the trick, provided you are content with adding the CTCP replies to listen for yourself. It possibly has some flaws; no warrenty, yo. ``` (20:09:29) <*ctcp_notifier> Replying to CTCP VERSION by name (name!~ident@host) to #znc. (20:09:29) [name:#znc VERSION] ``` that said, considering I wrote the module, I'm all in favour of this issue being in the core of ZNC. Note: the main concern for this when I proposed it on IRC was that the client would also respond. Which is why I used PutModule.

adam commented

2026-10-05 04:08:08 +02:00

I don't know how to access existing custom CTCP's

@Zarthus you can look how webadmin does it.
https://github.com/znc/znc/blob/fd4c355e46234ef0d9c33e14418706fbc9be7b75/modules/webadmin.cpp#L1211

> I don't know how to access existing custom CTCP's @Zarthus you can look how webadmin does it. https://github.com/znc/znc/blob/fd4c355e46234ef0d9c33e14418706fbc9be7b75/modules/webadmin.cpp#L1211

adam commented

2026-10-05 04:08:09 +02:00

Thanks for the feedback, I'll see if I can get about improving it.

Thanks for the feedback, I'll see if I can get about improving it.

adam commented

2026-10-05 04:08:09 +02:00

I updated the module to incorporate the feedback and created a wiki page for it here. Let me know if there is anything else.

The only issue it seems to have after extended testing is that the constructor may not properly call LoadCustomUserCtcpResponses(), I tried debugging and in general it just doesn't seem to trigger. Other modules seem to do the same, and all documentary found suggests this is fine. So I decided to leave it like that.

I updated the module to incorporate the feedback and created a wiki page for it [here](http://wiki.znc.in/Ctcp_Notifier). Let me know if there is anything else. The only issue it seems to have after extended testing is that the constructor may not properly call `LoadCustomUserCtcpResponses()`, I tried debugging and in general it just doesn't seem to trigger. Other modules seem to do the same, and all documentary found suggests this is fine. So I decided to leave it like that.

adam commented

2026-10-05 04:08:10 +02:00

Looks like @Zarthus fixed this issue... Reopen if it's not the case.

Looks like @Zarthus fixed this issue... Reopen if it's not the case.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#256