View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000039 | unreal | ircd | public | 2002-01-14 00:00 | 2003-11-03 01:18 |
| Reporter | matrixnet2020 | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | open | ||
| Platform | X86 | OS | Linux | OS Version | 2.4.8 |
| Product Version | 3.2-beta6 | ||||
| Summary | 0000039: Hide channel ops | ||||
| Description | There is a new mode with EFNet's hybrid ircd (+a) that hides channel operators and makes them appear as normal users. Example: #Testnet modes +nta Users: Mike Mitch Julie Mike sees: @Mike @Mitch Julie Mitch sees: @Mike @Mitch Julie Julie sees: Mike Mitch Julie When Julie is opped: Mike sets mode +o Julie SERVER +oo Mike Mitch (From Julie's perspective) | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
CHmode /mode #ch +a NOT usermode |
|
|
Well if such a thing were implimented, we'd obviously have to choose a different channel mode, since unreal already uses +a. |
|
|
Chan mode doesnt matter.. just a great feature to accompany +u (auditorium) |
|
|
IMO this would be a nice feature. It should also completely apparently flatten channel flags, i.e. newly joined clients should see neither ops, nor halfops, nor voices. Probably voices should be shown in case the channel is +m. |
|
|
I would like to implement this, however there are some questions: - Should voice be hidden too? - If I get ops I will see the server op/voice/halfop everyone so I get a synced list, however what will happen if I get halfop, or even voice? a) Only ops can see all the status b) Only halfops/ops can see all the status c) All three can see the status of everyone d) Halfoped users can see other halfops/voiced users, voiced users see nothing special e) Voiced users see other users with voice, halfop users see other users with halfop/voice (BTW I didnt look at hybrid ircd) I like e, but... what's the best? :) |
|
|
In my personal opinion: (I use the term "unflagged" to refer to a -ohv user) - unflagged user on -m chan sees all users as unflagged - unflagged user on +m chan sees +ohv users as +v - +v user (no matter whether +m or -m) sees +ohv users as +v - +h user (no matter whether +m or -m) sees +oh users as +h and +v users as +v - +o user (no matter whether +m or -m) sees +o users as +o, +h users as +h and +v users as +v We just don't care about +q and +a, since those are "protect" modes (they don't even show up in /names, indeed). Anyway, even unflagged users will be able to see when someone kicks someone, but they wouldn't know whether the kicker is an op or an halfop. The problem, however, would be the need to send out a /names-like list each time a "flagging chanmode" (+o, +h, +v, -o, -h, -v) is toggled, which could possibly lead to some kind of flood. Am I crazy? :) |
|
|
Thanks for your input :) I think the purpose of this mode was to make it a bit harder for takeover ppl since we are 'hiding' information about 'important' ppl. Feel free to tell me about other purposes :). It could be pretty usefull on a big channel I think... Some comments: - If you show the (half)op name in a kick/topic/whatever a user will be able to build an channel-ops list ("ah he kicked someone, *add to (half)op list*"). - When is a user given voice? Possibly not because he/she is "trusted", if a user with voice would be able to distinct between normal users and users with "more status" then +v has a bit too much rights I think. - I don't think when +m is set the normal users should see all +hov's as +v, because of the same reason. When is +m set? Mostly in case of flooding/TO's and then you are giving them out this info.. mm.. - About flagged users seeing other same-flagged-user-status (+v seeing +v's/etc) I think we all agree... - halfops: (after thinking a while :P) I agree halfops should see ops/halfops as halfops because otherwise a halfop will see "anonymous kicks/modes" from the real ops which are confusing for her/him. in short: - +v sees +v, but +ho are normal users - +h sees +h, and +o as +h users - +o sees everything - only +h/+o see the real user who did the topic/kick/mode/etc, others see the server doing it. affected: [invite,] mode, kick, topic (more?) invite: this is a bit dangerous to make "anonymous" (in case of +i/whatever) because of mass inviting... I think it should just show the nickname since you shouldn't invite "a bad person" in such a case.. (so invite=no change). |
|
|
I have noticed that +h/+o can speak on a +m channel without the need of an explicit +v. That is why i was suggesting that +v users should see +h/+o as +v: it'd be misleading, to see people who talk without any voice. I mean, we should either have anyone who can talk (i.e. +v/+h+/o) seen as +v, or no shown +v at all. This would also be nice: users won't see any flags unless they are halfops or ops. So: - +v users all users as unflagged (wondering why people can talk :P) - +h users see +v as +v, +h as +h, and +o as +h - +o users see +v as +v, +h as +h, and +o as +o Or +v users would see +v/+h/+o as +v, and even in case of a flood they wouldn't be able to find out what who has what, but at least they won't wonder why someone who appears as unflagged does talk (because he's, say, +h but no +v). About the showing out who sets topic or changes mode, the server could 'mask' it with something fake, i.e. "=Operator=". Ok, it looks lame :P but it should be some word _not usable_ as a nick, to avoid confusion. Services would make a mess anyway, because if you use Epona's /cs topic command, it will set the topic like this: "my topic (mynick)". And /topic #channel will return only "mytopic" as the topic, and mynick as the one who set it. I don't know about other Services, but I guess it'll look quite the same. |
|
|
I don't think it's important to show the users some rightfull user status (voice) when the channel is +m, since the purpose of this channelmode is exactly the oposite :). I agree users may find it weird in the beginning, but everything about this channelmode is weird, so... About masking... I think you shouldn't see (as a user): *** =Operator= sets mode +o Someone altough it would be nice, I think some clients won't like it because =Operator= isn't on the channel ("desync!!" :P). So I think they should just see the server setting it, like: *** irc.whatever.org sets mode +o Someone Or you could "reserve" a "ops.of.channel sets mode blabla" for it but that would be a bit ugly :). Services, well, you are right... They should be changed or one should not use it for topic/kick/whatever. This however remembers me of 2 servers linking again and a (newer) topic on server A which hasn't been set on server B.. then at server B you will also see the *** server.a sets topic to 'Blabla (originalnick)', that should be sent differently to non-h/o users then ofcourse.. |
|
|
Can't the topic be 'signed' as completely being set by a servername? So that they would see something like "Bla bla (server.name.net)"? A dumb question: can a TOPIC/MODE/KICK command be apparently issued by a _channel_? :P Somthing like: :#channel TOPIC #channel :I am your topic No, huh? Anyway, I never heard of any client getting confused by Chanserv opping people, so I guess they could be confused only because of the non-nick characters... but again, we could also use a fake TopicServ (reserving this nick - or any nick for it). |
|
|
Or we could use something issue such command as coming from "Channel.mode" (literally, without changing it into Mychan.mode). This way, clients will think it's a (dumb) server name and they'll be happy in any case :P |
|
|
about topic: the (nick) was ment to give some information, I think we should just drop the (nick)-part when sending to non-+h/+o clients instead of filling it with something unusefull. Mmm you are right about chanserv I think, it's just I see eggdrop (1.4) complaining sometimes, don't know about others... Then we could use =Operator= like you suggested, might be even better so it looks like a regular mode instead of a server mode. |
|
|
Eggdrops are for bad networks like ircnet and efnet, not unreal-based ones :P I just have the feeling that "=Operator=" looks totally lame :D "Channel.mode" would probably also avoid newbies asking "what's that stuff", as it's easier to understand what's going on. Again, just my two-cents (but will you name me somewhere if you're going to implement this crazy modes, for I have helped out with planning what it should do? :DDDDDD) (off-topic: could anyone please have a look at bug report #330? i have had to recompile without v6 support to avoid crashes :| and it works seamlessly now, proving that it was indeed a v6-related problem) |
|
|
Ok.. "chan.op" then :)). Since it may also set the topic or kick :P. I will name you somewhere hehe... Btw, first a previous (pretty big) patch has to get in since we are now "out of channel mode space" and that patch adds more space... (off-topic: not me atm... I know nothing about the resolver code :P). |
|
|
Cool, but I want my real name on it, because I am myself and not my nick. Wow, it sounds strange, for I've been too much into irc :P Write to jollino-at-discussioni-dot-org and I'll reply ;) Does that patch allow for STRANGE channel modes like +1, +2 .. please, don't tell me so :) Right now used channel modes are abcefhiklmnopqrstuvzACGHKLNOQSV, which means Unreal can still use dgjwxyBDEFIJMPRSTUWXYZ. (I did it by hand, I probably forgot something :P) Btw, can't the user and channel mode listings in numeric 004 be sorted? Does that order have any special meaning or is it just 'historical'? ( off-topic: SIGH :( ) |
|
|
Hehe I will move this to mail instead of discussing this at the bug report :P. |
|
|
I decided not go ahead with this. This doesn't seem to be very useful on a network with services, it won't justify the time involved to code it, to maintain it, and the mess it would create. |
