What Hermes is

End-to-end encrypted DMs over Nostr, addressed by your on-chain registered name instead of a public-key string. The desktop client (inside Theseus) is live today; the browser messenger is in progress. This page shows the UI, the plan, and what still has to land before the browser version ships.

Preview. The desktop messenger inside Theseus is live today — threaded chat, persistent history, address book, keyboard shortcut Ctrl+Shift+E. The web-only client (what this page becomes) is in development: BIP-39 → Nostr key derivation, BCH-name resolution via gateway, NIP-17 wrap/unwrap, WebSocket to relays, IndexedDB inbox. Everything client-side, nothing uploaded.
Hermes · hermes.x/messenger
your npub: npub1ab…z89 1/1 relay
bob
023bf8c1…9ad2
hey, did you register your name yet?11:38
just now — bob.x is live11:40
nice. send me the hermes.x link11:42
https://hermes.x/messenger11:43
great, send me the link11:44
Non-interactive preview — live build pending (see roadmap below).

Two clients, one identity

Desktop (Theseus) live

  • Full crypto in-process (NIP-17, nip44 v2)
  • Persistent inbox + read-state on disk
  • Address book (local JSON + vCard import)
  • Sidebar panel, Ctrl+Shift+E shortcut
  • Vault-bind: no re-typing the mnemonic
  • Reverse-resolve pk → on-chain name

Web (this page) building

  • Same crypto, same identity (same wallet seed derivation)
  • BCH name resolution via public gateway
  • WebSocket to Nostr relays from the browser
  • IndexedDB inbox — survives tab close, scoped to this origin
  • No download, no install, no account
  • Mnemonic entry only — never stored in plaintext

Why wait for the web client

The web messenger isn't ready yet because of three things we want to get right before shipping:

  1. Key handling in a tab. A wallet mnemonic is the most sensitive bit of data a user has. In the desktop app it lives in main-process memory; in a tab it has to survive page reloads without ever landing in plaintext anywhere. We're wiring a WebCrypto-backed non-extractable key path with the vault PIN as the gate.
  2. Resolver gateway. The desktop talks to a chipnet Fulcrum directly. A browser can't — it needs an HTTPS gateway that answers np / nr for a name. The gateway is live (navigate.st/api/dns/alice.x) but the client-side cache + signature-verification path still has an edge case with lapsed names.
  3. Relay persistence. Desktop keeps a long-lived WebSocket to each relay. A tab doesn't, because browsers throttle background sockets. The web client needs offline queueing and a well-defined "catch-up" fetch on return — otherwise you re-open the tab and the inbox feels empty.

Until the three are solid, install Theseus for the real thing. The web client will land here when the above are green.