| 1 |
This file is mostly notes/ideas/etc of things I'll be doing/finishing. |
| 2 |
Some of the info in this file is out of date now, and just serves as a |
| 3 |
guideline as I get to things. -Toth |
| 4 |
|
| 5 |
core: |
| 6 |
implement YAML markup processor for saving/loading data |
| 7 |
|
| 8 |
redesign/rewrite config file code; |
| 9 |
have all modules save their config in wolfpack.conf instead of |
| 10 |
dozens of individual files. |
| 11 |
|
| 12 |
rewrite help code and move to wolfpack.tcl |
| 13 |
|
| 14 |
binds selectable in bind array based on eggdrop and/or tcl versions |
| 15 |
|
| 16 |
Module load order not matter; load modules, then handle their init proc? |
| 17 |
|
| 18 |
Add code to support different modules providing the same function: |
| 19 |
requires: {procname {module_name1 module_name2 module_name3}} |
| 20 |
|
| 21 |
Add an 'optional:' or 'recommended:' module option that does not require |
| 22 |
the function to be avialble; a counterpart to 'requires:' |
| 23 |
|
| 24 |
Add variable dependency tracking code along the lines of provides:/requires: |
| 25 |
optional: {procname {options}} |
| 26 |
options - {return "x"}; {script "x"} |
| 27 |
optional: fubar |
| 28 |
optional: {fubar {script {return [lindex $args 2]}}} |
| 29 |
optional: {fubar {return ""}} |
| 30 |
|
| 31 |
Handle circular dependency loops better: |
| 32 |
'moduleA' provides 'functionA'; requires 'functionB' |
| 33 |
'moduleB' provides 'functionB'; requires 'functionA' |
| 34 |
|
| 35 |
'.rehash' causes problems if version numbers are increased, |
| 36 |
hook to package forget? |
| 37 |
refresh command for wpconf |
| 38 |
finish CheckData.tcl code and merge |
| 39 |
bind load/unld module hooks to unload/load dependant tcl modules |
| 40 |
data input control proc for wpconf |
| 41 |
%b %u etc help substitution |
| 42 |
multiple lines of help text [split \n] with flag stuff |
| 43 |
enable/disable/load/unload/status/refresh in dcc:wpconf |
| 44 |
add botnet config extensions with bot bindings |
| 45 |
web based config extensions |
| 46 |
? usage reply proc for modules; shared usage info for all commands |
| 47 |
automatic distributed update system: |
| 48 |
fold this into part of wpconf |
| 49 |
send out updated modules to "subscribed" bots |
| 50 |
[logfile] wrapper and support for more/custom log levels |
| 51 |
|
| 52 |
other: |
| 53 |
ison/notify script, send info to idx, partyline, channel, email |
| 54 |
write standalone Tk app that connects to botnet to configure bots |
| 55 |
recreate peak chanstats / total joins script i had in 1.0 days |
| 56 |
logman [started] (lots of ideas ...) |
| 57 |
bottree to html (planning) |
| 58 |
url/email catcher: http/sort by |
| 59 |
seen module, hooks for other modules to use, flag/xtra field matching |
| 60 |
make moonphase and weather http code generic and merge into http module |
| 61 |
files from file area avaliable thru http |
| 62 |
|
| 63 |
alias: |
| 64 |
chon/chof type aliases |
| 65 |
|
| 66 |
auth: |
| 67 |
share auth across bots on the same channel that shared channel data |
| 68 |
|
| 69 |
bseen: |
| 70 |
finish conversion |
| 71 |
|
| 72 |
checkpass: |
| 73 |
filt binding for +user/adduser to create timestamp? |
| 74 |
would this be useful or would the automatic checking be sufficient? |
| 75 |
|
| 76 |
compat: |
| 77 |
compat:erasenotes, compat:listnotes - need to be finished] |
| 78 |
|
| 79 |
jester: |
| 80 |
case insensitive and '[ { \' fixes for channel names |
| 81 |
logging |
| 82 |
"main" channel group, and "list" channel group, main higher priority |
| 83 |
user channels from [channels] initially unless var is set to 1 |
| 84 |
ctcp version reply with contact info |
| 85 |
|
| 86 |
moonphase: |
| 87 |
rewrite - surely this doesn't work anymore? |
| 88 |
full time with moonphase data |
| 89 |
|
| 90 |
netserv: |
| 91 |
add time binding? |
| 92 |
|
| 93 |
portctrl: |
| 94 |
seems to be broken |
| 95 |
|
| 96 |
pubcmds: |
| 97 |
-whois needs improvement |
| 98 |
-kickban <nick|mask> [reason], configurable masking |
| 99 |
|
| 100 |
servman: |
| 101 |
UpdateServers trace problems with $servers variable |
| 102 |
traced server data has problems if server removed |
| 103 |
|
| 104 |
texttools: |
| 105 |
telnet/irc autoconversion of [b] [v] [u] [c #n] etc |
| 106 |
|
| 107 |
userinfo: |
| 108 |
add pub commands? |
| 109 |
|
| 110 |
userping: |
| 111 |
pub:ping - add msg and dcc commands |
| 112 |
|
| 113 |
weather: |
| 114 |
rewrite - surely this doesn't work anymore? |
| 115 |
|
| 116 |
wrpg: |
| 117 |
|
| 118 |
track/place user in the "clearing", locations, grid? elevation? |
| 119 |
|
| 120 |
stats based information, rather than hp/fp, etc |
| 121 |
dice weight set by "strength" stat for a particular animal, |
| 122 |
curve shifting as "hp" decreases? |
| 123 |
|
| 124 |
wrpg/foodcmds: |
| 125 |
finish rewrite |
| 126 |
-------------- |
| 127 |
count2 |
| 128 |
-bury * (?) |
| 129 |
-caught 'trout' broken |
| 130 |
-------------- |
| 131 |
|
| 132 |
wrpg/fooddata: |
| 133 |
finish rewrite |
| 134 |
|
| 135 |
wrpg/huntcmds: |
| 136 |
finish rewrite |
| 137 |
-------------- |
| 138 |
$huntinfo(channel); $animal == "" |
| 139 |
-chase [animal] |
| 140 |
-sniff [category] (category to number mapping) |
| 141 |
-------------- |
| 142 |
do away with user level against hunt level checking |
| 143 |
hunt level changed to hunt group |
| 144 |
register system for nicks involved in a hunt/nonpack too, etc? |
| 145 |
? autocaught is broken (still?) |
| 146 |
addhunt & chhunt: sanity checks for dice options |
| 147 |
listhunt; show dice options |
| 148 |
time_min_1 hunt timeout rework, make show real elapsed time etc |
| 149 |
endhunt rework, make show real elapsed time etc |
| 150 |
during dice roll during active hunt: |
| 151 |
if {($animal(hp_left) >= [expr $animal(hp_total) / 2]) && \ |
| 152 |
(($dice_rolls >= $max_dice_rolls) || \ |
| 153 |
($elapsed_time >= $max_elapsed_time))} then { |
| 154 |
putnot $huntinfo(channel) "The $huntinfo(animal) escapes with [grammar_check3 [grammar_check1 0 $huntinfo(hits_scored) hit]] scored out of $huntinfo(hits_total)." |
| 155 |
clear_hunt |
| 156 |
} |
| 157 |
calculate max_dice_rolls and max_elapsed_time based on animal's total hp |
| 158 |
|
| 159 |
wrpg/huntdata: |
| 160 |
finish rewrite |
| 161 |
|
| 162 |
wrpgfserv: |
| 163 |
probably scratch rewrite, integrate with new wrpg/ |
| 164 |
binding against !$nick |
| 165 |
|
| 166 |
wrpgnet: |
| 167 |
probably scratch rewrite, integrate with new wrpg/ |
| 168 |
channel number must be global channel, not local channel? |
| 169 |
3d grid type map, each "point" gets x:y:z (n/s/e/w/nw/ne/sw/se/u/d) |
| 170 |
channel number to map coordinates |
| 171 |
.map to display a clearing tree/map similar to .bottree |
| 172 |
consistant between bots? possible? |
| 173 |
|
| 174 |
wrpgpers: |
| 175 |
probably scratch rewrite, integrate with new wrpg/ |
| 176 |
remove hardcoded data |
| 177 |
moonphase howling at full moon |
| 178 |
bindings against *$nick* |
| 179 |
|
| 180 |
wrpgsound: |
| 181 |
probably scratch rewrite, integrate with new wrpg/ |
| 182 |
'bind join/part P|P, utimer, if {![onchan $nick]} then { ... }' |
| 183 |
use datafile for sound text (half done) |
| 184 |
|
| 185 |
misc other wrpg: |
| 186 |
eggdrop tcl http server on set port will display rpg bot structure |
| 187 |
bot/channel/clearing structure and assessment dates etc via http |
| 188 |
'.delfp/.delhp user n' (+FH stuff is crap) |
| 189 |
user data; multiple channels per bot packlist/data for each clearing |
| 190 |
hp/fp/commands/etc while in assessment ? |
| 191 |
.matchhunt/.matchfood/.matchas/.matchpack? |
| 192 |
don't change H/FPINFO1/2 for users with +H or +F |
| 193 |
|
| 194 |
wp botnet protocol / rpg botnet protocol: |
| 195 |
new bot links |
| 196 |
foreach bot [bots] {putbot $bot "are you a rpg bot?"} |
| 197 |
each rpg bot responds back to query if it is an rpg bot, with structure info |
| 198 |
bot creates list of rpg bots with structure info |
| 199 |
|
| 200 |
secure gain ops/invite/etc (similar to old authop code): |
| 201 |
opedbot in chan |
| 202 |
{ |
| 203 |
newbot joins chan |
| 204 |
newbot looks up opedbot in userfile |
| 205 |
newbot if hosts/etc match, and opedbot with name linked, |
| 206 |
newbot sends gainop request to opedbot |
| 207 |
} { |
| 208 |
newbot sends gainop request to botnet |
| 209 |
} |
| 210 |
opedbot looks up name of newbot |
| 211 |
opedbot sends back random line number from auth list encrypted with password |
| 212 |
newbot encrypt string found at line number with password |
| 213 |
newbot sends ack with encrypted string back to opedbot |
| 214 |
opedbot checks password encrypted string |
| 215 |
if match opedbot ops newbot |
| 216 |
|
| 217 |
-------------------------------------- |
| 218 |
1: |
| 219 |
|
| 220 |
Distributed botnet trust system |
| 221 |
|
| 222 |
Bottree: |
| 223 |
|
| 224 |
BotA |
| 225 |
|--BotB |
| 226 |
`--BotC |
| 227 |
`--BotD |
| 228 |
`--BotE |
| 229 |
|
| 230 |
-------------------------------------- |
| 231 |
2: |
| 232 |
|
| 233 |
BotA directly linked to BotB |
| 234 |
BotA initially trusts BotB level 'n' |
| 235 |
BotA sends greeting to BotB when it links; |
| 236 |
if BotB responds with proper credentials, BotA trusts BotB more |
| 237 |
else BotA trusts BotB less |
| 238 |
|
| 239 |
BotA directly linked to BotC |
| 240 |
BotA initially trusts BotC level 'n' |
| 241 |
BotA sends greeting to BotC when it links; |
| 242 |
if BotC responds with proper credentials, BotA trusts BotC more |
| 243 |
else BotA trusts BotC less |
| 244 |
|
| 245 |
BotA linked via BotC to BotD; initially trusts BotD level 'n - 1' |
| 246 |
BotA linked via BotC via BotD to BotE; initially trusts BotE level 'n - 2' |
| 247 |
|
| 248 |
-------------------------------------- |
| 249 |
3: |
| 250 |
|
| 251 |
BotA |
| 252 |
|--BotB |
| 253 |
`--Newbot |
| 254 |
|
| 255 |
Newbot links to BotA |
| 256 |
BotA sends Newbot a security challenge |
| 257 |
Newbot hashes the security challenge with a password and sends the result |
| 258 |
back to BotA |
| 259 |
BotA broadcasts 'Newbot trusted' |
| 260 |
BotA sets its trust for Newbot to '1' |
| 261 |
|
| 262 |
BotB sees 'Newbot trusted' and if it knows Newbot, sends it a security |
| 263 |
challenge |
| 264 |
Newbot hashes the security challenge with a password and sends the result |
| 265 |
back to botB |
| 266 |
BotB broadcasts 'Newbot trusted' |
| 267 |
BotB sets its trust for Newbot to '2'; 1 for BotB and 1 for BotA previously |
| 268 |
|
| 269 |
When 'Newbot trusted' is seen by BotA after BotB verifies the challenge, |
| 270 |
BotA increases the trust level for BotB 'n + 1' (or '1 + 1 = 2' in this |
| 271 |
example) |
| 272 |
|
| 273 |
-------------------------------------- |
| 274 |
4: |
| 275 |
|
| 276 |
Each bot must have a way to securely identify to at least one other bot in |
| 277 |
the botnet. This is possible by using a challenge request of a random string |
| 278 |
that is then hashed with the linking password. The linking password is the |
| 279 |
same on both bots when they link so [getuser PASS] can be used. |
| 280 |
|
| 281 |
When a new bot identifies to another bot, the bot that it identified to |
| 282 |
must confirm to other bots directly linked to itself that the new bot has |
| 283 |
identifed itself. Those bots can then issue their own challenges to the new |
| 284 |
bot if they have a user record for it. This is preferred over using a global |
| 285 |
broadcast, as it limits the number of challenges at any given moment. The |
| 286 |
number of challenges may increase as the bot tree branches if all other |
| 287 |
bots know the new bot, however common botnet structures usually have less |
| 288 |
than 2 or 3 dozen bots that all know each other. Even with a large botnet |
| 289 |
message flooding shouldn't be too much of a problem, as the new bot can |
| 290 |
regulate how fast it is sending out replies. Since the new bot could recieve |
| 291 |
multiple challenge queries when it answers a reply properly, it should answer |
| 292 |
challenge queries in the order in which it recieves them. |
| 293 |
|
| 294 |
All bots should tally and store all identy confirmations, even if the bot |
| 295 |
storing results from other bots does not yet know or have its own trust info |
| 296 |
for some bots. It may gain trust for a particular bot later, and should be |
| 297 |
able to immediately increase its level for the new bot when it learns it. |
| 298 |
|
| 299 |
-------------------------------------- |
| 300 |
5: |
| 301 |
|
| 302 |
BotA |
| 303 |
| |
| 304 |
|----BotB |
| 305 |
| |
| 306 |
|----BotC |
| 307 |
| |
| 308 |
`----NewBot |
| 309 |
|
| 310 |
BotA: |
| 311 |
Knows(BotA) (knows self - duh) |
| 312 |
Knows(BotB) |
| 313 |
Knows(BotC) |
| 314 |
Knows(NewBot) |
| 315 |
Trust(BotB) {BotA BotC} (2) |
| 316 |
Trust(BotC) {BotA BotB} (2) |
| 317 |
Trust(NewBot) {BotA} (1) |
| 318 |
|
| 319 |
BotB: |
| 320 |
Knows(BotA) |
| 321 |
Knows(BotB) (knows self - duh) |
| 322 |
Knows(BotC) |
| 323 |
Trust(BotA) {BotB BotC} (2) |
| 324 |
Trust(BotC) {BotA BotB} (2) |
| 325 |
|
| 326 |
BotC: |
| 327 |
Knows(BotA) |
| 328 |
Knows(BotB) |
| 329 |
Knows(BotC) (knows self - duh) |
| 330 |
Trust(BotA) {BotB BotC} (2) |
| 331 |
Trust(BotB) {BotA BotC} (2) |
| 332 |
|
| 333 |
NewBot: |
| 334 |
Knows(BotA) |
| 335 |
Knows(NewBot) (knows self - duh) |
| 336 |
Trust(BotA) {NewBot) (1) |
| 337 |
|
| 338 |
-------------------------------------- |
Parent Directory
| 
Revision Log
| 
Revision Graph