How the stack fits together

Three products, three different jobs, one stack. Bare is the engine: a small JavaScript runtime with a module system, native addons, and threads, and nothing else built in. P2P is the peer-to-peer building blocks—Hypercore, Hyperswarm, Autobase, and the rest—ordinary JavaScript modules that happen to run on Bare. Pear is the platform on top of both: a CLI, over-the-air updates, and the machinery that turns building blocks into a shippable app. Knowing which layer you're working at makes the rest of these docs easier to navigate.

This page lays out the layers, bottom to top, and shows where each library you'll meet elsewhere belongs.

The layers at a glance

Each layer runs on the one beneath it. Read from the bottom up, it's a story about how raw C bindings become a peer-to-peer app you can install. The three product tabs in this site's sidebar map onto four of these layers: Bare covers the runtime and its userland modules, P2P covers the building blocks, and Pear covers the platform and app layers on top.

The engine room: native foundations and the Bare runtime

At the very bottom are C libraries: libjs (and its JavaScriptCore-backed sibling libjsc) give an engine-independent, ABI-stable way to talk to a JavaScript engine; libuv provides the asynchronous I/O event loop; libudx carries the reliable UDP streams the networking stack rides on.

Bare sits directly on top. It's a small, embeddable JavaScript runtime that adds only what those C primitives can't supply on their own: a module system (with CommonJS/ESM interop), a native-addon loader, and lightweight threads. Everything else is left to userland—which is the next layer up.

Bare userland: the bare-* modules

Bare ships almost no standard library. The familiar runtime surface—file system, sockets, crypto, HTTP—lives in installable bare-* modules you opt into. The same layer holds two other families that matter for cross-platform apps:

• Embedding & native (bare-kit, react-native-bare-kit, and the typed RPC seam of bare-rpc + hyperschema) let a native app run a Bare core on a background thread. See One core, many platforms.
• Build & bundle (bare-pack, bare-bundle, bare-make, bare-build) turn a Bare program and its dependencies into an embeddable bundle or a standalone executable.

The P2P building blocks

The libraries P2P is built around—Hypercore, Hyperbee, Hyperdrive, Autobase, Hyperswarm, HyperDHT, and Corestore—are ordinary JavaScript modules. They have no special status in the runtime; they run on Bare like any other dependency, and they don't require Pear at all. That's why the same storage and networking code works unchanged whether it's hosted by Electron on the desktop, a worklet on a phone, or a plain Bare or Node.js process with no Pear app around it.

The Pear platform

Pear is the layer that turns those building blocks into a product: pear-runtime spawns and updates your app, the pear-* modules supply application services, and the Pear CLI stages, seeds, and releases it. Pear is built on both Bare and the P2P building blocks—it doesn't replace them.

Apps: one core, many UI hosts

At the top are the apps—Keet, PearPass, and whatever you build. The recommended shape splits an app into a portable JavaScript core (peer-to-peer logic and storage) and a thin UI host that changes per platform: Electron on desktop, a native shell on mobile, a standalone binary in the terminal. The core is the same code everywhere; only the host swaps. That split is the subject of Runtime and languages and One core, many platforms.

See also

• Inside Bare—what the runtime layer actually adds.
• One core, many platforms—how the portable core reaches mobile and native apps.
• Runtime and languages—why the stack is JavaScript and how other languages join in.
• Bare modules—the catalog of bare-* userland modules.
• Building blocks, helpers & tools—the full P2P module catalog.
• Pear modules—the pear-* libraries at the platform layer.