Similar to #315. These two capabilities would allow clients to see users' services accounts without having to poll WHO or even WHOIS. This is supported by freenode server-side.
(Bonus points if znc itself enables/disables the capabilities on the server depending on how many attached clients request them, to reduce traffic from the server (useless AWAY and ACCOUNT messages). On the other hand, this would probably make the znc implementation more complex than needed.)
Similar to #315. These two capabilities would allow clients to see users' services accounts without having to poll WHO or even WHOIS. This is supported by freenode server-side.
Both capabilities are usually used together:
- http://ircv3.org/extensions/account-notify-3.1
- http://ircv3.org/extensions/extended-join-3.1
---
(Bonus points if znc itself enables/disables the capabilities on the server depending on how many attached clients request them, to reduce traffic from the server (useless AWAY and ACCOUNT messages). On the other hand, this would probably make the znc implementation more complex than needed.)
##
<bountysource-plugin>
---
The **[$20 bounty](https://www.bountysource.com/issues/141915-add-support-for-account-notify-and-extended-join-capabilities?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>
<!-- github-sync-id:12895007 -->
ZNC should be intelligent enough to only route to the correct client. If a client didn't ask for account-notify, then data shouldn't be forwarded. Same was as how multi-preifx and userhost-in-names are implemented.
ZNC should be intelligent enough to only route to the correct client. If a client didn't ask for account-notify, then data shouldn't be forwarded. Same was as how multi-preifx and userhost-in-names are implemented.
<!-- github-comment-id:16014796 -->
Yes – this is actually required for extended-join. If you're referring to my last paragraph, then I just added that suggestion as a way to reduce traffic between znc and the server, when no cap-using clients are connected.
Yes – this is actually required for `extended-join`. If you're referring to my last paragraph, then I just added that suggestion as a way to reduce traffic between znc and the server, when no cap-using clients are connected.
<!-- github-comment-id:16014867 -->
Is there anything new about this? http://wiki.znc.in/Identifymsg says that identify-msg is depreceated in favour account-notify and extended-join and the code links don't work.
freenode still supports identify-msg and I am able to enable it with send_raw.
Is there anything new about this? http://wiki.znc.in/Identifymsg says that `identify-msg` is depreceated in favour `account-notify` and `extended-join` and the code links don't work.
freenode still supports `identify-msg` and I am able to enable it with send_raw.
<!-- github-comment-id:50333833 -->
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.
Similar to #315. These two capabilities would allow clients to see users' services accounts without having to poll WHO or even WHOIS. This is supported by freenode server-side.
Both capabilities are usually used together:
(Bonus points if znc itself enables/disables the capabilities on the server depending on how many attached clients request them, to reduce traffic from the server (useless AWAY and ACCOUNT messages). On the other hand, this would probably make the znc implementation more complex than needed.)
--- The **[$20 bounty](https://www.bountysource.com/issues/141915-add-support-for-account-notify-and-extended-join-capabilities?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).ZNC should be intelligent enough to only route to the correct client. If a client didn't ask for account-notify, then data shouldn't be forwarded. Same was as how multi-preifx and userhost-in-names are implemented.
Yes – this is actually required for
extended-join. If you're referring to my last paragraph, then I just added that suggestion as a way to reduce traffic between znc and the server, when no cap-using clients are connected.Is there anything new about this? http://wiki.znc.in/Identifymsg says that
identify-msgis depreceated in favouraccount-notifyandextended-joinand the code links don't work.freenode still supports
identify-msgand I am able to enable it with send_raw.WeeChat has open pull request about extended-join. https://github.com/weechat/weechat/pull/212
And today WeeChat added account-notify https://github.com/weechat/weechat/commit/c10787d92fbb6419b8e2940daec1069b711306d4.