Two paths toward the same goal
Both Gozzip and Pubky reject the surveillance-capitalism model of social media. Both put the user, not the platform, at the center. But they make fundamentally different architectural bets on how to get there.
Gozzip says: your friends are your infrastructure. Pubky says: your homeserver is your hub.
Neither is wrong. They are different trade-offs rooted in different assumptions about trust, availability, and how much infrastructure a sovereign user should need. Understanding where they diverge helps you decide which model fits the future you want to build.
How Gozzip works: your friends are your infrastructure
Gozzip is a peer-to-peer protocol built on trusted storage. There are no homeservers and no central indexers, and relays are demoted from the home of your data to an optional fallback. Instead, the peers in your social graph store your data on your behalf.
When you publish a post, your close friends store it first: the peers you hold storage pacts with. When someone reads it, their client fetches it locally, then directly from the author's pact partners, and only falls back to a relay if neither has it. The protocol respects Dunbar-inspired trust layers: your closest 15 contacts get the most data, your broader 150-circle gets less, and beyond that, information reaches you through relay-assisted discovery.
Storage is cooperative. Your data lives on the devices of people who care about you, and theirs lives on yours. No single point of failure, no single point of surveillance.
The key insight is that social trust already forms a network. Gozzip makes that network the transport layer.
How Pubky works: your homeserver is your hub
Pubky takes a different approach. Each user runs (or rents) a homeserver: a persistent process that stores their data and handles incoming requests. Discovery happens through a Mainline DHT, the same distributed hash table that powers BitTorrent.
When someone looks you up, the DHT resolves your public key to your homeserver's address. Your homeserver serves your content, manages access control, and handles the mechanics of data availability.
The homeserver is yours. You can self-host it, run it on a VPS, or use a hosting provider. Your keys stay with you. If you switch providers, you point the DHT record to a new address and carry on.
Pubky's insight is that having a persistent, addressable endpoint simplifies many hard problems: offline delivery, search, and third-party integrations.
Where the designs diverge
| Aspect | Gozzip | Pubky |
|---|---|---|
| Data availability | Replicated across trust graph peers | Served by homeserver |
| Discovery | Gossip propagation through social graph | DHT lookup of public key → homeserver |
| Infrastructure needed | None beyond your own device + peers | Homeserver (self-hosted or rented) |
| Offline delivery | Peers buffer messages until you return | Homeserver buffers messages |
| Trust model | Dunbar-layered, per-relationship | Key-based identity, per-homeserver |
| Scaling unit | Social graph density | Homeserver capacity |
| Transport | iroh (QUIC) peer-to-peer | HTTP-based homeserver API |
| Indexing | Emergent: peers index what they see | Homeserver can expose indexes |
Why gossip scales with trust
One common concern with gossip-based systems is "how does it scale?" The answer is that Gozzip deliberately does not try to scale like a broadcast platform. It scales like human relationships do.
You do not need to reach a million people. You need to reach the people who matter, and let them decide what to pass forward. The gossip protocol naturally limits propagation based on trust distance, which prevents the viral amplification that makes centralized platforms toxic.
This is a feature, not a limitation. The protocol's capacity grows with genuine social connections, not with server hardware.
The indexing question
The most meaningful difference between the two approaches is how they handle search and discovery.
Pubky's homeserver can expose structured APIs. Third-party indexers can crawl homeservers (with permission) and build search experiences. This is familiar; it resembles how the web works with search engines.
Gozzip takes a different path. There is no central index to crawl because there is no central store. Instead, indexing is emergent: each peer builds a local view of the content it has seen through its trust graph. Specialized indexer peers can aggregate and serve broader views, but they operate as participants in the gossip network, not as external crawlers.
Both approaches have trade-offs. Pubky's model makes it easier to build conventional applications on top. Gozzip's model makes it harder for anyone to build a panopticon.
Transport
Gozzip's transport is iroh: a production-grade QUIC peer-to-peer stack. Nodes get Ed25519 endpoint identity, relay-assisted NAT traversal, and connection migration, so a session survives the network changing underneath it. The protocol logic cares about the social graph structure, not the physical path a message takes to get there, which leaves the door open to additional transports over time.
One natural future direction is an offline Bluetooth path. BitChat is a strong complement here: an open-source protocol purpose-built for encrypted peer-to-peer messaging over BLE. BitChat brings excellent cryptographic foundations: Noise Protocol (XX pattern) handshakes with forward secrecy, compact binary framing designed for low-bandwidth links, Bloom filter gossip deduplication, and traffic analysis resistance through fixed-size packet padding. These are hard problems that BitChat solves well.
The two protocols are complementary rather than competing. BitChat excels as a real-time mesh layer: ephemeral, local, designed for scenarios like protests or disaster zones where there is no internet. Gozzip adds the persistence layer on top: storage pacts that keep your data alive when you go offline, a Web of Trust that filters what propagates, and a social graph that serves as long-term infrastructure. BitChat handles "send a message to someone nearby right now." Gozzip handles "own your social life permanently." Together, they form a complete stack from Bluetooth radio to sovereign social media.
Pubky is HTTP-first. The homeserver exposes an HTTP API, and clients connect over the web. This makes integration with existing web infrastructure straightforward but ties the system to IP-reachable endpoints.
Transport flexibility matters in censorship-resistant scenarios. Because the protocol is decoupled from any single transport, additional channels can be added over time: a BLE mesh path like BitChat's is a candidate future fallback for when IP connectivity is unavailable entirely. This resilience comes from keeping the protocol independent of any single transport mechanism.
Conclusion: different bets on the same future
Gozzip and Pubky both want a world where users own their social data. They differ on what "ownership" requires in practice.
Pubky bets that a personal server (lightweight, portable, yours) is the most practical unit of sovereignty. It inherits the web's architecture and improves on it with cryptographic identity and decentralized discovery.
Gozzip bets that sovereignty means removing the server entirely. Your data lives in the social graph itself, replicated and relayed by the people you trust. No server to maintain, no endpoint to defend, no hosting bill to pay.
Both are legitimate paths. Both may coexist. But if you believe the future of social media should look more like a conversation between friends than a database query against a server, Gozzip's gossip-based approach offers something that server-centric models (even decentralized ones) cannot: true infrastructure independence.
