Adversarial Review: Protocol Design and Networking Architecture

Date: 2026-03-14 Scope: Gossip protocol mechanics, relay dependency, NIP-46 transport, volume matching, WoT boundary, alternative architectures Documents reviewed: Whitepaper v1.2 (gossip-storage-retrieval.tex), plausibility-analysis.md, relay-diversity.md, surveillance-surface.md, equilibrium-pact-formation.md Reviewer focus: Distributed systems and network protocol design

Executive Summary

Gozzip presents a thoughtful layered architecture that maps social trust onto storage infrastructure. The core insight -- that bilateral storage obligations within a Web of Trust create a self-reinforcing decentralized storage mesh -- is sound. The simulation work is honest and has led to meaningful corrections of the analytical models. However, this review identifies several structural issues in the protocol design: (1) the gossip layer delivers only 0.1-9% of reads yet imposes significant protocol complexity, raising questions about whether a simpler 3-tier architecture would achieve the same results; (2) the "relay as optional accelerator" framing is contradicted by simulation data showing 0.4-13% permanent relay dependency, making relay a load-bearing architectural component that deserves first-class treatment rather than rhetorical demotion; (3) NIP-46 relay-mediated channels for all pact communication introduce a permanent relay dependency into the protocol's most critical path; (4) bilateral volume matching excludes 60-80% of users (lurkers) from the pact economy; (5) the 2-hop WoT boundary creates a sharp cliff that may be too restrictive for real-world social graphs with heavy-tailed follow distributions; and (6) several alternative architectures would achieve comparable results with less complexity. None of these are fatal -- the protocol could ship as designed -- but they represent design decisions that should be revisited with production data.

Issues

1. The Gossip Layer May Not Justify Its Complexity

Severity: High

Description:

The protocol devotes substantial design effort to WoT-filtered gossip forwarding: TTL=3 hop propagation, fanout=8, per-source rate limiting, LRU deduplication caches, WoT-bounded forwarding rules, rotating request tokens for pseudonymous lookup, and gossip reach analysis grounded in small-world network theory. This is the most intellectually elaborate component of the protocol.

Simulation shows gossip delivers 0.1-9% of reads. The dominant delivery path is pact-local instant reads at 74-92%. Relay fallback handles 6-21%. Gossip is a rounding error in the delivery architecture.

The complexity cost of the gossip layer is real:

Client complexity: Every client must implement WoT graph computation (2-hop boundary evaluation for every forwarded message), gossip forwarding logic with priority queuing (active pact > 1-hop > 2-hop), TTL decrementing, request deduplication via LRU cache, rotating request token computation, rate limiting per source pubkey, and 64KB gossip payload size enforcement.
Bandwidth cost: The plausibility analysis computes 4.1 MB/day gossip overhead per online node. This is negligible per-node but is network-wide overhead for a mechanism that resolves fewer than 1-in-10 reads.
Privacy cost: Gossip forwarding creates a surveillance surface. Each forwarding node sees the rotating request token (trivially reversible by anyone who knows the target pubkey), the originator's pubkey, and the TTL (which reveals hop distance from the originator). The gossip fan-out pattern is distinguishable from vanilla Nostr traffic, as documented in surveillance-surface.md.
Design surface area: The gossip layer interacts with flow control (pact-aware priority), rate limiting, the WoT computation, and the retrieval cascade. Each interaction creates potential bugs and edge cases.

Consider the counterfactual: a 3-tier architecture with (1) pact-local reads, (2) direct pact-partner queries via cached endpoints, and (3) relay fallback. This eliminates the gossip layer entirely. Based on simulation data, pact-local reads handle 74-92% of traffic. Cached endpoint queries (Tier 2) would handle most of the remainder -- the requester already knows the target's pact partners from kind 10059 events and can query them directly. Relay fallback handles the rest. The 0.1-9% gossip contribution would be absorbed by slightly increased relay usage and more aggressive endpoint caching.

The whitepaper's own analysis supports this: "pact-local reads dominate at 74-92% of all retrievals" and "gossip's role is real but marginal -- it functions as a last-resort discovery mechanism before relay fallback, not as the primary delivery path the analytical model implies." If the protocol's own simulation confirms gossip is marginal, the complexity must be justified on grounds other than delivery percentage.

Possible justifications for keeping gossip:

Censorship resistance: Gossip provides a relay-independent discovery path for in-WoT content. If all relays are censored or offline, gossip is the only path between Tier 1/2 and total failure. This is the strongest argument, but it applies only to catastrophic relay failure scenarios.
Latency for 2-hop content: For content from friends-of-friends (2-hop WoT), gossip may discover a storage peer faster than relay fallback. But the 30s gossip timeout before relay fallback means this advantage is marginal.
Future value: As the network matures and pact coverage grows, gossip may become more important. But simulation shows the opposite trend -- gossip contribution decreases as pact-local reads increase.

Recommendation:

Consider making gossip an optional client feature rather than a required protocol component. Define the protocol with a 3-tier cascade (local, cached endpoint, relay) and specify gossip as an optional Tier 2.5 that clients may implement for censorship-resistance scenarios. This reduces the minimum viable client complexity substantially while preserving the option for sophisticated clients. If gossip proves more valuable in production than simulation suggests, promote it to a required tier later.

Alternatively, simplify the gossip mechanism dramatically: remove priority queuing, remove rate limiting (rely on WoT boundary + TTL as sufficient spam resistance), and reduce TTL to 2 (simulation shows most gossip value comes from 1-2 hop peers, not 3-hop). This retains the censorship-resistance benefit at lower complexity.

2. Relay Dependency Is Structural, Not Transitional -- The Framing Should Be Honest

Severity: High

Description:

The whitepaper frames the relay role as: "demoted from gatekeeper to optional accelerator, useful during bootstrap and for distant authors, but not required for typical social reading patterns." The conclusion states: "the relay is demoted from gatekeeper to optional accelerator." The implementation roadmap says: "relay dependency drops naturally as pacts form."

Simulation tells a different story. At network maturity (days 20-30), relay dependency ranges from 0.4% (BA m=10 sparse) to 13% (Watts-Strogatz and BA m=50+timezone). Only the sparsest topology achieves near-zero relay usage. All realistic topologies show 6-13% permanent relay reads.

More importantly, the protocol has several structurally permanent relay dependencies that will not diminish with pact maturity:

Content discovery beyond WoT: The whitepaper explicitly acknowledges this: "content discovery is permanently relay-dependent -- not a transitional artifact of the bootstrap phase." Finding new authors, trending topics, and content outside the 2-hop WoT boundary requires relays indefinitely.
NIP-46 pact communication: All pact negotiation, challenge-response, and event synchronization flows through relay-mediated encrypted channels. This is not a bootstrap artifact -- it is the permanent communication substrate for the protocol's most critical operations. Even "mature" pact relationships depend on relays for their ongoing communication (see Issue #3).
DM routing: DMs require relay-mediated delivery. The whitepaper acknowledges this with no proposed alternative.
Push notifications: Kind 10062 push token registration requires relay infrastructure.
Bootstrap and guardian pacts: New user onboarding is relay-dependent, and the network always has new users joining.
Lurker population: The whitepaper acknowledges that 60-80% of users are lurkers who "would continue operating in a relay-dependent mode indefinitely."

The gap between the rhetoric ("optional accelerator") and the reality (structurally permanent for 6-13% of reads, 100% of discovery, 100% of pact communication, 100% of DMs, and 100% of the lurker population) undermines credibility. A reviewer or potential adopter who discovers this gap will question what other claims are aspirational rather than architectural.

Recommendation:

Reframe the relay role honestly. Rather than "optional accelerator," describe relays as "a permanent infrastructure component whose control surface is reduced." The protocol does not eliminate relay dependency -- it reduces the consequences of relay failure for content storage and retrieval within the WoT. This is still a significant architectural improvement over vanilla Nostr, where relay failure means data loss. There is no need to oversell.

Specifically:

Replace "optional" with "reduced" or "diminished" in relay descriptions.
Acknowledge relay as a first-class protocol component, not a legacy artifact being phased out.
Quantify the permanent relay surface: discovery (permanent), DMs (permanent), pact communication (permanent unless direct connections are used), and content retrieval (0.4-13% at maturity, topology-dependent).
The honest framing strengthens the paper: "We reduce the relay from a single point of failure for data existence to an accelerator for content discovery and cross-WoT retrieval, while pact partners guarantee data survival independent of any relay" is more defensible and more true than "optional."

3. NIP-46 for All Pact Communication Creates a Permanent Relay Bottleneck

Severity: High

Description:

The protocol routes all pact communication through NIP-46 relay-mediated encrypted channels: pact negotiation (kind 10053), challenge-response verification (kind 10054), event synchronization, and gossip forwarding. The whitepaper lists the benefits: no NAT traversal, no IP exposure, no simultaneous online presence required, queued delivery for offline recipients.

These are real benefits. But routing the protocol's most critical path through relays creates several problems:

Latency: Every challenge-response round trip traverses: client -> relay -> partner -> relay -> client. This is at minimum 4 network hops for a single challenge-response exchange, compared to 2 hops for a direct connection. At 200ms per relay hop (the whitepaper's own Tier 4 latency estimate), a challenge-response cycle takes 800ms+ via relay vs. 60ms direct. The protocol sends challenges to 20 pact partners daily -- small individually, but the latency accumulates and the relay becomes a serialization point.
Relay as chokepoint for pact liveness: If a user's NIP-46 relay goes down, all challenge-response traffic for pacts using that relay fails. The relay-diversity document (relay-diversity.md) requires distributing pact communication across at least 3 relays, but even with 3 relays, each relay is a single point of failure for the pacts routed through it. A relay outage triggers the channel-aware retry logic, which adds 10 seconds of timeout before trying an alternative relay -- a 10-second delay in challenge-response for every affected pact, every time.
Relay operator visibility into pact operations: The surveillance-surface document acknowledges that relay operators see NIP-46 timing patterns and can infer pact pairings through timing correlation. Routing all pact communication through relays maximizes this surveillance surface. The relay-diversity document's mitigation (5 relays in privacy mode, 30-day rotation) reduces but does not eliminate this exposure.
Scaling: At 100,000 users with 20 pacts each, the daily challenge-response traffic alone is 2 million NIP-46 message pairs flowing through the relay network. Add pact negotiation, event sync, and gossip forwarding, and the relay network carries the full weight of the protocol's control plane.

The relay-diversity document proposes direct TCP connections as a fallback for full-full node pairs, but this is marked "opt-in" and exposes IPs. This is the correct direction but needs to be more prominent.

Recommendation:

Promote direct peer connections from "opt-in fallback" to "preferred path for full-node pairs." The protocol already has the infrastructure: kind 10059 endpoint events, NAT hole-punching signaling. For full-node-to-full-node pact pairs (which the equilibrium model estimates at 15-40% of all pact pairs based on the 25% full node ratio), direct connections should be the default, with relay-mediated NIP-46 as the fallback.

Consider adopting WebRTC or QUIC for direct peer connections. WebRTC is particularly well-suited because:

It handles NAT traversal natively (ICE/STUN/TURN).
It provides encrypted channels with forward secrecy (DTLS-SRTP).
It is available in every browser and most mobile platforms.
TURN servers can serve as the relay fallback, but unlike Nostr relays, they see only encrypted traffic with no application-layer metadata (no pubkeys, no event kinds, no timing patterns).

For light-node-to-full-node pairs, QUIC offers connection migration (survives IP changes when a phone switches networks) and 0-RTT resumption (fast reconnect after sleep). These are real advantages over NIP-46's relay-mediated approach for the intermittent connectivity pattern of mobile devices.

The hybrid approach: NIP-46 for initial contact and peer discovery, direct connections for ongoing pact operations, NIP-46 fallback when direct connections fail. This reduces relay dependency for the control plane while preserving the benefits of relay-mediated communication for initial setup and offline queuing.

4. Bilateral Volume Matching Excludes the Majority of Users

Severity: Medium-High

Description:

The protocol requires pact volume balance within 30% tolerance: |V_p - V_q| / max(V_p, V_q) <= 0.30. This means a user generating 675 KB/month (active) can only form pacts with users generating 473-878 KB/month. Power users at 2.2 MB/month cannot form pacts with casual users at 112 KB/month.

The whitepaper acknowledges the lurker problem: "60-80% of users are consumers who produce little or no content. These lurkers have minimal storage to offer pact partners, effectively excluding them from the bilateral pact economy." This is a critical design limitation, not a minor edge case. In every social network ever built, the vast majority of users are consumers.

The volume matching mechanism is motivated by a real concern: asymmetric obligations create incentive to defect. If Alice stores 2.2 MB for Bob but Bob only stores 112 KB for Alice, Bob benefits disproportionately. But the protocol's response -- excluding low-volume users from the pact economy entirely -- creates a two-tier network where only content creators get data sovereignty, while the majority remain relay-dependent.

This has cascading effects:

Reduced pact partner pool: Active users can only form pacts with other active users in their volume band. In a 100K network, if only 20-40% are content creators, the effective pact economy operates over 20-40K users. The WoT constraint further reduces the pool -- your pact partners must be both in your WoT and in your volume band.
Network effects work against you: In the bootstrap phase, the active user percentage is likely higher (early adopters tend to be power users). As the network grows to include mainstream users, the lurker percentage increases, and the effective pact economy shrinks as a fraction of total users.
Philosophical inconsistency: The protocol claims to "return data custody to the social graph." But the social graph includes lurkers -- they are the audience, the consumers, the social proof that makes content creation worthwhile. Excluding them from data sovereignty undermines the core value proposition.

Recommendation:

Consider alternatives to strict bilateral volume matching:

Asymmetric pacts with service exchange: Instead of requiring volume balance, allow pacts where one party stores more data in exchange for other services: gossip forwarding capacity, relay bandwidth contribution, or simply being an available query endpoint. A lurker who stores 112 KB for a power user but serves as a reliable query endpoint (forwarding requests to other pact partners) provides real value even without volume symmetry.
Volume bands with pooling: Group users into volume bands (casual, active, power) and allow cross-band pacts with explicit acknowledgment of asymmetry. A power user might accept 5 casual pacts (total 560 KB obligation, negligible) in exchange for the gossip reach those 5 casual users provide.
Community pact pools: Allow groups of lurkers to collectively form a pact pool that stores data for an active user. Ten lurkers each storing 220 KB collectively provide 2.2 MB of redundant storage for a power user, with the pool distributing challenge-response obligations.
Relax the tolerance: Increase the volume tolerance from 30% to 80% or remove it entirely. The equilibrium formation model already handles partner quality through the comfort condition -- if a low-volume partner is unreliable, the reliability scoring system drops them. Volume matching is solving a problem that reliability scoring already addresses.
Storage-for-compute: Allow asymmetric exchanges where a lurker offers compute resources (challenge verification, gossip forwarding, relay operation) instead of storage volume. This is closer to how real communities work: not everyone contributes the same thing.

5. The 2-Hop WoT Boundary Creates a Sharp Cliff

Severity: Medium

Description:

The protocol enforces a hard boundary at 2-hop WoT distance for gossip forwarding: "Nodes only forward gossip from pubkeys within their 2-hop WoT." This means content from a 3-hop peer is treated identically to content from a complete stranger -- both are dropped with zero forwarding.

The theoretical justification is sound: the epidemic threshold on the WoT subgraph needs to be non-trivial to prevent spam propagation, and the 2-hop boundary aligns with Dunbar's 150-person layer. The TTL=3 combined with the 2-hop forwarding boundary provides dual protection against runaway gossip.

However, real social graphs have properties that make a hard 2-hop boundary problematic:

Heavy-tailed follow distributions: In real social networks, most users follow a small number of accounts, but some follow thousands. The "2-hop WoT" for a user who follows 50 people is radically different from the "2-hop WoT" for a user who follows 500. The 2-hop boundary does not account for this heterogeneity.
Asymmetric follows: The protocol's WoT includes non-mutual follows (the "1-hop WoT tier" in the whitepaper). In Nostr, follows are predominantly unidirectional -- I follow a journalist, they do not follow me back. The 2-hop WoT based on directed follow edges creates an asymmetric reachability graph where popular accounts are reachable from many users, but those users are not reachable from the popular account. This is fine for content retrieval (the popular account's content propagates widely) but means requests for unpopular users' content have limited gossip reach.
Community bridging: Communities are connected by a small number of bridge nodes (the weak ties in Granovetter's framework). If the bridge node is at exactly 2-hop distance from both communities, gossip flows. If they are at 3 hops, the communities are gossip-disconnected. The hard boundary creates a fragile dependence on the specific hop count of bridge nodes.
The cliff effect: At 2 hops, a peer gets full gossip forwarding. At 3 hops, they get nothing. This binary transition does not match the gradual trust decay observed in real social networks. A 3-hop peer with 10 mutual connections is more trustworthy than a 2-hop peer with 1, but the protocol treats the latter as inside the boundary and the former as outside.

The epidemic threshold math in the whitepaper (Section 3.3) argues that the WoT restriction restores a non-trivial threshold by reducing the effective spectral radius. This is correct in principle but the paper does not actually compute the spectral radius of the realized WoT subgraph for any specific topology. The argument is qualitative ("substantially smaller") rather than quantitative. Without an actual bound on the spectral radius under 2-hop restriction, the claim that the threshold is "finite and non-trivial" is hand-waving.

Recommendation:

Consider a graduated trust model instead of a hard boundary:

Trust-weighted forwarding probability: Instead of forward/don't-forward, compute a forwarding probability based on WoT distance and mutual connection count. At 1 hop: forward with probability 1.0. At 2 hops: forward with probability proportional to mutual connection count. At 3 hops: forward with probability proportional to (mutual connections / threshold), capped at 0.3. This provides a soft boundary that degrades gracefully.
Compute the spectral radius: The qualitative argument about epidemic threshold should be supported with actual spectral radius computations on the simulated topologies. This would reveal whether the 2-hop boundary is unnecessarily restrictive (the threshold might be non-trivial even at 3 hops) or insufficient (the threshold might be near-zero even with the 2-hop restriction on dense graphs).
Adaptive boundary based on node degree: High-degree nodes (many followers) should use a stricter boundary (perhaps 1-hop) because their fan-out is already large. Low-degree nodes (few followers) could safely use a 3-hop boundary because their fan-out is small. This adapts the boundary to the local topology rather than applying a global constant.
At minimum, report sensitivity analysis: Run the simulation with WoT boundaries of 1, 2, and 3 hops and report the impact on gossip delivery, relay dependency, and spam propagation. This data would ground the 2-hop choice in empirical evidence rather than theoretical analogy.

6. The Rotating Request Token Provides Negligible Privacy

Severity: Medium

Description:

Data requests use a rotating token bp = H(target_pubkey || YYYY-MM-DD) for pseudonymous lookup. The whitepaper is commendably honest about its limitations: "trivially reversible by any party that knows the target's public key" and "a casual-observer deterrent, not a cryptographic blinding scheme."

The problem is that the token provides no privacy against the adversaries who actually matter:

Relay operators: Know all pubkeys published to them. Can pre-compute H(pubkey || date) for every known pubkey. Can resolve every request token to its target author instantly. The surveillance-surface document confirms: "Colluding relays with a directory of known pubkeys can resolve every request token to its target identity."
Pact partners: Know the target pubkey (they store the data). The token provides zero privacy against them.
WoT peers forwarding gossip: Know the originating pubkey and can infer the target from the request context (which users does the originator follow?).

The only adversary the token protects against is a passive observer who (a) intercepts a gossip message, (b) does not know any pubkeys, and (c) cannot compute a rainbow table. This adversary does not exist in practice -- anyone positioned to intercept gossip messages has at least partial knowledge of the network's pubkey space.

The token does provide one real property: it prevents cross-day request linkability for observers who are not actively targeting a specific pubkey. But day-boundary linkage is acknowledged in the protocol (storage peers match both today's and yesterday's tokens), so even this property is weakened.

Recommendation:

Either invest in proper privacy (PIR-style private information retrieval, or onion-routing for gossip requests) or remove the token and simplify the protocol. The current middle ground adds implementation complexity (token computation, dual-day matching, rotation logic) for negligible practical privacy.

If the token is kept for its minimal deterrence value, rename it in the documentation. "Rotating request token" and "pseudonymous lookup" imply more privacy than the mechanism provides. Consider "request routing key" or "daily lookup identifier" -- names that describe function without implying privacy properties.

7. Proof of Storage Is Weak Against Rational Adversaries

Severity: Medium

Description:

The challenge-response mechanism proves that a pact partner possesses data at challenge time. The whitepaper acknowledges this is weaker than Filecoin's Proof of Replication: "a malicious partner could theoretically re-fetch data before responding." The 500ms latency check on serve challenges is described as "a weak heuristic."

The weakness is more significant than the whitepaper suggests:

Re-fetch attack: A rational adversary stores only the most recent events (frequently challenged due to recency bias in real-world usage) and re-fetches older events from the author's other pact partners when challenged. The age-biased challenge distribution (50% oldest third, 30% middle, 20% newest) partially addresses this, but the adversary can optimize: store the oldest and newest thirds, discard the middle third, and maintain >80% challenge success while storing only 2/3 of the data.
Proxy attack: A pact partner could proxy all storage to a centralized backend (a relay, a cloud service) while presenting as a peer-to-peer storage node. The 500ms latency heuristic catches slow proxies, but a well-placed cloud proxy (same region, same datacenter) can respond under 500ms trivially. The partner appears to store data locally but is actually a relay frontend.
Hash collision preimage: The hash challenge requires computing SHA-256 over a range of events concatenated with a nonce. An adversary who stores only Merkle roots (not raw events) cannot respond to hash challenges, but an adversary who stores a compressed/deduplicated representation of events can reconstruct the required hash on demand.
Challenge frequency is too low: One challenge per day per pact partner means a defecting partner has a 24-hour window between challenges to purge data. The exponential moving average with alpha=0.95 means a single failed challenge barely moves the score (from 0.95 to 0.9025). A partner who defects 10% of the time maintains a score of ~0.90 -- still in the "healthy" range.

The whitepaper argues that "social trust reduces the need for cryptoeconomic enforcement." This is true for friends, but the protocol allows pact formation with 2-hop WoT peers -- friends-of-friends. The social trust at 2-hop distance is weak. A 2-hop peer has no personal relationship with you and minimal reputational consequence from defection.

Recommendation:

Increase challenge frequency for unproven partners. New pacts should face 4-8 challenges per day for the first 30 days, tapering to 1 per day after establishing a track record. This reduces the re-fetch window from 24 hours to 3-6 hours.
Add random-offset serve challenges: instead of requesting a specific event by sequence number, request a random byte range within an event. This prevents proxy attacks unless the proxy stores the full data (defeating the purpose of proxying).
Consider cross-verification: periodically, challenge partner A with data that partner B should also hold, and compare responses. If A and B give different answers for the same event range, one of them is defecting. This detects data corruption and selective storage without requiring a trusted third party.
Lower the "healthy" threshold from 90% to 95% and the "failed" threshold from 50% to 70%. The current thresholds are too permissive -- a partner who fails 10% of challenges is storing your data unreliably and should trigger replacement negotiation.

8. Pact Churn Creates a Fragile Equilibrium

Severity: Medium

Description:

Simulation reveals net-negative pact churn across all topologies tested: the network sheds more pacts than it forms after the bootstrap phase. Churn rates range from 2.79 pacts/node/day (BA m=10) to 8.04 pacts/node/day (BA m=50+TZ). The equilibrium-pact-formation document confirms: "In every run, more pacts are dropped than formed after the bootstrap phase."

This is a structural problem, not a simulation artifact. The protocol has multiple mechanisms that dissolve pacts (failed challenges, volume drift, reliability score degradation, OVER_PROVISIONED dissolution) but limited mechanisms that form new ones (the formation state machine only actively seeks pacts in BOOTSTRAP, GROWING, and DEGRADED states). The asymmetry is built into the state machine: COMFORTABLE nodes stop seeking, but they can still lose pacts.

The anti-thrashing mechanisms (hysteresis, jittered renegotiation, dissolution notice period, minimum tenure) slow the churn rate but do not address the fundamental asymmetry. They make individual transitions slower but do not change the net direction of pact flow.

The consequence: over long time horizons, pact counts drift downward toward a lower equilibrium than the comfort condition predicts. This means higher relay dependency than the design targets, and potentially a slow degradation loop where reduced pact counts -> reduced availability -> reduced perceived value -> reduced participation -> further pact count reduction.

Recommendation:

Add a pact renewal mechanism: when a pact has been healthy for 90+ days, automatically extend it with a lightweight renewal handshake (not a full renegotiation). This converts the default from "pacts dissolve unless actively maintained" to "pacts persist unless actively dissolved."
Reduce the dissolution trigger sensitivity. The reliability scoring EMA with alpha=0.95 reacts slowly to individual failures but the 50-70% "unreliable" band triggers replacement negotiation. Consider adding a minimum tenure override: pacts older than 90 days require a sustained failure rate (below 50% for 14 consecutive days) before triggering replacement, not a single crossing of the threshold.
Make the COMFORTABLE state more generous: comfortable nodes should continue accepting pact requests from GROWING and DEGRADED nodes even when at or above their comfort threshold, up to the ceiling. The current design says comfortable nodes "accept offers only if partner needs help" but this requires the comfortable node to evaluate the partner's state -- a cooperative action with no direct incentive.
Monitor and report the pact formation/dissolution ratio as a network health metric. If the ratio stays below 1.0 for extended periods, the protocol should automatically relax formation criteria (lower follow-age requirement, wider volume tolerance) to increase pact supply.

9. The 30% Volume Tolerance Is Arbitrary and Possibly Wrong

Severity: Low-Medium

Description:

The volume matching tolerance delta = 0.30 (30%) is a protocol constant with no stated derivation. The plausibility analysis uses it as an input constant without sensitivity analysis. The equilibrium-pact-formation document does not discuss how the tolerance interacts with the comfort condition.

30% is tight enough to exclude many natural pairings (a user who posts 20/day cannot form pacts with one who posts 30/day, because 30/20 = 50% > 30%) but loose enough to create meaningful asymmetry (a 30% volume difference on a power user's 2.2 MB/month means one partner stores 660 KB more than the other -- a real but manageable imbalance).

The problem is that activity levels are not stable. A user's posting rate varies by week (vacation, busy periods, news events), by month (seasonal patterns), and by life stage (new users post more, established users plateau). A pact formed during a period of matched activity may drift out of tolerance within weeks, triggering dissolution. The 30-day checkpoint window smooths some of this variance, but a user who posts heavily for 2 weeks and then goes quiet for 2 weeks will show high variance in their rolling volume.

The simulation evidence suggests this is happening: the net-negative pact churn may be partially explained by volume drift triggering pact dissolution. The equilibrium document's finding that "nodes dissolve marginal pacts" is consistent with volume-drift-driven dissolution.

Recommendation:

Report sensitivity analysis: run the simulation with delta = 0.50, 0.80, and 1.0 (no volume matching) and compare pact stability, churn rates, and availability. If relaxing the tolerance significantly reduces churn without introducing exploitable asymmetry, the tolerance should be relaxed.
Use rolling volume with hysteresis: compute volume match over a 90-day rolling window (not 30-day checkpoint) and only trigger dissolution when the mismatch exceeds delta for 3 consecutive checkpoints. This prevents transient activity spikes from destabilizing pacts.
Consider removing volume matching entirely and relying on the reliability scoring system to detect and remove defecting partners. The original motivation (preventing asymmetric obligation) is better addressed by making the protocol robust to asymmetry than by excluding it.

10. The Protocol Lacks a Coherent Bandwidth Accounting Model

Severity: Low-Medium

Description:

The plausibility analysis computes bandwidth requirements per user type, but the protocol itself has no mechanism for nodes to signal, negotiate, or enforce bandwidth constraints. A full node serving 80 pacts at 300 MB/day outbound has no way to tell the network "I am bandwidth-constrained" or to refuse pact requests based on bandwidth capacity. The pact formation model considers storage capacity (volume matching) and availability (uptime histograms) but not bandwidth.

This matters because bandwidth is the binding constraint for full nodes (53 MB storage is trivial, 300 MB/day outbound is meaningful) and for light nodes on cellular data plans. A full node on a 5 Mbps upload connection is rate-limited to ~625 KB/s -- enough for routine operations but insufficient for a viral-post spike from one of its 80 stored users.

The absence of bandwidth accounting means:

A full node cannot signal that it is overloaded. Pact partners continue sending events and challenges at the same rate regardless of the node's bandwidth situation.
The viral-post analysis (F-39, F-40) shows that a single viral event can spike per-peer bandwidth to 2.6 MB/s -- exceeding a 10 Mbps upload connection. The protocol relies on read-cache propagation to resolve this within seconds, but has no backpressure mechanism if the cache buildup is slower than expected.
Light nodes on metered connections cannot set a monthly bandwidth budget and have the protocol respect it.

Recommendation:

Add a lightweight bandwidth signaling mechanism to pact negotiation: nodes advertise their upload bandwidth capacity (or a bandwidth class: "fiber," "broadband," "cellular") in kind 10055 pact requests. The formation model should consider bandwidth class when selecting partners -- a user whose content is likely to receive many reads should prefer high-bandwidth pact partners.

For viral-post scenarios, implement explicit backpressure: when a storage peer's outbound queue exceeds a threshold, it responds to new data requests with a "retry-after" hint (a standard HTTP-style backpressure mechanism). Requesting clients switch to alternative storage peers or relay fallback. This is more robust than relying on read-cache propagation timing.

Alternative Architecture Analysis

The protocol's stated goal is decentralized storage and retrieval for social data. Several alternative architectures achieve this goal with different trade-offs. This section compares the Gozzip approach against three alternatives.

A. DHT-Based (IPFS/libp2p Model)

Architecture: Content-addressed storage with a distributed hash table for lookup. Each piece of content is identified by its hash. Nodes participate in a Kademlia-style DHT to resolve content hashes to node addresses. Nodes voluntarily pin content they care about.

What it does well:

Content discovery is O(log N) DHT lookups -- no need for WoT boundary, gossip forwarding, or relay fallback.
Content deduplication is automatic (content-addressed).
No pact negotiation, volume matching, or challenge-response -- nodes pin what they want.
Battle-tested at scale (IPFS has millions of nodes).

What it does poorly:

No social-graph-aware routing. The DHT does not know who your friends are; it treats all content as equally important. Gozzip's pact model ensures your close contacts' data is always available; IPFS ensures popular content is available but has no mechanism for unpopular-but-important data (your friend's posts that only you read).
No bilateral obligation. IPFS pinning is unilateral -- you pin content because you choose to, not because someone stores your content in return. This means your data survives only as long as someone chooses to pin it.
Sybil vulnerability in the DHT. Eclipse attacks on Kademlia are well-documented. Gozzip's WoT-bounded pact formation provides Sybil resistance that DHTs lack.
High metadata exposure. DHT lookups reveal which content a node is seeking to every node on the lookup path.

Verdict: DHT-based systems solve content retrieval better than Gozzip (no gossip layer needed, O(log N) lookup) but solve content persistence worse (no bilateral obligation, no social-graph-aware redundancy). Gozzip could potentially use a DHT for beyond-WoT content discovery (replacing the relay fallback tier) while retaining the pact model for within-WoT storage guarantees. This hybrid would eliminate the weakest part of Gozzip's architecture (relay-dependent discovery) using the strongest part of the DHT model (efficient content lookup).

B. Erasure Coding (Storj Model)

Architecture: Content is split into N pieces using Reed-Solomon erasure coding, distributed to N storage nodes. Any K-of-N pieces suffice to reconstruct the original (typically K = N/3). Storage nodes are paid via cryptocurrency. Retrieval queries go to random subsets of the N nodes.

What it does well:

Mathematically optimal redundancy: K-of-N reconstruction is the most storage-efficient way to survive node failures. Gozzip's full-replication model (every pact partner stores a complete copy) uses 20x the storage for similar availability guarantees.
Paid storage eliminates the cooperative-equilibrium fragility. Nodes store data because they are paid, not because of social obligation. The net-negative pact churn problem does not exist.
No volume matching needed -- the payment handles asymmetry.

What it does poorly:

Requires a payment layer (cryptocurrency, tokens). This is a massive adoption barrier for a social networking protocol.
No social-graph awareness. Storage nodes are selected for availability and price, not social proximity. Your data might be stored by nodes on the other side of the world who have no social relationship with you.
Latency: erasure-coded retrieval requires fetching K pieces from different nodes and reconstructing locally. This is slower than Gozzip's pact-local instant reads (which deliver 74-92% of reads with zero network latency).
Centralization risk: Storj's storage node network tends toward large operators running many nodes. The economic incentives favor professionalized storage, not peer participation.

Verdict: Erasure coding is more storage-efficient than full replication, but the payment requirement and lack of social-graph awareness make it unsuitable as a direct replacement. However, Gozzip could use erasure coding for archival storage: instead of every pact partner storing a complete copy, encode events into K-of-N shards distributed across pact partners. This reduces per-partner storage from 675 KB to ~225 KB (with K=N/3 and 20 partners) while maintaining the same availability guarantee. The challenge-response mechanism would need modification to verify shard possession rather than full-event possession.

C. Mutual Pinning (SSB Pub Model, Bilateralized)

Architecture: The simplest possible version of Gozzip: bilateral pinning agreements between peers, with no gossip layer, no tiered retrieval cascade, and no WoT-bounded forwarding. Users form mutual storage agreements with friends. Each partner stores a complete copy. Retrieval is direct query to known partners, with relay fallback.

What it does well:

Minimal protocol complexity. No gossip forwarding, no TTL management, no rotating request tokens, no WoT boundary computation. The protocol is: form pacts, store data, serve queries.
Same storage availability as Gozzip (the pact model is identical).
Same pact-local read performance (74-92% of reads are pact-local in Gozzip's own simulation).
The relay fallback handles the remaining 8-26% of reads.
Easier to implement, audit, and reason about.

What it does poorly:

No gossip-based discovery path. If cached endpoints fail and the relay is down, there is no intermediate tier. Gozzip's gossip tier (0.1-9% of reads) provides a censorship-resistant fallback between cached endpoints and relay.
No cascading read-caches from gossip propagation. Popular content relies entirely on pact partners and relays for distribution.
No WoT-bounded spam resistance in the forwarding layer (but there is no forwarding layer to spam).

Verdict: This is the strongest alternative and the closest to what Gozzip's own simulation data suggests is happening in practice. The simulation shows that pact-local reads dominate (74-92%), relay handles most of the rest (6-21%), and gossip is marginal (0.1-9%). A simplified mutual-pinning protocol would achieve approximately the same delivery profile with substantially less complexity. The cost is losing the gossip tier's censorship-resistance properties, which are real but marginal based on current data.

Synthesis

The analysis suggests that Gozzip's core innovation -- bilateral storage pacts with challenge-response verification within a WoT -- is valuable and defensible. The surrounding infrastructure (gossip forwarding, WoT-bounded propagation, rotating request tokens, tiered retrieval cascade) adds complexity that is not fully justified by current simulation data.

A pragmatic architecture would:

Keep the pact model exactly as designed (it is the protocol's strongest contribution).
Simplify the retrieval cascade to 3 tiers: pact-local, cached endpoint, relay.
Specify gossip as an optional extension for censorship-resistance scenarios.
Consider erasure coding for storage efficiency (reducing per-partner obligation).
Consider a DHT or decentralized discovery mechanism for beyond-WoT content, reducing permanent relay dependency for discovery.
Adopt direct peer connections (WebRTC/QUIC) for pact communication where possible, using NIP-46 as fallback rather than default.

This would produce a simpler, more defensible protocol that achieves 95%+ of Gozzip's stated goals with perhaps 60% of the implementation complexity.