Buzz Mesh: When the Community Runs the Model

A few weeks ago, I wrote about the unused computing power all around us. The idea was a kind of compute smart grid: people, teams, or regional communities voluntarily provide spare capacity, others use it, and not every AI request automatically ends up in a data center run by the same large providers.

At the time, this was mainly an architectural idea. Buzz now shows what a first, surprisingly concrete building block could look like. The project combines a shared workspace for people and AI agents with Nostr identities and a compute pool inside its own community. One member can provide a local model that other members’ agents use. In the broader vision, several devices could even hold parts of a model that fits on none of them individually.

That sounds very much like our earlier idea. But Buzz should not be made either smaller or bigger than it currently is. This is not a global AI supercomputer, and unused RAM does not suddenly become magical shared memory. Buzz first creates a trust-based cell. That may be the more sensible place to begin.

What Buzz Actually Is

Buzz is an open-source project from Block, the company behind Square led by Jack Dorsey. It would still be inaccurate to describe Buzz simply as “Jack Dorsey’s new app.” It is developed as a Block project, and its public source code is available on GitHub under the Apache 2.0 license.

At first glance, Buzz looks like a mixture of Slack, GitHub, and an agent platform. People and AI agents work in the same channels, discuss tasks, manage code, and trigger workflows. Agents receive their own cryptographic identity and narrowly defined permissions. This makes it possible to distinguish the person who authorized an action from the agent that actually performed it.

That is more than cosmetic user management. In many current agent systems, a bot simply uses a shared service account or an API key with excessive privileges. Afterwards, we may know that “the automation” did something, but not always which instance acted under which instruction. Buzz aims to make authorization and authorship separately visible.

The workspace can be self-hosted. Its published architecture is not a mysterious peer-to-peer cloud but a set of familiar components: a Buzz Relay, PostgreSQL for events and search, Redis for Pub/Sub and presence, and S3-compatible media storage. I like that pragmatism. Decentralization does not become more credible by hiding operational reality.

Nostr Is the Foundation

Nostr stands for Notes and Other Stuff Transmitted by Relays. The protocol was not built specifically for Buzz. Its core idea is compact: users own a cryptographic key pair, sign events, and publish them to relays. Clients subscribe to the events they care about through one or more relays.

A Nostr event includes the sender’s public identity, a timestamp, a type, content, references, and a signature. The private key stays with the user and signs. The public key acts as the identity and enables verification. Technically, Nostr uses Schnorr signatures on secp256k1, the same elliptic curve that also plays a central role in Bitcoin.

A Signed Log, but Not a Blockchain

This distinction matters: Nostr is not a blockchain. There is no mining, no global consensus, and no single chain that every relay must wait for. A relay accepts events, stores them according to its own rules, and returns them to clients. Other relays may hold the same events or different ones.

Buzz uses this event model for messages, reactions, agent tasks, workflow steps, and Git events. Within a Buzz community, the relay is still the workspace’s central source. It checks membership, distributes events, and maintains state. The protocol makes identities and data formats more portable, but it does not automatically eliminate the operator, database, backups, retention rules, or the possibility of relay failure.

Signatures prove who signed an event with a particular key. They do not guarantee that a relay will deliver every previous event forever. Anyone self-hosting Buzz therefore still needs backups, exports, monitoring, and proper key management. A lost private key is not an ordinary password an administrator can simply reset. A stolen key is an identity with which an attacker can produce valid signatures.

What Bitcoin Has to Do with It

Nostr is culturally and technically close to the Bitcoin community. In addition to using the same curve for signatures, NIP-57 defines Lightning Zaps. They let Nostr clients initiate payments in satoshis to people or events and represent the corresponding payment receipts as events.

That does not mean every Nostr application must use Bitcoin. Nostr works without a blockchain and without a coin. Buzz Shared Compute is also not currently an open marketplace where unknown computers automatically earn satoshis per token. The published idea is based on capacity voluntarily shared within a community. Lightning could later support compensation or quotas, but it is not yet the economic answer to electricity, wear, and operations.

How Shared Compute Works in Buzz

Buzz Mesh links community membership to access to the compute pool. A member enables sharing, selects a model that fits their hardware, and makes inference available to other members. An agent can select “Buzz shared compute” like a model provider without storing an API key for an external AI service.

The relay provides the trust and coordination layer. It knows who belongs to the community and which node offers a model. The actual model request travels directly and encrypted between the participating machines. The prompt should therefore not pass through the Buzz server. It still leaves the requester’s device and reaches another community member’s machine.

That sentence belongs in every security assessment. Transport encryption protects the path. It does not blind the endpoint. Anyone using third-party hardware for inference must trust its operator within the chosen trust boundary. Buzz states this clearly in its Mesh vision: the community is only as private as its members are trustworthy.

Remote Inference Is Not Automatically Distributed Inference

“Shared Compute” can refer to two very different technical models.

In the simpler case, the complete model runs on one powerful workstation. Other devices send requests to it. This is remote inference within a community. It does not require a GPU-cluster-grade interconnect. Mostly prompts, generated tokens, and protocol overhead cross the network. Good bandwidth and reasonable latency help, but the model itself runs on one machine.

In the harder case, a model is split across multiple computers. Each node holds only some weights or performs part of the computation. During token generation, intermediate results must continuously move between nodes. A normal client-server connection becomes a tightly coupled distributed system. Bandwidth, latency, topology, and failures suddenly determine model speed directly.

Buzz describes both directions. The current public development guide shows a real path from the desktop app through the agent to local or remote inference. Splitting a model across multiple community devices appears in the larger Mesh vision. It is a plausible goal, but it should not be confused with a mature platform that scales arbitrarily. Parts of the compute interface still require a feature flag in development.

The Mac Studio Cluster Shows the Network Problem

NetworkChuck provides a vivid example. His current setup connects four Mac Studios with 512 GB of Unified Memory each, producing a local cluster with 2 TB of GPU-accessible memory. But an earlier experiment with five Macs already exposed the problem: adding computers did not make inference faster. According to his comparison, it made it 91 percent slower.

The video goes beyond the impressive RAM total and explains the difference between pipeline and tensor parallelism. In a pipeline, one Mac processes its model layers and passes the result to the next. This provides enough capacity for a large model, but the other nodes repeatedly wait. With tensor parallelism, every Mac works on the same layer at the same time. That requires frequent exchanges of small amounts of data during every layer, which makes latency decisive.

NetworkChuck shows latency dropping from roughly 300 to 3 microseconds in his setup. In his Llama 70B comparison, output rises from about 5 tokens per second with pipeline parallelism to around 16 tokens per second with tensor parallelism and RDMA. That is a strong result, but it needs precise language: the whole cluster is not 100 times faster. Connection latency falls by roughly that factor, while measured model throughput is a little over three times higher.

Normal IP over Thunderbolt introduces more latency and CPU overhead. Since macOS 26.2, Apple silicon Macs with Thunderbolt 5 support RDMA over Thunderbolt. RDMA lets suitable software move data between registered memory regions with much less overhead. Apple explicitly coordinated this capability with MLX Distributed and the JACCL backend.

The update solves a real problem, but it does not repeal physics. Apple’s technote recommends a fully connected topology for minimum latency. Two Macs need one connection, three need three cables, and four need six. With five or more nodes, limited ports may make a ring topology more practical, but then the application must forward data through intermediate nodes. Apple also documents current limits, including a maximum of ten UC queue pairs and only two-sided send/receive operations.

This example matters to Buzz. A community can readily offer several complete models on different computers over the internet and route jobs to them. Stretching one large model across distant machines is a different class of problem. Six Thunderbolt cables cannot bridge Zurich, Berlin, and New York. Every additional network hop delays token generation, and one slow or vanished node can stall the entire pipeline.

RAM Does Not Simply Add Up

For local language models, memory is often a harder limit than raw compute. Model weights must live somewhere. The KV cache, runtime data, and reserves for longer contexts or concurrent users require additional capacity.

If two members each run a model in 64 GB of RAM, the community has two inference nodes. It does not automatically have one machine with 128 GB of shared memory. Only real model sharding can move that boundary, and the price is more communication, complexity, and failure risk.

In 2026, this technical constraint meets an unpleasant market. TrendForce describes the third-quarter DRAM market as still extremely tight. Demand from AI servers supports record prices while PC and smartphone manufacturers reach their price limits. Shared Compute therefore makes existing hardware more valuable, but it does not make new local systems with large amounts of RAM cheap.

This also changes the economics of my earlier compute smart-grid idea. If a group already owns three workstations, sharing them may make excellent sense. Buying three expensive computers solely to avoid a cloud bill may be the worse investment. Electricity, cooling, spare parts, internet access, administration, and outage risk do not vanish merely because no hyperscaler appears on the invoice.

What Is Genuinely Cool About Buzz Mesh

For me, the strongest aspect is not that Buzz invented a new distributed-inference method. It is how the project connects existing building blocks.

The community already has members, identities, and permissions. Agents already work in the same spaces. Models can already run locally through a compatible interface. Buzz links these layers so a user can actively share compute and an agent can use it like an ordinary provider. An infrastructure project becomes a product setting.

The size of the trust zone is also sensible. Our earlier thought experiment extended to cities, cooperatives, and millions of devices. Buzz starts with people who already work together. That does not eliminate trust problems, but it reduces the number of unknown parties. For an agency, small business, research project, or developer group, this is more realistic than an anonymous global GPU bazaar.

Another advantage is model independence. Buzz can connect different agents and model providers. Operators of local open-weight models can control weights, configuration, and runtime. “Owning the model” remains shorthand, however. Open weights are not automatically public domain. Licenses may restrict use, redistribution, or commercial operation. Real sovereignty therefore means having the weights, understanding the license, controlling the runtime, exporting the data, and being able to operate without the original provider.

What Is Not Yet Convincing

The first open question is compensation. Voluntary sharing may be enough in a small team because everyone benefits from the project. Once one person permanently supplies electricity and hardware while ten others consume it, camaraderie turns into capacity planning. The system needs limits, priorities, metrics, and eventually fair accounting. Nostr and Lightning offer interesting building blocks, but Buzz does not yet provide a finished economic model.

The second question is operations. Who updates models? Who verifies their source and license? Who decides which node may see sensitive prompts? What happens under load, in sleep mode, on a laptop in a train, or when a computer disappears halfway through an answer? Cloud providers charge money, but they also absorb much of this unglamorous work.

The third question is security. Buzz Shared Compute forwards model requests, not arbitrary foreign code to every workstation. That is a much healthier boundary than an open compute marketplace. Prompts may still contain confidential information, models may be manipulated, and agents may send more context than users expect. Membership is access control, not a guarantee of good behavior. Companies additionally need data classification, logging, quotas, model approvals, endpoint hardening, and clear rules for jobs that must remain local.

Finally, Buzz is young. Public code, architecture, and a concrete Shared Compute test path are more than a slide deck. At the same time, feature flags, rapid releases, and open development documents show that the system is still moving quickly. This is a good moment to experiment with non-critical data. It is not a good moment to make core business processes dependent on it without an exit plan.

What Is Actually Being Implemented

Buzz does not implement the entire compute smart grid from my previous article. But it implements its most sensible first layer: a limited, voluntary compute cell built on an existing social trust structure.

The open market, stable credits, hardware attestation, independent result verification, and an operating model for thousands of unknown nodes are still missing. In return, Buzz offers something many decentralized projects lack: an understandable interface and an immediate use case. An agent needs a model. A member has a computer. Both belong to the same community. The relay coordinates, and the machines compute.

Perhaps that matters more than attempting the grand design immediately. Decentralized infrastructure often fails because it first tries to build a global economic system and only afterwards searches for an everyday problem. Buzz starts the other way around. It takes an existing workspace and makes spare compute visible and usable inside it.

If that works reliably, quotas, credits, Lightning payments, regional federation, or verifiable jobs can follow later. But first the small circle has to compute reliably. Only then is it worth expanding the circle.

Basis and Limitations of This Article

I did not test Buzz Mesh myself in a multi-computer setup for this article. The technical assessment is based on Buzz’s public source code, architecture, Mesh vision, development guide, the Nostr specifications, and Apple’s RDMA documentation, reviewed on August 21, 2026. Statements about stability, throughput, and behavior under real load are therefore not my own measurements.

Buzz is nevertheless the most tangible example I have seen so far of how our distributed-compute idea could become a usable product. Still small, still early, and still without a solved economy, but no longer merely theoretical.

Until next time,
Joe