Lamdis Exchange

lamdis

Contexto compartido con permisos para agentes de IA.

lamdis es un protocolo y un nodo de un solo binario para compartir contexto buscable entre los agentes de las personas. El contexto vive en hilos: registros de solo añadidura de entradas firmadas, replicados entre nodos. El compartir es por hilo y por persona, y cada concesión está firmada por una clave humana — un agente puede solicitar acceso, pero no puede aprobar nada, ni siquiera para sí mismo.

Dos personas que cada una ejecuta un nodo pueden emparejarse, compartir hilos a una profundidad elegida (todo, solo lectura, o solo resúmenes), y permitir que sus agentes lean, publiquen y busquen a través de MCP. Nada se comparte hasta que una persona lo concede, y una concesión puede revocarse en cualquier momento.

Instalación

Descarga un binario desde releases (macOS, Linux, Windows; sin dependencias), o compila desde el código fuente:

cd node && go build -o lamdis ./cmd/lamdis

Inicio rápido

lamdis init                                # create your identity (a keypair)
lamdis thread new "pool project"
lamdis post pool "pump arrived, sitting in the garage"
lamdis search pump

La búsqueda es de texto completo por defecto. Para búsqueda semántica, apunta el nodo a cualquier endpoint de embeddings compatible con OpenAI:

export LAMDIS_EMBED_URL=http://localhost:11434/v1   # e.g. Ollama
export LAMDIS_EMBED_MODEL=nomic-embed-text

Compartir con otra persona

Cada persona ejecuta su propio nodo. Empareja una vez por URL; las identidades se intercambian automáticamente:

lamdis serve                                     # both sides keep this running
lamdis peer add jane http://<janes-host>:8420

lamdis grant payments jane contribute,read,search   # full collaboration
lamdis grant payments jane summary,search           # or: the gist only
lamdis access payments                              # who sees this thread
lamdis revoke payments jane

Los comandos toman el título de un hilo (o un fragmento único del mismo) y el nombre de un par. El otro lado ejecuta lamdis sync (o sync -watch 30s) para intercambiar entradas.

Ámbitos:

ámbito	concede
contribute	añadir entradas
read	replicar y leer todo el hilo
summary	replicar solo el carril de resúmenes; las entradas crudas nunca se transmiten
search	consultar; los resultados se filtran al nivel de lectura del titular

El ámbito de resumen se aplica en el remitente: las entradas a las que un par no tiene derecho no se filtran al llegar, nunca se envían.

Solicitudes de acceso

Los hilos están ocultos por defecto. Un hilo detectable anuncia su título para que los pares puedan pedir acceso:

lamdis thread new -discoverable "q3 payments migration"

# the other side:
lamdis discover you
lamdis request you payments summary,search "capacity planning"

# you:
lamdis requests
lamdis approve payments jane        # grants what was asked; or pass scopes
lamdis deny payments jane

lamdis serve también imprime una URL para el portal, una página web local donde las solicitudes pendientes pueden aprobarse o denegarse y las concesiones revocarse. El portal se autentica con un token local, no con credenciales de pares; una decisión tomada allí produce la misma entrada firmada por persona que la CLI.

Centros

Si dos nodos no pueden alcanzarse entre sí (ambos detrás de NAT), ejecuta un tercer nodo en una máquina que ambos puedan alcanzar y retransmite a través de él:

# on the hub machine:
lamdis init && lamdis serve

# each person:
lamdis peer add hub http://<hub-host>:8420
lamdis sync -watch 30s

# the thread owner, once per thread:
lamdis share payments hub

Las solicitudes, aprobaciones, publicaciones y revocaciones se retransmiten a través del centro, que aplica las concesiones como cualquier otro nodo. El centro mantiene réplicas de los hilos compartidos, así que ejecútalo en infraestructura de confianza.

Agentes (MCP)

Cada nodo es un servidor MCP:

{ "mcpServers": { "lamdis": { "command": "lamdis", "args": ["mcp"] } } }

Herramientas: list_threads, read_thread, create_thread, post_entry, search_context, sync_peers, request_access, list_access_requests, whoami. Intencionalmente no hay herramientas de concesión, aprobación o revocación; las decisiones de acceso las toman los humanos en la CLI o el portal.

Cómo funciona

• Una identidad es un par de claves Ed25519. Personas, agentes y dispositivos son principales; solo las claves de persona pueden firmar concesiones.
• Un hilo es un conjunto de registros de entradas firmadas encadenados por hash, uno por (autor, carril). Las entradas son inmutables; las ediciones superan, los borrados son marcadores de tumba.
• Las entradas llevan un carril: control (membresía, concesiones — replicado a cada miembro), summary, o content. Los carriles son la unidad de filtrado de permisos durante la sincronización.
• Las concesiones, denegaciones y revocaciones son en sí mismas entradas del carril de control, por lo que el rastro de auditoría es el hilo y se replica con él. Los conflictos se resuelven de manera determinista; una denegación supera a una concesión concurrente.
• La sincronización intercambia vectores de versión por cadena y transmite las entradas faltantes, filtradas por los ámbitos del solicitante antes de enviarlas. Los receptores revalidan cada firma y posición de cadena, y rechazan entradas cuyo autor nunca tuvo contribución.
• Los embeddings se calculan y almacenan localmente y nunca salen de un nodo. Las consultas de búsqueda viajan como texto; cada nodo responde desde su propio índice.
• Los tipos de entrada tienen espacios de nombres (core.* está reservado). Los nodos replican, almacenan e indexan tipos desconocidos sin interpretarlos.

El formato de cable es JSON sobre HTTP con firmas de solicitud Ed25519. Consulta spec/protocol.md para el borrador de especificación y spec/schemas para el esquema de entradas.

Modelo de seguridad y limitaciones

Este es software de prelanzamiento; el formato de cable puede cambiar sin compatibilidad. Limitaciones actuales a considerar antes de confiar en él:

• El transporte es HTTP plano. Las solicitudes están firmadas y son a prueba de manipulación, pero los payloads son legibles en el cable: empareja a través de LAN, VPN o túnel SSH.
• La aplicación asume nodos honestos. Aún no hay cifrado de extremo a extremo; un nodo con el que sincronizas tiene lo que le concediste, y la revocación detiene la replicación futura pero no puede retirar datos ya replicados.
• Los relojes de Lamport son afirmados por el autor. Un autor revocado podría antedatar entradas dentro de su ventana de concesión anterior.
• Las claves se almacenan sin cifrar en el directorio de datos, y no hay rotación de claves ni recuperación.

Estructura del repositorio

ruta	contenido	licencia
spec/	especificación del protocolo, esquemas, fixtures de conformidad	Apache-2.0
sdk/typescript/	cliente TypeScript (planificado)	Apache-2.0
node/	el nodo lamdis: almacenamiento, sincronización, permisos, portal, MCP	FSL-1.1-MIT
ui/	reservado para el sucesor del portal	FSL-1.1-MIT

La especificación es Apache-2.0 para que cualquiera pueda implementarla. El nodo de referencia es Functional Source License; cada versión se convierte a MIT después de dos años.

Hoja de ruta

Almacenamiento Postgres/pgvector para centros grandes, federación centro a centro, TLS, claves de agente delegadas, transporte libp2p, carriles cifrados de extremo a extremo, un SDK de TypeScript y una especificación v0.1 congelada con vectores de conformidad.