Stratus - P2P storage

Inspiration

We all know the frustration of running out of storage. Our friend Mihajlo constantly struggles with it — always out of space, deleting things he shouldn't have to. That got us thinking: within any friend group, storage is unevenly distributed. Some of us have terabytes sitting idle while others are scraping by. Why not share it?

At the same time, we were drawn to the idea of truly owning your data. Cloud providers hold your files hostage behind subscriptions and terms of service. We wanted to build something where important data could be replicated across a fully distributed peer network — no central server, no middleman, no single point of failure. Just friends helping friends.

What it does

P2P Storage is a desktop application that turns your friend group into a personal cloud. It has three core capabilities:

• File Sharing - Join a shared room by typing the same code on two or more machines. Files you drop in are instantly replicated to every peer in the room and mirrored to a local folder of their choice. Live sync keeps everyone up to date.

• Storage Replication - Encrypt and chunk your important files, then distribute those encrypted chunks across multiple peers ("keepers") in the network. Health monitoring with heartbeats and cryptographic challenges ensures your data stays available even when individual peers go offline.

• Friend Storage - A friend with spare disk space can volunteer to store your encrypted data without ever being able to read it. The owner encrypts everything client-side before it leaves their machine; the friend stores opaque blobs. When the owner needs the data back, they retrieve and decrypt it locally.

All of this happens without any server. Discovery, connection, and replication are fully peer-to-peer.

How we built it

We built P2P Storage as a Pear Runtime desktop application using the Holepunch ecosystem:

• Hyperswarm handles peer discovery via a distributed hash table (DHT). Peers find each other by joining the same "topic" - a hash derived from a shared room code or the fixed replication pool identifier.
• Corestore + Hyperdrive provide the replicated filesystem layer. Each peer has a writable Hyperdrive; when two peers connect, a single store.replicate(conn) call fans out all hypercore blocks over the encrypted Noise stream.
• Protomux multiplexes multiple logical protocols over one connection: a key-exchange channel for file sharing and a structured RPC channel for replication/friend-storage messages.
• Localdrive + MirrorDrive materialize remote Hyperdrives onto the local filesystem, giving users normal files they can open with any application.
• sodium-universal powers all cryptography: Ed25519 identity keypairs, NaCl secretbox for chunk encryption, and sealed boxes for peer-targeted payloads.
• Hyperbee stores structured metadata (replication manifests, keeper agreements, friend-storage records) as key-value indexes on top of hypercores.

The architecture splits into a shared core/ layer (store, network, identity, encryption, chunking, erasure coding, health monitoring, protocol definitions) and feature modules (file-sharing, replication, friend-storage), each with their own sync logic, manager, and UI bindings.

Challenges we ran into

• NAT traversal and peer connectivity - P2P networking means no guaranteed relay. Hyperswarm's holepunching works well, but we still encountered scenarios where peers behind restrictive firewalls couldn't connect. Understanding and debugging DHT-level discovery was a steep learning curve.
• Peer availability - Unlike a server that's always on, peers come and go. Designing the health monitor with heartbeats and cryptographic challenges to detect degraded keepers — and deciding how many copies of each chunk to maintain - required careful thought about availability vs. storage overhead.
• Multiplexing protocols - Running Hyperdrive replication and our custom replication RPC over the same encrypted connection via Protomux required understanding the Holepunch stream internals deeply.
• Encryption at the chunk level - Ensuring data is encrypted before it ever leaves the owner's machine while still allowing efficient chunked transfer and retrieval added complexity to the data pipeline.
• Pear Runtime ecosystem - Pear is cutting-edge and documentation is still maturing. We spent significant time reading source code of dependencies and experimenting to understand lifecycle management, worker processes, and the correct way to handle teardown.

Accomplishments that we're proud of

• A working end-to-end encrypted file sharing flow where two peers can type the same room code and instantly sync files — no accounts, no servers, no configuration.
• A full replication protocol with typed message exchanges, chunked encrypted transfer, vault isolation per owner, and health monitoring - built from scratch on top of Protomux.
• The friend storage model where a friend stores your data without being able to read any of it — true zero-knowledge storage between friends.
• A clean architecture that separates core P2P infrastructure from feature-level logic, making each feature independently testable and extensible.
• Building all of this in a hackathon timeframe using a relatively new and evolving technology stack.

What we learned

• How distributed hash tables work in practice for peer discovery, and the real-world challenges of NAT traversal and holepunching.
• The power of the Holepunch / Pear ecosystem - Hyperswarm, Hyperdrive, Corestore, and Protomux compose into a remarkably capable P2P stack once you understand the primitives.
• That encryption and chunking at the application layer are essential for trustless distributed storage - you can't just replicate raw files if you want privacy.
• The fundamental tension in P2P systems between availability and peer uptime - and how health monitoring, redundancy (N-copy replication), and future erasure coding can address it.
• How to build a desktop application with Pear Runtime and pear-electron, including lifecycle management, frameless windows, and worker processes.

What's next for P2P Storage

• Reed-Solomon erasure coding - replace simple N-copy replication with proper erasure codes so files survive peer loss with far less storage overhead.
• Incentive and reputation system - track keeper reliability over time and prioritize storing chunks with peers who have the best uptime history.
• Direct connect mode - we have a HyperDHT-based direct connection module already prepared (direct-connect.js) that will let peers connect by public key without needing a shared topic.
• Mobile companion app - extend the Pear app to mobile so users can access their distributed storage on the go.
• Improved UX — drag-and-drop file sharing, storage usage dashboards, and one-click friend invitations via QR codes or shareable links.

Built With

• node.js
• npm
• pears