Lamdis Exchange

lamdis

Contexto compartilhado com permissões para agentes de IA.

lamdis é um protocolo e um nó de binário único para compartilhar contexto pesquisável entre os agentes das pessoas. O contexto vive em threads: logs somente de acréscimo de entradas assinadas, replicados entre nós. O compartilhamento é por thread e por pessoa, e cada concessão é assinada por uma chave humana — um agente pode solicitar acesso, mas não pode aprovar nada, inclusive para si mesmo.

Duas pessoas que cada uma executa um nó podem parear, compartilhar threads em uma profundidade escolhida (tudo, somente leitura ou apenas resumos) e deixar seus agentes lerem, postarem e pesquisarem via MCP. Nada é compartilhado até que uma pessoa conceda, e uma concessão pode ser revogada a qualquer momento.

Instalação

Baixe um binário em releases (macOS, Linux, Windows; sem dependências) ou compile a partir do código-fonte:

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

Início 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

A pesquisa é de texto completo por padrão. Para pesquisa semântica, aponte o nó para qualquer endpoint de embeddings compatível com OpenAI:

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

Compartilhamento com outra pessoa

Cada pessoa executa seu próprio nó. Pareie uma vez por URL; as identidades são trocadas automaticamente:

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

Os comandos usam o título de uma thread (ou um fragmento único dele) e o nome de um par. O outro lado executa lamdis sync (ou sync -watch 30s) para trocar entradas.

Escopos:

escopo	concede
contribute	anexar entradas
read	replicar e ler a thread inteira
summary	replicar apenas a faixa de resumo; entradas brutas nunca são transmitidas
search	consultar; os resultados são filtrados para o nível de leitura do titular

O escopo de resumo é aplicado no remetente: entradas às quais um par não tem direito não são filtradas na chegada, elas nunca são enviadas.

Solicitações de acesso

As threads ficam ocultas por padrão. Uma thread detectável anuncia seu título para que os pares possam solicitar acesso:

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 também imprime uma URL para o portal, uma página web local onde solicitações pendentes podem ser aprovadas ou negadas e concessões revogadas. O portal é autenticado por um token local, não por credenciais de pares; uma decisão tomada lá produz a mesma entrada assinada por pessoa que a CLI.

Hubs

Se dois nós não conseguem se alcançar (ambos atrás de NAT), execute um terceiro nó em uma máquina que ambos possam alcançar e faça o relay através dele:

# 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

Solicitações, aprovações, postagens e revogações são retransmitidas pelo hub, que aplica concessões como qualquer outro nó. O hub mantém réplicas de threads compartilhadas, então execute-o em infraestrutura em que você confia.

Agentes (MCP)

Todo nó é um servidor MCP:

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

Ferramentas: list_threads, read_thread, create_thread, post_entry, search_context, sync_peers, request_access, list_access_requests, whoami. Não há intencionalmente ferramentas de concessão, aprovação ou revogação; decisões de acesso são tomadas por humanos na CLI ou no portal.

Como funciona

• Uma identidade é um par de chaves Ed25519. Pessoas, agentes e dispositivos são principais; apenas chaves de pessoas podem assinar concessões.
• Uma thread é um conjunto de logs de entradas assinadas e encadeadas por hash, um por (autor, faixa). As entradas são imutáveis; edições substituem, exclusões são tombstones.
• As entradas carregam uma faixa: control (associação, concessões — replicada para cada membro), summary ou content. As faixas são a unidade de filtragem de permissões durante a sincronização.
• Concessões, negações e revogações são elas mesmas entradas da faixa de controle, então a trilha de auditoria é a thread e replica com ela. Conflitos são resolvidos deterministicamente; uma negação vence uma concessão concorrente.
• A sincronização troca vetores de versão por cadeia e transmite entradas ausentes, filtradas pelos escopos do chamador antes do envio. Os receptores revalidam cada assinatura e posição na cadeia, e rejeitam entradas cujo autor nunca teve permissão de contribuir.
• Embeddings são calculados e armazenados localmente e nunca saem de um nó. Consultas de pesquisa viajam como texto; cada nó responde a partir do seu próprio índice.
• Os tipos de entrada são namespaced (core.* é reservado). Os nós replicam, armazenam e indexam tipos desconhecidos sem interpretá-los.

O formato de transmissão é JSON sobre HTTP com assinaturas de solicitação Ed25519. Veja spec/protocol.md para o rascunho da especificação e spec/schemas para o esquema de entradas.

Modelo de segurança e limitações

Este é um software de pré-lançamento; o formato de transmissão pode mudar sem compatibilidade. Limitações atuais a considerar antes de confiar nele:

• O transporte é HTTP simples. As solicitações são assinadas e à prova de adulteração, mas os payloads são legíveis na transmissão: pareie em uma LAN, VPN ou túnel SSH.
• A aplicação pressupõe nós honestos. Ainda não há criptografia de ponta a ponta; um nó com o qual você sincroniza mantém o que você concedeu, e a revogação interrompe a replicação futura, mas não pode recuperar dados já replicados.
• Os relógios de Lamport são afirmados pelo autor. Um autor revogado poderia retrodatar entradas para dentro da sua janela de concessão antiga.
• As chaves são armazenadas sem criptografia no diretório de dados, e não há rotação ou recuperação de chaves.

Estrutura do repositório

caminho	conteúdo	licença
spec/	especificação do protocolo, esquemas, fixtures de conformidade	Apache-2.0
sdk/typescript/	cliente TypeScript (planejado)	Apache-2.0
node/	o nó lamdis: armazenamento, sincronização, permissões, portal, MCP	FSL-1.1-MIT
ui/	reservado para o sucessor do portal	FSL-1.1-MIT

A especificação é Apache-2.0 para que qualquer pessoa possa implementá-la. O nó de referência é Functional Source License; cada versão converte para MIT após dois anos.

Roadmap

Armazenamento Postgres/pgvector para hubs grandes, federação hub-a-hub, TLS, chaves de agente delegadas, transporte libp2p, faixas criptografadas de ponta a ponta, um SDK TypeScript e uma especificação v0.1 congelada com vetores de conformidade.