Bantracker Specification
== Blueprint ==
=== Features ===
==== Ban parsing ====
===== Brief =====
Bantracker should parse channel MODE +b/+q/-b/-q messages and add/modify entries in the database accordingly.
===== Details =====
The Bantracker should understand simple ''nick!user@host'' style bans, as well as CIDR and "Extban" style bans.
====== Extban ======
The way to identify an Extban is that it begins with a '$', optionally followed by an '~' to invert its meaning, optionally a ':' to indicate some data follows it.
 "$" ( "~" | ) ( "a" | "r" | "x" ) [ ":" [ data... ] ]
On [http://freenode.net/ freenode] these ''extbans'' are as follows:
{| style="width: 100%; text-align: left"
! Type character
! Data is required
! Type of data
! notes
|-
| a
| false
| <nowiki>NickServ</nowiki> account
| Match any user logged into the <nowiki>NickServ</nowiki> account '''account'''. '''account''' is optional, "$a" would be equivalent to "$a:*" and matches any identified user, and the inverse ("$~a" and "$~a:*") matches any unidentified user.
|-
| r || true || real name (<nowiki>GECOS</nowiki>) || Match any user with the real name (or <nowiki>GECOS</nowiki>) that matches the data.
|-
| x || true || full ''nick!user@host#gecos'' match || This will match any user whos prefix (nick!user@host) and <nowiki>GECOS</nowiki>, joined with a "#" symbol, matches the mask in the data.
|}
====== CIDR ======
<nowiki>CIDR</nowiki> masks are also accepted, for instance:
{| style="width: 100%; text-align: left;"
! <nowiki>CIDR</nowiki> mask
! Start of range
! End of range
|-
| 192.0.0.0/8 || 192.0.0.0 || 192.255.255.255
|-
| 192.168.0.0/16 || 192.168.0.0 || 192.168.255.255
|-
| 192.168.1.0/24 || 192.168.1.0 || 192.168.1.255
|}
Those are only the most simple forms. See the [http://www.subnet-calculator.com/cidr.php this CIDR calculator] for some more complex forms.

==== Logging ====
===== Brief =====
Bantracker should log all channel activity in a channel, including MODEs, JOINs, NICKs, PRIVMSGs, NOTICEs, and CTCPs. It should recognise MODEs adding or removing mode "b" and mode "q". When Bantracker sees a KICK, or detects a /remove (special kind of forced PART message), it should log that action in the database appropriately.
===== Details =====
Bantracker currently keeps an in-memory 200 line log for each channel it's in where Bantracker is enabled. It then inserts a copy of that log into the database for <u>every</u> +b/+q/kick/remove action taken.
==== Ban Scoring ====
===== Brief =====
Scoring bans would help to maintaining large list of bans, where bans with low scores are candidates for removal and bans with high scores are worth keeping. Operators can review and raise a ban's score, while it decreases as the ban grows older.
===== Details =====
(Ban scoring implementation) TODO

==== Ban grouping ====
===== Brief =====
If someone has been banned more than once, the BT should be able to group that ban with others of matching criteria. 
===== Details =====
If someone has been banned more than once, the BT should be able to group that ban with others of matching criteria. This criteria could be IP, ident, nick, provider etc.