Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Ethan Carr]

Hello, my name is Merbo.
Ever seen on Atheme, how there is /msg chanserv FLAGS?
I'd like a module for those, a lot of my clients come from freenode and therefore seriously are used to chanserv's FLAGS feature,
and don't have a clue how to use the access list.
So I'd like FLAGS as a module.

Code: [Select]

-ChanServ- ***** ChanServ Help *****
-ChanServ- Help for FLAGS:
-ChanServ- 
-ChanServ- The FLAGS command allows for the granting/removal of channel
-ChanServ- privileges on a more specific, non-generalized level. It
-ChanServ- supports both nicknames and hostmasks as targets.
-ChanServ- 
-ChanServ- When only the channel argument is given, a listing of
-ChanServ- permissions granted to users will be displayed.
-ChanServ- 
-ChanServ- Syntax: FLAGS <#channel>
-ChanServ- 
-ChanServ- Otherwise, an access entry is modified. A modification may be
-ChanServ- specified by a template name (changes the access to the
-ChanServ- template) or a flags change (starts with + or -). See the
-ChanServ- TEMPLATE help entry for more information about templates.
-ChanServ- 
-ChanServ- If you are not a founder, you may only manipulate flags you
-ChanServ- have yourself, and may not edit users that have flags you
-ChanServ- don't have. For this purpose, +v grants +V, +o grants +O
-ChanServ- and +r grants +b.
-ChanServ- 
-ChanServ- If you do not have +f you may still remove your own access
-ChanServ- with -*.
-ChanServ- 
-ChanServ- Syntax: FLAGS <#channel> [nickname|hostmask template]
-ChanServ- Syntax: FLAGS <#channel> [nickname|hostmask flag_changes]
-ChanServ- 
-ChanServ- 
-ChanServ- 
-ChanServ- Examples:
-ChanServ-     /msg ChanServ FLAGS #foo
-ChanServ-     /msg ChanServ FLAGS #foo foo!*@bar.com VOP
-ChanServ-     /msg ChanServ FLAGS #foo foo!*@bar.com -V+oO
-ChanServ-     /msg ChanServ FLAGS #foo foo!*@bar.com -*
-ChanServ-     /msg ChanServ FLAGS #foo foo +oOtsi
-ChanServ-     /msg ChanServ FLAGS #foo TroubleUser!*@*.troubleisp.net +b
-ChanServ- ***** End of Help *****
I'd know that this module should have XOP turned off.
I'd also like it, so that if there are FLAGS then the ACCESS list is ignored. You can leave the access list though, not
a big deal.

Flags that I want:

Code: [Select]

+v: Allows using /cs voice <chan>
+V: Auto voice on join.
+o: Allows use of /cs op <chan>
+O: Auto op on join.
+s: Allows use of the /cs SET <stuff> command.
+i: Enable use of /cs INVITE, and /cs GETKEY
+f: Enables access to the flags list.
+t: Allows changing of the topic using /cs TOPIC or /cs TOPICAPPEND
+A: Enables viewing of channel flags list.
+F: Allowed to do anything and everything. Full founder access, but dont get listed on /cs info as the founder.
+k: Automatic kick.
+b: Automatic ban.
+B: Automatic kickban.
+q: Automatic +b ~q: (quiet)
+*: Adds all permissions except for +F, +k, +b, +B, and +q.
-*: Allows +F users to remove ALL flags from a mask, or allows users on the flags list to remove ALL of their own.
I honestly don't mind it if it isn't a precompiled .dll, I'd love to get the source.
You could also make me a simple template, with two flags, one that allows them to use /cs voice and one that automatically gives this voice on join, and ill work my way around the rest.

[katsklaw]

The only way to do this is to have a module that completely replaces all of Chanserv's xop and access levels. That's no small thing. In fact it would be like re-writing 75% of Chanserv it's self. Which could take months (maybe a bit sooner if someone devoted more time to the module). Which by that time you've either lost your users, migrated to Atheme or your users have grown accustomed to xop/access levels.

Secondly, while Atheme's flags are "cool", they really don't add a huge amount of functionality. What I mean is it doesn't make sense to have ChanOps that can't change the topic but Voiced users that can. Even by that example, RFC1459 allows ChanOps to change the topic, thus so will the ircd. That's just simply part of IRC. IRC's current hierarchical layout is very sane, it makes perfect sense and has worked very well on much larger nets than FreeNode since 1993 (that means before FreeNode).

Continuing on the above example, if you used flags to deny ChanOps the ability to change the topic, what you are really doing is having ChanServ reverse the topic change since ChanServ can't actually prevent anything, only react after the fact, just as it would with Anope's topiclock. This adds resource usage, namely cpu cycles and bandwidth. Which is actually counter productive.

I'm fortunate enough to be good friends with both IRC developers as well as users and I assure you that in many cases, the users desires and the developers desires are not in accord. Most users I've talked to are in IRC to chat, that is what the "C" in IRC stands for. There really don't want to devote a bunch of time to reading and decoding manuals or the helpfile for 56346534564365 commands. Why is it you think the xOP system is so popular? It's very simple, that's why. ChanOps learn a few commands and get back to chatting. Developers try to complicate things by making things "finer grained" which translated means more things to lear and/or foul up. I was once one such person. More is not always better regardless of how much "sugar coating" a developer puts on their sales pitch to get you to switch to their software. In the end, they care more about their own popularity than they do about your networks success.

At anyrate, FreeNode is a specialised IRC network, it's not surprising that they use highly specific software. If you like FreeNode's set-up, then it's far easier for you to simply use their software.

Good luck

[JD]

katsklaw is mostly correct. If your users/you feel you want/need flags, you should use Atheme (the Services package Freenode uses) instead of Anope. I personally feel like xOP is easy enough for most users, however.

Unlike katsklaw though, I do see the use of flags and once you use them on a regular basis, they can be extremely useful as you can simply not give a user the +oO flag (for example), but still allow them to kick/ban people or change the topic or similar.

[katsklaw]

Actually JD, I have used the system. Quite a lot. However, I firmly believe that if a user is trusted enough to use kick/ban, just +o them. It's far easier. IRC isn't designed to be complicated and you are just making more work for yourself in the long run.

Less is more
work smarter, not harder

[Ethan Carr]

Alright katsklaw, I'll end this D:

[katsklaw]

Alright katsklaw, I'll end this D:

I've only expressed my opinion. I hope you truly aren't so discouraged by such a trivial thing. I'm in no position to deny the creation of such a module.

[JD]

Actually JD, I have used the system. Quite a lot. However, I firmly believe that if a user is trusted enough to use kick/ban, just +o them. It's far easier. IRC isn't designed to be complicated and you are just making more work for yourself in the long run.

Less is more
work smarter, not harder

I agree with you that if you can trust a user to kick/ban, you can trust them with +o (that was just an example, but...). I disagree that it's more complex though as you (or your netadmins) can just set up some templates and then you can just: /cs flags #whatever jdhore admin.

The only part that makes it a bit complex is some of the flags don't map very well in your head, annoyingly, but after having used them for a while, you wind up memorizing them anyway.