When adding a new unknown hostmask to the message history accounts, we now
take significant advantage of the aliases table to find an existing account
id for the hostmask before assigning it a new account id.
Likewise, we now take significant advantage of the aliases table when looking
for a nick-change match.
Fix misc channel case-sensitivity issues, add missing last-seen hostmask
updates, reduce message account linking log verbosity level.
Factoids can now have an effective-level metadata field. When set, certain
functionality requiring an effective-level will be enabled.
For now, that is currently only the /kick command, which has an effective-level
of 10.
Factoids with an effective-level set will also have the locked metadata
attribute set as well to prevent people from changing the factoid. The
locked and/or effective-level attributes will be removable only by admins
whose level is equal to or greater than the effective-level.
Previously, the bot wouldn't address people by nick if the provided nick
argument doesn't exist in the channel.
Now, the bot's nick list is searched for a nick with a certain similarity
percentage in the order of most recently spoken nicks first. This allows
the bot to address nicks when somebody may have forgotten to add a trailing
underscore/punctuation or may have typoed the nick.
The similarity percentage can be set via the interpreter->nick_similiarty
registry key. A value of 0 should disable the behavior.
When joining a channel, check the WHO list for that channel in order
to obtain all hostmask, nickserv and gecos information and check for
potential ban evasions.
Linking of message accounts is now significantly less likely to produce
false-positives.
Previously, any hostmasks with matching nick!*@* would be strongly linked
together. This led to falsely-linking accounts, either inadvertently or
intentionally.
For example, Bob might also be known as Bob_ and Bobby,
but primarily uses Bob as his main nick. Somebody else might join with
Bobby and end up being linked to Bob. Now both Bob and the new Bobby are
linked together as the same person, but likely with different *!user@host.
Now if the new Bobby ever gets banned, then Bob will also end up being
banned for evading Bobby's ban.
This was a sore spot in the previous linking implementation.
This new implementation has several adjustments to more intelligently link
accounts only when they're proven beyond a reasonable doubt to be the same
person (e.g. by matching nickserv accounts, etc).
Consequently, rather than aggressively linking accounts and catching more
ban-evaders at the risk of potentially falsely-linking accounts and falsely
detecting innocent people as ban-evaders, this new implementation will instead
link accounts more reliably at the risk of potential ban-evaders not yet being
linked together and thus being able to evade a ban.
This is a more preferable and reasonable risk. Active channel ops should be
able to catch any obnoxious ban-evaders that slip through this net.
Extremely minor rearrangement of interpreter logic so that `!commands` are
parsed before `command, botnick`. Totally not a bug at all. Pay no attention.
