Anope IRC Services

Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: [1]   Go Down

Author Topic: Some ideas  (Read 8166 times)

0 Members and 1 Guest are viewing this topic.

ShawnSmith

  • Anope User
  • Offline Offline
  • Posts: 46
Some ideas
« on: December 27, 2008, 10:05:50 PM »

I was looking at the 1.9 roadmap and figured I'd post my opinion on a few things.

[ ] NS SUSPEND: show suspender and reason, probably to sopers only (see CS SUSPEND)
I think NS SUSPEND should show the user the reason is was suspended, so they don't have to bother a staff member if they're curious about why it's suspended.
? [ ] Don't allow soper accounts to expire
Anyone who has services oper shouldn't really need this as they're on often enough to keep their nickname, if they ever leave for an extended period of time a sadmin could just give them noexpire, it seems like a waste of space to make them automatically not expire.
[ ] CS SET INHABIT to keep pseudoclient in a channel after it empties to maintain banlists and such
I don't think this should be added, any channel that doesn't have enough active members to keep it open 24/7 isn't going to have a big enough banlist to bother keeping, any modes they want kept can be kept with mlock.
[?] Remote identification (1.9.1? will this break stuff?)
I thought that this was talked about and decided against because NickServ already offers nick grouping, making the need for remote identification useless.
[ ] Useful/common "third party" modules to core distro - [ ] NS AJOIN
I would vote against this because... (Well, vote against the NS AJOIN because..) Almost every client has an autojoin feature, and the ones that don't (web clients) aren't used as a very common way of chat, mostly just from work/school where the people don't bother identifying anyway.
? [ ] MS IGNORE. Make it take nick (accounts) or n!u@h masks. Fake success of memo send still, but send to opers?
I vote for the fake success of memo, but not sent to opers. This would be a very effective way of spamming a staffs Memo box. - Though maybe make it log in the logchan if it's on, Like MemoServ: Ignored memo from <Nick> Message: <Message>
Logged

katsklaw

  • Guest
Re: Some ideas
« Reply #1 on: January 13, 2009, 05:46:03 AM »

I was looking at the 1.9 roadmap and figured I'd post my opinion on a few things.

[ ] NS SUSPEND: show suspender and reason, probably to sopers only (see CS SUSPEND)
I think NS SUSPEND should show the user the reason is was suspended, so they don't have to bother a staff member if they're curious about why it's suspended.

agreed as long as it's restricted to staff only. normal users have no business knowing the reason, that is between the user and the network only.

Quote
? [ ] Don't allow soper accounts to expire
Anyone who has services oper shouldn't really need this as they're on often enough to keep their nickname, if they ever leave for an extended period of time a sadmin could just give them noexpire, it seems like a waste of space to make them automatically not expire.

I'd have to say as long as it's optional since not all network use noexpire.

Quote
[ ] CS SET INHABIT to keep pseudoclient in a channel after it empties to maintain banlists and such
I don't think this should be added, any channel that doesn't have enough active members to keep it open 24/7 isn't going to have a big enough banlist to bother keeping, any modes they want kept can be kept with mlock.

This is already set in services.conf This value shouldn't change so often as to warrant it be moved to an on-the-fly setting.

Quote
[?] Remote identification (1.9.1? will this break stuff?)
I thought that this was talked about and decided against because NickServ already offers nick grouping, making the need for remote identification useless.

This I think was on the original 1.9 todo list before anope-ng. BTW, not everyone keeps their nicks in the same group, nor is it impossible for a trusted friend to ID for someone whos out for an extended time (since Anope doesn't have a vacation mode) or ID'ing for boy/girlfriends. There are several reasons that remote ID are useful for nicks outside your own group.

Quote
? [ ] MS IGNORE. Make it take nick (accounts) or n!u@h masks. Fake success of memo send still, but send to opers?
I vote for the fake success of memo, but not sent to opers. This would be a very effective way of spamming a staffs Memo box. - Though maybe make it log in the logchan if it's on, Like MemoServ: Ignored memo from <Nick> Message: <Message>

Only registered nicks can send/receive memos in the first place so why would we need to specify anything else? iirc "nick" will be applied to the display name and affect all nicks in said group.
Logged

Obi_Wan

  • Guest
Re: Some ideas
« Reply #2 on: January 13, 2009, 02:34:06 PM »

I think remote identification is quite useful if you have an immediate kill option in nickserv and you have to identify to a nick before you are able to use it.
Logged

katsklaw

  • Guest
Re: Some ideas
« Reply #3 on: January 13, 2009, 02:53:30 PM »

I think remote identification is quite useful if you have an immediate kill option in nickserv and you have to identify to a nick before you are able to use it.

only if you are from an address *not* listed in /ns access, otherwise NS with act normally to you regardless of kill settings.
Logged
Pages: [1]   Go Up