Buddy/notify lists:
Most mature irc clients do this already for the most part. Clients have a built in notify list. Some go as far as even calling it a buddy list. mIRC if i remember correctly has 3rd party scripts that enhance this feature. Clients such as mIRC also have an address book style manager so you can write notes or memos about a person, load a small pic of the person as well as many many other things.
Lastly, for this to be supported as you describe you would also need the ircd's support as well for this to work even half well. For example if nick1 adds nick2 to their notify list, nick2 not only can do nothing about it but may not even know. Users can add anyone to their notify list and other users can't prevent it.
Either I do really write totally incomprehensible (Could someone give me any feedback on that point pls?) or you are trying to understand me wrong again - as you did in the X discussion last time.
All the needed ircd support is allready there, as nickserv allready has the ability to detect new users on a network. (and ask them for their password and so on)
doing this on client side is never gonna be reliable.
Even if the client regulary polls either /who or /whois or something else and/or is listening on in the channels that nick2 will join to, it does not guarantee that the user will connect under the same nick or from the same address. And the case where the nick AND the addresses are new to nick1 is the one where a client side recognition WILL definitely fail.
Even if it is not done intentionally by the user of nick2 it is an avoidable problem that can be solved by grouping all nicks to one ns group.
On the other hand services do get the info that a user connected (and identified) and could generate a notification immidiately, while the client side polling solution is slower, not reliable at all and generally a waste of ressources.
But allowing easily to detect what nicks belong to a nickgroup is a thing that is not cared about by any current ircd (i know) and therefore i wanted to add the ability to deny the adding of nicks to other users notify list.
Users in general don't need to know if/when other users identify, it's simply none of their business
Well, if you see nickserv as something that prevents MY nick to get used by someone else, true.
But as soon as you see nickserv as a tool that helps at authentication of the user behind a nick, then the event of identifying becomes interesting.
Using nickservnicks on chanserv access lists means the devs already acccepted the fact that nickserv has at least some little importance in authenticating users.
Yeah, sure it does not guarantee the authentcity of a user 100% but knowing a nick has been registered 2 years ago and the user behind that is identified, tells me that the nick most likely is still the same person.
On the other hand an unregistered nick could be anyone and could change anytime.
So some kind of notification on the positive identification would be interesting to users.
if its done by some nickserv setting "notify me about identified users on channels i am in/i select" would be nice, but im not sure if all anope's supported ircds share information on user's joined channels.
Again clients can do that by polling nickserv (as you suggested) which is again at least a waste of ressources.
Also imho the features to (not) be implementing should be determined by "does such a feature enrich an irc network for users irrespective of the client they use" and not by "it is possible to do that by a client on the client side" as this logic would demand the immidiate drop of any service development, as you can do nearly ANYTHING services do with polling and an opered up client.
If thats the good, efficient and free/open way is another question, but you seem to disregard these arguments at all anyway.
greetz
~someone
PS: thanks for doing /ns help status for me... im too dumb to do that by myself and i have also never studied the features my servers serve...
srsly -.-
