Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for cap-notify #182

Closed
Mikaela opened this Issue Aug 30, 2014 · 13 comments

Comments

Projects
None yet
4 participants
@Mikaela
Copy link
Contributor

Mikaela commented Aug 30, 2014

The cap-notify client capability allows a client to be notified when the client capability offering (i.e. capabilities listed in CAP LS) on a server changes.

When enabled, the server MUST notify clients about all new capabilities and about existing capabilities that are no longer available via the messages specified in this document.

If I have understood correctly, cap-notify must be supported by IRCd and client before ZNC can add support for capabilities like account-notify, away-notify account-tag etc.

@Shawn-Smith

This comment has been minimized.

Copy link
Contributor

Shawn-Smith commented Aug 31, 2014

If I have understood correctly, cap-notify must be supported by IRCd and client before ZNC can add support for capabilities like account-notify, away-notify account-tag etc.

I see no reason why cap-notify is needed to add support for the others, they are completely unrelated.

@Mikaela

This comment has been minimized.

Copy link
Contributor Author

Mikaela commented Aug 31, 2014

@Shawn-Smith because ZNC cannot claim that all networks support the others, because if it does that, clients that think that those are supported break. ZNC cannot check what capabilities are available and tell them to client, because the client might have connected to ZNC before the capability negotiation. Cap-notify is required for ZNC so it can tell what capabilities really are supported by the server even if the client is already connected.

At least this is what I understood.

@Mikaela

This comment has been minimized.

Copy link
Contributor Author

Mikaela commented Aug 31, 2014

Logs from #znc, if someone minds about this, please tell me and I will remove this comment.

2014-08-30 21:14:31+0300 < MrC> Also, the many clients out there that don't support away-notify.
2014-08-30 21:16:22+0300 < Mikaela> HexChat and WeeChat support it, I don't know about others, but for me issue with away-notify is that ZNC doesn't support it, so WeeChat cannot use it.              
2014-08-30 21:18:38+0300 < Zarthus> I just wish simple_away were the solution most people used over awaynick
2014-08-30 21:19:10+0300 < MrC> It doesn't? Interesting. I suspect implementing support for away-notify it may help quicken the demise of *awaynick .   
2014-08-30 21:19:28+0300 < Zarthus> By making it external people will have to manually add it - which I think is a fine idea.                           
2014-08-30 21:20:19+0300 < Mikaela> MrC: https://github.com/znc/znc/issues/315
2014-08-30 21:20:20+0300 < ZNC-Linker> https://github.com/znc/znc/issues/315 “Add support for 'away-notify' at capability negotiation time [$20]” (open)
2014-08-30 21:20:58+0300 < Mikaela> Related? https://github.com/znc/znc/issues/316
2014-08-30 21:20:59+0300 < ZNC-Linker> https://github.com/znc/znc/issues/316 “Add support for 'account-notify' and 'extended-join' capabilities [$10]” (open)
2014-08-30 21:21:42+0300 < MrC> I think that's a bit different, though yes those would also be good features to have.                                   
2014-08-30 21:22:40+0300 < Mikaela> I would like away-notify and account-notify and extended-join could be helpful.
2014-08-30 21:22:51+0300 < Cajs> Ooh interesting conversation.. 
2014-08-30 21:23:08+0300 < Mikaela> Limnoria can use account-notify and extended-join for identifying.
2014-08-30 21:28:40+0300 < MrC> Hm... should ZNC itself be able to do (ideally implemented as a network-level module if it's possible) /who polling and provide away-notify that way? On some IRCds, account-notify could be provided the same way.
2014-08-30 21:29:03+0300 < MrC> Wait a minute....
2014-08-30 21:29:18+0300 --> BtbN (btbn@btbn.de) has joined #znc
2014-08-30 21:30:02+0300 < MrC> What IRCds support WHOX but not account-notify ?
2014-08-30 21:31:20+0300 < Zarthus> What is account-notify?
2014-08-30 21:32:13+0300 < Zarthus> [[account-notify]]
2014-08-30 21:32:13+0300 < ZNC-Linker> http://wiki.znc.in/account-notify
2014-08-30 21:32:17+0300 < Mikaela> Why not user level?
2014-08-30 21:32:27+0300 < BtbN> That's extremely strange. The moment i start ZNC with my module, or even just copy it into the modules dir while znc is running, it imediately stops responding to connections. It's still running and listening though. It just closes any connection it gets imediately oO                     
2014-08-30 21:32:27+0300 < Mikaela> Zarthus: http://ircv3.org/extensions/account-notify-3.1                                                             
2014-08-30 21:32:46+0300 < Zarthus> that page is not loading for me.
2014-08-30 21:32:48+0300 < MrC> Zarthus: Basically if someone changes NickServ account name for whatever reason.                                        
2014-08-30 21:32:50+0300 < BtbN> That doesn't happen on my local test znc. Only on the "live" one                                                       
2014-08-30 21:32:53+0300 < Mikaela> Oh, but their DNS is still down.
2014-08-30 21:33:02+0300 < MrC> http://ircv3.atheme.org/extensions/account-notify-3.1
2014-08-30 21:33:24+0300 < Mikaela> https://github.com/ircv3/ircv3-specifications/blob/master/extensions/account-notify-3.1 
2014-08-30 21:33:35+0300 < MrC> Or that too.
2014-08-30 21:33:49+0300 < Zarthus> I see
2014-08-30 21:34:09+0300 < MrC> "<Mikaela> Why not user level?" You might not want /who polling to take place on certain, or even most networks.
2014-08-30 21:34:29+0300 < MrC> If the IRCd supports the functions natively, why emulate it?
2014-08-30 21:34:42+0300 < Mikaela> MrC: My WeeChat is doing that, because of missing account-notify support in ZNC. On all networks.
2014-08-30 21:34:44+0300 < Mikaela> 1 windows used (0 vertically / 0 horizontally split). 115 (of which 9 merged) buffers open: 1 core, 1 perl, 10 irc servers, 12 irc queries, 91 irc channels
2014-08-30 21:35:52+0300 < Mikaela> I think there was some reason for not doing it yet, but I cannot find it.
2014-08-30 21:36:36+0300 < Mikaela> MrC: https://github.com/ircv3/ircv3-specifications/blob/master/extensions/cap-notify-3.2.md
2014-08-30 21:37:01+0300 < Mikaela> If I understood correctly, that must be supported first, before ZNC can add caps like those.
2014-08-30 21:38:15+0300 < MrC> WeeChat (or any other client) has to because it can't yet utilize away-notify. If ZNC would be able to "pass-through" the away-notify and account-notify messages, it of course would no longer *need* to use /who polling on all nets.
2014-08-30 21:39:59+0300 < MrC> The cap-notify thing is a little different, but probably a good idea at some point. It's to cover the unusual situation where an IRCd may gain additional caps sometime after connection.
2014-08-30 21:40:49+0300 < MrC> At present, caps are determined during connection.
2014-08-30 21:59:37+0300 < grawity> MrC: cap-notify might be required in order to 'pass-through' the other two
2014-08-30 21:59:59+0300 < grawity> MrC: because clients normally only CAP LS before znc even knows which network the client's connecting to
2014-08-30 22:00:25+0300 < MrC> Damn... that's right.
2014-08-30 22:00:29+0300 < grawity> MrC: so, if znc offers away-notify unconditionally, it'll break clients which activate it & attach to a network that doesn't actually support away-notify
2014-08-30 22:00:45+0300 < grawity> so the client will turn off its polling while expecting notifications for a nonexistent cap
2014-08-30 22:01:47+0300  * grawity should take a look at ircv3.2 sometime
2014-08-30 22:05:13+0300 < MrC> Are there any clients out there that support cap-notify, or IRCds for that matter? Though I don't suppose the IRCd would need to support it for this application.
2014-08-30 22:05:34+0300 < MrC> Then again, for that reason probably no client supports it either.
2014-08-30 22:06:04+0300 < Mikaela> There is issue for WeeChat (which was opened by me half hour ago, because I noticed there wasn't an issue about it before).
2014-08-30 22:12:03+0300 < grawity> MrC: cap-notify isn't finished yet, AFAIK
2014-08-30 22:12:29+0300 < MrC> No?
2014-08-30 22:13:20+0300 < MrC> It looks like it might work as is, unless I'm missing something (which is quite possible).
2014-08-30 22:14:01+0300 < grawity> oh, right, it's already in the repo
2014-08-30 22:14:02+0300 < MrC> Though, not really sure what "sticky capabilities" means.
2014-08-30 22:14:20+0300 < grawity> coming from the original CAP spec, 'sticky' capabilities are ones that cannot be disabled by the client
@maxteufel

This comment has been minimized.

Copy link
Contributor

maxteufel commented Aug 31, 2014

I don't like the reason that ZNC needs it (ZNC could just KILL the client on every (re)connect to tell it about the capabilities), but I like the idea of adding that capability to WeeChat.

@Mikaela

This comment has been minimized.

Copy link
Contributor Author

Mikaela commented Aug 31, 2014

ZNC could just KILL the client on every (re)connect to tell it about the capabilities

Lets imagine that the user hasn't done anything recently, but it connected and has long buffer playbacks and ZNC gets disconnected from the network and it KILLs the client and the client reconnects and starts receiving massive playback and fails to ping in time and timeouts and moves back to receiving the same buffer…

I am not sure how likely this case is, but my HexChat always crashes when I connect it to my primary ZNC's freenode.

@maxteufel

This comment has been minimized.

Copy link
Contributor

maxteufel commented Feb 7, 2015

Temporary solution as a script (not tested with a real IRCd/bouncer due to lack of support): https://raw.githubusercontent.com/maxteufel/code/master/irc/weechat/cap-notify.py

@Mikaela

This comment has been minimized.

Copy link
Contributor Author

Mikaela commented Mar 11, 2015

Cap-notify is becoming more important now as it's required by SASL3.2 which introduces SASL REAUTH.

IRCv3.2 is expected to be released at end of this month.

@Mikaela

This comment has been minimized.

Copy link
Contributor Author

Mikaela commented Apr 29, 2015

ZNC has PR on cap-notify now znc/znc#957.

@Mikaela

This comment has been minimized.

Copy link
Contributor Author

Mikaela commented Jul 12, 2015

And ZNC has merged znc/znc#957 so for WeeChat to be able to use away-notify and similar capabilities, WeeChat must add support for cap-notify

cap-notify is also required for SASL 3.2 (REAUTH) #413 which would also be important.

@Mikaela

This comment has been minimized.

Copy link
Contributor Author

Mikaela commented Aug 6, 2015

Extended-join znc/znc@6246899 and account-notify znc/znc@d070a6e are in ZNC master now and also require cap-notify in order to be enabled.

@maxteufel

This comment has been minimized.

Copy link
Contributor

maxteufel commented Aug 6, 2015

https://github.com/maxteufel/weechat/tree/feature/cap-notify should work, but I'd like some feedback before I open a pull request. Doesn't support SASL Reauth.

@flashcode

This comment has been minimized.

Copy link
Member

flashcode commented Aug 8, 2015

Pull request: #477

@Mikaela

This comment has been minimized.

Copy link
Contributor Author

Mikaela commented Oct 19, 2015

It looks like #477 was finally merged.

Thanks @flashcode 😄

@Mikaela Mikaela closed this Oct 19, 2015

@flashcode flashcode added this to the 1.4 milestone Jan 7, 2016

@flashcode flashcode self-assigned this Jan 7, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.