Deployment Reality Review: Mobile Constraints, App Store Compliance, and Production Feasibility

Reviewer perspective: Mobile app developer and production systems engineer Date: 2026-03-14 Documents reviewed: Whitepaper (v1.2), push-notifications.md, key-management-ux.md, media-layer.md, monitoring-diagnostics.md, genesis-bootstrap.md, moderation.md, gdpr-deletion.md Review type: Adversarial -- focused on what breaks when theory meets deployment

Executive Summary

Gozzip is an ambitious and intellectually honest protocol. The whitepaper acknowledges its own gaps more candidly than most academic work. The design documents demonstrate real engineering thought, not just protocol idealism. The push notification architecture is well-researched. The key management UX document correctly identifies the core tension (cryptographic security vs. user comprehension) and proposes reasonable solutions.

However, the protocol has a fundamental tension that no design document resolves: it requires always-on infrastructure to function, but frames itself as eliminating infrastructure dependency. The "5-25% full node ratio" is not a decentralized network -- it is a distributed server fleet operated by volunteers. The protocol's availability, pact verification, gossip delivery, and push notifications all depend on these full nodes existing, being reliable, and being geographically distributed. This is not a criticism of the architecture -- it is the correct architecture -- but the framing obscures the deployment reality.

The protocol is approximately 18-24 months of engineering work for a team of 4-6 developers. The design documents describe a system that would require simultaneous expertise in iOS/Android native development, cryptographic protocol implementation, distributed systems, and Nostr ecosystem integration. A 2-developer team shipping in 6 months would need to cut approximately 70% of the protocol.

The mobile experience -- which will be 80-90% of users -- is where the protocol faces its hardest constraints. iOS and Android aggressively limit background execution, and the protocol's core mechanisms (challenge-response, gossip forwarding, pact sync) all assume the app can do meaningful work in the background. The push notification design correctly identifies this problem and proposes a workable solution, but the solution reintroduces centralized infrastructure (notification relays) that the protocol claims to eliminate.

Bottom line: The protocol is sound in theory and honest about its limitations. But shipping it requires either (a) a significantly larger team and timeline than a typical startup, or (b) aggressive scoping that defers most of the protocol's distinguishing features to post-launch. Option (b) is the correct choice, and the result would look remarkably similar to "a good Nostr client with encrypted backup."

Issue 1: Mobile Background Execution is a Protocol Breaker

Severity: Critical

The protocol assumes light nodes (75% of the network, essentially all mobile users) can participate in storage pacts, respond to challenges, forward gossip, and sync events. The whitepaper acknowledges that "iOS BGAppRefreshTask and Android Doze limit true background uptime to 0.3-5%" but then asserts this is acceptable because "full nodes dominate the availability guarantee."

This understates the problem. The issue is not just availability -- it is protocol participation:

Challenge-response on mobile. A pact partner challenges your phone. Your phone is in Doze mode. The challenge times out. Your reliability score drops. After enough timeouts, your pact is dropped. You lose your reciprocal storage. This is not a theoretical concern -- it is the default mobile behavior. iOS grants BGAppRefreshTask approximately 30 seconds of execution time, scheduled at the OS's discretion (typically 1-4 times per hour for well-behaved apps). Android's WorkManager periodic tasks have a minimum interval of 15 minutes and are subject to Doze deferral.

The exponential moving average with alpha=0.95 means a single failed challenge barely moves the score. But mobile devices will fail most challenges when the app is not in the foreground. A phone that is actively used 2 hours per day has ~8% foreground time. The remaining 92% of challenges will time out unless the push notification system wakes the app -- but waking the app for challenges is not what the push notification system is designed for.

Gossip forwarding on mobile. The protocol expects light nodes to forward gossip to their WoT peers. A phone in Doze mode cannot forward anything. When 75% of the network cannot forward, gossip propagation degrades to forwarding through the 25% of full nodes. The gossip layer becomes a server-mediated relay layer by another name.

Pact sync on mobile. When a pact partner publishes a new event, the mobile device needs to receive and store it. If the phone's app is suspended, the event sits on the relay until the phone wakes up and syncs. During that window, the phone cannot serve the event to anyone. This is fine for the "witness" role (30-day window storage), but it means the phone is effectively a write-only backup that can serve data only when the user is actively using the app.

Recommendation: Accept that mobile devices are consumers, not infrastructure. Light nodes should receive data but never be expected to serve it reliably. Challenge-response should use asymmetric timing: full nodes respond within 10 seconds, light nodes within 24 hours. Gossip forwarding should be full-node-only. The protocol should be redesigned around 100% of protocol infrastructure being provided by the 5-25% of full nodes, with mobile devices as beneficiaries, not participants.

Issue 2: App Store Compliance is Not Guaranteed

Severity: High

Apple's App Store Review Guidelines (Section 2.5.1) prohibit apps that "browse the web, general file sharing, or act as extensions of other apps." More relevantly, Section 4.2.6 requires that apps "not act as general-purpose storage containers or facilitate file sharing between apps." The P2P storage pact mechanism, where your phone stores other users' encrypted data, could be interpreted as general-purpose file storage.

Specific Apple concerns:

Background processing abuse. Apple is aggressive about apps that consume background execution time for non-user-facing tasks. Storage challenges, gossip forwarding, and pact sync are all background tasks that benefit other users, not the device owner. Apple has rejected apps for excessive background processing that does not directly serve the user. The BGAppRefreshTask documentation explicitly states: "Use this task to update your app's content from the server."
Encrypted data storage. Storing other users' NIP-44 encrypted blobs on the device creates a "you're storing content you can't inspect" situation. Apple may ask what data the app stores and why. "We store encrypted data for other users as part of a peer-to-peer storage protocol" is a difficult pitch to App Review.
Battery and data consumption. If the app is noticeable in the battery usage screen (Settings > Battery), users will uninstall it. The whitepaper estimates 1-3% battery for background sync only, 10-20% for background + BLE. The 10-20% figure is a non-starter. Even 3% is noticeable and will generate 1-star reviews. For context, Signal uses approximately 1% of battery per day.
BLE mesh. Using Bluetooth for data relay between devices requires specific Apple entitlements (Core Bluetooth background modes) and is scrutinized during review. Apple approves BLE background mode for fitness devices, medical devices, and accessories -- not for ad-hoc mesh networking. The BLE mesh (Tier 0) will likely require a separate review process and may be rejected outright.

Google Play concerns are similar but less severe. Google is more permissive about background processing and P2P functionality. However, Android 15's "limited background starts" further restrict when apps can perform background work.

Recommendation: For App Store submission, strip the app to its Nostr client functionality. Pact storage should be limited to the user's own data + their directly followed contacts' recent events (defensible as "caching content the user wants to see"). Challenge-response and gossip forwarding should be foreground-only features. BLE mesh should be a separate build for TestFlight/sideloading, not the App Store submission.

Issue 3: UX Complexity Exceeds User Tolerance

Severity: High

Signal's UX model: install the app, verify your phone number, message people. Zero new concepts.

Gozzip's UX model requires the user to eventually understand or interact with: storage pacts, pact partners, pact health, challenge-response results, WoT distance, full nodes vs. light nodes, Keepers vs. Witnesses, bootstrap phase vs. hybrid phase vs. sovereign phase, root keys, governance keys, device subkeys, DM key rotation, social recovery guardians, relay selection, notification relay registration, media pacts (separate from text pacts), blocklist subscriptions, moderation service subscriptions, deletion requests, and checkpoint verification.

The key-management-ux.md document does excellent work hiding the key hierarchy from standard users. The "zero key management" goal is the right goal. But the pact layer has no equivalent UX simplification document. The monitoring-diagnostics.md document describes a comprehensive dashboard with per-pact health indicators, challenge pass rates, volume balance ratios, WoT visualizations, and relay compatibility scores. This is a power-user tool, not a consumer app.

The concept-count problem. Research on cognitive load in application design (Nielsen Norman Group, various) suggests that users can effectively manage 3-5 novel concepts in an application. Gozzip introduces approximately 15-20 novel concepts, even with good UX hiding most of them. When something goes wrong (a pact degrades, a challenge fails, storage fills up), the user is confronted with concepts they never signed up to understand.

Comparison to competitors:

Signal: 0 novel concepts. It is a phone app that sends messages.
WhatsApp: 0 novel concepts. Same.
Telegram: 1 novel concept (channels/supergroups as distinct from chats).
Mastodon: 2-3 novel concepts (instances, federation, content warnings).
Nostr: 3-4 novel concepts (keys, relays, follows, zaps).
Gozzip: 15-20 novel concepts.

Each additional concept reduces the addressable market. Signal has 40M+ DAU. Mastodon peaked at ~2.5M MAU with its 2-3 extra concepts. Nostr has ~200K MAU with 3-4 extra concepts. The correlation is not causal, but it is directional.

Recommendation: Reduce the user-facing concept count to 3 or fewer. The pact layer should be invisible -- no "pact health dashboard" in v1. Users should see "your data is backed up across your network" as a single status indicator, not a 7-column table with color-coded health scores. The sovereignty phase progression (Bootstrap/Hybrid/Sovereign) should never be visible to users -- it is an internal state machine detail.

Issue 4: The Bootstrap Chicken-and-Egg is Really a Server Problem

Severity: High

The genesis-bootstrap.md document is admirably honest. It proposes 5-10 operator-controlled VPS nodes running as Genesis Guardians for 6-12 months at a cost of $3,000-7,000. These nodes provide storage for all new users, accept bootstrap pacts, and serve as high-uptime pact partners.

This is a server deployment. The Genesis Guardians are Nostr relays with extra responsibilities. The framing ("temporary centralized scaffolding") obscures a deeper truth: the protocol always needs these servers. The genesis-bootstrap.md document defines sunset conditions that require 1,000+ Sovereign-phase users and organic guardian supply exceeding Seedling demand. It also defines failure conditions: if after 12 months, sovereignty ratio is below 5% and Genesis nodes serve >80% of guardian pacts, the bootstrap strategy has failed.

The failure conditions are the likely outcome. Comparable decentralized systems (the whitepaper itself notes this) achieve 0.1-5% always-on node participation. If 5% of users run full nodes and the network has 10,000 users, that is 500 full nodes. With 20 pacts per node, that is 10,000 pact slots -- enough to serve the network. But reaching 10,000 users requires the bootstrap infrastructure, and the bootstrap infrastructure is servers.

The timeline to organic sustainability is optimistic. Mastodon launched in 2016 and still depends on a small number of large instances (mastodon.social alone hosts 348K+ accounts). Matrix launched in 2014 and matrix.org remains the dominant homeserver. The pattern is clear: centralized bootstrapping infrastructure tends to become permanent infrastructure.

The "relay-as-Keeper" model acknowledged in the failure conditions section is actually the correct architecture. Relay operators already run always-on servers. Adding pact partner functionality to relays (accept pacts, respond to challenges, store user data with bilateral obligations) is a natural extension. This is not a failure -- it is a pragmatic deployment model where relay operators are the full nodes, and the protocol's contribution is adding reciprocal obligations and challenge-response verification to the relay-user relationship.

Recommendation: Embrace the relay-as-Keeper model from day one. Do not frame it as a failure condition. The Genesis Guardians should be branded as the project's relay fleet, with a clear path for community operators to run their own. The sunset conditions should be reformulated: success is "community-operated Keepers exceed project-operated Keepers," not "users run their own full nodes."

Issue 5: Content Moderation is Legally Insufficient for EU/US Launch

Severity: High

The moderation.md document is thoughtful and well-structured. The comparison to Bluesky's labeling model is apt. The WoT boundary as a structural anti-harassment measure is genuinely novel and defensible.

However, the document has a critical gap: it does not address the legal obligations of the app publisher. The app that ships on the App Store and Google Play has a legal entity behind it. That entity is subject to the Digital Services Act (EU), the Online Safety Act (UK), and various US state laws. "The protocol does not enforce content policy" is a protocol design principle, not a legal defense.

Specific concerns:

CSAM: The hash-matching approach is necessary but insufficient. The moderation.md document correctly identifies CSAM as a hard exception. The relay-level hash matching (PhotoDNA, PDQ) and client-side perceptual hash checking are the right approach. However, obtaining access to NCMEC's hash database requires organizational application, vetting, and ongoing reporting obligations. A 2-person startup may not qualify. PDQ (Meta's open-source alternative) is more accessible but less comprehensive.
DSA designated-contact requirements. The Digital Services Act requires "intermediary services" (which includes hosting services) to designate a point of contact for authorities and a legal representative in the EU. The protocol's "no central authority" design does not exempt the app publisher from these requirements. Someone has to be the designated contact.
Pact partner liability. The moderation.md document asserts a "common carrier" principle for pact partners: "A pact partner stores data. They are not responsible for the content of that data." This is legally untested for peer-to-peer social media storage. Common carrier protections (Section 230 in the US, Article 14 of the E-Commerce Directive in the EU) apply to hosting providers who do not have knowledge of illegal content. A pact partner who receives a CSAM report and does not act could be held liable. The document's CSAM section addresses this with "immediate deletion," but the legal framework around peer-to-peer CSAM storage has not been tested in court.
The "no default blocklists" principle is admirable but impractical. The moderation.md document states: "No client should pre-subscribe users to any blocklist without explicit opt-in." In practice, App Store reviewers and regulators will expect the app to provide some baseline content filtering. Apple's App Store guidelines (Section 1.2) state: "Apps should not include content that is offensive, insensitive, upsetting, intended to disgust, in exceptionally poor taste, or just plain creepy." An app with zero default content filtering will face review challenges.

Recommendation: Ship with a default moderation service operated by the project. Frame it honestly: "We operate a default content filter. You can disable it or switch to alternatives." This is what Bluesky does, and it works. The "no default" principle is correct at the protocol level but wrong at the product level. The protocol should not mandate a default; the app should ship with one.

Severity: Medium

The gdpr-deletion.md document is unusually honest for a decentralized protocol project. It explicitly acknowledges that deletion cannot be cryptographically guaranteed, that BLE mesh copies may persist, and that non-compliant nodes cannot be compelled. The "reasonable efforts" framing aligns with GDPR Recital 66.

Concerns:

72-hour deletion window for pact partners. GDPR Article 17 says "without undue delay and in any event within one month." The 72-hour target is more aggressive than required, which is good. But the enforcement mechanism (pact degradation) is a social incentive, not a technical guarantee. A DPA (Data Protection Authority) asking "can you guarantee deletion?" will get the answer "no, but we incentivize it." This is honest but may not satisfy all regulators.
Controller-controller model. The GDPR analysis correctly identifies each pact partner as an independent data controller. This is the right legal framing. However, it means each pact partner has independent GDPR obligations -- including providing their own privacy notice, responding to data subject access requests, and maintaining records of processing activities. Individual users running light nodes on their phones are unlikely to comply with these obligations. A DPA could interpret this as the protocol creating an ecosystem of non-compliant controllers.
Cross-border transfers. The document acknowledges that "pact partners may be in any jurisdiction" and that a DPIA is required. Under GDPR Chapter V, transferring personal data to a country without an adequacy decision requires appropriate safeguards (Standard Contractual Clauses, binding corporate rules, etc.). A bilateral storage pact does not constitute appropriate safeguards. Users cannot meaningfully consent to cross-border transfers to unknown pact partners in unknown jurisdictions.

Recommendation: For EU launch, the app should default to pact formation only with partners in adequate jurisdictions (EU, EEA, adequacy-decision countries). This limits the pact pool but avoids cross-border transfer issues. The DPIA should be completed before beta launch, not deferred to "before EU launch."

Issue 7: Push Notifications Reintroduce Central Infrastructure

Severity: Medium

The push-notifications.md document is the best-designed document in the set. It correctly identifies the problem ("the single most important UX gap versus Signal"), proposes a workable architecture, and honestly acknowledges the privacy trade-offs.

However, the architecture reintroduces the centralized dependency the protocol claims to eliminate:

Notification relays are servers. They maintain WebSocket subscriptions, hold push tokens, and deliver wake-up signals via APNs/FCM. They are functionally equivalent to a simplified relay with push delivery capability. The project will operate 1-2 notification relays during bootstrap. Users are expected to register with 2-3 notification relays for redundancy. This is a server fleet.
APNs/FCM dependency is unavoidable. Every mobile messaging app uses APNs/FCM for push delivery. This is correctly acknowledged in the document ("This is a platform reality, not a protocol compromise"). But it means the protocol's messaging functionality depends on Apple and Google infrastructure -- the same platforms the protocol positions itself against.
The notification relay knows the social graph. The document acknowledges this: "The notification relay learns timing metadata: 'user X received an event matching filter Y at time T.'" With 2-3 notification relays, the metadata is distributed but not eliminated. A notification relay operator can reconstruct who messages whom and when.

What works well: The pact-partner-as-notification-proxy design (Section 6) is elegant. If a user has a full-node pact partner, that partner can trigger push notifications on behalf of the mobile user, reducing the notification relay's metadata exposure. This is the right architecture -- but it requires the user to have a full-node pact partner, which circles back to the full-node availability problem.

Recommendation: Accept the notification relay as permanent infrastructure, not bootstrap scaffolding. Budget for operating 3-5 notification relays across geographic regions as a long-term operational cost. The pact-partner proxy should be the recommended path for users who care about metadata privacy, with the project-operated notification relay as the default for everyone else.

Issue 8: The Full-Node Economics Don't Close

Severity: Medium

The protocol requires 5-25% of users to run always-on full nodes (Keepers). The whitepaper frames this as "one technical friend in every friend group runs the server." The genesis-bootstrap.md estimates $20-50/month per VPS node.

Who pays for this? The protocol offers no economic incentive for running a full node. The incentive is social: "reliable storage reciprocity" and "gossip priority boost." In practice:

A VPS costs $5-50/month depending on specs.
Electricity for a home server costs $5-15/month.
A Raspberry Pi costs $35-75 upfront plus $3-5/month electricity.
Bandwidth costs vary but can be significant for full nodes serving media pacts.

The whitepaper's bandwidth calculations show full-node outbound at 301-333 MB/day (3.6-4.0 GB/month for text pacts alone). This is within typical VPS bandwidth allowances but adds up across 20+ pact partners.

Comparison to relay economics: Nostr relay operators can charge for access (~$5-20/month per user). Mastodon instance operators fund through donations (Patreon, OpenCollective). Matrix homeserver operators are typically organizations, not individuals. Gozzip full node operators have no revenue path. The "pay-it-forward" framing relies on altruism -- the same incentive structure the whitepaper identifies as having "nobody volunteers" as the Nash equilibrium for guardian pacts.

Recommendation: Design an economic model for full nodes. Options: (a) Lightning micropayments for pact storage (extends the NIP-57 zap model), (b) relay operators bundle full-node service with relay access (pay for relay, get pact storage included), (c) the project operates a fleet of full nodes funded by donations/grants. Option (b) is the relay-as-Keeper model from Issue 4 and is the most practical.

Issue 9: Media Pacts Create Unrealistic Storage Obligations

Severity: Medium

The media-layer.md document correctly separates media from event storage. The "events are metadata, media is data" principle is the right design. The volume calculations are reasonable.

However, media pacts require Keepers (90%+ uptime) to store 675 MB - 2 GB per partner for 90 days. With 5 media pact partners, a Keeper stores 675 MB - 2 GB of someone else's photos. This is fine for a VPS with a 100 GB disk. It is less fine for a home server or Raspberry Pi where storage is limited.

The real problem is volume matching for media. The document uses +/-100% tolerance (vs. +/-30% for text). This means a user producing 30 MB/month of media can be matched with a user producing 60 MB/month. Over 90 days, that is a 90 MB vs. 180 MB obligation asymmetry. The higher-volume user stores twice as much for their partner as they receive in return. The wider tolerance is necessary because media volume is bursty, but it weakens the reciprocity incentive.

Video is unaddressed. The document acknowledges this in Open Questions: "Video files (10MB-500MB) may need a chunked storage model." A single 2-minute 720p video is ~15 MB. A user who posts one video per day generates 450 MB/month of media. This is 3x the "heavy-media" scenario in the calculations. Social media trends toward video (TikTok, Instagram Reels, YouTube Shorts). A protocol that handles images but not video is addressing the media landscape of 2015, not 2026.

Recommendation: Defer media pacts to post-launch. Ship with CDN-based media (url_hint in media tags) and content-addressed verification. Media sovereignty is a nice-to-have; text sovereignty is the core value proposition. If video support is needed, investigate chunked storage with erasure coding rather than full-blob replication across 5 partners.

Issue 10: The 30-Day Follow-Age Requirement Kills Growth

Severity: Medium

Pact formation requires "at least 30 days of mutual follow history." This means a new user who joins and immediately follows 50 people cannot form any pacts for 30 days. During this period, they are entirely relay-dependent plus whatever bootstrap/guardian pacts they can get.

The genesis-bootstrap.md relaxes this to 7 days during bootstrap (<1,000 users), scaling back to 30 days at 3,000 users. But even 7 days is a long time in app retention terms. Mobile app retention data (Adjust, AppsFlyer) shows that ~70% of users who install an app never return after day 1. By day 7, retention is typically 15-25%. By day 30, it is 5-10%.

This means 75-90% of users will never reach the follow-age requirement for pact formation. They will experience Gozzip as a Nostr client with no sovereignty benefits. The protocol's distinguishing features only activate for the 10-25% of users who survive the first month -- and those users are already the most engaged, most technical, and most tolerant of complexity.

Recommendation: Reduce the follow-age requirement to 72 hours for the first year of operation. The Sybil protection that follow-age provides can be supplemented with other signals: account age, event publication history, social graph density (how many of the followed user's followers also follow this user). The 30-day requirement is appropriate for a mature network where Sybil attacks are a real threat; it is counterproductive for a network trying to grow.

Issue 11: Monitoring and Diagnostics is Over-Specified for Launch

Severity: Low

The monitoring-diagnostics.md document describes a comprehensive diagnostic system with pact health dashboards, gossip propagation debugging, relay interaction logging, WoT visualization with community detection, and protocol-level tracing. This is excellent engineering documentation.

It is also approximately 3-4 months of development work. For a 2-developer team with a 6-month timeline, implementing the monitoring system described in this document would consume 25-50% of the entire development budget.

What is actually needed at launch: A single screen showing "Your data: backed up (18 copies)" or "Your data: not yet backed up -- keep using the app to build your network." One number. One color (green/yellow/red). Everything else can wait.

Recommendation: Ship priorities 1-2 from the document's own priority list (pact health dashboard, challenge-response diagnostics) in simplified form. Everything else is post-launch.

Issue 12: Simpler Alternatives Deliver 80% of the Value

Severity: Strategic (not a bug, but a question the project must answer)

Alternative A: Nostr relay with built-in replication. Run 3-5 Nostr relays that replicate events between each other (negentropy sync, NIP-77). Users publish to any relay; all relays have all events. Add the key hierarchy (kind 10050) and social recovery (kinds 10060/10061) as client-side features. Result: multi-device identity, encrypted DMs, censorship resistance through relay diversity, social recovery. Cost: 5 VPS nodes at $20-50/month each. Development time: 3-4 months for a competent Nostr developer.

What you lose: peer-to-peer storage sovereignty, WoT-filtered gossip, pact-based reciprocal storage. What you gain: a shipping product in 4 months with 90% of the user-facing value.

Alternative B: Signal with social features. Fork Signal's server (open source) and add public posting (feed), follows, and reactions. Signal already has: end-to-end encryption, push notifications, multi-device, key management, group messaging. Adding a social feed is ~2-3 months of work. Result: encrypted messaging + social feed with Signal's UX quality. Cost: Signal server hosting ($500-2,000/month at scale).

What you lose: decentralization, censorship resistance, protocol interoperability, data sovereignty. What you gain: the best UX in the category, existing user trust in Signal's brand, and a shipping product.

Alternative C: Nostr client with encrypted local backup. Build a Nostr client that encrypts the user's event history and backs it up to iCloud/Google Cloud. If a relay deletes their data, they restore from backup. Add the key hierarchy and social recovery as client features. Result: data sovereignty through encrypted backup, multi-device identity, social recovery. Development time: 4-5 months.

What you lose: peer-to-peer storage, censorship resistance beyond what Nostr relays provide. What you gain: a product that ships, works on mobile without background processing, passes App Store review trivially, and provides real data sovereignty (your backup, your iCloud, your encryption key).

The strategic question: Is the delta between Alternative C and full Gozzip worth 12-18 additional months of development? The answer depends on whether the target audience values peer-to-peer storage sovereignty over "encrypted backup to my own cloud account." For 95% of users, the answer is no. For journalists, activists, and dissidents, the answer may be yes -- but that is a niche market, not a consumer product.

What Would Actually Ship

A 2-developer team with 6 months and a mission to ship a working product would build the following:

Month 1-2: Foundation

Nostr client core. Event publishing, feed display, profile management, follow lists. Use existing Nostr libraries (nostr-tools for JS, rust-nostr for native). Target iOS first (SwiftUI), Android second (Jetpack Compose), or React Native for both.
Key hierarchy. Root key + device subkeys (kind 10050). Root key in platform secure storage (Keychain/Keystore). No cold storage, no hardware wallet, no advanced mode.
Encrypted DMs. NIP-44 encryption with dedicated DM key. Threading support.

Month 3-4: Differentiation

Social recovery. Kind 10060/10061 with 3-of-5 threshold. Simple UI: "Choose 3 friends who can help you recover your account."
Push notifications. Integrate with a single notification relay (project-operated). APNs + FCM. Silent wake-up, content-free push. This is the most critical UX feature.
Device-to-device delegation. QR code scan for adding a new device. 7-day temporary delegation confirmed via synced keychain.
Encrypted backup. Encrypt event history to root key, back up to iCloud/Google Cloud. Restore on new device. This replaces the entire pact layer for the MVP.

Month 5: Polish

Media support. Content-addressed media tags with url_hint. CDN upload (nostr.build, void.cat). Thumbnail generation. No media pacts.
Basic content filtering. NIP-32 label support. Subscribe to 1-2 community labeling services. Mute and block.
Relay management. NIP-65 relay list configuration. Basic relay health indicators.

Month 6: Ship

TestFlight/Play Store beta. Fix bugs, iterate on UX, gather feedback.
Deploy project infrastructure. 3 Nostr relays (different regions), 1 notification relay, 1 Genesis Guardian node (for future pact layer activation).

What Gets Deferred

Pact layer (storage pacts, challenge-response, equilibrium-seeking formation). This is the protocol's core innovation but requires 6-9 months of additional development and is not needed for a functional product.
Gossip layer (WoT-filtered forwarding, rotating request tokens, tiered retrieval). Depends on the pact layer.
Media pacts. Depends on the pact layer and full-node infrastructure.
BLE mesh / FIPS integration. Significant engineering effort with niche use cases.
Monitoring and diagnostics dashboard. Not needed until the pact layer ships.
Moderation services integration. NIP-32 labels are sufficient for launch.
GDPR deletion protocol. Standard NIP-09 deletion is sufficient for launch. Kind 10063 with pact-partner propagation can wait.
Guardian pacts. No pact layer means no guardian pacts. The Genesis Guardian nodes serve as reliable relays instead.
Advanced key management. Hardware wallet, governance key on separate device, manual key export. Power-user features for post-launch.

What This Product Is

A Nostr client with three genuine differentiators: multi-device identity with device delegation, social recovery for key loss, and encrypted cloud backup for data sovereignty. These features work without any peer-to-peer infrastructure, pass App Store review, work on mobile without background processing heroics, and provide real value from day one.

The pact layer, gossip routing, and WoT-filtered storage -- the protocol's core innovations -- ship in version 2.0, after the client has users, after the Genesis infrastructure is running, and after the team has grown to handle the engineering complexity.

The Honest Framing

The MVP is "the best Nostr client with real key management and data backup." The full Gozzip protocol is the vision that justifies building the client. The path from MVP to vision is 18-24 months with a team of 4-6, and the intermediate milestones (each phase delivering independent value) are well-described in the whitepaper's implementation roadmap. The roadmap's instinct -- "transition, not revolution" -- is correct. The MVP should embody that instinct by shipping what works today and earning the right to ship what requires infrastructure tomorrow.