Anope IRC Services

Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: [1]   Go Down

Author Topic: Possibly add /ns identify NICK PasswordForNick  (Read 9193 times)

0 Members and 1 Guest are viewing this topic.

Ben

  • Anope User
  • Offline Offline
  • Posts: 1
Possibly add /ns identify NICK PasswordForNick
« on: March 16, 2013, 01:14:40 AM »

Good evening, everyone.  My first post here.  As many networks use Anope, this is one thing I've noticed that has bothered me about it.

On Atheme, and even on DALnet's NickServ, it's possible to use /ns identify OtherNick PasswordForOtherNick in addition to /ns identify PasswordForNickYouAreUsing .

In Anope, only the latter is possible.

This is mostly useful for folks who auto-connect via ZNC or mIRC perform.  While the original nick may not have yet been ghosted, nick groups are how channel access is determined, amongst other things.  Under the current situation, you'd have to group all alternative nicks.  In theory, if someone (who isn't supposed to be) happens to be using that alternate nick, then for obvious reasons, /ns identify PasswordForCurrentNick will fail.

I can't imagine it would be too difficult to add this capability, but I haven't reviewed Anope's source code.

This way, when the original nick is regained, you wouldn't have to identify to it again.

Thank you all in advance for your possible consideration.
Logged

Adam

  • Team
  • *
  • Offline Offline
  • Posts: 463
Re: Possibly add /ns identify NICK PasswordForNick
« Reply #1 on: March 16, 2013, 01:17:51 AM »

Use 1.9.
Logged

Swampy

  • Guest
Re: Possibly add /ns identify NICK PasswordForNick
« Reply #2 on: March 17, 2013, 03:48:46 PM »

Well I dont see this being much of a problem, if folks use services properly.

Most ZNC / BNC's can do "Perform On Connect" functions, so you'd only ever need these lines here:

/NickServ Ghost <normal_nick> <pass>
/Nick <normal_nick>
/NickServ Identify <pass>

1) That will only kill any ghost sessions and not your current one (meaning its safe to use all the time)
2) It will rename you back to your original nickname
3) It will automatically identify you.

That should help with your problem, I use this method all the time on every network I connect to, and since using this method, I've never had any problems or issues.
« Last Edit: March 17, 2013, 03:50:22 PM by swampy »
Logged

John

  • Anope User
  • Offline Offline
  • Gender: Male
  • Posts: 19
    • IRCSpeed - The Network with a Difference
Re: Possibly add /ns identify NICK PasswordForNick
« Reply #3 on: November 21, 2013, 04:02:21 AM »

It would actually make sense, and be highly beneficial for someone to make a patch for this.

Some people use Unreal3.2.9 with Anope-1.8.6 - a Popular set up. With networks that are either unable to upgrade to the 1.9, or simply don't want to, a command like this would be good for user's wanting to use an unidentified nickname and /identify to a specific nickname, or a user identifying to another nick while using their preferred registered one. This effectively allows that nickname to be identified for several nicknames|channels at once.
Logged

Adam

  • Team
  • *
  • Offline Offline
  • Posts: 463
Re: Possibly add /ns identify NICK PasswordForNick
« Reply #4 on: November 21, 2013, 04:06:58 AM »

The way 1.8 is designed makes this not possible, you would have to rework a large amount of logic throughout pretty much all of the source. This is one of the reason for 1.9's existence.

The 2.0-rc1 release is in one month, and once the full 2.0 release is out 1.8 will be considered largely obsolete. We expect users to move to it then. I assume your "not wanting to move to 1.9" statement is due to the perceived instability of it, and not to due to its behavior changes.
Logged

John

  • Anope User
  • Offline Offline
  • Gender: Male
  • Posts: 19
    • IRCSpeed - The Network with a Difference
Re: Possibly add /ns identify NICK PasswordForNick
« Reply #5 on: November 21, 2013, 04:17:22 AM »

I assume your "not wanting to move to 1.9" statement is due to the perceived instability of it, and not to due to its behavior changes.

Heh, well, it's more of a modular issue. I have loaded a lot, for many features on my network, but when I upgraded from anope-1.8.5 to anope-1.8.6 I had several modules not autoload and also not load using /operserv modload.
I thought about downgrading, just to run those modules again, but I maintained the release. Upgrading to 1.9 gives me some reservations, modular and stability issues, connectivity and latency, etc.

I think there will still be a large crowd that stays on 1.8, or keeps it for whatever reasons. I will do what is in my networks best interests, even if that means an upgrade.
« Last Edit: November 21, 2013, 04:19:51 AM by John »
Logged

Adam

  • Team
  • *
  • Offline Offline
  • Posts: 463
Re: Possibly add /ns identify NICK PasswordForNick
« Reply #6 on: November 21, 2013, 04:21:52 AM »

99.9% of the modules for the 1.8.x releases are compatible with all of the releases (and a good amount of 1.7.x). Assuming you do properly recompile them across releases. I doubt that you really found any modules that would work with one but not the other.

Many of the more popular features modules provide with 1.8 are shipped with 1.9, which means users need less modules.

Stability used to be more a problem than it is now, we are very close to a final release, so it is not much of an issue.

No clue what you're referring to re connectivity and latency... that sounds like a network problem you're having. I don't see how that is related.
Logged
Pages: [1]   Go Up