diff --git a/README.md b/README.md
index 9e4e744..e58bc3e 100644
--- a/README.md
+++ b/README.md
@@ -1,21 +1,15 @@
 # NeoNucleus
 
 The core of NeoComputers.
+This repository has both NeoNucleus itself (NN) and the NeoNucleus Component Library (NCL).
 
-It provides:
-- the computer model and state implementation
-- architecture system
-- (NOT NOW) basic component implementations
-- (NOT NOW) standard emulator
-- (NOT NOW) some extra components
+These libraries provides:
+- the base architecture, with computer states (for running machines), components, architectures, etc.
+- (NCL) base component implementations for common ones (GPU/FS/tmpfs/EEPROM/etc.)
+- fine control over component limits, with default references
 
-The library does not provide:
-- The sandbox (equivalent to OpenComputer's `machine.lua`)
-- Default architectures
-- Default host interop (as in, the vtables that control the basic component's internals, such as the filesystem implementation)
-
-The emulator *will* (as its gonna be made after the engine is functional) provide:
-- A simple Lua sandbox
-- Very simple workspaces
-- Ocelot components for debug
-- Headless mode (single computer, uses actual terminal for a teletypewriter).
+They do not provide:
+- Networking implementation, so you need to pass vtables for all network-related components
+- Default architecture. While the testing emulator has a test version of the common Lua architecture seen in OpenComputers,
+it is not propely sandboxed nor safe. Neither NN nor NCL provide any architectures.
+-  
diff --git a/TODO.md b/TODO.md
index 9981242..44e3103 100644
--- a/TODO.md
+++ b/TODO.md
@@ -1,19 +1,19 @@
 # For MVP functionality
 
-- finish `eeprom` class and volatile eeprom 
-- `filesystem`, `drive`, `gpu`, `screen` class implementations
-- `ncomplib` with reference component implementations (depends on libc)
+- `gpu`, `screen` class implementations
 - write a tester OS, basically a menu with tests to run
-- volatile drive
-- volatile filesystem
+- move veeprom into NCL as tmpeeprom
+- tmpdrive
+- tmpfs
 - device info
+- userdata support
 
 # To re-evaluate
 
-- More stack manipulation functions to allow libraries to have better APIs.
+- Exposing the internal non-resizing hashmap implementation.
+- More stack manipulation functions to allow libraries to have better APIs. (rotate)
 - Having a copy of the context stored directly in requests instead of having to use getComputerContext, as it simplifies the APIs and allows them
 to be made more portable.
-- Exposing more context wrappers than just the memory allocation functions.
 - Exposing more internal functions that may be useful to the user to prevent pointless rewriting and duplicate machine code.
 
 # Vanilla components needed
@@ -23,6 +23,7 @@ Not everything OC has (as a few of them are really MC-centered) but most of it.
 - `data` component (note: maybe add hamming code support?)
 - `modem` component
 - `tunnel` component
+- `internet` component
 - `relay` component (note: OCDoc still refers to it as `access_point`)
 - `computer` component
 - `geolyzer` component