Gozzip Earns a 50 Proof of Usefulness Score by Building an Open Social Protocol That Turns Trust Graphs Into Storage Infrastructure

Today, we are speaking with Leon Nicolas Acosta, the creator of Gozzip, an open social protocol that transforms the user's trust graph into its own storage and delivery infrastructure. Built on Nostr primitives, the project aims to replace centralized server dependency with bilateral storage pacts between peers.

What does Gozzip do? And why is now the time for it to exist?

Gozzip is an open social protocol that makes the user's trust graph the storage and delivery infrastructure, replacing relay dependency with bilateral storage pacts between peers. Built on Nostr primitives, it enforces reciprocal data obligations via cryptographic challenge-response and bounds gossip to a 2-hop Web of Trust. It bridges to ActivityPub and AT Protocol, formalizing human gossip dynamics like Dunbar layers, reciprocity and triadic closure as protocol mechanics, not UI concerns. Now’s a good time for Gozzip to exist because internet users are increasingly vulnerable to server operators dictating data control, and privacy-conscious communities urgently need decentralized solutions that can survive platform censorship.

What is your traction to date?

Gozzip is in alpha with ~20 testers. The first implementation is Nostrito (nostrito.com), a desktop client and mini-relay that handles WoT-based storage and retrieval with low-latency local access across devices. The protocol is also being implemented via Nostr WoT (nostr-wot.com), a browser extension live on Chrome Web Store and Firefox Add-ons that provides NIP-07 signing, Lightning wallet, and a Web of Trust engine. Reach is currently developer-focused: extension users within the Nostr ecosystem. Storage pact formation within the WoT social graph is the next milestone for both clients.

Who does your Gozzip serve? What’s exciting about your users and customers?

Anyone who communicates online and doesn't want a company or server operator deciding what gets stored, seen, or deleted. Today that starts with the Nostr developer community and early adopters of decentralized social protocols, but the protocol is designed for the billions of people currently using platforms that treat their relationships and data as product inventory. Gozzip gives individuals infrastructure ownership over their social life by turning their existing trust relationships into the storage and delivery layer. The immediate users are developers building decentralized clients, privacy-conscious communicators, and communities in adversarial environments where relay censorship or platform shutdown is a real threat. Long term, it's for anyone who texts, posts, or messages and assumes their conversations will survive the platform they happen on.

What technologies were used in the making of Gozzip? And why did you choose ones most essential to your tech stack?

Gozzip leverages foundational decentralized technologies, primarily relying on Bitcoin, Nostr, and Web of Trust (WoT) primitives. By utilizing Nostr's architecture alongside a custom Web of Trust engine, the protocol enforces reciprocal data obligations and organic storage mechanics. This stack was chosen because it perfectly aligns with the project's goal of removing centralized servers and embedding resilient infrastructure directly into human social relationships.

Gozzip scored a 50 proof of usefulness score (https://proofofusefulness.com/reports/gozzip) - how do you feel about that? Is it just right, or does it need to be reassessed?

The maths of the calculation do not add up. The numbers were all over the place, so I am not sure where the 50 comes from. However, I suppose 50 is fair for where we are right now in terms of development, but far from the potential behind the vision and architecture.

The PoU scoring weights traction at 25% and reach at 20%. Gozzip has neither yet. It's a published protocol with simulation validation, not a deployed product with users. You can't score traction on a system that hasn't been deployed to production. The score reflects that reality accurately.

Where I think it undersells us is problem-solution fit. The Nostr centralization problem isn't theoretical; I measured it. analytics.nostr-wot.com shows the relay dependency empirically: events clustering on 2 to 3 dominant relays, declared outbox relays missing data or offline. The protocol's simulation results demonstrate that the architecture actually works against that measured problem. The fit between "relays are centralizing" and "make the social graph the storage layer" is tight. Whether that comes through in a scoring model that leans heavily on existing traction signals, probably not. And that's fine.

The score I care about is the one in 12 months when there are real pacts between real users and data that survived because the trust network held it. 50 today with a protocol and a whitepaper is a starting position, not a verdict.

If we re-score your project in 12 months, which criterion will show the biggest improvement, and what are you doing right now to make that happen?

Traction. Right now, Gozzip is a published protocol with a whitepaper and simulation validation at 5,000 nodes. In 12 months, the goal is a working implementation with real pacts between real users.

Right now, the protocol spec is public, and the simulation code validates the core mechanics. Pact formation, tiered retrieval, challenge-response verification, and reliability scoring. The next step is a reference implementation. A client that can form storage pacts, run challenge-response cycles, and execute the full retrieval cascade against real Nostr infrastructure. Nostrito is the first desktop implementation, and the target is to get it running on Nostr users' machines.

The bet: within 12 months, a community of Nostr users will be running Gozzip pacts where their data survives relay outages because their trust network holds copies. That's the traction proof. Not downloads, not signups. Data that persists because the social graph preserved it

What excites you about this Gozzip's potential usefulness?

The internet moved human communication onto infrastructure designed to extract value from relationships, not preserve them. Every decentralized protocol that tried to fix this reproduced the same dependency by routing everything through servers that control storage and delivery. Gozzip is the first protocol that makes the social graph itself load-bearing, turning trust relationships into actual infrastructure rather than a display layer. What excites me is that this isn't a novel invention, it's a formalization of how human communities have propagated and stored information for 150,000 years. Dunbar layers, reciprocity, gossip boundaries, these aren't metaphors mapped onto a protocol, they're functional isomorphisms that evolution already validated. The potential is that billions of people could own their social infrastructure the same way villages always did, through mutual obligation between people who know each other, without needing to understand any of the cryptography underneath.

Walk us through your most concrete evidence of usefulness.

I built an analytics platform at https://analytics.nostr-wot.com, which gives the evidence. We monitor 105 relays and have collected 668,000+ events across 27 tracked profiles. The data exposes something the Nostr community talks about but nobody had quantified: storage centralization, and therefore also retrieval. We can show, per-profile, that events cluster on 2-3 dominant relays while declared outbox relays are often offline or missing events entirely. The gap between NIP-65 relay declarations and reality is measurable, and it's bad. That's the data point: Nostr's decentralization promise is empirically falsifiable with our tooling. Whether through gozzip or another alternative we need to return ownership and decision power to the user, that's the whole point of a decentralized network. I see many founders and developers working on top of Nostr, creating very complex structures trying to solve these problems, but they only work from the relay perspective. With the current state of affairs and technology advancements we can create a protocol that will favor the user, without compromising in user experience.

That empirical finding is what drove the protocol design. Gozzip isn't a solution looking for a problem. The analytics proved the problem exists, the whitepaper proposes the architecture, and the simulation validates that social-graph-first storage achieves high availability without centralized infrastructure. The need is demonstrated by the data: if you depend on relays, you depend on infrastructure you don't control, and that infrastructure is already failing its decentralization promise.

How do you measure genuine user adoption versus "tourists" who sign up but never return?

Gozzip is a protocol, not a platform. There are no signups to count. The meaningful adoption metric will be active storage pacts: bilateral agreements where two peers are actually storing each others data and passing challenge-response verification.

The protocol has a built-in adoption funnel with three phases. Bootstrap (0 to 5 pacts, relay-dependent), Hybrid (5 to 15, mixed), Sovereign (15+, peer-primary). A tourist is someone who installs a Gozzip-compatible client and never forms pacts. They stay in Bootstrap, functionally identical to a regular Nostr user. Thats fine. They lose nothing.

Retention here is structural, not behavioral. Once you have 15+ active pacts with people in your trust network, your data availability hits roughly one-in-a-billion chance of simultaneous failure across all partners. That's not something you toggle off. It's insurance for your digital life, maintained by people who actually know you. Volume-matched reciprocity means your pact partners have skin in the game. They stop storing your data, you stop storing theirs. Asymmetric relationships decay, same as in real life. The ones that survive are genuine.

Where we are today: validated by simulation (5,000 nodes), not production. The retention story gets written by the first communities that adopt it. What I can say is the architecture makes retention a structural property, not a growth hack.

How Did You Hear About HackerNoon? Share With Us About Your Experience With HackerNoon.

I've been writing in hackernoon about my journey and findings. I was suggested to search for funding in Proof of Usefulness, and I thought it was interesting both for the financial side, but also from a marketing perspective. If someone finds it interesting, the possibilities of making the dream true are much bigger.

Given that your initial traction relies heavily on the Nostr developer ecosystem, how do you plan to incentivize the first 200 mainstream users to form bilateral storage pacts without needing to understand the underlying cryptography?

They won't see the cryptography. Same way you don't understand SMTP to send an email.

The onboarding works like this. You install a Gozzip-compatible client. Your follow graph already exists on Nostr. The protocol automatically identifies peers within 2 hops who run the same software and proposes bilateral storage pacts based on volume compatibility. The user sees something like "5 people in your network can back up your data. Allow?" One click. You're in Bootstrap phase. As pacts form you graduate to Hybrid then Sovereign without ever making a single decision about cryptographic primitives.

For the cold-start problem, when a mainstream user has zero Nostr follows, the protocol includes guardian pacts. Established users voluntarily store data for one newcomer outside their Web of Trust. The framing is deliberate: today's seedling becomes tomorrow's guardian. This is how every real community has always worked. A shopkeeper gives a stranger their first job. A neighbor cosigns a lease for someone who just moved in. Generosity bootstraps trust where none exists. The protocol just formalizes what anthropology documented centuries ago.

The first 200 mainstream users won't come because they understand secp256k1 key hierarchies. They'll come because someone they trust says "install this, your data is safer now" and the experience confirms it.

As Gozzip aims for organic expansion along trust graph edges, what are the primary growth bottlenecks you anticipate when crossing from early adopters to everyday internet users?

Three, ordered by severity.

Graph density: Trust graphs need critical mass. If you're the only person in your friend group on Nostr, your WoT is empty and Gozzip has no peers to form pacts with. Gozzip cannot grow faster than the Nostr social graph grows. The protocol adds value to that graph, gives follow relationships a functional purpose beyond content filtering, but it depends on the graph existing first. Guardian pacts and relay fallback soften this but don't eliminate it.

The motivation gap: Early adopters run this infrastructure because they want sovereignty. They derive meaning from self-reliance. Adler would call it striving for significance through mastery. Nietzsche would recognize a master-morality relationship with technology: I control my tools, my tools don't control me. Mainstream users operate on completely different values. Convenience, social proof, does my friend use this. The bridge isn't technical, its motivational. Gozzip needs to deliver immediate visible value before anyone cares about the decentralization thesis. If the only pitch is sovereignty you get 10,000 cypherpunks. If the pitch is "your digital life doesn't depend on a company's goodwill" you get millions. But only if the UX delivers without friction.

Uptime expectations: Mainstream users expect high availability. A peer network where your friends' devices are your storage tier sounds unreliable on its face. The math says otherwise, 20 active pacts with a small percentage of Full nodes gives P(all-offline) of roughly 10 to the negative 9. But math doesn't matter if the first experience is a failed retrieval. The tiered cascade is designed so most of reads succeed, relays catch most of the rest. The failure rate needs to shrink before mainstream users trust it with stuff they care about. Thats engineering, not architecture.

How will Gozzip ensure data availability and reliability within a 2-hop Web of Trust if a significant portion of a user's peer network temporarily goes offline?

Four levels.

Redundancy by default: Each user maintains 20 active storage pacts plus 3 standby. Data isn't on one peer, its across 23 with a mix of Full nodes (95% uptime, complete history) and Light nodes (30% uptime, 30-day window). Probability of all pact partners being simultaneously offline is about 1.48 times 10 to the negative 9. Half your network goes down? You still have 10+ peers serving your data.

Instant failover: Standby pacts exist for exactly this. When an active partner becomes unreachable, a standby gets promoted immediately. No renegotiation, no discovery delay. The standby already has your recent events because they receive them passively.

Cascading read-caches: This one is interesting. Every read creates a replica. Bob fetches Alice's events from a pact partner, now Bob holds a local copy. Carol requests Alice's events via gossip, Bob can respond, and he's not even one of Alice's formal pact partners. Popular content replicates naturally across the follower base. Even if all of Alice's pact partners go offline, anyone who recently read her stuff can serve it.

Relay fallback: The protocol doesn't pretend relays are evil. It just demotes them from gatekeeper to safety net. If gossip can't resolve a read within 30 seconds, the request falls through to traditional relay infrastructure. The relay catches exactly this scenario: temporary widespread peer unavailability. Difference from today is the relay handles the exception, not the default.

And then there's a separate layer to work under other transmission medi. "Offline" doesn't necessarily mean unreachable. A device that loses cellular might still be accessible via BLE mesh (up to 7 hops), WiFi, or radio modem. Sessions survive transport switching. A pact partner's data stays accessible as long as any physical path exists between you and them, internet or not.