View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002847 | unreal | ircd | public | 2006-03-05 15:18 | 2006-06-29 18:05 |
| Reporter | tabrisnet | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 3.2.4 | ||||
| Summary | 0002847: SILENCE should send a reply back to user that they are being ignored, a la m_privdeaf | ||||
| Description | Attached is a patch that will do that, and looks like the same coding style as the surrounding code. I admit it creates more network traffic, but it seems like the 'obvious' thing to do. The only trick I can think that might be a good idea is to rate-limit it, but that's not in m_privdeaf either. I have tested this on my testnet, and am now implementing it on my ircnet. | ||||
| Attached Files | silence-notice.diff (567 bytes) silence-notice-2.diff (548 bytes) | ||||
| 3rd party modules | |||||
|
|
Er... why? Clients with builtin /ignore don't tell people they're being ignored. (or at least all the ones I've seen don't) :) |
|
|
Hmm. just thought of something else that might need doing. this should _not_ affect NOTICEs, or should just bail out for that case, to not violate RFC1459 4.4.2 (consider case where user uses silence on a services agent... otoh, most services shouldn't respond to NOTICEs) |
|
|
IGNORE is client-side, and would possibly present a flood-risk. But it seems a good idea to let ppl actually know you're ignoring them so they don't end up just getting frustrated. I'm not _married_ to the idea, but... if m_privdeaf does it, I figure that it would be a good idea for SILENCE too, given they have almost the same effects. |
|
|
The fact that privdeaf, a 3rd party module (though, by me ;p), does something like that does not mean it should be added to a command like SILENCE. Privdeaf basically behaves the same as +R but then for "everyone". While SILENCE is usually used (eh.. always..) to actively ignore someone or a hostmask. Actually, I think it should not notify the user being ignored. I don't see why... client-side ignore doesn't do this either, and personally I wouldn't want to let the other guy know he's on SILENCE ;). Also, presumably, no other IRCd does this either. |
|
|
It may not be entirely the answer you wanted, but I know that ConferenceRoom's +m (equiv of privdeaf/+D in Unreal) does send a message back to the sending user. It does not with SILENCE, but I still think it a good idea. |
|
|
It probably doesn't help, but some ppl (admittedly lame) Query-blocker/ignore scripts _do_ notify the user, if rate-limited. |
|
|
I'm not too worried about it. Personally, I use SILENCE when I just want someone to shut the hell up. I really don't care whether they know or not, my goal is to have them leave me alone. Perhaps I'm the minority, and if that's the case, others should speak up, but to me, I don't really care if the user knows he's silenced. In fact, I'd prefer he doesn't know. Most people I silence are stupid script kiddie type guys. Once he receives the "codemastr has silenced you" message, he's gonna start trying to evade because that's what those morons do. Whereas if he doesn't receive a message, for all he knows I'm receiving everything he says and just choosing not to listen. |
|
|
'Tis why i used the same message as +D. Figured they can't tell the difference. Admittedly, they could get wise. I try to tell my users, "if someone is harassing you in PM, use (custom services command) /ns silence add annoyingperson. If they evade, contact the network staff [channel]. |
|
|
/me jumps in and comments without reading anything anyone has said. This is absolutely a **BAD** idea. Ficticious Probable Situation 1: * GoodGuy connects * BadGuy connects * BadGuy msg GoodGuy: f*** you **** this bla bla etc * GoodGuy SILENCE BadGuy * BadGuy msg GoodGuy: (some more expletives) * Server (insert numeric here) BadGuy: Cannot send - You are being ignored by GoodGuy * BadGuy gets-on-a-proxy/changes-nick/etc * BadGuy continues to harass GoodGuy Yes, we can ban such jerkoffs, but is that really efficient? I say we leave it as is, so BadGuy can spout off all he wants and the target user doesn't have to be bothered any more. |
|
|
ok. fine. make it a configure option. It's not necessarily a bad idea. It has proven useful, at least in my limited testing. It saves me from ppl bugging me in another channel about 'why are you not responding'. This way it's obvious that it's being blocked, even if it's not obvious it's JUST THEM. Sure, anything bad can be done with anything. I could probably take spamfilter and effectively ban ALL users on a network, thus bypassing the GLINE 'too wide' limits. And your whole 'will not read what anyone said', or your misunderstanding of bug 2613, thus leading to your lecturing me on an irrelevant point... it doesn't make me very compelled to consider you credible. I know the patch could use some more work, be made better (has at least one potentially BAD [RFC violating] thing). I'm sure that it could be moved client-side, like all of those lame AWAY systems in scripts like Invision. |
|
|
for ppl who stumble across this and like the idea, be aware of the following issues a) silence-notice-1 does not apply against 3.2.5 cleanly b) silence-notice-1 currently violates RFC1459 4.4.2, as it does not check if(!notice) { } silence-notice-2 should fix these issues. |
|
|
Hardly anyone pays attention to the "NOTICE must never send replies" deal anymore. Look at some of the other errors you get from noticing around. |
|
|
I'll grant that. for example, umode +R (and presumably +D) violate this. However, my concern is one that would not have affected either of these (as U:lines are excepted from +D, and presumably +R). Did you know that SILENCE can block NickServ and friends (is this a bug?)? Now, in particular, services tend to be coded well enough that they don't ever autorespond to NOTICEs. In fact, for the major agents, they should not even respond to NOTICEs ever. However, I don't know that this is universal. And there are few things more potentially dangerous... than a looping services/ircd b/c of a stray error message. |
|
|
I don't like it at all, really. There's also a difference with the 2 examples you mentioned vs silence. With +D you cannot get around it (flooders I mean, ircops/etc can), and +R is usually set in-advance so people aren't spammed and such.. user can simply become registered and talk. There's a huge difference between those GENERAL ignores, and SPECIFICly targetted server-side ignores. Anyway... This is what I did: - Added HOOKTYPE_SILENCED: this is called whenever a message did not get delivered to a user because the user was on the silence list. (src/modules/m_message.c: ctrl+f HOOKTYPE_SILENCED, pgup a bit for more info). So with this, you should still be able to do what you want, without any code changes. And you can decide yourself how you want to do it, etc etc. EDIT: rephrased a bit |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-03-05 15:18 | tabrisnet | New Issue | |
| 2006-03-05 15:18 | tabrisnet | File Added: silence-notice.diff | |
| 2006-03-05 15:22 | aquanight | Note Added: 0011333 | |
| 2006-03-05 15:26 | tabrisnet | Note Added: 0011334 | |
| 2006-03-05 15:28 | tabrisnet | Note Added: 0011336 | |
| 2006-03-05 15:42 | syzop | Note Added: 0011337 | |
| 2006-03-05 23:05 | tabrisnet | Note Added: 0011340 | |
| 2006-03-06 01:34 | tabrisnet | Note Edited: 0011340 | |
| 2006-06-21 19:16 | tabrisnet | Note Added: 0012000 | |
| 2006-06-22 22:18 |
|
Note Added: 0012002 | |
| 2006-06-22 23:11 | tabrisnet | Note Added: 0012003 | |
| 2006-06-25 23:11 | Zell | Note Added: 0012015 | |
| 2006-06-26 00:07 | tabrisnet | Note Added: 0012022 | |
| 2006-06-26 00:12 | tabrisnet | Note Added: 0012023 | |
| 2006-06-26 00:18 | tabrisnet | File Added: silence-notice-2.diff | |
| 2006-06-26 00:19 | tabrisnet | Note Edited: 0012023 | |
| 2006-06-26 00:19 | tabrisnet | Note Edited: 0012023 | |
| 2006-06-26 20:43 | aquanight | Note Added: 0012027 | |
| 2006-06-26 23:25 | tabrisnet | Note Added: 0012028 | |
| 2006-06-27 07:59 | syzop | Note Added: 0012029 | |
| 2006-06-27 08:02 | syzop | Note Edited: 0012029 | |
| 2006-06-29 18:05 | syzop | Status | new => closed |
| 2006-06-29 18:05 | syzop | Resolution | open => no change required |
