/[cvs]/wolfpack/TODO
ViewVC logotype

Contents of /wolfpack/TODO

Parent Directory Parent Directory | Revision Log Revision Log | View Revision Graph Revision Graph


Revision 1.10 - (show annotations) (download)
Mon Jan 17 07:51:54 2005 UTC (14 years, 9 months ago) by tothwolf
Branch: MAIN
Changes since 1.9: +2 -1 lines
*** empty log message ***

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

webmaster@eggheads.org
ViewVC Help
Powered by ViewVC 1.1.23