/[cvs]/wolfpack/TODO
ViewVC logotype

Contents of /wolfpack/TODO

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


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

webmaster@eggheads.org
ViewVC Help
Powered by ViewVC 1.1.23