Table of contents· 5 sections+
Every tool in the Zippytal ecosystem (Meet, Chat, Community, Drive) runs on the same little piece of software. It's called a Zippytal Node. It's about 12MB. It runs on anything with a CPU and a network cable.
We could have skipped it. We could have built yet another SaaS, put five tools behind a login, and shipped in half the time. We didn't. Here's why.
The SaaS default makes sovereignty impossible
If the tool lives on our servers, 'privacy' is a policy we promise to follow. That's not privacy. That's trust. The tool could be E2E encrypted, but if the architecture depends on our uptime, our billing, and our continued existence, you're still renting.
The only way to make sovereignty real is to move the infrastructure layer to the user. Not as a deploy-it-yourself option. As the default.
What a node actually does
- Discovery: finds other nodes in the network via DHT + optional rendezvous relays.
- Transport: handles encrypted peer-to-peer connections (Noise protocol over QUIC).
- Identity: one ed25519 keypair per node. No accounts, no emails, no harvesting.
- Storage: encrypted, erasure-coded shards for services like Drive.
- Runtime: hosts services (Meet, Chat, Community, your own) as WASM modules.
Why WASM for services
We wanted services to be portable, signed, and sandboxed. WASM gives us all three. Anyone can write a Zippytal service in Rust, TypeScript, Go, or Python, compile to WASM, sign it, and publish it. Any node can install it. The node enforces quotas, memory limits, and network policies.
It also means the core ecosystem isn't privileged. Our Meet service is a WASM module. So is Chat. So is Drive. Nothing in the core daemon knows they're 'ours'.
Federation: the internet we wanted in the first place
Nodes talk to nodes. Identities are portable across nodes. A community on your node can federate with a community on someone else's. The network scales by getting more members, not by getting more expensive servers.
The trade-off we chose
A node-based architecture is harder to build and slower to ship than a classic SaaS. Some features feel less magical in the first 30 seconds, too. You have to run a thing, not just sign up.
We accepted the trade-off because the alternative (yet another cloud-hosted tool asking you to trust us) doesn't solve the problem we set out to solve.
"If the architecture doesn't make the right thing easy, the policy can't save you."