View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001865 | unreal | ircd | public | 2004-06-09 07:49 | 2004-06-09 22:18 |
| Reporter | vonitsanet | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | open | ||
| Product Version | 3.2 | ||||
| Summary | 0001865: Delay Before Sending Info. | ||||
| Description | I don't know if this a can be added... Delay 2-3 seconds before sending information (names/topic/modes/Creation time/etc) when a user join on +s channel. This because +s channels usually are in restricted access mode on services and if a delay exists the user who join without access can't see the nickname list on the channel / channel modes / channel topic/Creation time before chanserv kick and ban him because chanserv will kickban him on about 1 second. | ||||
| 3rd party modules | |||||
|
|
Well, such channels are indeed supposed to be "secret"... This is also good for channels that ask ChanServ to MLOCK +k. They SET #Blah MLOCK +sk MyKey, and the last person who leaves the channel sets it restricted and the first person allowed to join will unset that. If a user joins while the channel is empty, they might see the key before ChanServ will kickban him/her (depending on what ChanServ does first). Hm... but then again, that may not necessarily work because the channel wasn't +s when the user joined... but it would work for people who manage to "slide in" during a netsplit (channel is empty on the other side, so he joins it and on net join, he gets de-opped but also gets to see the key). By delaying the information in this case, a channel operator can kick the user (maybe not ban) before the mode synch gets displayed on his client. (Naturally, it would have to work by having the server doing the synch actually withhold the channel modes and names list, or the server receiving this detecting the addition of +s and withhold the information from the client. For the latter method, it would work with the first example as well.) But yeah, this does seem pretty good to keep secret channels secret, because if a person were to be allowed to see the Names list, etc... well it's not really a secret channel anymore :) . |
|
|
Secret has nothing to do with what you want. It has to do with hiding from public view, not from keeping people out. The system you are proposing would be incredibly complex, buggy, and would break just about every IRC client. You are trying to turn +s into +k. If you want +k, then use +k. |
|
|
Ekk, sorry, I got a little overboard with the +k part... But the idea is the keep the channel information hidden from users that aren't supposed to know about it. Normally, hiding it from list/whois/etc is enough, but if a user just does a random /join and stumbles into a secret channel, how do you hide it then? Then again, +i does exist on this earth along with ChanServ INVITE. :) |
|
|
Exactly, other methods of doing this already exist. I'm not going to turn +s into modes that already exist. And as I said, this system would take me weeks to code, and it would break every client that joins the channel. |
|
|
*nod* |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-06-09 07:49 | vonitsanet | New Issue | |
| 2004-06-09 12:23 | aquanight | Note Added: 0006622 | |
| 2004-06-09 12:32 |
|
Note Added: 0006623 | |
| 2004-06-09 12:46 | aquanight | Note Added: 0006624 | |
| 2004-06-09 13:00 |
|
Note Added: 0006625 | |
| 2004-06-09 22:18 | syzop | Status | new => closed |
| 2004-06-09 22:18 | syzop | Note Added: 0006627 |
