Silo
← Newsroom
Blog

Announcing silo-node and the silo-buzz integration

Two new open-source projects — long-term memory for your Buzz workspace, and a One Silo node you run on your own hardware. Both Apache-2.0, both built on the open .silo file format.

By The One Silo team

Memory is the most personal data an AI system holds. Our position is simple: it should be yours — portable, inspectable, revocable, and, when you want it to be, entirely on hardware you own.

Today we're releasing two projects that put that position into code:

  • silo-buzz — a memory agent for Buzz, Block's open workspace where humans and AI agents work side by side.
  • silo-node — an open-source node that serves memory and local LLM traffic from your own machine, and can act as a private gateway to the One Silo platform.

Both are Apache-2.0. And both lean on silo-spec, the open specification for the exportable .silo file format — so nothing either project remembers is ever locked in.

Memory for Buzz

Buzz gets a lot right: every message is a cryptographically signed event, and agents join channels the same way coworkers do. But like every chat tool, conversation scrolls away. Decisions get re-litigated. Facts get re-asked. Context evaporates.

silo-buzz adds a memory agent to your workspace — a Buzz member with its own keypair that quietly distills your channels into durable, searchable memory, and answers with that memory when asked, across channels and across time:

#eng     <alice>  after the debate yesterday: we decided to ship the payments
                  migration on Friday, behind the flag

         ... the next day, in a different channel ...

#support <bob>    @silo what did we decide about the payments migration?
#support <silo>   Here's what I remember about "the payments migration":
                  1. [Decision] we decided to ship the payments migration on
                     Friday, behind the flag
                     — alice, 2026-07-25, event de579e4d

Every recalled memory cites its provenance — author, date, and the signed Buzz event it was distilled from — because in Buzz, everything is verifiable.

A few things we think matter about how it's built:

  • Conversation-aware capture. The agent doesn't guess at single messages. It buffers rolling turn windows per channel and captures whole episodes — speaker-attributed transcripts — so "yeah, let's do that" is remembered with the turns that give it meaning. The distillation and enrichment (entities, topics, relationships) happen in One Silo's pipeline, with full context.
  • Standard protocols only. To Buzz it speaks Nostr. To One Silo it's a standard MCP client, paired with the same OAuth flow ChatGPT, Claude, and Cursor use. Your agent shows up in your dashboard as a connection you can inspect, rate-limit, or revoke.
  • Shared silos. Memory lives in silos, and one agent isn't limited to one. Map channels to different silos, or point several agents — different workspaces, different machines, different keypairs — at the same silo for genuinely shared memory. #exec can keep a separate memory from #eng while one agent serves both.
  • The agent never rewrites memory on its own. When new information would replace something already remembered, it's surfaced for the owner to confirm — rewriting memory is your call, not the agent's.

There's an offline demo that runs with no account and no infrastructure — git clone, npm install, npm run demo.

A node of your own

silo-node is the other half of the story: a small, dependency-light Go binary that turns a machine you own — a Mac in your office, a home server, a container on your NAS — into part of your memory infrastructure.

A node runs in one of two modes:

  • Local (the default) — fully self-contained. Memory is stored on-device (SQLite, hybrid keyword + vector recall) and LLM inference runs on your machine via Ollama. Left alone, a local node never talks to the One Silo control plane — that's enforced in code, not just promised in docs.
  • Gateway — a private relay to One Silo. The node signs in with its own credential (a browser OAuth flow, the same pairing our apps use — it appears in your dashboard as a revocable connection) and exposes the cloud surface — cloud silos, connectors, the MCP gateway — to apps and agents on your network. Local clients authenticate to the node; they never hold cloud credentials at all.

Mode decides what a node relays. Whether it's reachable is a separate switch — so a purely local node can still answer from anywhere.

Reachable from anywhere, private by construction

Turn on remote access and your node — local or gateway — becomes reachable from your own authenticated apps everywhere, not just your LAN. The One Silo control plane does discovery and routing only: the connection between your app and your node is end-to-end encrypted, and the key is never ours to hold. Your memory and your local model are usable from your phone on the other side of the world, and the cloud in the middle sees ciphertext.

Pairing that remote connection used to mean scanning a QR code or hand-copying a 64-character key. Now it's automatic. Your app and node run an authenticated Diffie-Hellman handshake over the relay — the app's key lives in the device's Secure Enclave, the node's in a protected file on its own disk — and confirm it with a one-time 8-digit code shown on both ends. Match the code once and you're paired; the control plane relays only the public halves and never sees the session key. It's the same safety-number trust model Signal and WhatsApp use for multi-device, and it means "reachable from anywhere" costs you none of the privacy that made you run your own node in the first place.

Running a node locally is free, forever — on-device memory and local inference on your own hardware. Reaching it from anywhere through One Silo is included with any paid plan; see pricing.

And because nobody enjoys assembling infrastructure by hand, setup is one command:

./silo-node setup

The wizard asks two questions — which mode you want, and whether to make the node reachable from anywhere — then provisions the rest: it finds or downloads Ollama and pulls a model, sets up the admin token, opens a Cloudflare tunnel if you asked for remote access, and walks you through sign-in (you can create your One Silo account right in the flow). Re-running it is always safe.

The open thread: silo-spec

Both projects write memory into silos, and every silo exports to the open .silo file format, specified at onesilo/silo-spec.

That's not a footnote — it's the contract that makes the rest trustworthy. Your Buzz workspace's memory, your node's on-device silos, your cloud silos: all of it is yours to export, inspect, move, or take somewhere else entirely. An open format is what keeps "your memory" from quietly becoming "our database."

Better together: private distillation

The two projects meet in the middle, out of the box. Run a silo-node on the same machine as your Buzz agent and set one variable:

silo-node setup && silo-node     # once
DISTILL_MODE=node npm start      # the agent finds the node automatically

Now the distillation itself happens on your hardware: each conversation episode is distilled by the node's local model into standalone memory statements, and only those statements sync to your silo — raw transcripts never leave machines you own. If the node is down, captures buffer and retry; the agent never silently falls back to shipping raw conversation. For the privacy-conscious communities Buzz attracts, we think that's the right default.

Also on the roadmap: browserless agent pairing (letting a Buzz agent authenticate with the same Nostr key it signs messages with), memory recall for the other agents in your workspace, and backfill of channel history.

Build your own — the docs are the product

Here's the part we want to be held to: silo-buzz uses nothing private. It's a standard MCP client of the same surface every connector uses — OAuth pairing, get_scope discovery, silo_remember, silo_recall, silo_ask — all documented at onesilo.com/docs.

And as part of this release we put those docs through the strongest test we know: we rebuilt the integration from them and audited every documented request and response against the live API, down to the field names. The MCP quickstart's curl sequence now runs exactly as written — discovery, session handshake, first tool call — and every tool page shows the real wire shapes.

So if Buzz isn't your workspace, treat silo-buzz as a reference implementation. A Discord bot, a CLI, your own agent framework — the same quickstart gets any of them a silo, and the same dashboard gives your users the same control over it.

Get started

Give your Buzz workspace memory:

git clone https://github.com/onesilo/onesilo-buzz.git
cd onesilo-buzz && npm install
npm run demo       # offline, no account needed
npm run connect    # pair with your One Silo account
npm start

Run a node:

git clone https://github.com/onesilo/onesilo-node.git
cd onesilo-node && make build
./bin/silo-node setup
./bin/silo-node

Sign up at dashboard.onesilo.com — free to start. Both repos are developed in the open; issues and PRs welcome.


Buzz is a product of Block, Inc. silo-buzz is an independent integration and is not affiliated with or endorsed by Block.