← back

Why Pear Runtime for P2P Infrastructure: Building Tzimtzum Without Servers

How a messaging app demo in 2023 led to the architecture behind tzimtzum.

I first saw Keet in 2023. Holepunch had just launched it. Encrypted messaging, fully peer-to-peer, no servers routing your messages, no metadata collection. Think Signal but without Signal's servers.

What stuck with me wasn't the encryption. Plenty of apps encrypt. What stuck was that it just worked. Behind NAT, on mobile networks, no port forwarding, no firewall dance. You installed it and it connected. That almost never happens with P2P software. I've tried enough of them to know.

I bookmarked it and moved on. But the impression stayed.

The Constraint That Made the Choice

When I started designing tzimtzum in late 2025, the product requirement was specific: a publishing platform where users own their knowledge bases completely, share them peer-to-peer, and monetize access directly. No servers in the middle. Actually no servers.

The moment that constraint became clear, Pear was the obvious answer. I wasn't exploring options. I already knew. But I still needed to validate the intuition, make sure I wasn't choosing based on familiarity rather than fit.

What TzimTzum Actually Needed

The requirements list was specific:

Most P2P stacks are built for one use case. File sharing. Video calls. Blockchain consensus. I needed something general-purpose enough to build a complete application on top of, something that could serve as the foundation rather than a feature bolted onto a traditional web app.

The Validation: What Else Was Out There?

IPFS/libp2p is the one everyone knows. Massive ecosystem. Filecoin backing. But IPFS is built for immutable content distribution. Static websites. Files that don't change. You can layer OrbitDB on top for mutable databases, and people have, but it felt like forcing a CDN to act like a database. The architecture wasn't designed for what I needed.

WebRTC handles real-time peer connections well. Video calls, live collaboration. But connections are ephemeral. Close the browser, gone. And WebRTC requires signaling servers to establish initial connections, which puts a server right back in the middle. I needed data that persists and syncs even when peers aren't simultaneously online.

GUN caught my eye. Decentralized graph database with real-time sync. Interesting concept. The ecosystem felt small, though, and I couldn't find enough production examples to trust it for a long-term bet. Tzimtzum isn't a weekend project. I needed infrastructure that would be actively maintained five years from now.

None of them changed my mind. Pear was still the right choice.

Why Hypercore Protocol Fits

Hypercore Protocol is what Pear is built on. Purpose-built for exactly this problem: applications where multiple peers share mutable, verifiable data without servers.

Hypercore itself is an append-only log. Like Git, but for arbitrary data. Every entry is cryptographically signed and linked to previous entries via Merkle trees (BLAKE2b hashes, Ed25519 signatures). You can't tamper with history without detection. When you download a knowledge base from another peer, you can cryptographically prove the data hasn't been altered. Prove it, not trust it.

Hyperbee sits on top. B-tree database with key-value lookups, range queries, and sparse indexing. That last one mattered a lot. Users shouldn't need to download a 10GB knowledge base to run a single query. Sparse indexing means you pull exactly the entries you need. The rest stays on the peer until you ask for it.

Hyperswarm handles networking. DHT-based discovery with UDP hole punching for NAT traversal. This is why Keet felt so smooth back in 2023. Peers find each other and establish direct connections even when both are behind routers or corporate firewalls. No STUN/TURN servers. No signaling infrastructure. Just a distributed hash table and some clever UDP packets.

Autobase handles multi-writer coordination. When multiple peers need to write to the same database, Autobase merges their append-only logs using causal ordering. Knowledge base owners update content, subscribers receive changes, all without server-mediated sync.

Why Pear Runtime Specifically

Hypercore Protocol is the data layer. Pear Runtime is the application framework.

Pear uses Bare, a lightweight JavaScript runtime stripped of browser bloat. Not Electron. Doesn't ship Chromium. It runs on desktop and mobile (iOS/Android) without the resource overhead that makes Electron apps feel like they're running a second operating system.

This turned out to be architecturally convenient. Tether's Wallet Development Kit (WDK), which we use for Lightning/Spark payments, is also built on Bare. So the same runtime handles both data (Hypercore replication) and payments (Spark transactions). One process. One runtime. One identity derived from the same BIP-39 seed.

Keet proved Pear works in production. Thousands of users, real-time encrypted chat, across mobile and desktop. If it handles that, it handles a publishing platform.

The backing helped too. Tether and Holepunch are actively maintaining this. Real funding, regular releases, production software shipping. An actively maintained stack, not an abandoned GitHub repo with a last commit from 2021.

The Tradeoffs

I should be honest about what you give up.

Tooling is less mature than traditional web development. Debugging P2P replication issues is harder than reading PostgreSQL logs. There's no managed hosting for Hyperbee, no Vercel equivalent for P2P apps. When something breaks between peers, you're reading Hyperswarm debug output.

The ecosystem is smaller. Stack Overflow won't have your answer. The community lives in Keet Rooms and GitHub issues. You read source code more than documentation.

Compatibility is a real cost. When your runtime is 95% compatible with the npm ecosystem, the last 5% is where all the work lives. We learned this the hard way integrating Tether's WDK. The patch script we wrote to make it run on Bare is 350 lines. That story is for another article.

What This Means for TzimTzum

With Pear Runtime, tzimtzum can:

For a product where sovereignty and zero intermediaries are core to the value proposition, Hypercore Protocol and Pear Runtime weren't just a good choice. They were the only serious one.

I knew that when I saw Keet. The validation just confirmed it.