12 KiB
Morpheus — Threat Model & Workarounds
Legal Posture
Morpheus is a compliant, principled operation:
- We register where required and operate within applicable law
- We respond to lawful data requests with data we actually have
- We use NIP-44 end-to-end encryption for DMs — meaning DM content is not data we have in readable form
- We will never add backdoors, key escrow, or weaken encryption under any circumstances
- We are transparent: if asked for data we cannot provide, we explain why
This is the Apple/WhatsApp model applied to social networking: cooperate fully, but the architecture makes certain requests technically impossible.
The Core Distinction: Private ≠ Anonymous
Morpheus is private, not anonymous.
| Anonymous | Private (Morpheus) | |
|---|---|---|
| Identity | Hidden, disposable | Real, persistent, reputation-bearing |
| Public content | Untraceable to author | Author known — that's the point |
| DMs | Nobody can read them | Nobody can read them (NIP-44) |
| Metadata | Hidden (Tor-level) | Available to relay operators |
| Legal posture | Evades identification | Compliant; encryption protects content |
| Vibe | Dark web, paranoia | Normal social life with real protection |
Morpheus position: "Everyone knows your name. Nobody reads your messages."
NIP-44 encrypts the content of direct messages. Metadata (who talked to whom, when) is visible to relay operators. This is an honest and defensible position: we protect the conversation, not the fact that it happened.
Problem 1: Target Audience vs. Value Proposition Mismatch
Problem: Teens don't buy "privacy." They buy speed, aesthetics, and social status.
Workarounds:
-
Lead with product, not protocol. Marketing never mentions Nostr, relays, or encryption upfront. It says: "the fastest social app" or "group chats that actually work."
-
Privacy as texture, not feature. Instead of a "privacy settings" page, privacy manifests as:
- A subtle lock icon on DMs (always there, never toggleable — it just works)
- "Messages are encrypted" shown once during onboarding, then never again
- No "last seen" or "read receipts" by default (privacy = social comfort for teens)
-
Speed IS the feature. Teens compare apps by how fast they feel. Invest disproportionately in perceived performance: optimistic UI, instant message sending, preloaded feeds, aggressive caching.
-
Social proof matters more than features. Get 5 popular creators on the platform before public launch. Teens follow people, not protocols.
Problem 2: Nostr Technical Limitations
Problem: Nostr lacks native support for features teens expect.
2a. Group Chats
Current state: NIP-29 (relay-based groups) is basic. No rich features.
Workaround:
- Build on NIP-29 for public groups (relay-moderated, discoverable)
- For private groups: use NIP-44 encryption with a shared group key, rotated when members change
- Implement group features at the client level: replies, reactions, pins, mentions, threads
- This is custom work but gives competitive advantage — "best group chats on Nostr"
2b. Media Hosting
Current state: Nostr events are text. Media requires external hosting.
Workaround:
- Run managed Blossom (BLOb Simple Storage) servers for media uploads
- NIP-96 file storage as standard — users upload via the app, served via CDN
- Aggressive client-side compression (WebP/AVIF for images, H.265 for video)
- Progressive loading: thumbnail → medium → full resolution
- Storage quota tied to account tier (free = reasonable, Pro = generous)
- Content-addressed storage (deduplication by hash) saves costs
2c. Search & Discovery
Current state: No global search. Relay search is relay-specific.
Workaround:
- Client-side full-text index of followed users' content (SQLite/Realm on device)
- "Explore" powered by curated relay aggregation — Morpheus runs an indexing relay
- Trending topics computed from public event volume across Morpheus community relays
- Hashtag-based discovery (NIP-12 generic tag queries)
- "People you might know" based on social graph overlap (computed client-side, not server-side)
- Human-curated featured accounts and communities (editorial, not algorithmic)
2d. Key Management / Identity Recovery
Current state: Lose your nsec = lose everything. Unacceptable for teens.
Workaround:
- Social key recovery (primary): Shamir's Secret Sharing — split the recovery key among N trusted contacts, require K of N to reconstruct. "Choose 5 friends. Any 3 can help you recover your account."
- Encrypted cloud backup (optional): Encrypt nsec with a user-chosen passphrase, store encrypted blob in iCloud/Google Drive. User controls the encryption key.
- Device-bound keys: Store nsec in device Secure Enclave / Android Keystore. Biometric unlock. Key never leaves the device in plaintext.
- NIP-46 (Nostr Connect): Remote signer pattern — the key lives in a signer app, Morpheus never touches it directly. Advanced users can use this.
- Progressive disclosure: New users get device-bound key + cloud backup prompt. Power users can export nsec and manage it themselves.
2e. Stories / Ephemeral Content
Current state: No native Nostr primitive for disappearing content.
Workaround:
- Use NIP-40 (expiration timestamp) on events — relays delete after TTL
- Client enforces expiration display-side (even if a rogue relay keeps the event)
- Stories rendered as a carousel of kind:20 (short text notes) or kind:1063 (file metadata) events with 24h expiration
- Not truly "disappearing" in the Signal sense — but matches Instagram/Telegram stories UX
Problem 3: Government Blocking
Problem: Roskomnadzor can block relay domains and IPs.
Context: Morpheus operates compliantly, but blocking may happen regardless (as it did with Telegram in 2018-2020). The goal is not to evade law enforcement — it's to ensure service availability for users.
Workarounds:
Layer 1: Standard resilience
- WebSocket over TLS (wss://) looks like normal HTTPS traffic to DPI
- Run relays behind Cloudflare or similar CDN — blocking the CDN blocks millions of sites
- Multiple relay domains in different TLDs — redundancy, not evasion
- App automatically falls back to working relays if some are unreachable
Layer 2: Distribution resilience
- Android: available via Google Play, RuStore, direct APK download, F-Droid
- iOS: App Store, PWA as fallback if removed from store
- Web app always available as baseline
- APK/PWA links shared via existing channels (Telegram bots, QR codes)
Layer 3: Proactive engagement
- Engage with regulators proactively — explain what data we have and provide it
- Demonstrate compliance willingness to reduce motivation for blocking
- Maintain dialogue — blocking is often a negotiation, not a binary
Note: If Morpheus is blocked despite compliance, the Nostr protocol ensures users can access their data through any other Nostr client. Their social graph and messages are not locked in our infrastructure. This is the ultimate resilience.
Problem 4: Legal Compliance (Yarovaya Law / SORM)
Problem: Russian law requires storing and providing access to user communications.
Approach: Cooperate fully, explain architecture honestly.
-
Register as required. Operate a legal entity (jurisdiction TBD based on legal advice). Register as an information distribution organizer if required.
-
Store what we can store. Public posts, metadata, connection logs — these exist on our relays and we can provide them.
-
Explain what we cannot store. DM content is encrypted client-side with NIP-44. We never hold decryption keys. This is not evasion — it is the documented, auditable architecture. We cannot provide what we do not have.
-
Open source supports our claims. Any technical audit of the codebase will confirm that the server never has access to plaintext DMs. This is verifiable, not just claimed.
-
Legal precedent. WhatsApp, Signal, and iMessage operate E2E encryption in many jurisdictions. The legal landscape for E2E encryption is complex but there is significant precedent.
-
No user registration data collection beyond what's needed. If registration requires phone/email for legal compliance, we collect it. But we don't collect more than required.
The key principle: We never refuse to cooperate. We explain the technical reality. What is encrypted is encrypted — not because we choose not to decrypt it, but because we cannot.
Problem 5: Monetization Without Ads
Problem: No ads, ever. Need alternative revenue.
Approach: See monetization.md. Summary:
- Morpheus Pro subscription (premium features, customization, higher limits)
- Sticker/theme marketplace (creator economy with commission)
- Creator tools (paid analytics, subscriber-only content)
- Business profiles (flat monthly fee, organic reach only)
- Managed relay hosting (infrastructure-as-a-service for communities)
All revenue streams are opt-in and require no user profiling.
Problem 6: Content Moderation
Problem: Teens on the platform require responsible content moderation without undermining privacy.
Approach:
-
Public content is moderatable. Public posts are... public. We can and will moderate public content on relays we operate. Standard community guidelines apply. This does not conflict with privacy — public speech has never been "private."
-
Encrypted DMs are not moderatable by us — and that's okay. Just like the postal service doesn't read your letters. Client-side safety features (block, report, mute) give users control.
-
Layered moderation for public content:
- Relay-level: Morpheus-operated relays enforce published community guidelines (no CSAM, no doxxing, no harassment). Content that violates guidelines is removed from our relays.
- Community-level: Group moderators manage their own spaces. NIP-56 reporting flows to moderators.
- Client-level: Spam filters, content warnings, mute/block tools.
-
CSAM compliance: Hash-matching (PhotoDNA or equivalent) on media uploaded to Morpheus-operated media servers. This is a non-negotiable legal and ethical obligation. Happens server-side on the media CDN before content is distributed.
-
Transparency reports. Publish quarterly: how many moderation actions, how many legal requests, what data was provided. Build trust through accountability.
Problem 7: Cold Start / Network Effects
Problem: A social network with no users is useless.
Workarounds:
-
Launch as a messenger first, social network second. Group chats don't need network effects — they need 5-10 friends. "Move your friend group to Morpheus" is a tractable pitch.
-
Telegram bridge. Bot that cross-posts between Telegram groups and Morpheus groups. Reduces switching cost. Users can migrate gradually.
-
Target specific communities, not "everyone":
- University student groups
- Gaming communities
- Music/art scenes
- Tech-savvy early adopters
-
Creator partnerships. Get popular Russian content creators to use Morpheus. Their audiences follow.
-
"Import your group" feature. Create a Morpheus group from an existing Telegram/VK group, auto-invite members. Minimize friction.
-
Referral mechanics. "Invite 3 friends → unlock exclusive sticker pack." Simple, proven, no ads needed.
-
Ship a killer feature that doesn't exist elsewhere:
- Voice messages with automatic transcription (huge in Russian-speaking communities)
- Built-in meme editor
- Anonymous Q&A on profiles (like ASKfm — fun and viral)
- Superior sticker creation tools