Print

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

[demon]

Hello,

Some suggestions:

1) Make possible to set different ident, hostmask, modes, realname for each service

ex: nick@nickserv.mynet - I am NickServ
ex: chan@chanserv.mynet - I am ChanServ
ex: bot@botserv.mynet - I am BotServ (and ability to have mode +B so as when you /whois it to say is a bot (and also that appears to all bots))

I know that some of them (like the modes) can be done by little change the source, but it would easier and more flexible to do those changes in conf

2) Check some of the best modules out there, (with most downloads, or the best rate) and add them in core code.. some of them are really useful and i dont see why it shouldnt be in the core as so many users request them and download them for their networks.

3) A minimal web interface for services? simple things such as register nick/chan

4) Change the oper types.. Ability to create your own oper types and also to specify exactly what commands can be used by each type.. (i think atheme have done sth like that so you can get an idea)

5) CommServ - Communitties Service, ability to create communities for your network, and add users and opers in each one.. the community name will be displayed in the /ns info and the use of that service is for: sending memos/emails to members of each community or all members of CommServ, give them ability to use some commands, for example: Helpers Community can use the /os mode /os kick etc.. Generaly Organize better your network

6) /os mail <email address> <subject>: message ! That would be usefull for opers to send emails from services@my.net so as to warn users, inform them etc..

Tell me your opinions..

Thanks

[katsklaw]

1> it's been suggested already.

2> we do this already, hs_request, ns_noop, os_info, ns_maxemail just to name a few. They were at one time all 3rd party modules and added as supported modules.

3> it's been mentioned. IMHO, nick/chan registration should only be allowed on IRC, because if you allow such events to occur off IRC, users will 1) have no need to come to IRC. 2) malicious users can exploit and misuse the registration process. Other access such as read memos or change/delete nick/chan attributes are ok.

4> it's on the to-do list (flag based oper levels with possibly individual and grouped flags).

5> This can be covered in #4 and we don't need to introduce yet another *Serv bot to handle it. This can currently be done with a module, swhois on IRCds that support it and free web based email groups such as gmail or yahoo groups which include file sharing, community calendars etc ... Lets not re-invent the wheel, but instread recognize when something that already exists can do what we want just as well or better than we are proposing.

6> can be done nicely with a module.

[demon]

Ok i get your points..

Hope to see those changes and addons in the next version? or is planned for the long... future?

And also isnt it time after 19 releases to made the 1.7 version Stable (possible 1. ? when are you planning to do that..?

Thanks

[demon]

Also:

(Killed (OperServ (OpenNick: Bla Bla Bla [ID: #32984 ] [1])))

That would be a nice feature so as users can easily say to opers which akill effect them just by the ID number..

Thanks

[katsklaw]

ID numbers have been argued many many times. The result has always been that ID numbers are only good on very large networks where it is more beneficial to search by number instead of by hostname. Such very large networks include nets as large as DALnet (40,000+ users) can make use of ID numbers, the rest of us can simply use the already provided method and yield the same results just as fast. Again, don't re-invent the wheel ;P

As far as adding the kill command to OperServ and adding the oper to the kill message, that's very possible with a small module, I'll look into it and perhaps write it for you.

Thirdy, we will release 1.8 stable when we feel that 1.7 is stable enough to be deemed stable. Until then, patience is a virtue

in reference to your original #5, I've made a module that you can use to denote what community a user/channel belongs to. This of course is just for starters, as more info/features can be added and I may entertain the idea of making the module use it's own pseudoclient at a later date.

You can view/download the module at: http://modules.anope.org/viewmod.php?id=91


Enjoy!

[Jobe]

Well my view of point #5 is basically this:

Are channels not communities?

[Edited on 30-6-2007 by Jobe1986]

[katsklaw]

UPDATE: I created the os_kill module. It adds the /operserv kill command and adds the killer.

http://modules.anope.org/viewmod.php?id=92

[demon]

Heh.. some guys out there says that Anope is dead.. Well they get their answer..

Thanks katsklaw.. nice work

Probably the /os kill could add akill ? for example to have a default time of ex: 30mins (changeable) ?

Community Module is really good.. and hope to include it in the core too

PS: i grap both of them.. hehe

[demon]

And something that have been requested also many times.. just to remind it in case someone would like to do it in module or add it in the next version in core..

To calculate the days left to expire the nick/chan, and also the time the nick/chan is registered..

      Registered: Jun 29 20:45:55 2005 EDT
    Register For: 2 years 2months 2days etc...
       Expires In: Jul 29 20:45:55 2007 EDT
       Last used: Jun 29 21:04:11 2007 EDT (Before 1day 1hour etc)

(in the same line or different doesnt really matters, but if they are in the same they could probably make the line too long and some users would have problem reading it or get confused because of line changes)

I know they probably use more resources, but they are nice info that are calculated already (for opers like the expiry) so why not shown them to everyone? i dont think that users all the time do /ns info or /cs info .. once in month or whenever they do it to see ALL info, nice displayed.. for example the expiry time is too important.. and maybe a network change it (the expiration time) once in a while and the users are not informed.. by that they always know exacrly the date of the expiry so as not to lose the chan/nick

Thanks
And again great work guys!!!

[Jobe]

If you know when a nick/channel is going to expire, what does it matter how long it is until then?

[katsklaw]

Originally posted by demon
Heh.. some guys out there says that Anope is dead.. Well they get their answer..

Thanks katsklaw.. nice work

Probably the /os kill could add akill ? for example to have a default time of ex: 30mins (changeable) ?

Community Module is really good.. and hope to include it in the core too

PS: i grap both of them.. hehe

A kill is a kill, they are not timed .. a kill is just like a kick from a channel, they are instant.

Dead? whom ever says that live under a rock! Anope is one of the most pupular IRC Services Packages in the world.

It's true that we have been a little slow at releasing stable versions, but I assure you that there is a world of difference between 1.6 and what 1.8 will be. We currently have nearly 1000 changes from 1.6 to 1.7 and we aren't quite done yet!

[demon]

because to see the expiry you have to do /ns help .. well if someone do /ns info nick, and dont do the other command how should he/she knows that the will expire in some days? and if admins change those days often? there are many reasons why that info should be displayed.. and i just request it as its already calculated for opers/admin so why dont display it to everyone..

Of course is just a suggestion.. dont like it.. dont make it

[katsklaw]

I was refering to this "Probably the /os kill could add akill ? for example to have a default time of ex: 30mins (changeable) ?"

kills do not have expire times .. they are instant.

[demon]

heh, we replied in the same time.. you are a bit quicker than me.. i was repling to Jobe.. for the nick/chan expiry and not in your post

[Jobe]

-NickServ- Expires on: Jul 30 22:06:49 2007 BST

^^ currently already a part of Anope, not sure who can see when a nick expires, but still its available.

Maybe a request to make it visible to the nicks owner, but then youd know the next expires X days from "now" anyway since youre using the nick.

[katsklaw]

personally, I think most people know how to count .. so there isn't a need to state the obvious.

[SNU]

yeah katsklaw, thats great.

short hint:

having
AnonymousGlobal

enabled, does not interest os_kill. Would be nice if this option is enabled the killer wont be shown. otherwise you could implement an own config-directive.

[Bearbeitet am 1-7-2007 von SNU]

[katsklaw]

Originally posted by SNU
yeah katsklaw, thats great.

short hint:

having
AnonymousGlobal

enabled, does not interest os_kill. Would be nice if this option is enabled the killer wont be shown. otherwise you could implement an own config-directive.

[Bearbeitet am 1-7-2007 von SNU]

There are alot of things I could do. But I chose to do things as I have.

use the module if you like it .. don't use the module if you don't like it, it's all the same to me.

btw, nothing stopping you from killing the user yourself ya know.

[Jobe]

Originally posted by SNU
yeah katsklaw, thats great.

short hint:

having
AnonymousGlobal

enabled, does not interest os_kill. Would be nice if this option is enabled the killer wont be shown. otherwise you could implement an own config-directive.

[Bearbeitet am 1-7-2007 von SNU]

Last time I checked AnonymousGlobal makes global notices anonymous. Nothing else.

[demon]

probably he means if by enabling that you can in the same time enable the hiding of oper's nick in the kill, and if you disable it the oper's nick to appear in the kill.. i hope he means that..

Thanks

[demon]

katsklaw about the web interface.. you said that has been requested again.. So what the plans for that? if any? Something advanced like GNUworld? or something simpler? give us an idea

Thanks

[katsklaw]

there is no plan, but since Anope can dump to mysql a php web interface can access the mysql tables in a "read only" fashion already. Once Phase 3 is complete or at least functional that same interface could write to anopes mysql database as well.

[demon]

so its prefered to use mysql from now on.. as most of the development will be in that field.. right?

If i choose mysql, for example the module for communities will write the data in the mysql database? or it needs further changes for that?

[Jobe]

demon, at present, ANope only writes to MySQL once its running. For a third part program to write to the DB and Anope to acknowledge that would require shutting down Anope, then the application writing, then Anope being started back up.