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 gossip-based protocol. There are no servers in the traditional sense — no homeservers, no relays, no central indexers. Instead, every peer in your social graph stores and forwards data on your behalf.
When you publish a post, it propagates through your trust graph. Your close friends receive it first. They store it and, depending on their own trust settings, forward it outward. 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 flows only when explicitly permitted.
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 | Protocol-level transport independence | 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 independence
Gozzip's protocol layer is transport-agnostic. Messages can flow over TCP, WebSocket, Bluetooth, mesh radio, or sneakernet. The gossip protocol cares about the social graph structure, not the physical path a message takes to get there.
This is not theoretical. For its offline Bluetooth layer, Gozzip integrates BitChat — 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 independence matters in censorship-resistant scenarios. If one network path is blocked, Gozzip messages can route through any available channel — including BitChat's BLE mesh as the ultimate fallback when IP connectivity is unavailable entirely. This resilience comes from making 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.