Dependencies and network

Two questions come up enough during onboarding to deserve their own page: why Pear uses NPM at all when applications run on Bare, not Node, and what peers can learn about you when you join a swarm. Both have the same shape — a deliberate trade-off between developer ergonomics and the platform's clean-room ideals.

Why NPM for dependencies

NPM is a great package manager for JavaScript, and most JavaScript developers already know how to use it. All of Holepunch's modules — Hypercore, Hyperdrive, Hyperbee, the lot — are published there. Reinventing a peer-to-peer package manager would have meant reinventing every developer's habits at the same time, for very little upside.

The bootstrap relationship is what's interesting: NPM and Node.js are required to install Pear initially (npm install -g pear), but once the platform is set up neither is needed at runtime. The pear command after install is using Bare, not Node, to run your application; NPM was just the delivery mechanism.

What dependencies your application declares stays meaningful, though. When you pear stage, every dependency in your package.json is bundled into the application's hyperdrive and replicated to peers along with your code. A few practical implications follow:

• Audit before you ship. Run pear stage --dry-run to review the file list before announcing a release; this is where you'd catch a dependency that ballooned in size or pulled in something unexpected.
• Updates ship fully replicated. If you update a dependency, you're not merely changing a package-lock.json — you're shipping the actual new code to every running peer. Ordinary semver discipline applies, but the consequence is more direct than on a server-rendered web app.

What peers learn from your IP

When you connect to a swarm — directly via hyperswarm, or transitively because you're running a Pear application that swarms — your IP address is exposed to the peers you connect to. This is unavoidable for the same reason it's unavoidable for any peer-to-peer network: peers need a routable address to reach you, and IP is what TCP/UDP transport provides.

This means a peer you connect to can, in principle:

• Geolocate you to the level of granularity their IP database supports (typically city, sometimes ISP).
• Correlate your presence on multiple swarms if they participate on more than one.
• Log timing of your connections and disconnections.

What they can't do without further ado: read your traffic (Pear connections are end-to-end encrypted via Secretstream), impersonate you (your peer key is a public key you control), or identify you across IP changes (the IP changes; your peer key is what's stable).

If your IP is sensitive — you're a journalist, an activist, or just privacy-conscious — route Pear's traffic through a VPN or Tor. The peer-to-peer protocol doesn't care what's underneath the transport, and using a privacy network shifts the IP-disclosure surface from your real address to the exit node's.

See also

• Connect to many peers by topic with Hyperswarm — joining a swarm in practice.
• Secretstream — the encryption layer on every Pear peer connection.
• Storage and distribution — what actually crosses the wire when peers replicate.