adam/znc
1
0 Fork 0
mirror of https://github.com/znc/znc.git synced 2026-11-03 10:52:22 +01:00
Code Issues 362 Packages Projects Releases Wiki Activity

[Feature Request] Option to make ZNC/*status NOTICE instead of PRIVMSG [$5] #219

New Issue
Open
opened 2026-10-05 04:05:43 +02:00 by adam · 8 comments
adam commented 2026-10-05 04:05:43 +02:00
Owner
Copy link
Copy source

It is a matter of taste but I think having *status NOTICE is less annoying, for example in this case:

06:43 <_status> IRC connection timed out. Reconnecting...
06:43 <_status> Disconnected from IRC. Reconnecting...
06:44 <_status> IRC connection timed out. Reconnecting...
06:46 <_status> IRC connection timed out. Reconnecting...
06:48 <_status> IRC connection timed out. Reconnecting...
06:50 <_status> IRC connection timed out. Reconnecting...
06:51 <_status> Connected!
06:53 <_status> The channel #xy could not be joined, disabling it.

Sometimes NOTICE is used already, in this case parting #xy:
11:43 -*status(znc@znc.in)- Removing channel [#xy]

My wish: Let the user choose if he wants to get PRIVMSG'd or NOTICE'd

--- There is a **[$5 open bounty](https://www.bountysource.com/issues/276583-feature-request-option-to-make-znc-status-notice-instead-of-privmsg?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** on this issue. Add to the bounty at [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github).
It is a matter of taste but I think having *status NOTICE is less annoying, for example in this case: 06:43 <_status> IRC connection timed out. Reconnecting... 06:43 <_status> Disconnected from IRC. Reconnecting... 06:44 <_status> IRC connection timed out. Reconnecting... 06:46 <_status> IRC connection timed out. Reconnecting... 06:48 <_status> IRC connection timed out. Reconnecting... 06:50 <_status> IRC connection timed out. Reconnecting... 06:51 <_status> Connected! 06:53 <_status> The channel #xy could not be joined, disabling it. Sometimes NOTICE is used already, in this case parting #xy: 11:43 -*status(znc@znc.in)- Removing channel [#xy] My wish: Let the user choose if he wants to get PRIVMSG'd or NOTICE'd ## <bountysource-plugin> --- There is a **[$5 open bounty](https://www.bountysource.com/issues/276583-feature-request-option-to-make-znc-status-notice-instead-of-privmsg?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** on this issue. Add to the bounty at [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github). </bountysource-plugin> <!-- github-sync-id:13529147 -->
adam commented 2026-10-05 04:05:44 +02:00
Author
Owner
Copy link
Copy source

If you don't mind my opinion, I don't think this is a bright idea. A problem I routinely see with IRC clients is that they don't show notices all on one screen. By using a PRIVMSG it will open a window with *status and all messages will be seen, rather than notices sometimes getting missed because they don't always get dumped into a "notices" window, and sometimes only show up on the active tab/channel/window.

If you don't mind my opinion, I don't think this is a bright idea. A problem I routinely see with IRC clients is that they don't show notices all on one screen. By using a PRIVMSG it will open a window with *status and all messages will be seen, rather than notices sometimes getting missed because they don't always get dumped into a "notices" window, and sometimes only show up on the active tab/channel/window. <!-- github-comment-id:19500151 -->
adam commented 2026-10-05 04:05:45 +02:00
Author
Owner
Copy link
Copy source

See http://tools.ietf.org/html/rfc1459.html#section-4.4.2

4.4.2 Notice

      Command: NOTICE
   Parameters: <nickname> <text>

   The NOTICE message is used similarly to PRIVMSG.  The difference
   between NOTICE and PRIVMSG is that automatic replies must never be
   sent in response to a NOTICE message.  This rule applies to servers
   too - they must not send any error reply back to the client on
   receipt of a notice.  The object of this rule is to avoid loops
   between a client automatically sending something in response to
   something it received.  This is typically used by automatons (clients
   with either an AI or other interactive program controlling their
   actions) which are always seen to be replying lest they end up in a
   loop with another automaton.

   See PRIVMSG for more details on replies and examples.
See http://tools.ietf.org/html/rfc1459.html#section-4.4.2 ``` 4.4.2 Notice Command: NOTICE Parameters: <nickname> <text> The NOTICE message is used similarly to PRIVMSG. The difference between NOTICE and PRIVMSG is that automatic replies must never be sent in response to a NOTICE message. This rule applies to servers too - they must not send any error reply back to the client on receipt of a notice. The object of this rule is to avoid loops between a client automatically sending something in response to something it received. This is typically used by automatons (clients with either an AI or other interactive program controlling their actions) which are always seen to be replying lest they end up in a loop with another automaton. See PRIVMSG for more details on replies and examples. ``` <!-- github-comment-id:46812940 -->
adam commented 2026-10-05 04:05:45 +02:00
Author
Owner
Copy link
Copy source

@teward that depends on the client and its configuration, I don't think this is a valid concern, especially not if PRIVMSG/NOTICE is toggleable as an option in ZNC and you default to PRIVMSG (even if it would be wrong to do (at least in the case of the lines I have posted in op), see @Mikaela's post).

@teward that depends on the client and its configuration, I don't think this is a valid concern, especially not if PRIVMSG/NOTICE is toggleable as an option in ZNC and you default to PRIVMSG (even if it would be wrong to do (at least in the case of the lines I have posted in op), see @Mikaela's post). <!-- github-comment-id:70457970 -->
adam commented 2026-10-05 04:05:46 +02:00
Author
Owner
Copy link
Copy source

👍

I'd also prefer such messages as "Connected!" as notices, instead of opening a new *status query window.

:+1: I'd also prefer such messages as "Connected!" as notices, instead of opening a new *status query window. <!-- github-comment-id:131646307 -->
adam commented 2026-10-05 04:05:47 +02:00
Author
Owner
Copy link
Copy source

+1

I'd also prefer such messages as "Connected!" as notices, instead of opening a new *status query window.

+1 I'd also prefer such messages as "Connected!" as notices, instead of opening a new *status query window. <!-- github-comment-id:186895195 -->
adam commented 2026-10-05 04:05:47 +02:00
Author
Owner
Copy link
Copy source

Hi. In the meantime I have a suggested a workaround for weechat client, which is being proposed in the form of a bug fix, on an existing feature of weechat/buffers.pl

https://github.com/weechat/scripts/issues/146

Unfortunately it seems the script's author is being highly resistive to the idea of merging it ATM. Heres to hoping they will be a bit more sympathetic, and possibly change mind / make a concession. Its just a couple of lines of code.

Hi. In the meantime I have a suggested a workaround for weechat client, which is being proposed in the form of a bug fix, on an existing feature of weechat/buffers.pl https://github.com/weechat/scripts/issues/146 Unfortunately it seems the script's author is being highly resistive to the idea of merging it ATM. Heres to hoping they will be a bit more sympathetic, and possibly change mind / make a concession. Its just a couple of lines of code. <!-- github-comment-id:207846932 -->
adam commented 2026-10-05 04:05:48 +02:00
Author
Owner
Copy link
Copy source

My wish: Let the user choose if he wants to get PRIVMSG'd or NOTICE'd

I know @incognico's original request is almost six years old, but I ran into the same issue and decided to scratch my itch. I have just submitted PR #1645, which adds a new module hook, and introduces a new user module called "statusnotice". Users can activate this module in order to make *status send NOTICEs instead of PRIVMSGs.

> My wish: Let the user choose if he wants to get PRIVMSG'd or NOTICE'd I know @incognico's original request is almost six years old, but I ran into the same issue and decided to scratch my itch. I have just submitted PR #1645, which adds a new module hook, and introduces a new user module called "statusnotice". Users can activate this module in order to make *status send NOTICEs instead of PRIVMSGs. <!-- github-comment-id:473708719 -->
adam commented 2026-10-05 04:05:49 +02:00
Author
Owner
Copy link
Copy source

I agree with this, the *status constant reconnection, and *perform (because I have a trigger in my client to call perform when a specified nick comes online) can be annoying. It should simply be an option, that avoids the concern of "it may not be shown properly by all clients". People who enable the option will take care of properly configuring their client.

I agree with this, the `*status` constant reconnection, and `*perform` (because I have a trigger in my client to call perform when a specified nick comes online) can be annoying. It should simply be an option, that avoids the concern of "it may not be shown properly by all clients". People who enable the option will take care of properly configuring their client. <!-- github-comment-id:850970129 -->
Sign in to join this conversation.
No Branch/Tag Specified
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/znc#219