? fix tempban for nick -- looks fine
x fix triggers - users need to add exta column
! fix drop not to ban -- done, test it
! fix user count
* fix send_user_ip bug..
* have a look at tag parser and rules

* PERFORMANCE
	- faster nUtils::tUniqueHashArray::::iterator::operator++() or less calls => resisable hash arrays
	- OptOut ... takes time
	- delayed $Hello
	- usercollection separate SendToAll X CacheToAll (for profilinPurposes)
	- Less Log(int) in cAsyncConn::Write
	- cAsyncConn::Send right now or later ??? how long does it take to attempt sending when not ready??
x timer for reloadConfig
* PM, CTM antiflood to test
* multicommand
* extended trigger gestion (maybe plugin)
x auto include path info configure (acinclude.m4)
x win connchose iterator
* http://dcplusplus.sourceforge.net/wiki/index.php/UserCommand%20command
x chatfilter, diakritika plugin
* fix show_tags option
X bantest masks X enum
X fix range test
x nobase_include_HEADERS into makefile.am
x ops can use whatever characters in nick
* +hubinfo
x invalid tag .. limit_ratio better message
x fix gag (apply immediately , does not work)
x reg users no prefix needed
* reg user bug : http://czpro.no-ip.com/verliboard/index.php?showtopic=201&st=0&#entry860
* hidekickclass nefunguje
* nick prefix system (unallow..)

- ctm :protect random ips
- prikaz hideme (from userlists/oplist)
* finish the mean_measre
	- detect flooding
	- measure traffic
	- fix time outs
- allow list
* timeins like timouts
* $GetNetInfo
* $OpPlus ; $Ban Unban; $GetBanlist , $GetRegList, $tempBan $WhoIP, $Banned/$BanInfo
* $Supports
./ configurable commands that send files
x freezed user detection
* rights for commands
* connectome (test for ghosts)
* progressive myinfos sending
* public register bug

[13:54:34] Jaaa: karel.navratil: 1. ./ redirecty povolit od cheefa a vejs
karel.navratil: a logovat :)
karel.navratil: 4. kdyz je master zabanenej, aby to na nej neplatilo :)
karel.navratil: 5. u verlihubu dodelat !pm aby se dalo posilat jenom urcitejm lidem :)
karel.navratil: 6. ./ (!= bc_reply nick) u verlihubu dodelat prikaz !me nebo neco takovyho abych si to mohl na sebe preponout kdyz posilam broadcast a nekdo napise pres !oc ;)
karel.navratil: 7. kontrola na spamy .. kdyz nekdo posle stejnou pmku 3 a vice lidem tak aby ho to vyspamovalo a odpojilo a zabanovalo
8 registrace pres mail / generace hesla

* paypal message

before the last i'd prefer, if anything like this $SetVar <variable>$value| and
$GetVar <variable>| and maybe $GetVarList| ; $VarList var$$var$$var...$$|
[23:27:09] Verliba: but the first two, ok, i'll add it to todo list

* 0.9

* registered users ban specials
* remember ip's
* mysql interface
* split on server lib and dchub application
* multi thread
* equilibred binary tree / command rendering
* forwarding
* adreguser

* flood detection
* 0.9.5 - no more features
* 1.0 - public release

* send userlist per partes with delays - genialni idea
* statistics through command
*
[21:13:47] nexus:
zakazat  v nicku  .no-ip., .com, .ftp, .net

x zabudovat moznost vypnuti chatu (ne aby nechodil..ale aby proste neexistoval)...

x ./ udelat aby nastaveny hodnoty (sloty, huby, limitery) se kontrolovaly uz pri vstupu..takze by je to proste nepustilo....

neco typu volba lidu..paklize se 5lidi shodne..tak by mohli nejakym prikazem vyhodit treba spamera....IP tedle lidi by se samozrejme schovavalo do logu spolu s nickama...aby byla mozna zpetna kontrola...

hostname na vyssi vrstve programu. hub by hostname resil az v momente kdy by nejaky OP poslal request(ale to je spis ukol pro PPK..aby naucil svoje DC prekladat IPadresy na hostanames)


CHAT:

x vymyslet na chat neco co by koplo uzivatele paklize by vice nez 2x rekl stejnou hlasku po sobe...(je to v noci takze by to nezpomalovalo)... a interval by byla treba pulminuta

moznost jazykovy kontroly ..paklize by nekdo rekl vicekrat treba FUCK, NASRAT etc..tak by ho to koplo...

zvetsit mezeru v rikanych vecech alespon na 2sekundy

x ./ [20:21:42] nexus: tak bysme meli neposilat TAGy lidem...
x [21:19:19] nexus: este me napadlo: mame omezovac minimalniho poctu zadanejch pismenek do search??? protoze kdyz nekdo zada jenom tecku..tak to posle zbytecne strasny mnozstvi dat..
x [23:40:18] Jaaa: a zprav ten !getconfig :)
------

(2004-01-12 20:41:00) Jafra: Hoj, v hubu jsme objevili nasledujici bugy:
x (2004-01-12 20:42:00) Jafra: pak opravi duplikovani funkce, udelat korektni slinkovani pcre.h na <pcre/pcre.h> a taktez na pcreposix.h
x (2004-01-12 20:43:00) Jafra: dopsat cestu ke knihovnam -L/usr/lib/mysql
x (2004-01-12 20:43:00) Jafra: # do konfiguraku
(2004-01-12 20:43:00) Jafra: prolozit debug tabulek mysql, myslim pocatecni zalozeni
(2004-01-12 20:43:00) Jafra: bylo by dobre, pokud by ".verlihub/soubor" bylo treba v #define FILE_RULES ".verlihub/rules' v main.h
(2004-01-12 20:43:00) Jafra: jsou to drobne, ale zasadni opravy
(2004-01-12 20:44:00) Jafra: pokud chce s necim picnout, napis ... debug tabulek, pripadne full konfigurak se zakomentovanym nepotrebnym muzem taky, main.h taky, pokud si pk v cpp opravis hodnoty
(2004-01-12 20:44:00) Jafra: zatim


 FPRIVATE "TYPE=PICT;ALT=DCPlusPlus: HomePage"
 

Bloom Filter
One of the larger bandwidth consumers of a hub is search propagation, due to its frequency and broadcast nature. Bloom filters provide one method of mitigating that issue.
Bloom Filters and DC
Bloom filters are a way of summarizing the content of a set by hashing its elements' values into a specified codomain with a range designed to allow for easy manipulation, and enabling a bit in an array at the resulting index. They provide approximate set membership information. By applying this to a user's share, a hub can refrain from sending a search to that user when he's guaranteed not to respond due to a lack of matching files; Bloom filters may exhibit false positives but not false negatives.
Substring considerations
The description of bloom filters above neglects that DC's searches are of a (multiple, but that's not a problem) substring nature. Accordingly, the standard bloom filter will not function. This may be solved by splitting search terms into n-grams, these being all of the substrings of length n in a search term ("palindromes"'s n-grams might be palin, alind, lindr, indro, ndrom, drome, and romes for n = 5, for example). When adding a term to the bloom filter table, add all of those n-grams. When checking for a term's presence, check for all of the n-grams as well.
Optimal n-gram length
Simulations of varying values of n have shown that for diverse workloads, n = 5 is optimal, and n = 4 is quite close.
Interaction with hashes
Hashes behave quite differently than other DC search terms, in that they're not substrings. Thus, one should only insert the hashes of entire hash strings.
Hub-side treatment
A hub should store the Bloom filter tables for each connected client, and verify that that client might potentially respond to a search query before forwarding it a search. It should assume an initially completely-filled table, so that clients which don't send it a bloom filter still receive all searches.
Protocol Implementation
The client should specify in its Supports command that it supports bloom filtering. A hub wishing to use that to its advantage should then send reply with its own Supports noting that it too agrees to use Bloom filters, and (how precisely?) the (maximum?) size of the tables it's expecting to receive. From then on, any change in shares by the client should be signalled to the hub via (compressed? sure helps, and DC client-hub connections aren't otherwise compressed...) xor-updates from the last one sent.



 FPRIVATE "TYPE=PICT;ALT=DCPlusPlus: HomePage"
 

UserCommand command
The UserCommand command is used by hubs to put commands into the users context menu.
Syntax
$UserCommand <type> <context> <details>|
<type> is a positive integer describing the kind of command, where: 
0 = separator 
1 = raw 
2 = raw-nick-limited (same as raw with the exception that it should only be used once per %[nick]) 
255 = erase all sent commands 
<context> tells in which context the command should be shown, where: 
1 = Hub command (View hub rules for example, change own password)
this command should contain no 'somenick' arguments (i.e. not %[nick] but it may contain %[mynick] or %[line:blah]) 
2 = User command (Show someones stats for example, ban someone)
this command may take nick-specific arguments 
4 = User file command (Report bad file found for example)
this command may take nick- and file-specific arguments 
<details> differs per <type> 
type 0 (separator) and 255 (erase) leave this field empty 
type 1 (raw) uses <title>$<command> for the command title and the command itself
Furthermore, clients MAY support sub-menu's using the backslash (\) in <title>, like: <menuname>\<title>. If they do not support it, it will still look decent. (This scheme could also be used to create sub-sub-sub-menu's.) 
Higher numbers are reserved for future use.
Escaping
Escaping of dollar and pipe is necessary for the <command> in 'raw' mode. The DC++ escape sequence will be used. I.e. &#124; for pipe, &#36; for dollar and &amp; for the ampersand. Escapes are used for all fields before they're sent to the hub / shown to the user. Don't forget to add a pipe at the end of every command!
Contexts
The context number is a binary flag that can be combined with other numbers, i e a user command shown in chat and search has number (2 | 4 = 6).
Details
Separator
$UserCommand 0 <context> | 
Will add a menu separator (vertical bar) to the specified contexts (<context>). It is legal to add text (after the space) before the pipe, but it won't be used (yet).
Raw
$UserCommand 1 <context> <title>$<raw>| 
Will add a raw menu item with title <title> with command <raw>. This command MUST end with a &#124;, if not it SHOULD be discarded. The raw command may be used to specify multiple commands to be sent to the hub.
Raw-Nick-Limited
$UserCommand 2 <context> <title>$<raw>| 
Is exactly the same as Raw, except that the command should only be run once per %[nick]. This is to prevent the client from sending out more than one message that disconnects someone. Generally, this is only useful in the User-File context (e.g. viewing Search Results) where it is possible to select one user multiple times.
Erase
$UserCommand 255 <context> | 
Will erase all commands that the hub has sent previously. This is for hubs/scripts that allow for updates while running. The erase all is intentional, keeping it simple. Note that contexts must still be used, and that erasing will remove all commands that match any of those ORed contexts (i.e. 7 will remove commands previously sent with any context of 1 through 7) but only from that context
Examples
$UserCommand 0 7 | 
(should put a horizontal separator bar in the menu (1+2+4=7 for all contexts))
$UserCommand 1 1 View Rules$<%[mynick]> +rules&#124;| 
(reacts as if the user types +rules in mainchat, shows up in a hub command context)
$UserCommand 1 2 Register User$&#36;To: RegBot From: %[mynick] &#36;<%[mynick]> +reg %[nick] %[line:password]&#124;| 
(reacts as if the user sends +reg + arguments to the RegBot through PM)
$UserCommand 2 6 Kick$&#36;To: %[nick] From: %[mynick] &#36;<%[mynick]> You are being kicked!&#124;&#36;Kick %[nick]&#124;| 
(sends a PM with "You are being kicked!" to nick, and sends the $Kick command, shows up in search and chat, uses Raw-Nick-Limited to prevent multiple (redundant) kicks of one user)
$UserCommand 255 1 | 
(removes all commands in the hub context, also removing those that were sent with any mask which included the hub context, from the hub context commands. i.e., if you had some-command with context 7, you now have some-command with context 6)
TODO
Document the following:
The %[mynick], %[nick] and %[line:password] are DC++ specific, but they should form some standard. 





$UserCommand 1 1 View Rules$<%[mynick] +rules>|
$UserCommand 1 1 View Motd$<%[mynick] +motd>|
