MALLA CERRADA
Firewall por proceso. Apps en sandbox.
Cada byte que sale de Aether pasa por el proceso main. Las apps en sandbox no tienen capacidad de red en crudo. La salida queda registrada.
space-os · Seguridad
Cadena abierta. Malla cerrada.
Dos zonas de confianza, trazadas a propósito. La cadena pública está abierta a cualquiera. Tu malla personal — desktop, móvil, inferencia, peers emparejados — está cerrada a integraciones externas. La frontera se hace cumplir en el runtime, no solo por política.
01 · Frontera
Cadena abierta. Malla cerrada.
space-os tiene dos zonas de confianza distintas. La cadena pública es sin permisos — cualquiera despliega contratos, cualquiera ejecuta nodos, cualquiera audita el tráfico. La malla personal — tu Aether desktop, móvil emparejado, llamadas de inferencia, superficie Hyperworld — está cerrada. Solo tus dispositivos emparejados se hablan entre sí. Solo apps en sandbox se ejecutan dentro. La frontera se hace cumplir en el runtime, no solo por política.
- Cadena pública — abierta, sin permisos, auditable
- Malla personal — solo dispositivos emparejados, sin integraciones externas
- Las apps de la Desktop App vienen de nosotros; los widgets y nodelets vienen de cualquiera
- Frontera aplicada en el runtime, no solo por política
02 · Firewall del desktop
Cada byte que sale de Aether queda contabilizado.
Aether viene con un firewall de red por proceso dentro del runtime del desktop. Cada petición saliente — del agente, de una app en sandbox, de una skill — pasa por el proceso main. Las apps en sandbox no tienen capacidad de red directa; llaman a herramientas del host que pasan por signed-fetch con tus claves. La salida queda registrada; los destinos sospechosos aparecen en Ajustes.
- Monitorización de salida por proceso dentro del runtime
- Las apps en sandbox no tienen capacidad de red en crudo
- Todas las llamadas salientes pasan por main → signed-fetch con tus claves
- El log de salida muestra destinos inesperados
- Allowlist por defecto; deny ante anomalía
03 · Timelock de rollover
Si algo no encaja, bloqueamos las claves.
Un timelock de rollover protege todo lo que toca claves o saldos. Tras un umbral de inactividad o ante una anomalía detectada — volumen súbito de transacciones, destinos inusuales, dispositivo inesperado — la capacidad de firma se autosuspende. Hace falta reautenticación para reanudar. Los cambios de política son a su vez timelock: cualquier regla nueva espera la ventana de rollover antes de surtir efecto, así ningún dispositivo puede relajar la seguridad en silencio.
- Timer de inactividad autosuspende la capacidad de firma
- Detector de anomalías se dispara por volumen de tx, destinos, nuevos dispositivos
- Reautenticación requerida para reanudar — passphrase o llave hardware
- Los cambios de política son a su vez timelock
- Visa Stamps revocables por app, por dispositivo, al instante
04 · Monitorización de la malla
La malla WireGuard son peers emparejados, monitorizados.
Los dispositivos emparejados ejecutan una malla WireGuard. Los túneles se levantan a demanda y se registran en relays. Las llamadas peer-RPC entre dispositivos van por allowlist por herramienta — tu móvil puede pedir una búsqueda usando la IP residencial de tu desktop solo porque le concediste esa capacidad. Monitorizamos el tráfico de relay buscando patrones de abuso: cuentas de peer inusuales, intentos de replay, churn de túneles. Los dispositivos externos no pueden enrutarse a la malla — no hay ingress público.
- Túneles WireGuard con registro automático en relays
- Allowlists peer-RPC por dispositivo, por herramienta
- Ancho de banda, estadísticas de paquetes, salud del peer visibles en Ajustes
- Tráfico de relay monitorizado por patrones de abuso
- Sin ingress público — los dispositivos externos no pueden enrutarse hacia dentro
05 · Sandbox de inferencia
Los proveedores de modelos ven prompts. No te ven a ti.
Las llamadas de inferencia — locales o enrutadas por SpaceRouter — están aisladas de la malla. Los proveedores reciben la carga del prompt y devuelven tokens; no pueden llamar de vuelta a la malla, no pueden enumerar dispositivos emparejados, no pueden leer memoria ni estado de cartera. Los recibos del proveedor se firman solo para facturación. El manifiesto de capacidad que un nodo proveedor anuncia es el contrato — todo lo que esté fuera se rechaza en el relay.
- Los nodos proveedor reciben solo prompts — sin acceso a la malla
- Sin callbacks salientes desde la inferencia hacia tus dispositivos
- Recibos firmados de facturación; nada más se devuelve
- Los manifiestos de capacidad regulan qué trabajo puede asumir un proveedor
- Las claves API son scoped, rotables y revocables desde Aether
06 · Apps frente a widgets
Las apps vienen de nosotros. Los widgets vienen de cualquiera.
La Desktop App ejecuta apps de la App Store — solo de primera parte. Nosotros publicamos, nosotros firmamos, nosotros auditamos. Los widgets y nodelets son la capa abierta: cualquiera puede crear, publicar e instalar uno, pero corren con capacidad fuertemente reducida — sin fetch en crudo, sin llamadas a la cadena, sin peer-RPC salvo concesión explícita. Los tintes de seguridad por skill siguen los datos por el runtime; la búsqueda en el registro es remota e inspeccionable.
- Apps — publicadas solo por nosotros, firmadas y auditadas
- Widgets y nodelets — capa abierta, cualquiera puede publicar
- Los widgets corren en sandbox: sin fetch en crudo, sin cadena, sin peer-RPC
- Tintes de seguridad por skill siguen los datos por el runtime
- Búsqueda en registros remotos — cada widget inspeccionable antes de instalar
07 · Cadena pública
Sin permisos. Auditable. Spec abierta.
La cadena es lo opuesto a la malla. Cualquiera despliega contratos en la EVM integrada. Cualquiera ejecuta validadores, proveedores o relays bajo el Open Node Protocol. Cualquiera audita el explorador. El modelo de amenazas on-chain es "el código es la ley" — el mismo que Ethereum. Los fondos y la identidad están protegidos por tus claves, alojadas en KIS en un dominio de confianza separado. Comprometer un servicio de la red no puede mover fondos sin cruzar la frontera de confianza.
- Contratos sin permisos — cualquiera despliega en la EVM
- Nodos sin permisos — el Open Node Protocol es la spec
- KIS sostiene claves en un dominio de confianza separado
- Modelo de tres carteras — connected · proxy · native
- Block explorer público para cada transacción
08 · Custodia de claves
Las claves viven en KIS. La región te sigue.
Las claves de cartera se alojan en KIS — el Key Issuing Service — un proceso Rust en un dominio de confianza separado. Las claves nunca aparecen en la app API, en logs ni en backups fuera de KIS mismo. El modelo de cuatro modos mapea a dónde vive realmente la clave: Modo 0 (un pod central), Modo 1 (pods regionales en tu jurisdicción — UE o EE. UU. — para residencia de datos MiCA / GDPR), Modo 2 (tu Aether desktop, Fase 2), Modo 3 (umbral / MPC, Fase 3). El Modo 1 no tiene failover entre regiones por política — la residencia tiene precedencia sobre la disponibilidad. Cuando cambias de jurisdicción, una ceremonia criptográfica X25519 + ChaCha20Poly1305 mueve la clave entre pods regionales sin que el relay vea claro nunca.
- Cuatro modos de custodia — central → regional → user-hosted → umbral
- Pods regionales del Modo 1 en UE + EE. UU. — las claves se quedan en jurisdicción
- Ceremonia de migración entre regiones — sobre cifrado, el relay no puede descifrar
- Modo 2 user-hosted — sidecar en Aether desktop; las claves nunca cruzan a nuestros servidores
- Migración soberano-a-soberano de dispositivo (Fase 2.5) — ambos extremos bajo control del usuario
- Hook de notificación a counsel — registro de cambios de custodia por encima del umbral
- Sin failover entre regiones — residencia sobre disponibilidad, por diseño
- Patrón de proxy-contract (Safe + AllowanceModule) para firma delegada
Modelo de amenazas
Dos zonas. Una identidad. Tus claves, tu decisión.
La cadena es pública a propósito. Tu malla está cerrada a propósito. Lo que cruce la línea — una app en sandbox pidiendo red, un proveedor de inferencia pidiendo callback, un dispositivo nuevo pidiendo unirse — debe pasar primero la frontera.