It might go against the RFC but notices on many clients end up in the status tab or get lost in chat etc. Bottomline is that whoever is messaging the client behind ZNC might never see the autoreply notice.
It was pointed to me by Mikaela that as the RFC states it could lead to an infinite loop of two clients auto replying to each other.
What I propose for that is that when the option is set to autoreply with a msg, autoreply will reply only once every 3 or 5 or X msgs it receives from an individual nick. That should avoid the infinite loops.
So on a nick messaging the client it will send the auto-msg-reply and if it receives another msg from that nick it won't reply until it receives another 2,4, X msgs.
I understand the risk so notice should stay the default way but I think we should be given the choice of using autoreply with a message, in cases we need to make sure whoever is contacting us receives the autoreply.
It might go against the RFC but notices on many clients end up in the status tab or get lost in chat etc. Bottomline is that whoever is messaging the client behind ZNC might never see the autoreply notice.
It was pointed to me by Mikaela that as the RFC states it could lead to an infinite loop of two clients auto replying to each other.
What I propose for that is that when the option is set to autoreply with a msg, autoreply will reply only once every 3 or 5 or X msgs it receives from an individual nick. That should avoid the infinite loops.
So on a nick messaging the client it will send the auto-msg-reply and if it receives another msg from that nick it won't reply until it receives another 2,4, X msgs.
I understand the risk so notice should stay the default way but I think we should be given the choice of using autoreply with a message, in cases we need to make sure whoever is contacting us receives the autoreply.
Cheers
## <bountysource-plugin>
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/26893910-autoreply-option-to-send-the-reply-as-a-message-instead-of-the-rfc-suggested-notice?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github).
</bountysource-plugin>
<!-- github-sync-id:107908756 -->
Reminder of https://github.com/znc/znc/issues/556 / https://github.com/znc/znc/issues/561 that it should be an option instead of forced.
> Why not choose a better client?
:+1:
<!-- github-comment-id:142584202 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
It might go against the RFC but notices on many clients end up in the status tab or get lost in chat etc. Bottomline is that whoever is messaging the client behind ZNC might never see the autoreply notice.
It was pointed to me by Mikaela that as the RFC states it could lead to an infinite loop of two clients auto replying to each other.
What I propose for that is that when the option is set to autoreply with a msg, autoreply will reply only once every 3 or 5 or X msgs it receives from an individual nick. That should avoid the infinite loops.
So on a nick messaging the client it will send the auto-msg-reply and if it receives another msg from that nick it won't reply until it receives another 2,4, X msgs.
I understand the risk so notice should stay the default way but I think we should be given the choice of using autoreply with a message, in cases we need to make sure whoever is contacting us receives the autoreply.
Cheers
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
Why not choose a better client?
Reminder of https://github.com/znc/znc/issues/556 / https://github.com/znc/znc/issues/561 that it should be an option instead of forced.
👍
Because I can't choose which client whoever is messaging me is using?