Roadmap: yap → personal Telegram replacement (desktop + Android)

[melvincarvalho]

Vision

Grow yap from a minimal chat into a personal / family Telegram replacement — your messages on your pod (durable, identity-anchored) delivered live over nostr relays (cross-device, NAT-traversing). Same build-free web codebase ships as web → desktop → Android.

Scope note: we're aiming at the personal/family model first (your devices + people who'll accept npub-based contacts + your own relay & pod). Mass-market, phone-number onboarding is a separate, much bigger bet — explicitly out of scope here.

Shipped (v1)

• Pod rooms — Solid Chat model (meeting:LongChat + flow:Message) stored/read as JSON-LD via content negotiation; read + post + poll(4s)
• Nostr rooms — per-device keys, kind:42 events keyed by a #t tag, live over the relay socket, no pod/login needed
• Default relay wss://melvin.me/relay (editable via Device), nostr:<name> rooms + ?chat=<url> deep links
• Purple, minimal UI; verified live (browser → melvin.me → browser roundtrip)

Phase 1 — durable & reliable messaging

• Pod ↔ nostr mirroring: one room = live nostr delivery + durable LongChat history on the pod
• Multi-relay write/read (NIP-65 relay lists) + cross-relay dedupe for redundancy
• History backfill on open (since/limit) + pagination

Phase 2 — notifications (the "feels like an app" unlock)

• Web Push (VAPID) + service worker
• Relay → Web Push gateway service (watches the relay for events addressed to you, fires a push) — the one non-client piece; runs on melvin.me / the pod server
• Unread badges, per-room mute

Phase 3 — identity, contacts, privacy

• Resolve per-device keys vs one-account-many-devices: person identity + QR device pairing + history sync
• Contacts/discovery: npub exchange, NIP-05 names, NIP-02 follow lists
• Encrypted DMs (NIP-17 / NIP-44 / NIP-59 gift wrap) — can beat Telegram's non-E2E default

Phase 4 — media & richer messages

• Media upload to your pod (and/or NIP-96 / Blossom), inline render (reuse gallery / instant)
• Markdown, reactions (schema:ReactAction / NIP-25), edit/delete, replies/threads

Phase 5 — desktop app

• Tauri/Electron shell over jspod (cf. JavaScriptSolidServer/solid-desktop) with a bundled local relay — makes the LAN/offline path one-click and dodges the mixed-content constraint below
• Tray, native notifications, auto-launch

Phase 6 — Android app

• Capacitor wrap (or TWA): install, background, secure key storage, native push (FCM bridge), share-target
• QR pairing for multi-device

Later / stretch

• Group chat with real membership + group E2E (MLS-style) — genuinely hard
• Voice/video calls (WebRTC + nostr signaling)

Key constraints & decisions

• Mixed content: browsers block an https:// page from opening an insecure ws:// socket. So a plain-ws:// LAN relay only works when yap is served over http (local jspod / the desktop shell). wss://melvin.me works from gh-pages anywhere. → drives the "bundled local relay in the desktop shell" approach (Phase 5).
• Push gateway (Phase 2) is the single biggest lift toward the Telegram feel and the only piece that isn't pure client-side.
• Identity model (Phase 3): per-device keys are great for "my gadgets"; Telegram users expect one account across devices. Decide deliberately — likely support both.
• Encryption: DMs first (tractable); group E2E later.

Suggested order

Phase 1 (durability) and Phase 2 (push) give the biggest jump in "real app" feel; Phase 5 (desktop + bundled relay) makes the local/LAN story turnkey. Each phase can ship independently behind the existing room UI.