{
  "markdown": "# lamdis\n\nPermissioned shared context for AI agents.\n\nlamdis is a protocol and a single-binary node for sharing searchable context\nbetween people's agents. Context lives in threads: append-only logs of signed\nentries, replicated between nodes. Sharing is per thread and per person, and\nevery grant is signed by a human key — an agent can request access, but it\ncannot approve anything, including for itself.\n\nTwo people who each run a node can pair, share threads at a chosen depth\n(everything, read-only, or summaries only), and let their agents read, post,\nand search over MCP. Nothing is shared until a person grants it, and a grant\ncan be revoked at any time.\n\n![demo: two nodes, one permissioned thread](docs/demo.gif)\n\n## Install\n\nDownload a binary from [releases](https://github.com/lamdis-ai/lamdis/releases)\n(macOS, Linux, Windows; no dependencies), or build from source:\n\n```sh\ncd node && go build -o lamdis ./cmd/lamdis\n```\n\n## Quick start\n\n```sh\nlamdis init                                # create your identity (a keypair)\nlamdis thread new \"pool project\"\nlamdis post pool \"pump arrived, sitting in the garage\"\nlamdis search pump\n```\n\nSearch is full-text by default. For semantic search, point the node at any\nOpenAI-compatible embeddings endpoint:\n\n```sh\nexport LAMDIS_EMBED_URL=http://localhost:11434/v1   # e.g. Ollama\nexport LAMDIS_EMBED_MODEL=nomic-embed-text\n```\n\n## Sharing with another person\n\nEach person runs their own node. Pair once by URL; identities are exchanged\nautomatically:\n\n```sh\nlamdis serve                                     # both sides keep this running\nlamdis peer add jane http://<janes-host>:8420\n\nlamdis grant payments jane contribute,read,search   # full collaboration\nlamdis grant payments jane summary,search           # or: the gist only\nlamdis access payments                              # who sees this thread\nlamdis revoke payments jane\n```\n\nCommands take a thread's title (or a unique fragment of it) and a peer's\nname. The other side runs `lamdis sync` (or `sync -watch 30s`) to exchange\nentries.\n\nScopes:\n\n| scope | grants |\n|---|---|\n| `contribute` | append entries |\n| `read` | replicate and read the whole thread |\n| `summary` | replicate the summary lane only; raw entries are never transmitted |\n| `search` | query; results are filtered to the holder's read level |\n\nThe summary scope is enforced at the sender: entries a peer is not entitled\nto are not filtered on arrival, they are never sent.\n\n## Access requests\n\nThreads are hidden by default. A discoverable thread advertises its title so\npeers can ask for access:\n\n```sh\nlamdis thread new -discoverable \"q3 payments migration\"\n\n# the other side:\nlamdis discover you\nlamdis request you payments summary,search \"capacity planning\"\n\n# you:\nlamdis requests\nlamdis approve payments jane        # grants what was asked; or pass scopes\nlamdis deny payments jane\n```\n\n`lamdis serve` also prints a URL for the portal, a local web page where\npending requests can be approved or denied and grants revoked. The portal is\nauthenticated by a local token, not by peer credentials; a decision made\nthere produces the same person-signed entry as the CLI.\n\n## Hubs\n\nIf two nodes cannot reach each other (both behind NAT), run a third node on\na machine both can reach and relay through it:\n\n```sh\n# on the hub machine:\nlamdis init && lamdis serve\n\n# each person:\nlamdis peer add hub http://<hub-host>:8420\nlamdis sync -watch 30s\n\n# the thread owner, once per thread:\nlamdis share payments hub\n```\n\nRequests, approvals, posts, and revocations relay through the hub, which\nenforces grants like any other node. The hub holds replicas of shared\nthreads, so run it on infrastructure you trust.\n\n## Agents (MCP)\n\nEvery node is an MCP server:\n\n```json\n{ \"mcpServers\": { \"lamdis\": { \"command\": \"lamdis\", \"args\": [\"mcp\"] } } }\n```\n\nTools: `list_threads`, `read_thread`, `create_thread`, `post_entry`,\n`search_context`, `sync_peers`, `request_access`, `list_access_requests`,\n`whoami`. There are intentionally no grant, approve, or revoke tools;\naccess decisions are made by humans in the CLI or the portal.\n\n![demo: agents sharing context over MCP](docs/agent-demo.gif)\n\n## How it works\n\n- An identity is an Ed25519 keypair. People, agents, and devices are\n  principals; only person keys can sign grants.\n- A thread is a set of hash-chained, signed entry logs, one per\n  (author, lane). Entries are immutable; edits supersede, deletes are\n  tombstones.\n- Entries carry a lane: `control` (membership, grants — replicated to every\n  member), `summary`, or `content`. Lanes are the unit of permission\n  filtering during sync.\n- Grants, denials, and revocations are themselves control-lane entries, so\n  the audit trail is the thread and replicates with it. Conflicts resolve\n  deterministically; a deny beats a concurrent grant.\n- Sync exchanges per-chain version vectors and streams missing entries,\n  filtered by the caller's scopes before sending. Receivers re-validate\n  every signature and chain position, and reject entries whose author never\n  held contribute.\n- Embeddings are computed and stored locally and never leave a node. Search\n  queries travel as text; each node answers from its own index.\n- Entry kinds are namespaced (`core.*` is reserved). Nodes replicate, store,\n  and index unknown kinds without interpreting them.\n\nThe wire format is JSON over HTTP with Ed25519 request signatures. See\n[spec/protocol.md](spec/protocol.md) for the draft specification and\n[spec/schemas](spec/schemas) for the entry schema.\n\n## Security model and limitations\n\nThis is pre-release software; the wire format may change without\ncompatibility. Current limitations to weigh before relying on it:\n\n- Transport is plain HTTP. Requests are signed and tamper-evident, but\n  payloads are readable on the wire: pair over a LAN, VPN, or SSH tunnel.\n- Enforcement assumes honest nodes. There is no end-to-end encryption yet;\n  a node you sync with holds what you granted it, and revocation stops\n  future replication but cannot recall data already replicated.\n- Lamport clocks are author-asserted. A revoked author could backdate\n  entries into their old grant window.\n- Keys are stored unencrypted in the data directory, and there is no key\n  rotation or recovery.\n\n## Repository layout\n\n| path | contents | license |\n|---|---|---|\n| `spec/` | protocol specification, schemas, conformance fixtures | Apache-2.0 |\n| `sdk/typescript/` | TypeScript client (planned) | Apache-2.0 |\n| `node/` | the `lamdis` node: store, sync, permissions, portal, MCP | FSL-1.1-MIT |\n| `ui/` | reserved for the portal's successor | FSL-1.1-MIT |\n\nThe specification is Apache-2.0 so anyone can implement it. The reference\nnode is [Functional Source License](LICENSE); each release converts to MIT\nafter two years.\n\n## Roadmap\n\nPostgres/pgvector storage for large hubs, hub-to-hub federation, TLS,\ndelegated agent keys, libp2p transport, end-to-end encrypted lanes, a\nTypeScript SDK, and a frozen v0.1 specification with conformance vectors.\n",
  "bytes": 6997,
  "sha": "0b7a6f78c14eafcded2e194edcffec18b627ba9dd8070de343b8586020c425ff",
  "repo_slug": "lamdis-ai/lamdis-protocol",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/mcp_ai_lamdis_exchange_241a2a5d/readme"
}