Add support for 'away-notify' at capability negotiation time [$30 awarded] #209

New Issue

2026-10-05T04:04:44+02:00

adam commented

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

This would make displaying of the away status in irc clients possible without the need for WHO polling which is not a nice way to do it. More information: http://ircv3.atheme.org/extensions/away-notify-3.1

Of course this only works with irc servers/networks that support this feature. ~~As far as I know this should work on freenode, which is one of the biggest networks.~~

The $30 bounty on this issue has been claimed at Bountysource.

This would make displaying of the away status in irc clients possible without the need for WHO polling which is not a nice way to do it. More information: http://ircv3.atheme.org/extensions/away-notify-3.1 Of course this only works with irc servers/networks that support this feature. <del>As far as I know this should work on freenode, which is one of the biggest networks.</del> ## <bountysource-plugin> The **[$30 bounty](https://www.bountysource.com/issues/141917-add-support-for-away-notify-at-capability-negotiation-time?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** on this issue has been claimed at [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github). </bountysource-plugin>

adam closed this issue

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

adam commented

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

I'll go ahead and share the solution I tossed together for myself, though it is as of yet not ideal. It could be improved upon in a few ways, I think, with some additional code, but as it is the proper solution is to wait for cap-notify and then implement it properly that way.

The module away_notify can be found here along with some additional notes.

I'll go ahead and share the solution I tossed together for myself, though it is as of yet not ideal. It could be improved upon in a few ways, I think, with some additional code, but as it is the proper solution is to wait for [cap-notify](https://github.com/ircv3/ircv3-specifications/blob/master/extensions/cap-notify-3.2.md) and then implement it properly that way. The module away_notify can be found [here](https://github.com/NuclearW/znc-modules/tree/master/away_notify) along with some additional notes.

adam commented

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

Support for away-notify would also be nice to have in core. WeeChat and many other clients support it, but they fallback to something else than away-notify when it's not supported. I don't remember what it was.

Support for `away-notify` would also be nice to have in core. WeeChat and many other clients support it, but they fallback to something else than `away-notify` when it's not supported. I don't remember what it was.

adam commented

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

It would indeed, but it has the same problems that the module I wrote has. Namely one cannot know during capability exchange before authentication if the client connecting is connecting to a network that supports away-notify.

Once cap-notify is no longer a moving target and IRCds start supporting it, adding away-notify and other capabilities to the core proper will be possible in a proper manner.

I imagine WeeChat falls back to doing WHO polling of channels periodically (this is what HexChat does, at least).

It would indeed, but it has the same problems that the module I wrote has. Namely one cannot know during capability exchange before authentication if the client connecting is connecting to a network that supports `away-notify`. Once `cap-notify` is no longer a moving target and IRCds start supporting it, adding `away-notify` and other capabilities to the core proper will be possible in a proper manner. I imagine WeeChat falls back to doing `WHO` polling of channels periodically (this is what HexChat does, at least).

adam commented

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

Namely one cannot know during capability exchange before authentication if the client connecting is connecting to a network that supports away-notify.

Oh, so this is the issue, I didn't understand this before.

Once cap-notify is no longer a moving target and IRCds start supporting it, adding away-notify and other capabilities to the core proper will be possible in a proper manner.

Is IRCd support really required? Why would anyone support it if no one else supports it either and most of networks aren't upgrading IRCds so often, so there would still be issue of the network maybe not supporting cap-notify.

I imagine WeeChat falls back to doing WHO polling of channels periodically (this is what HexChat does, at least).

Probably. The help text only says rc.server_default.away_check: interval between two checks for away (in minutes, 0 = never check) [default: "0", values: 0 .. 10080. It seems to be 1 for me and whoing medium number of channels which I am currently doesn't seem to be a good idea for me when away-notify is supported by the network.

WeeChat also has variable for setting maximum number of nicks on channel where to check away status and this seems to be set 0 to me (unlimited) while it defaults to 25.

> Namely one cannot know during capability exchange before authentication if the client connecting is connecting to a network that supports away-notify. Oh, so this is the issue, I didn't understand this before. > Once cap-notify is no longer a moving target and IRCds start supporting it, adding away-notify and other capabilities to the core proper will be possible in a proper manner. Is IRCd support really required? Why would anyone support it if no one else supports it either and most of networks aren't upgrading IRCds so often, so there would still be issue of the network maybe not supporting cap-notify. > I imagine WeeChat falls back to doing WHO polling of channels periodically (this is what HexChat does, at least). Probably. The help text only says `rc.server_default.away_check: interval between two checks for away (in minutes, 0 = never check) [default: "0", values: 0 .. 10080`. It seems to be `1` for me and `who`ing medium number of channels which I am currently doesn't seem to be a good idea for me when `away-notify` is supported by the network. WeeChat also has variable for setting maximum number of nicks on channel where to check away status and this seems to be set `0` to me (unlimited) while it defaults to `25`.

adam commented

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

Is IRCd support really required? Why would anyone support it if no one else supports it either and most of networks aren't upgrading IRCds so often, so there would still be issue of the network maybe not supporting cap-notify.

Now that I think about it more, no actually. We just need clients to support it to make it useful to us. znc'd offer cap-notify at connection time, then if the client has it znc could then enable the network-specific capabilities before playing back buffer on a connection with the network already connected, or later on when znc itself connects to the network.

> Is IRCd support really required? Why would anyone support it if no one else supports it either and most of networks aren't upgrading IRCds so often, so there would still be issue of the network maybe not supporting cap-notify. Now that I think about it more, no actually. We just need clients to support it to make it useful to us. znc'd offer `cap-notify` at connection time, then if the client has it znc could then enable the network-specific capabilities before playing back buffer on a connection with the network already connected, or later on when znc itself connects to the network.

adam commented

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

I am running ZNC with -D at the moment and it seems to be mostly WHO replies.

I haven't heard anything useful from clients and I know only WeeChat (https://github.com/weechat/weechat/issues/182) to have issue about cap-notify and nothing seems to have happened there. There was only weird sounding suggestion to make ZNC just disconnect clients when it's not connected to server (https://github.com/weechat/weechat/issues/182#issuecomment-53982865).

I am running ZNC with `-D` at the moment and it seems to be mostly `WHO` replies. I haven't heard anything useful from clients and I know only WeeChat (https://github.com/weechat/weechat/issues/182) to have issue about `cap-notify` and nothing seems to have happened there. There was only weird sounding suggestion to make ZNC just disconnect clients when it's not connected to server (https://github.com/weechat/weechat/issues/182#issuecomment-53982865).

adam commented

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

We were just discussing about this at #znc at freenode and noticed that I have very high amount of traffic which I think is mostly caused by WHO. Another person pasted their traffic which was 2GiB in one week.

2014-09-19 19:41:41+0300 < *status> +----------+-------+--------+--------+
2014-09-19 19:41:41+0300 < *status> | Username | In    | Out    | Total  |
2014-09-19 19:41:41+0300 < *status> +----------+-------+--------+--------+
2014-09-19 19:41:41+0300 < *status> | Mikaela  | 3 GiB | 3 GiB  | 6 GiB  |
2014-09-19 19:41:41+0300 < *status> | <Users>  | 3 GiB | 3 GiB  | 6 GiB  |
2014-09-19 19:41:41+0300 < *status> | <ZNC>    | 8 KiB | 21 KiB | 29 KiB |
2014-09-19 19:41:41+0300 < *status> | <Total>  | 3 GiB | 3 GiB  | 6 GiB  |
2014-09-19 19:41:41+0300 < *status> +----------+-------+--------+--------+
2014-09-19 19:41:43+0300 < *status> Running for 3d 9h 28m 55s

We were just discussing about this at #znc at freenode and noticed that I have very high amount of traffic which I think is mostly caused by `WHO`. Another person pasted their traffic which was 2GiB in one week. ``` 2014-09-19 19:41:41+0300 < *status> +----------+-------+--------+--------+ 2014-09-19 19:41:41+0300 < *status> | Username | In | Out | Total | 2014-09-19 19:41:41+0300 < *status> +----------+-------+--------+--------+ 2014-09-19 19:41:41+0300 < *status> | Mikaela | 3 GiB | 3 GiB | 6 GiB | 2014-09-19 19:41:41+0300 < *status> | <Users> | 3 GiB | 3 GiB | 6 GiB | 2014-09-19 19:41:41+0300 < *status> | <ZNC> | 8 KiB | 21 KiB | 29 KiB | 2014-09-19 19:41:41+0300 < *status> | <Total> | 3 GiB | 3 GiB | 6 GiB | 2014-09-19 19:41:41+0300 < *status> +----------+-------+--------+--------+ 2014-09-19 19:41:43+0300 < *status> Running for 3d 9h 28m 55s ```

adam commented

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

cap-notify might not even be required for a prototype implementation... I think sending an unsolicited CAP LS would cause most existing clients to react in the expected way and request newly available caps.

(Edit: Thinking about it a bit more, I'm actually quite surprised it works at all.)

`cap-notify` might not even be required for a prototype implementation... I think sending an unsolicited CAP LS would cause most existing clients to react in the expected way and request newly available caps. (Edit: Thinking about it a bit more, I'm actually quite surprised it works at all.)

adam commented

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

@grawity

Using unsolicited CAP LS works at least for HexChat, and I've an away_notify_unsolicited module which uses that method here now.

@grawity Using unsolicited CAP LS works at least for HexChat, and I've an away_notify_unsolicited module which uses that method [here](https://github.com/NuclearW/znc-modules/tree/master/away_notify) now.

adam commented

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

I have been testing away_notify since https://github.com/znc/znc/issues/315#issuecomment-56202498 and here are my current uptime and traffic.

2014-09-23 14:02:32+0300 < *status> Running for 3d 17h 6m 24s
2014-09-23 14:02:34+0300 < *status> +----------+--------+--------+--------+
2014-09-23 14:02:34+0300 < *status> | Username | In     | Out    | Total  |
2014-09-23 14:02:34+0300 < *status> +----------+--------+--------+--------+
2014-09-23 14:02:34+0300 < *status> | Mikaela  | 23 MiB | 23 MiB | 46 MiB |
2014-09-23 14:02:34+0300 < *status> | <Users>  | 23 MiB | 23 MiB | 46 MiB |
2014-09-23 14:02:34+0300 < *status> | <ZNC>    | 1 KiB  | 3 KiB  | 4 KiB  |
2014-09-23 14:02:34+0300 < *status> | <Total>  | 23 MiB | 23 MiB | 46 MiB |
2014-09-23 14:02:34+0300 < *status> +----------+--------+--------+--------+

As you can see, traffic has decreased a lot.

I have been testing [away_notify](https://github.com/NuclearW/znc-modules/tree/master/away_notify) since https://github.com/znc/znc/issues/315#issuecomment-56202498 and here are my current uptime and traffic. ``` 2014-09-23 14:02:32+0300 < *status> Running for 3d 17h 6m 24s 2014-09-23 14:02:34+0300 < *status> +----------+--------+--------+--------+ 2014-09-23 14:02:34+0300 < *status> | Username | In | Out | Total | 2014-09-23 14:02:34+0300 < *status> +----------+--------+--------+--------+ 2014-09-23 14:02:34+0300 < *status> | Mikaela | 23 MiB | 23 MiB | 46 MiB | 2014-09-23 14:02:34+0300 < *status> | <Users> | 23 MiB | 23 MiB | 46 MiB | 2014-09-23 14:02:34+0300 < *status> | <ZNC> | 1 KiB | 3 KiB | 4 KiB | 2014-09-23 14:02:34+0300 < *status> | <Total> | 23 MiB | 23 MiB | 46 MiB | 2014-09-23 14:02:34+0300 < *status> +----------+--------+--------+--------+ ``` As you can see, traffic has decreased a lot.

adam commented

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

Maybe such usage of CAP LS works with some clients, but certainly not for every client.

Maybe such usage of `CAP LS` works with some clients, but certainly not for every client.

adam commented

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

The unsolicited CAP LS worked with HexChat, but was tested and shown not to work with weechat. It is not an acceptable solution at this point.

The unsolicited `CAP LS` worked with HexChat, but was tested and shown not to work with weechat. It is not an acceptable solution at this point.

adam commented

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

👍 Just put 10$ on this!

:+1: Just put 10$ on this!

adam commented

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

@NuclearW said:

It would indeed, but it has the same problems that the module I wrote has. Namely one cannot know during capability exchange before authentication if the client connecting is connecting to a network that supports away-notify.

cap-notify does not solve this problem. All capabilities are listed in CAP LS, and the spec says you should use CAP LS for discovery. Whatever weechat's problem is, it's not to do with CAP LS.

In other words why wouldn't the client know it's connecting to a network that supports away-notify. Is this some weird bouncer quirk? Can someone explain it?

@NuclearW said: > It would indeed, but it has the same problems that the module I wrote has. Namely one cannot know during capability exchange before authentication if the client connecting is connecting to a network that supports away-notify. `cap-notify` does not solve this problem. All capabilities are listed in `CAP LS`, and the spec says you should use `CAP LS` for discovery. Whatever weechat's problem is, it's not to do with `CAP LS`. In other words why wouldn't the client know it's connecting to a network that supports `away-notify`. Is this some weird bouncer quirk? Can someone explain it?

adam commented

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

Nevermind it's about offering the capabilities to clients. I get it now.

Nevermind it's about offering the capabilities to clients. I get it now.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#209