diff --git a/TODO b/TODO
--- a/TODO
+++ b/TODO
@@ -1,26 +1,18 @@
-Distrend.c FIXIT's, mostly for matt:
-
-1. Struct issues in frameset[frame_count]: frame_count isn't in scope, and defining obviously won't work. This is pretty crucial to the whole thing functioning. fixme!
-2. In the frame_finder, ya can't declare variables in for() loops. Unless we're in C99 mode. Which we arent.
-	Also, sframe, eframe, x, and frame_status are undeclared in the function. Or, rather, they aren't in the scope of the function. Make 'em args?
-3. status_report_generator has conflicting types.
+Master
+ -Add calls to remotio
+ -Write more meat into the pseudo-code main() to pull everything together
+ -Write a stub for getting info from the tarball/validifying the tarball. Read distren-job.xml, a file in the tarball, to find out 1. which rendering system to use (that system, e.g. blender/povray, can read more specifics, such as name of file to pass to blender and frames. Options common between different systems will be handled in common as best as possible)
+ -Write a stub for publishing file and constructing job description so that the job can be shared
 
-1. Create a CLI interface for distren
-	X command: distren
-	X args: -i infile.tar.bz2 -o outfile.tar.bz2 
-	action: submits and blocks and retreives result of rendering the contents of infile.tar.bz2. Should currently just call stub functions.
-	
-2. Design of stubs in distren library:
-   	X Stub for submitting file to server
-	WIP Write configuration loader
-	Stub for submitting file to a server (using a stream)
-	Stub for waiting for server -> Maybe the client can just poll? I've got to decide this.
-	Stub for retrieving result (using another stream)
+Slave
+ -Fix current bugs
+ -Add conf-file editing code where commented in register_user()
+ -Add calls to remoteio, once it works or even before it works
+ -Figure out how to get output back to the server!
+ -Add code to write arguments for exec_blender based on the contents of a job's xml file
 
-3. Design of stubs in distrend:
-	Stub for getting info from the tarball/validifying the tarball. Read distren-job.xml, a file in the tarball, to find out 1. which rendering system to use (that system, e.g. blender/povray, can read more specifics, such as name of file to pass to blender and frames. Options common between different systems will be handled in common as best as possible)
-	Storage of data + metadata: Stubs for unpacking tarball, assigning the submission an ID, and retrieving the file by the submission ID.
-	Actual rendering: Stub for calling subsystem's action that does the rendering. The subsystem should accept an XML fragment (a libxml subtree) that is specific to the subsystem. Ideally, subsystems will be both pluggable at both the dlopen() and link-time levels. dlopen may actually be easier than link-time pluggables...
-	Stub for submission of new jobs to be distributed (a subsystem rendering a file with multiples frames should generate a subjob for each frame)
-	Stub for publishing file and constructing job description so that the job can be shared
-
+Options
+ -Rewrite some stuff, try to make it simpler
+ -Move server and client confuse code into their individual files, rather than in the common file.
+ -Review all confuse interfacing
+ -Push patch for relative includes in confuse to the confuse developers
\ No newline at end of file