NickServ: detect when network supports SASL and suggest loading the SASL module instead #673

New Issue

2026-10-05T04:37:38+02:00

adam commented

2026-10-05 04:37:38 +02:00

It would make the module more useful if it could discover what networks supoort sasl during capability negotiation or performing cap ls (maybe even 3.2 to see what the mechanisms are) and suggest loading the sals lodule instead saying that it identifies you before being visible to the network (so a lot faster than nickserv does).

I think it should be automatic without switch to disable the behaviour except that it could be quiet if sasl was also loaded.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/29727402-nickserv-detect-when-network-supports-sasl-and-suggest-loading-the-sasl-module-instead?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).

It would make the module more useful if it could discover what networks supoort sasl during capability negotiation or performing cap ls (maybe even 3.2 to see what the mechanisms are) and suggest loading the sals lodule instead saying that it identifies you before being visible to the network (so a lot faster than nickserv does). I think it should be automatic without switch to disable the behaviour except that it could be quiet if sasl was also loaded. ## <bountysource-plugin> --- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/29727402-nickserv-detect-when-network-supports-sasl-and-suggest-loading-the-sasl-module-instead?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>

adam commented

2026-10-05 04:37:39 +02:00

I think it should be automatic without switch to disable the behaviour except that it could be quiet if sasl was also loaded.

If I'm interpreting this correctly, automatic *sasl setup when *nickserv password is set would be nice. But how would ZNC guess the SASL username?

Personally I prefer having both modules loaded in a setup so initial connections use SASL, but *nickserv will still identify me in cases where services go down and lose my login status.

> I think it should be automatic without switch to disable the behaviour except that it could be quiet if sasl was also loaded. If I'm interpreting this correctly, automatic `*sasl` setup when `*nickserv` password is set would be nice. But how would ZNC guess the SASL username? Personally I prefer having both modules loaded in a setup so initial connections use SASL, but `*nickserv` will still identify me in cases where services go down and lose my login status.

adam commented

2026-10-05 04:37:40 +02:00

If I'm interpreting this correctly, automatic *sasl setup when *nickserv password is set would be nice. But how would ZNC guess the SASL username?

No, only telling This network supports SASL so you might want to load the SASL module in order to identify before you are visible on the network (as opposed to this module which often identifies you after you are already joined to channels).

Personally I prefer having both modules loaded in a setup so initial connections use SASL, but *nickserv will still identify me in cases where services go down and lose my login status.

This is what I mean with I think it should be automatic without switch to disable the behaviour except that it could be quiet if sasl was also loaded. or in other words, always say that unless SASL is also loaded.

> If I'm interpreting this correctly, automatic *sasl setup when *nickserv password is set would be nice. But how would ZNC guess the SASL username? No, only telling _This network supports SASL so you might want to load the SASL module in order to identify before you are visible on the network (as opposed to this module which often identifies you after you are already joined to channels)._ > Personally I prefer having both modules loaded in a setup so initial connections use SASL, but *nickserv will still identify me in cases where services go down and lose my login status. This is what I mean with _I think it should be automatic without switch to disable the behaviour except that it could be quiet if sasl was also loaded._ or in other words, always say that unless SASL is also loaded.

adam commented

2026-10-05 04:37:40 +02:00

or in other words, always say that unless SASL is also loaded.

Couldn't it just be announced the first time the module (*nickserv) is loaded?

> or in other words, always say that unless SASL is also loaded. Couldn't it just be announced the first time the module (`*nickserv`) is loaded?

adam commented

2026-10-05 04:37:41 +02:00

Couldn't it just be announced the first time the module (*nickserv) is loaded?

No as the user might not be connected to the network at that time and network that doesn't have SASL today could get SASL tomorrow.

> Couldn't it just be announced the first time the module (*nickserv) is loaded? No as the user might not be connected to the network at that time and network that doesn't have SASL today could get SASL tomorrow.

adam commented

2026-10-05 04:37:42 +02:00

Or the first time the SASL cap is received but *sasl isn't loaded... I disagree with having the notice always on, it seems too naggy to me.

Or the _first_ time the SASL cap is received but `*sasl` isn't loaded... I disagree with having the notice always on, it seems too naggy to me.

adam commented

2026-10-05 04:37:42 +02:00

Naggy is the point and there is no reason to nag when sasl is loaded so it can well do it until thatm

Naggy is the point and there is no reason to nag when sasl is loaded so it can well do it until thatm

adam commented

2026-10-05 04:37:43 +02:00

Personally I prefer having both modules loaded in a setup so initial connections use SASL, but *nickserv will still identify me in cases where services go down and lose my login status.

The SASL module could use cap-notify so that it would know when SASL is re-introduced and can re-authenticate over SASL.

> Personally I prefer having both modules loaded in a setup so initial connections use SASL, but *nickserv will still identify me in cases where services go down and lose my login status. The SASL module could use [`cap-notify`](http://ircv3.net/specs/extensions/cap-notify-3.2.html) so that it would know when SASL is re-introduced and can re-authenticate over SASL.

adam commented

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

The SASL module could use cap-notify so that it would know when SASL is re-introduced and can re-authenticate over SASL.

https://github.com/znc/znc/issues/949

> The SASL module could use cap-notify so that it would know when SASL is re-introduced and can re-authenticate over SASL. https://github.com/znc/znc/issues/949

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#673