[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: nick collide prevention ideas
On Jul 03, m de`jour wrote:
| I am not a subscriber to this list, so not being that familiar with the scope
| of topics here, I can only hope I am reasching some of the intended target
| audience, those with input to changing and modifying the ircd code. If
| another list is more appropriate, please feel free to forward.
|
| Please bcc any comments and replies to me also, as I will not receive replies
| to these lists.
|
| -----------------------
| This outlines several possible techniques to reduce abusive mass nick
| collides. My experience relates to IRCnet and some ideas are net-specific I
| suppose, but others are general in nature.
which is fine, as ircd-users@xxxxxxx is IRCNet specific as
well
| There are peices of several different potential solutions. As I was writing
| about some ideas I have thought much about, a couple new, totally different
| ideas came to me. I added them at the bottom.
it makes a rather lengthy mail hard to read through entirely,
but i'll try :)
[..]
| Would some of the following ideas perhaps reduce nick collides?
| [/me lives on IRCnet without TS]
|
| suggestion:
| Test for characteristics of collide conditions. If any exist
| then don't allow self-service pick-a-nick and/or exact nick
| changes until collide conditions are abated.
|
| Perhaps test for some or a combination of things like:
| server reboots
| or
| server is split
hard to implement (especially in a general maneer that will
work even in differently sized nets)
| or
| total server count is < xx [some preset value]
(this solves my above objection, but)
how is preset defined?
| or
| queue is huge
what is huge?
| or
| lag is high
what is high? how do you measure it?
| or
| many kills [ or recent kill history as sometimes the same server
| connects and collides over and over before someone intervenes
| and conditions are corrected.
again this is easy in english, less easy to implement.
| or
| or ? [fill in whatever fingerprints might be used]
| or ? [as a profile that would match as many]
| or ? [typical probable collide scenarios as possible]
|
| If such monitoring indicates any or a predefined combination of
| characteristics exist that match "collide conditions", then when
| a client either connects or requests a new /nick abcd1234
|
| then:
| if nick requested is < 7 char, server would add 3 random
| characters
| if nick requested is > 6 char, server would truncate to 6 then
| add 3 random characters.
i think the only result would be more nick changes (e.g. more
bandwidth) as users fight to get a nick that the server
doesn't let them have.
| Alternately, if the nick length was increased to allow for
| longer -server set- nicks, the server might force expand all
| nicks to 9 characters if shorter, then add 3 random characters.
| for /nick able server would expand it to able-----x\^. Users
| would not be able to request nicks over 9 characters. Only
| servers could set longer nicks, doing so when said collide
| conditions exist.
that sounds like the new channels.
i considered this options many times, but it is too
problematic for backward compatibility and also user
friendlyness (!IDchannel is already annoying, but users
aren't forced to use them.. IDnick would prove to be very
unpopular)
| ------------
|
| Use the same technique colliders use to cure the problem.
|
| The collide-kiddies have clients on both sides of a split. Use that same
| method against them, make an integrated client type connection to test the
| waters before making the actual server connection.
this is rather complex & unpractical
| ===============================
|
| New ideas... hold the presses... seems much simpler but as I am
| just conceiving it as I write, it is not thought through.. flame
| me but be gentle ;)
|
| 1] Expand nick length to min. 15 characters,
| 2] if user selects nick over 9 characters, all characters >9 are
| forced to random by the server.
again, changing the nick length might cause more problems
that it would solve.
| ===================
|
| additional alternatives:
|
| also add a new command to ircd: /rnick for random nick
any client can do this. (mine used to)
| This /rnick function would assign a totally random nick of 9 characters.
|
| It would begin with a number.
|
| Read that somewhere ;) Beeth I think - this leading digit part is not my own
| orignal idea but neat.. and the /rnick function comes from a script I just
| started testing. Putting both functions together might well be the simplest,
| easiest method to implement a satisfactory solution to mass collides.
|
| Users could not request a specific nick starting with a number.
| Only servers would be able to assign nicks starting with digits
| and all would be totally random 9 character nicks - all
| beginning with a digit.
that would work, granted that users would agree to live with
random nicknames, which i highly doubt.
| those wanting collide protection merely request /rnick on
| connect and they accept whatever the server assigns.
|
| --------------------
|
| for this to work, the strong anti-bot sentiment in some quarters
| would need to be softened. Non-abusive defensive chanserv
| clients and bots should not be targeted because they chose to
| take advantage of this increased collision protection
| technique. Being pragmatic, bots are needed for basic community
| protection and survival on IRCnet. Building a chat community requires
| stability and consistancy. IMHO, bots are the only practical way to provide
| that on non-register nets like IRCnet.
|
| If this is effective, perhaps fewer bots would be needed.
| Now the primary threat is nick collides for which raw number
| is the best means of survival.
|
| If collides are controlled, DoS attacks on ops will possibly increase. :\
no doubt on this.