[meta] Require registration for talking (+q $~a) #612

New Issue

2026-10-05T04:33:07+02:00

adam commented

2026-10-05 04:33:07 +02:00

Alternative to https://github.com/znc/znc/issues/1076.

Allow anyone to join the channel, but require registration for sending messages.

I am aware of the arguments against +r, but other channels have moved to +q $~a with less spam and it's not so discriminating. Even if someone did come to freenode just for ZNC support, registering would be one command and copy-pasting another from email.

Freenode also almost never clears their services database, it seems that currently it has been done once in two years.

Alternative to https://github.com/znc/znc/issues/1076. Allow anyone to join the channel, but require registration for sending messages. Suggestion for topic. `www.znc.in | ZNC 1.6.1: http://wiki.znc.in/ChangeLog/1.6.1 | http://znc.in/nightly | https://github.com/znc/znc | Development at #znc-dev | Debian stable: 1.4 is 1.5 year old | 1.2 is 2 years old | 1.0 is 3 years old | Debian oldstable: 0.206 is 3.5 years old | don't randomly PM people | Cannot talk? https://freenode.net/faq.shtml#userregistration Automatic identifying https://wiki.znc.in/Sasl` I am aware of the arguments against +r, but other channels have moved to +q $~a with less spam and it's not so discriminating. Even if someone did come to freenode just for ZNC support, registering would be one command and copy-pasting another from email. Freenode also almost never clears their services database, it seems that currently it has been done once in two years.

adam closed this issue

2026-10-05 04:33:07 +02:00

adam commented

2026-10-05 04:33:08 +02:00

Travis? /cs flags #znc *!*@ec2-54-144-38-75.compute-1.amazonaws.com +V
Notifico (https://github.com/znc/znc/issues/1088)? /cs flags #znc *!*@198.199.82.216 +V

- Travis? `/cs flags #znc *!*@ec2-54-144-38-75.compute-1.amazonaws.com +V` - Notifico (https://github.com/znc/znc/issues/1088)? `/cs flags #znc *!*@198.199.82.216 +V`

adam commented

2026-10-05 04:33:08 +02:00

My comments still apply

https://github.com/znc/znc/issues/1076#issuecomment-139749504
https://github.com/znc/znc/issues/1076#issuecomment-142225645

My comments still apply https://github.com/znc/znc/issues/1076#issuecomment-139749504 https://github.com/znc/znc/issues/1076#issuecomment-142225645

adam commented

2026-10-05 04:33:09 +02:00

There's a lot of spam? It honestly hasn't bothered me.

It has bothered me and the users who have always after nick floodings asked why they were pinged etc. That also bothers me and without the spammers there wouldn't be those people.

I don't think these precautions are necessary, and if anything I'd rather see +q $~a than +r.

I believe they are or I wouldn't be opening these issues. I have also moved to +q $~a now, +r was #1076.

I don't really mind the topic. People already rarely read topics, let alone click on links in topics.

Not our problem, they either don't talk or go to #freenode to ask and they will be pointed to /topic #znc or https://freenode.net/faq.shtml#userregistration

botnets are only temporary, setting +r at the time of the event hasn't harmed anyone.

Unregistered trolls are also temporary, but hurting they case takes longer time to go away. I wish ZNC would be free of them in addition.

I also think that most of the banlist is unregistered and we could safely clear it if we agreed on +q $~a.

> There's a lot of spam? It honestly hasn't bothered me. It has bothered me and the users who have always after nick floodings asked why they were pinged etc. That also bothers me and without the spammers there wouldn't be those people. > I don't think these precautions are necessary, and if anything I'd rather see +q $~a than +r. I believe they are or I wouldn't be opening these issues. I have also moved to +q $~a now, +r was #1076. > I don't really mind the topic. People already rarely read topics, let alone click on links in topics. Not our problem, they either don't talk or go to #freenode to ask and they will be pointed to `/topic #znc` or https://freenode.net/faq.shtml#userregistration > botnets are only temporary, setting +r at the time of the event hasn't harmed anyone. Unregistered trolls are also temporary, but hurting they case takes longer time to go away. I wish ZNC would be free of them in addition. --- I also think that most of the banlist is unregistered and we could safely clear it if we agreed on `+q $~a`.

adam commented

2026-10-05 04:33:10 +02:00

... after nick floodings ...
I have not seen a nick flooder in #znc before. I think you can ask to get Sigyn in your channel (the freenode kill bot) to kill this abuse as well.

Not our problem
It is your problem, it defines how welcoming the channel is.

For a channel which provides mostly support to others, and no offense to the userbase, but they aren't super intelligent in some cases (as shown by the need for znc-linker and the use of !q), I think quieting unregistered users is crippling a large part of the userbase. Where botnets take an hour or so, and +q would not gain you anything to prevent the join flood. It would need an attentive channel op to enable +r temporarily.

... most of the banlist is unregistered ...
You could clear the ban list at any time, most of the bans are very old and a lot of them probably stopped visiting. Those who won't can be rebanned just as easily.

My primary issue is that a lot of these support inquiries come from people who may not use freenode actively and just want help installing or using the software. They are not interested in going through the registration process at all.

I've seen some neat workarounds for this, for example #git has a bot that can voice you to still allow you to talk, but seeing as your intention is to prevent abuse, this will just add another gate to be abused in the first place.

If botnets are the problem, (and I can't find any source aside from highlight flooding that's not the primary issue), perhaps setting a more accurate +j or having a third party bot detect botnets will be more beneficial.

For a support channel having to go through several hoops just to ask a question, where, from experience, people will have trouble finding out why they can't talk - is overall unpleasant for the people wanting support. And from my observations znc gets a lot more legitimate users than trolls, which is confirmed by the notices generated by AntiSpamMeta.

Don't get me wrong, it's true that these restrictive channel modes solve a lot of abuse - but the question is: What purpose will #znc serve when it also actively blocks users from asking questions and getting support in the first place?

> ... after nick floodings ... > I have not seen a nick flooder in `#znc` before. I think you can ask to get Sigyn in your channel (the freenode kill bot) to kill this abuse as well. > > Not our problem > It is your problem, it defines how welcoming the channel is. For a channel which provides mostly support to others, and no offense to the userbase, but they aren't super intelligent in some cases (as shown by the need for znc-linker and the use of `!q`), I think quieting unregistered users is crippling a large part of the userbase. Where botnets take an hour or so, and +q would not gain you anything to prevent the join flood. It would need an attentive channel op to enable +r temporarily. > ... most of the banlist is unregistered ... > You could clear the ban list at any time, most of the bans are very old and a lot of them probably stopped visiting. Those who won't can be rebanned just as easily. --- My primary issue is that a lot of these support inquiries come from people who may not use freenode actively and just want help installing or using the software. They are not interested in going through the registration process at all. I've seen some neat workarounds for this, for example `#git` has a bot that can voice you to still allow you to talk, but seeing as your intention is to prevent abuse, this will just add another gate to be abused in the first place. If botnets are the problem, (and I can't find any source aside from highlight flooding that's not the primary issue), perhaps setting a more accurate `+j` or having a third party bot detect botnets will be more beneficial. For a support channel having to go through several hoops just to ask a question, where, from experience, people will have trouble finding out why they can't talk - is overall unpleasant for the people wanting support. And from my observations znc gets a lot more legitimate users than trolls, which is confirmed by the notices generated by AntiSpamMeta. Don't get me wrong, it's true that these restrictive channel modes solve a lot of abuse - but the question is: What purpose will #znc serve when it also actively blocks users from asking questions and getting support in the first place?

adam commented

2026-10-05 04:33:10 +02:00

For a channel which provides mostly support to others, and no offense to the userbase, but they aren't super intelligent in some cases (as shown by the need for znc-linker and the use of !q), I think quieting unregistered users is crippling a large part of the userbase. Where botnets take an hour or so, and +q would not gain you anything to prevent the join flood. It would need an attentive channel op to enable +r temporarily.

This applies to many channels other than only #znc. Join flood is less problem than nick flooding and we already have join throtthling.

My primary issue is that a lot of these support inquiries come from people who may not use freenode actively and just want help installing or using the software. They are not interested in going through the registration process at all.

The registration progress isn't that difficult and it would protect the channel. If they wanted further help, they would already be registered next time.

I've seen some neat workarounds for this, for example #git has a bot that can voice you to still allow you to talk, but seeing as your intention is to prevent abuse, this will just add another gate to be abused in the first place.

We don't need workarounds, it's not like freenode asked police granted proofs of identities for registration.

If botnets are the problem, (and I can't find any source aside from highlight flooding that's not the primary issue), perhaps setting a more accurate +j or having a third party bot detect botnets will be more beneficial.

There are manual spammers too who don't identify to services and it would effectively prevent anonymous trolling too. If the current +j isn't accurate enough, you are free to suggest more accurate one.

For a support channel having to go through several hoops just to ask a question, where, from experience, people will have trouble finding out why they can't talk - is overall unpleasant for the people wanting support. And from my observations znc gets a lot more legitimate users than trolls, which is confirmed by the notices generated by AntiSpamMeta.

Most of networks have some kind of registration and #znc requiring it would just help those people with the other networks too.

Don't get me wrong, it's true that these restrictive channel modes solve a lot of abuse - but the question is: What purpose will #znc serve when it also actively blocks users from asking questions and getting support in the first place?

Requiring registration doesn't prevent anyone from asking questions after they have registered and the next time they would ask something, they were already registered.

> For a channel which provides mostly support to others, and no offense to the userbase, but they aren't super intelligent in some cases (as shown by the need for znc-linker and the use of !q), I think quieting unregistered users is crippling a large part of the userbase. Where botnets take an hour or so, and +q would not gain you anything to prevent the join flood. It would need an attentive channel op to enable +r temporarily. This applies to many channels other than only #znc. Join flood is less problem than nick flooding and we already have join throtthling. > My primary issue is that a lot of these support inquiries come from people who may not use freenode actively and just want help installing or using the software. They are not interested in going through the registration process at all. The registration progress isn't that difficult and it would protect the channel. If they wanted further help, they would already be registered next time. > I've seen some neat workarounds for this, for example #git has a bot that can voice you to still allow you to talk, but seeing as your intention is to prevent abuse, this will just add another gate to be abused in the first place. We don't need workarounds, it's not like freenode asked police granted proofs of identities for registration. > If botnets are the problem, (and I can't find any source aside from highlight flooding that's not the primary issue), perhaps setting a more accurate +j or having a third party bot detect botnets will be more beneficial. There are manual spammers too who don't identify to services and it would effectively prevent anonymous trolling too. If the current +j isn't accurate enough, you are free to suggest more accurate one. > For a support channel having to go through several hoops just to ask a question, where, from experience, people will have trouble finding out why they can't talk - is overall unpleasant for the people wanting support. And from my observations znc gets a lot more legitimate users than trolls, which is confirmed by the notices generated by AntiSpamMeta. Most of networks have some kind of registration and #znc requiring it would just help those people with the other networks too. > Don't get me wrong, it's true that these restrictive channel modes solve a lot of abuse - but the question is: What purpose will #znc serve when it also actively blocks users from asking questions and getting support in the first place? Requiring registration doesn't prevent anyone from asking questions after they have registered and the next time they would ask something, they were already registered.

adam commented

2026-10-05 04:33:11 +02:00

I now wrote quick page explaining how to register and it seems to be far from impossible.

http://wiki.znc.in/User:Mkaysi/register

Feel free to move it to more appropiate location if we agree on +q $~a.

I now wrote quick page explaining how to register and it seems to be far from impossible. - http://wiki.znc.in/User:Mkaysi/register Feel free to move it to more appropiate location if we agree on +q $~a.

adam commented

2026-10-05 04:33:12 +02:00

I will regret typing this, but what I don't regret anyway

I don't know if you had any idea on what happened on the channel last night, but there was personal attack against me and no good words or actions or anything. It seems to me that whole ZNC agrees with

nobody gives a damn that you are a tranny. Stop fucking correcting people you god damn suicidal abomination of some human. not a guy and that damned penis you have makes you some girl‽ you are indisputably the most obnoxious tranny on this network.

and that I am entirely useless for ZNC and don't ever do anything useful and don't deserve to be treated as a person and don't deserve to have safety in #znc about it being only about ZNC.

The only way it was acknowledged was /cs quiet being converted as ban and #znc-dev discussion on how the ban was entirely useless (and it took hours to explain that the ban should have been set for host instead of nick, but that was again done by ChanServ and not me). The reason I use ChanServ/quiet is https://github.com/communi/communi-sailfish/issues/121 and https://github.com/communi/communi-sailfish/issues/122 which make alias for chanserv quiet #znc %1+% the best way for quickly taking actions on my phone.

Then there was you saying how it would have been better to not do anything and show the world that ZNC doesn't respect gender, romantic, sexual, neurological (or any other) minorities as people.

_I will regret typing this, but what I don't regret anyway_ I don't know if you had any idea on what happened on the channel last night, but there was personal attack against me and no good words or actions or anything. It seems to me that whole ZNC agrees with > nobody gives a damn that you are a tranny. Stop fucking correcting people you god damn suicidal abomination of some human. `not a guy` and that damned penis you have makes you some girl‽ you are indisputably the most obnoxious tranny on this network. and that I am entirely useless for ZNC and don't ever do anything useful and don't deserve to be treated as a person and don't deserve to have safety in #znc about it being only about ZNC. The only way it was acknowledged was `/cs quiet` being converted as ban and #znc-dev discussion on how the ban was entirely useless (and it took hours to explain that the ban should have been set for host instead of nick, but that was again done by ChanServ and not me). The reason I use ChanServ/quiet is https://github.com/communi/communi-sailfish/issues/121 and https://github.com/communi/communi-sailfish/issues/122 which make alias for `chanserv quiet #znc %1+%` the best way for quickly taking actions on my phone. Then there was you saying how it would have been better to not do anything and show the world that **ZNC doesn't respect gender, romantic, sexual, neurological (or any other) minorities as people**.

adam commented

2026-10-05 04:33:12 +02:00

You misinterpret my statement. I stated that a nickname ban achieves nothing but that the harasser starts being more varied and harder to detect in their harassment. It's more productive to /ignore a name than to ban it if this is the best solution that can be thought of..

Based on the weak ban being set, I determined that having no ban would be better than having one. If it was possible to capture a more accurate banmask (which seems to not be the case with you due to sailfish being apparently poor software for IRC moderation in its current state, and that retrieving a banmask and applying it from a mobiel device is difficult to do.) This has nothing to do with the respect or disrespect of anything, it's just that nickname bans are ineffective and if that is the best solution you could find to ban someone - then perhaps a ban is not the solution at all.

Saying some entity or a group does not respect people is ridiculous. This has nothing to do with what you are or what you are not. At the time you raised the discussion in #znc-dev and I responded with my opinion on what would have been better if you want to keep them out. You could have been the president of the United States or a homeless cripple - my response would not have been changed by that.

This will be my last comment on this issue. If you truly think what you say, then I do not believe anything I will or will not say will persuade you to think otherwise. I've been honest with you within all conversations we've had up to this point. If you're still adamant my intentions are impure, then I have no interest in talking to a wall.

You misinterpret my statement. I stated that a nickname ban achieves nothing but that the harasser starts being more varied and harder to detect in their harassment. It's more productive to /ignore a name than to ban it if this is the best solution that can be thought of.. Based on the weak ban being set, I determined that having no ban would be better than having one. If it was possible to capture a more accurate banmask (which seems to not be the case with you due to sailfish being apparently poor software for IRC moderation in its current state, and that retrieving a banmask and applying it from a mobiel device is difficult to do.) This has nothing to do with the respect or disrespect of anything, it's just that nickname bans are ineffective and if that is the best solution you could find to ban someone - then perhaps a ban is not the solution at all. Saying some entity or a group does not respect people is ridiculous. This has nothing to do with what you are or what you are not. At the time you raised the discussion in #znc-dev and I responded with my opinion on what would have been better if you want to keep them out. You could have been the president of the United States or a homeless cripple - my response would not have been changed by that. This will be my last comment on this issue. If you truly think what you say, then I do not believe anything I will or will not say will persuade you to think otherwise. I've been honest with you within all conversations we've had up to this point. If you're still adamant my intentions are impure, then I have no interest in talking to a wall.

adam commented

2026-10-05 04:33:13 +02:00

Neither +r nor +q $~a would help against such targeted attacks. It wasn't even a botnet. Even +j won't help.
Ban is fine, but by hostname, not by nick. Yes, I know that your IRC client is too bad for that.
Just ban is enough, public comments about how upset you are will make it even worse. If person shows that he/she is vulnerable to such attacks, the attacker will see it, and will do it even more. Remember, the attacker wants you to be sad, if he attacks you like that. If he sees that he successfully made you sad, you can guess what will follow. So: just ban, and that's it.

Stupid people are stupid. It's better to ignore them than to become sad. "Dear Mikaela, what this yet another stupid person said, is not true" every time such people say that, won't help.

1. Neither `+r` nor `+q $~a` would help against such targeted attacks. It wasn't even a botnet. Even `+j` won't help. 2. Ban is fine, but by hostname, not by nick. Yes, I know that your IRC client is too bad for that. 3. Just ban is enough, public comments about how upset you are will make it even worse. If person shows that he/she is vulnerable to such attacks, the attacker will see it, and will do it even more. Remember, the attacker wants you to be sad, if he attacks you like that. If he sees that he successfully made you sad, you can guess what will follow. So: just ban, and that's it. Stupid people are stupid. It's better to ignore them than to become sad. "Dear Mikaela, what this yet another stupid person said, is not true" every time such people say that, won't help.

adam commented

2026-10-05 04:33:14 +02:00

PS. By "ignore" I don't say /ignore. As I said, ban is fine. But just don't show them that you're upset. I think it's the best strategy.

PS. By "ignore" I don't say `/ignore`. As I said, ban is fine. But just don't show them that you're upset. I think it's the best strategy.

adam commented

2026-10-05 04:33:14 +02:00

Neither +r nor +q $~a would help against such targeted attacks. It wasn't even a botnet. Even +j won't help.

The user wasn't identified to services so it would help or at least make more permanent identity bannable.

Ban is fine, but by hostname, not by nick. Yes, I know that your IRC client is too bad for that.

I cannot affect what @Atheme does when it decides to do nick bans after user has left.

Just ban is enough, public comments about how upset you are will make it even worse. If person shows that he/she is vulnerable to such attacks, the attacker will see it, and will do it even more. Remember, the attacker wants you to be sad, if he attacks you like that. If he sees that he successfully made you sad, you can guess what will follow. So: just ban, and that's it.

More reasons for suicide.

Stupid people are stupid. It's better to ignore them than to become sad. "Dear Mikaela, what this yet another stupid person said, is not true" every time such people say that, won't help.

I already answered that in my previous comment. I get the picture of ZNC project entirely agreeing with what they said and as the result what I opened in the previous comment.

> Neither +r nor +q $~a would help against such targeted attacks. It wasn't even a botnet. Even +j won't help. The user wasn't identified to services so it would help or at least make more permanent identity bannable. > Ban is fine, but by hostname, not by nick. Yes, I know that your IRC client is too bad for that. I cannot affect what @Atheme does when it decides to do nick bans after user has left. > Just ban is enough, public comments about how upset you are will make it even worse. If person shows that he/she is vulnerable to such attacks, the attacker will see it, and will do it even more. Remember, the attacker wants you to be sad, if he attacks you like that. If he sees that he successfully made you sad, you can guess what will follow. So: just ban, and that's it. More reasons for suicide. > Stupid people are stupid. It's better to ignore them than to become sad. "Dear Mikaela, what this yet another stupid person said, is not true" every time such people say that, won't help. I already answered that in my previous comment. I get the picture of ZNC project entirely agreeing with what they said and as the result what I opened in the previous comment.

adam commented

2026-10-05 04:33:15 +02:00

Apparently not going to happen and can be closed until the next time unless project collabator closes it.

Apparently not going to happen and can be closed until the next time unless project collabator closes it.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#612