/[cvs]/wolfpack/TODO
ViewVC logotype

Contents of /wolfpack/TODO

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


Revision 1.12 - (show annotations) (download)
Fri Jan 28 10:48:08 2005 UTC (13 years, 10 months ago) by tothwolf
Branch: MAIN
CVS Tags: HEAD
Changes since 1.11: +7 -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 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 --------------------------------------

webmaster@eggheads.org
ViewVC Help
Powered by ViewVC 1.1.23