v1.0.0

Top Level System

Un micronúcleo modular universal en C que conecta módulos hot-loadable mediante enrutamiento de mensajes basado en path. Todo es un path. Toda interacción es un mensaje.

28K+

Líneas de C

Módulos

Lenguajes

Interfaces

Código Fuente en GitHub Documentación Wiki

¿Qué es TLS?

Top Level System es un nuevo universo para crear soluciones y aplicaciones. El programa principal se llama portal porque es el punto de entrada — la puerta a través de la cual se accede a este universo. No se interactúa con los módulos directamente, no se llama a los lenguajes directamente, no se tocan los dispositivos directamente. Se entra por el portal, y el portal te lleva a donde necesites estar.

TLS es un núcleo que por sí solo no hace prácticamente nada. Carga módulos, enruta mensajes entre ellos mediante paths y gestiona su ciclo de vida. Servidores web, conectores de bases de datos, lectores de puertos serie, controladores IoT, agentes de IA, federation de nodos — todo es un module.

El núcleo proporciona:

Enrutamiento basado en path — búsqueda O(1) en hash table con fallback de comodines
Sistema universal de mensajes — una única estructura para toda la comunicación
ACL basado en etiquetas — grupos en usuarios, etiquetas en paths, intersección = acceso
Módulos hot-loadable — cargar, descargar y recargar en tiempo de ejecución con conteo de referencias
Event loop multiplataforma — libev integrado (epoll/kqueue/select)
Crash isolation de módulos — el núcleo sobrevive a segfaults de módulos
Trazabilidad de mensajes — trace_id, marca de tiempo y conteo de saltos en cada mensaje
Eventos pub/sub — suscripciones a eventos controladas por ACL con coincidencia de patrones

Top Level System ┌─────────────────────────────────────────────────┐ │ portal (el punto de entrada) │ │ CLI HTTP HTTPS TCP UDP SSH │ ├─────────────────────────────────────────────────┤ │ core (router + ACL + crash guard) │ │ paths · messages · labels · events │ ├─────────────────────────────────────────────────┤ │ modules (50 hot-loadable .so) │ │ web · node · iot · serial · cache · │ │ mqtt · email · cron · kv · audit ... │ ├─────────────────────────────────────────────────┤ │ logic engines │ │ Lua 5.4 · Python 3 · C (gcc) · Pascal │ ├─────────────────────────────────────────────────┤ │ federation │ │ node ↔ node ↔ node (TLS + hub) │ └─────────────────────────────────────────────────┘

Inicio rápido

Compilación

# Detectar bibliotecas y generar configuración
./configure

# Compilar core + 50 módulos
make clean && make

# Ejecutar 57 tests unitarios
make tests

# Instalar en /usr/local
make install

Crear una instancia

# Crear instancia (auto: puertos, certificados, usuarios, 50 configs de módulos)
portal -C myapp

# Iniciar en primer plano con depuración
portal -n myapp -f -d

# O mediante systemd
systemctl start portal-myapp

# Conectar CLI
portal -n myapp -r

Uso

# CLI — navegar como un sistema de ficheros
portal:/> ls
  core/  auth/  users/  groups/  events/  web/  node/  iot/  ...
portal:/> get /core/status
Portal v1.0.0 — running, 50 modules, 216 paths

# HTTP — cada path es un endpoint REST
curl http://host:8080/api/core/status
curl http://host:8080/api/iot/resources/devices
curl http://host:8080/api/node/resources/peers

# Nodos remotos — federation transparente
portal:/> get /remote-node/core/status
portal:/> get /remote-node/iot/resources/devices

Seis interfaces

TLS expone su sistema de paths a través de 6 interfaces simultáneas. Todas comparten los mismos paths, el mismo ACL y los mismos datos:

Interfaz	Protocolo	Descripción
CLI	UNIX socket	Shell interactiva con teclas de dirección, historial y autocompletado
HTTP	HTTP/1.1	API REST — cada path se convierte en un endpoint
HTTPS	TLS	REST cifrado con certificados autofirmados o personalizados
Core TCP	Wire protocol	Protocolo binario para integración directa
Core UDP	Wire protocol	Protocolo binario sin estado
SSH	SSH	CLI completa accesible desde cualquier cliente SSH

Tres backends de almacenamiento

Cada cambio se escribe en todos los backends activos simultáneamente:

Backend	Tipo	Descripción
`file`	Siempre activo	Ficheros de configuración en formato INI en el directorio de la instancia
`sqlite`	Opcional	Base de datos SQLite local en modo WAL
`psql`	Opcional	PostgreSQL remoto con tablas creadas automáticamente

Cuatro lenguajes de scripting

Escribe lógica de aplicación dentro del universo TLS usando cualquiera de estos lenguajes. Todos comparten el mismo sistema de paths, los mismos eventos y los mismos recursos:

Lenguaje	Motor	Funcionamiento
Lua 5.4	Intérprete integrado	En proceso, zero-copy. `portal.get()`, `portal.call()`, `portal.route()`
Python 3	Subproceso fork	Puente JSON pipe. `import portal`, misma API
C	gcc compile + dlopen	Velocidad nativa. Usa `portal.h` directamente
Pascal	fpc compile + dlopen	Free Pascal. Exporta `app_load`, `app_handle`

Cualquier lenguaje, un solo universo. Un script Lua, una aplicación Python, un module en C y un navegador ven todos los mismos paths, los mismos recursos y los mismos eventos. Al núcleo no le importa quién envió el mensaje — lo enruta, verifica el acceso y entrega la respuesta.

Conceptos clave

Todo es un path

Cada recurso tiene una dirección universal. Un puerto serie, una fila de base de datos, un dispositivo IoT remoto, una cuenta de usuario, un valor de configuración — todos residen en el mismo espacio de nombres:

/core/status                        # el propio núcleo
/iot/resources/devices              # dispositivos IoT en este nodo
/serial/com1/read                   # puerto RS232 físico
/cache/keys                         # caché en memoria
/remote-dc1/db/query                # base de datos en un nodo remoto
/warehouse/serial/com1/read         # puerto serie en una máquina remota

Todo es un mensaje

Una única estructura transporta toda la comunicación. Una petición para leer un puerto serie es idéntica a una petición para consultar una base de datos remota o conmutar un enchufe IoT:

portal_msg_t {
    id          // identificador único del mensaje
    path        // destino: "/module/resource"
    method      // GET, SET, CALL, EVENT, SUB, UNSUB, META
    headers     // metadatos clave-valor
    body        // carga útil (cualquier formato)
    ctx {       // viaja con cada mensaje
        auth    // usuario + etiquetas
        trace   // trace_id, marca de tiempo, saltos
    }
}

Los módulos se componen mediante mensajes

Los módulos nunca se llaman directamente entre sí. Envían mensajes a través del núcleo. Esto crea sistemas emergentes a partir de la composición:

cron dispara cada 30s → llama a /iot/functions/refresh → iot consulta todos los dispositivos Tapo → iot emite /events/iot/state_change → audit lo registra (suscrito a /events/*) → webhook envía HTTP POST → script Lua comprueba umbrales → si temp > 30: llama a /email/functions/send

Nadie orquestó esta cadena. Cada module hizo lo suyo. Los eventos los conectaron.