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.
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.
Sometimes people might join the channel uncloaked and get join-flood banned
with their uncloaked hostmask, and then later attempt to join the channel while
cloaked but the network will prevent them from joining since it checks their IP
address against the banlist in addition to their cloak.
Attempts to use unbanme while cloaked will look for a ban matching the cloak
instead of the IP address and will not find their uncloaked join-flood ban.
To fix this, we now traverse all known aliases/hostmasks for an individual
requesting a join-flood unban and remove any and all bans matching any of the
hostmasks linked to this individual.
PBot will now use weak links if the ip address portion of a hostmask
hasn't been seen in the last 48 hours in order to prevent false-positive
linking of dynamic ip addresses.
Weak links are excluded from ban-evasion logic.
Weak links can be manually upgraded to strong links with the `akalink`
command if a human confirms they are the same person through the `aka -w`
command.
Individuals with matching nicks or matching nickserv accounts, etc, will
automatically be strongly linked, as usual.
Improve linking of known aliases for users by using an aliases table
to track the linkages.
Improve check-bans implementation to use new aliases table for
significant performance gains and reduced resource usage.
to register handlers to listen for events.
Update IRCHandlers module to use new event dispatcher to dispatch
irc.events. Update several modules to register with dispatcher
to listen for irc.events.
Improve handling of reconnection upon unexpected disconnection.
Todo: update more things to use new event dispatcher logic.
