TC$mC$ on poikkeuksellisen vahva ja hyvin jC$sennelty RFC-luonnos. Se
tunnistaa oikein useita hajautettujen jC$rjestelmien sudenkuoppia, erityisesti
sen, ettC$ identiteetti ja valtuudet (authority) ovat kaksi eri asiaa, ja
ettC$ V8:n peruskontekstieristys (esim. Node.js vm-moduuli) ei riitC$
tietoturvalliseksi hiekkalaatikoksi.
Node.js on erinomainen tyC6kalu tC$mC$n MVP:n (Minimum Viable Product) nopeaan
iterointiin, koska se tukee asynkronista I/O:ta, kryptografiaa ja joustavaa
datan kC$sittelyC$ suoraan ytimessC$C$n.
TC$ssC$ on konseptisuunnitelma ja tiekartta, jolla tC$mC$ RFC kC$C$nnetC$C$n
kC$ytC$nnC6n Node.js-toteutukseksi.
NodeJS MVP Konseptisuunnitelma
Koska kyseessC$ on MVP, meidC$n on rajattava monimutkaisuus vain niihin
ominaisuuksiin, jotka todistavat UNIVERSE-arkkitehtuurin ydinteesin:
Identiteetti 
eq Valtuus 
eq Topologia.
1. Teknologiavalinnat (Node.js Ekosysteemi)
MVP-vaiheessa kannattaa vC$lttC$C$ omien protokollien kirjoittamista alusta
alkaen ja hyC6dyntC$C$ olemassa olevia, testattuja kirjastoja:
 * Identiteetti & Kryptografia: Node.js sisC$C$nrakennettu crypto-moduuli. Se
tukee suoraan Ed25519-avaimia (crypto.generateKeyPairSync('ed25519')).
 * Envelopen serialisointi: cbor-x (erittC$in nopea ja tukee kanonista
CBOR-muotoa, joka on kriittinen allekirjoitusten validoinnissa).
 * Reititys & Viiveensieto (DTN-jono): Paikallinen persistenssi SQLite:lla
(better-sqlite3). Se on nopea, lokaali ja turvallinen kaatumisille
(crash-safe), mikC$ tC$yttC$C$ RFC:n vaatimuksen kirjekuorien (envelopes)
sC$ilyttC$misestC$.
 * State Registry (CRDT): yjs tai @automerge/automerge. NC$mC$ ovat valmiita,
verkkoagnostisia CRDT-toteutuksia, jotka ratkaisevat konfliktit
automaattisesti.
 * Secure Sandbox: isolated-vm (tarjoaa oikean V8 Isolate -eristyksen,
muistirajat ja CPU-rajat) TAI puhdas WebAssembly-ajonaikainen ympC$ristC6
(node:wasi), jotta ulospC$C$sy kC$yttC6jC$rjestelmC$C$n on estetty.
2. MVP:n Arkkitehtuurin Rajaus
MVP:ssC$ rakennamme kolmen solmun verkon (Node A, Node B, Guardian C) ja yhden
"Airgap"-kuriirin (simuloidaan USB-tikulla tai paikallisella kansiolla).
 * Node A (LC$hettC$jC$): Luo Intentin (esim. "report_uptime") ja paketoi sen
Envelopeen.
 * Airgap-kuriiri: Node.js-skripti, joka lukee Envelopen Node A:n
tietokannasta tiedostoon, ja siirtC$C$ sen fyysisesti/loogisesti Node B:lle.
 * Node B (Vastaanottaja): Vastaanottaa tiedoston, validoi Ed25519-allekirjoitu
ksen, tarkistaa Capability-tokenin (saatu Guardian C:ltC$) ja suorittaa
JIT-moduulin hiekkalaatikossa.
Kehityksen Tiekartta (Roadmap)
Seuraava tiekartta seuraa RFC:n virstanpylvC$itC$, mutta soveltaa ne suoraan
Node.js-ohjelmistokehityksen vaiheiksi.
 * Vaihe 1: Identiteetti ja kirjekuori (RFC M1)
   Viikot 1-2
   Tavoite: Luodaan perusrakenteet kryptografialle ja viestien validoinnille.
   * Toteutetaan Node.js-moduuli avainten generointiin ja hallintaan
(Ed25519).
   * Luodaan Envelope-skeeman TypeScript-mC$C$rittelyt.
   * Toteutetaan funktiot Envelopen kanonisoimiseen, CBOR-koodaukseen ja
allekirjoittamiseen.
   * Testi: Solmu pystyy luomaan Envelopen, joka hylC$tC$C$n automaattisesti,
jos sen ttl on vanhentunut tai allekirjoitus ei tC$smC$C$ dataan.
 * Vaihe 2: DTN-Reititin ja Jono (RFC M1-M2)
   Viikot 3-4
   Tavoite: Rakennettaan viiveensietoinen (Delay-Tolerant) lokaali jono.
   * Otetaan kC$yttC6C6n better-sqlite3 Envelopien tallennukseen (tilat:
QUEUED, FORWARDING, EXPIRED).
   * Toteutetaan yksinkertainen "Airgap"-transport: reititin vie jonossa
olevat viestit .universe-pC$C$tteiseksi binC$C$ritiedostoksi levylle.
   * Toteutetaan funktio, joka lukee kansion sisC$llC6n, parsii tiedostot
Envelopeiksi ja validoi ne.
 * Vaihe 3: Turvallinen Hiekkalaatikko (RFC M3)
   Viikot 5-6
   Tavoite: Intentien suorittaminen turvallisesti eristetyssC$
ympC$ristC6ssC$.
   * Konfiguroidaan isolated-vm luomaan puhdas JavaScript-konteksti ilman
require, fs tai net -pC$C$syjC$.
   * Rakennetaan "brokered syscalls": hiekkalaatikosta voi kutsua vain ennalta
mC$C$riteltyjC$ asioita (esim. router.send() tai state.readUptime()).
   * MC$C$ritellC$C$n JIT-moduulin manifesti JSON-muodossa.
 * Vaihe 4: Capability Tokenit ja Guardian (RFC M5 & M7)
   Viikot 7-8
   Tavoite: LisC$tC$C$n Zero-Trust -valtuutusmalli.
   * Luodaan kolmas solmu (Guardian), joka generoi allekirjoitettuja
Capability-tokeneita (esim. oikeus reitittC$C$ tiettyyn Dark Mesh -solmuun).
   * Muutetaan Reitittimen logiikkaa: se kieltC$ytyy hyvC$ksymC$stC$
"Airgap"-tiedostoa, jos lC$hettC$jC$llC$ ei ole pC$tevC$C$ Capability-proofia
sisC$llytettynC$ Envelopeen.
Suositukset ensimmC$isiin koodiriveihin
Kun aloitat toteutuksen, suosittelen vahvasti TypeScriptin kC$yttC6C$.
RFC:ssC$ esitellyt skeemat (Envelope, Token, Manifest) hyC6tyvC$t
merkittC$vC$sti staattisesta tyypityksestC$, ja se estC$C$ monia
serialisointivirheitC$ CBOR/JSON-rajapinnoissa.
KC$ytC$ rakenteena puhdasta modulaarista arkkitehtuuria, joka heijastaa RFC:n
lukua 6:
src/
 identity/       # Avaimet, allekirjoitukset, H(pubkey) derivointi
 envelope/       # CBOR pakkaus, kanonisointi, skeemat (Zod/TypeBox)
 router/         # SQLite DTN-jonot, airgap-lukija/kirjoittaja
 sandbox/        # isolated-vm instanssit ja syscall-vC$littC$jC$t
 state/          # Yjs CRDT -instanssit