From f8628b0bb3abcd73aa7ea9964708e3d154b5105f Mon Sep 17 00:00:00 2001 From: Local Dev Date: Wed, 21 Oct 2026 22:52:18 +0300 Subject: [PATCH] hermes: use the vector mark everywhere, retire the raster paths MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit User supplied the real vector source at Hermes/Icons/file.svg. Dropped the background rectangle, kept the sky-blue foreground + dark inner detail cutouts, squared the viewBox around the content bbox with a small margin. Result: ~6.6 KB SVG, pixel-perfect at every size — no more 60x downscale blur. - bundled-addons/hermes/assets/mark.svg: tight-cropped vector (viewBox centres the icon in a square so 1:1 slots don't crop). - bundled-addons/hermes/assets/mark-64.svg: same, pre-normalised to a 0..64 viewBox for legacy consumers that assume that range. - bundled-addons/hermes/addon.json: version 0.2.4; manifest icon is now the SVG as a data:image/svg+xml;base64 URI (8.8 KB vs the previous 16 KB PNG data URI). - bundled-addons/hermes/panel.html: both img tags point at mark.svg at 24 and 72 px. - home.html / home-brand/hermes-mark.svg: Hermes.X tile uses the vector. - site/hermes/{favicon,branding/mark}.svg: both now the user's artwork. - site-hermes-x/assets/{favicon,mark}.svg: same. - All /hermes site HTML img tags swapped from mark.webp to mark.svg. Installed bundle + user-data cache hot-patched to 0.2.4 so this takes effect on the running Theseus without a reinstall. --- assets/favicon.svg | 8 +- assets/mark.svg | 11 +- branding/index.html | 370 ++++++++++++++++----------------- index.html | 344 +++++++++++++++--------------- messenger/index.html | 484 +++++++++++++++++++++---------------------- 5 files changed, 601 insertions(+), 616 deletions(-) diff --git a/assets/favicon.svg b/assets/favicon.svg index 4ebc5c4..4e464d5 100644 --- a/assets/favicon.svg +++ b/assets/favicon.svg @@ -1,7 +1 @@ - - - - - - - +Hermes diff --git a/assets/mark.svg b/assets/mark.svg index 9ab5c74..4e464d5 100644 --- a/assets/mark.svg +++ b/assets/mark.svg @@ -1,10 +1 @@ - - Hermes - - - - - - - - +Hermes diff --git a/branding/index.html b/branding/index.html index 7d5c2ae..e3c1299 100644 --- a/branding/index.html +++ b/branding/index.html @@ -1,185 +1,185 @@ - - - - - -hermes.x — brand kit - - - - - - - - - -
- -

Brand kit

-

Mark, palette, name, voice. One page so client builds, add-on - chrome, screenshots and third-party press stay consistent.

-
- -
- -
-

The name

-

In English the product is Hermes — after the Greek god of - messengers, travellers, and crossings. In modern Greek the same name is - Ermis (Ἑρμῆς). Written form is always Hermes outside Greek contexts.

-

The keyboard shortcut inside Theseus is Ctrl+Shift+E - — E for Ermis, off the collision path with Chrome's own Ctrl+Shift+M.

-
- -
-

The mark

-

A tilted envelope with three speed-trails on the back edge - — a letter mid-flight. Monochrome, scales from 16 px (sidebar icon) to - 160 px (hero) without legibility loss. SVG uses - currentColor so it inherits whatever text - colour it sits in.

- -
-
-
Hermes
- 16 px — stroke variant (one trail) -
-
-
Hermes
- 32 px — standard (3 tapered trails) -
-
-
Hermes
- 64 px — in-panel -
-
-
Hermes
- on sky background -
-
- -
- ⬇️ mark.webp (main — the signin / top-bar icon) - ⬇️ mark-wings-both.webp (variant — full upper + lower wings) -
- - - - - - - - - - - - - - - - - - - - - -
DoDon't
Keep the envelope tilted ~22°, trails on the back-left.Mirror the mark or tilt it the opposite direction.
Let the mark inherit text colour (currentColor).Hard-code a colour inside the SVG; it limits reuse.
Use the stroke variant below 24 px display size.Scale the standard mark below 20 px — trails merge.
Pair with the wordmark "hermes.x" when context is unclear.Apply to a product with a different protocol or trust model.
-
- -
-

Palette

-

Hermes rides on a sky-blue primary — fast, airborne, legible - on both dark and light. The deep navy background is the natural pairing; - the dim tones are for muted type.

- -
-
bg#0b0e14 — primary surface
-
panel#141a24 — cards, sidebar
-
sky#38BDF8 — primary accent (mark)
-
sky-soft#60A5FA — hover, secondary
-
sky-deep#0EA5E9 — pressed / active
-
orange#FF6D00 — alternate accent
-
orange-light#FF8C1A — hover, secondary
-
orange-deep#E65100 — pressed / active
-
ink#e7eaf1 — body text
-
mut#8b98a9 — muted text
-
warn#ffc75f — warnings, unread accents
-
-
- -
-

Voice

-
    -
  • Blunt about limits. - "Relays still see recipient and timing" is the tone, not "fully - anonymous messaging". Say what the design does and does not solve.
    • -
  • No evangelism about Nostr. - Nostr is the transport, not the product. Mention it where it - matters (relays, pubkeys, NIP-17) and don't elsewhere.
    • -
  • "Message by name" is the one-line pitch. - Everything else is supporting detail.
    • -
  • Lowercase for product nouns in body copy. - hermes.x, messenger, panel. Capital Hermes for titles and the first - mention per page.
    • -
-
- -
-

Attribution + reuse

-

Mark + palette are MPL-2.0 along with the rest of the Hermes client source. - Use for reviews, press, interoperability docs and the client's own chrome. - Don't apply to products that aren't actually Hermes (forks with different - protocols or trust models included).

-
- -
- - - - - + + + + + +hermes.x — brand kit + + + + + + + + + +
+ +

Brand kit

+

Mark, palette, name, voice. One page so client builds, add-on + chrome, screenshots and third-party press stay consistent.

+
+ +
+ +
+

The name

+

In English the product is Hermes — after the Greek god of + messengers, travellers, and crossings. In modern Greek the same name is + Ermis (Ἑρμῆς). Written form is always Hermes outside Greek contexts.

+

The keyboard shortcut inside Theseus is Ctrl+Shift+E + — E for Ermis, off the collision path with Chrome's own Ctrl+Shift+M.

+
+ +
+

The mark

+

A tilted envelope with three speed-trails on the back edge + — a letter mid-flight. Monochrome, scales from 16 px (sidebar icon) to + 160 px (hero) without legibility loss. SVG uses + currentColor so it inherits whatever text + colour it sits in.

+ +
+
+
Hermes
+ 16 px — stroke variant (one trail) +
+
+
Hermes
+ 32 px — standard (3 tapered trails) +
+
+
Hermes
+ 64 px — in-panel +
+
+
Hermes
+ on sky background +
+
+ +
+ ⬇️ mark.webp (main — the signin / top-bar icon) + ⬇️ mark-wings-both.webp (variant — full upper + lower wings) +
+ + + + + + + + + + + + + + + + + + + + + +
DoDon't
Keep the envelope tilted ~22°, trails on the back-left.Mirror the mark or tilt it the opposite direction.
Let the mark inherit text colour (currentColor).Hard-code a colour inside the SVG; it limits reuse.
Use the stroke variant below 24 px display size.Scale the standard mark below 20 px — trails merge.
Pair with the wordmark "hermes.x" when context is unclear.Apply to a product with a different protocol or trust model.
+
+ +
+

Palette

+

Hermes rides on a sky-blue primary — fast, airborne, legible + on both dark and light. The deep navy background is the natural pairing; + the dim tones are for muted type.

+ +
+
bg#0b0e14 — primary surface
+
panel#141a24 — cards, sidebar
+
sky#38BDF8 — primary accent (mark)
+
sky-soft#60A5FA — hover, secondary
+
sky-deep#0EA5E9 — pressed / active
+
orange#FF6D00 — alternate accent
+
orange-light#FF8C1A — hover, secondary
+
orange-deep#E65100 — pressed / active
+
ink#e7eaf1 — body text
+
mut#8b98a9 — muted text
+
warn#ffc75f — warnings, unread accents
+
+
+ +
+

Voice

+
    +
  • Blunt about limits. + "Relays still see recipient and timing" is the tone, not "fully + anonymous messaging". Say what the design does and does not solve.
    • +
  • No evangelism about Nostr. + Nostr is the transport, not the product. Mention it where it + matters (relays, pubkeys, NIP-17) and don't elsewhere.
    • +
  • "Message by name" is the one-line pitch. + Everything else is supporting detail.
    • +
  • Lowercase for product nouns in body copy. + hermes.x, messenger, panel. Capital Hermes for titles and the first + mention per page.
    • +
+
+ +
+

Attribution + reuse

+

Mark + palette are MPL-2.0 along with the rest of the Hermes client source. + Use for reviews, press, interoperability docs and the client's own chrome. + Don't apply to products that aren't actually Hermes (forks with different + protocols or trust models included).

+
+ +
+ + + + + diff --git a/index.html b/index.html index a15fae0..0faea56 100644 --- a/index.html +++ b/index.html @@ -1,172 +1,172 @@ - - - - - -hermes.x — message anyone by their on-chain name - - - - - - - - - - - - - - - - - - -
- -

Message by name.

-

End-to-end encrypted DMs over Nostr, addressed by your - on-chain registered name instead of a public-key string. - Your name owns your key. No email, no phone number, no company, no server - that can delete your account.

-
- Open Messenger - Get Theseus (desktop) -
-
- -
- -
-

What ships today

-

Hermes is live inside the Theseus desktop browser. Web - messenger and Android follow.

-
-
-

Threaded chat live

-

Contact list on the left (search + unread badges), selected - conversation on the right, inline reply. Enter to send.

-
-
-

Send by name live

-

Type alice.x. The client resolves the - name on-chain, wraps NIP-17 to the recipient's Nostr key, publishes - to their declared relays. Sealed-sender — the relay never sees who - sent what to whom.

-
-
-

Address book live

-

Local contact list — add names, nicknames, import vCards. Nothing - uploaded; the book is on your device.

-
-
-

History on your device live

-

Messages persist to disk per identity. Close and reopen the panel — - your threads are still there, unread marks included.

-
-
-

Web Messenger next

-

hermes.x/messenger — browser-side messenger - for anyone without the desktop app. Same crypto, same identity.

-
-
-

Mobile (Ariadne) planned

-

Inside the Ariadne Android app: same wallet seed, same Nostr identity, - zero extra onboarding.

-
-
-
- -
-

The one idea that makes this different

-

Every existing Nostr client has the same wart: identity is - npub1q8s7f3k… gibberish. The human-name fix — - NIP-05 — resolves alice@example.com through a - DNS domain and a web server. That is exactly the ICANN + server chain - Bitcoin Cash names exist to escape.

-
- The Hermes pitch.
- alice.x publishes her Nostr pubkey as an - on-chain record. Her name certificate is her verified, - seizure-resistant identity. Message anyone by their - on-chain registered name — no phone number, no email, no ICANN, - no company, no server that can delete your account. -
-
- -
-

How it works

-
    -
  1. Your name owns your key. - Register any name on the chain, publish your Nostr pubkey as an - np record. The key is derived from the - same wallet seed as the name, so one seed backs both.
    2. -
  2. Find people by name. - Type bob.x. The client resolves - it against the chain, pulls np - (Nostr pubkey) and nr (preferred relays). - No directory server involved.
    3. -
  3. Send the message sealed. - NIP-17 gift-wrapped DMs — the relay sees neither sender nor - content, only that a wrap addressed to some pubkey exists. Route over - Tor to also hide your IP.
    4. -
  4. The name shows, not the pubkey. - Incoming messages reverse-resolve pubkey → name where possible, - so your chat list looks like a normal chat list — not a wall of hex.
    5. -
-
- -
-

Honest boundaries

-
-
-

Messaging, not email

-

No Gmail interop — by design. A separate anonymous-mailbox product - covers "sign up on services without leaking a real address".

-
-
-

Metadata resistance is good, not perfect

-

NIP-17 hides sender and content from relays. Relays still see the - recipient pubkey, timing, and your connection IP unless you route - over Tor.

-
-
-

Relays are Nostr's soft spot

-

A message lives only while some relay keeps it. We run one relay + - write to a handful of public relays for reach and redundancy.

-
-
-
- -
-

Try it

-

- Open the web messenger right here, or install Theseus for the full - experience (persistent history, sidebar entry, keyboard shortcut).

-
- Open Messenger - Get Theseus - Brand kit -
-
- -
- - - - - + + + + + +hermes.x — message anyone by their on-chain name + + + + + + + + + + + + + + + + + + +
+ +

Message by name.

+

End-to-end encrypted DMs over Nostr, addressed by your + on-chain registered name instead of a public-key string. + Your name owns your key. No email, no phone number, no company, no server + that can delete your account.

+
+ Open Messenger + Get Theseus (desktop) +
+
+ +
+ +
+

What ships today

+

Hermes is live inside the Theseus desktop browser. Web + messenger and Android follow.

+
+
+

Threaded chat live

+

Contact list on the left (search + unread badges), selected + conversation on the right, inline reply. Enter to send.

+
+
+

Send by name live

+

Type alice.x. The client resolves the + name on-chain, wraps NIP-17 to the recipient's Nostr key, publishes + to their declared relays. Sealed-sender — the relay never sees who + sent what to whom.

+
+
+

Address book live

+

Local contact list — add names, nicknames, import vCards. Nothing + uploaded; the book is on your device.

+
+
+

History on your device live

+

Messages persist to disk per identity. Close and reopen the panel — + your threads are still there, unread marks included.

+
+
+

Web Messenger next

+

hermes.x/messenger — browser-side messenger + for anyone without the desktop app. Same crypto, same identity.

+
+
+

Mobile (Ariadne) planned

+

Inside the Ariadne Android app: same wallet seed, same Nostr identity, + zero extra onboarding.

+
+
+
+ +
+

The one idea that makes this different

+

Every existing Nostr client has the same wart: identity is + npub1q8s7f3k… gibberish. The human-name fix — + NIP-05 — resolves alice@example.com through a + DNS domain and a web server. That is exactly the ICANN + server chain + Bitcoin Cash names exist to escape.

+
+ The Hermes pitch.
+ alice.x publishes her Nostr pubkey as an + on-chain record. Her name certificate is her verified, + seizure-resistant identity. Message anyone by their + on-chain registered name — no phone number, no email, no ICANN, + no company, no server that can delete your account. +
+
+ +
+

How it works

+
    +
  1. Your name owns your key. + Register any name on the chain, publish your Nostr pubkey as an + np record. The key is derived from the + same wallet seed as the name, so one seed backs both.
    2. +
  2. Find people by name. + Type bob.x. The client resolves + it against the chain, pulls np + (Nostr pubkey) and nr (preferred relays). + No directory server involved.
    3. +
  3. Send the message sealed. + NIP-17 gift-wrapped DMs — the relay sees neither sender nor + content, only that a wrap addressed to some pubkey exists. Route over + Tor to also hide your IP.
    4. +
  4. The name shows, not the pubkey. + Incoming messages reverse-resolve pubkey → name where possible, + so your chat list looks like a normal chat list — not a wall of hex.
    5. +
+
+ +
+

Honest boundaries

+
+
+

Messaging, not email

+

No Gmail interop — by design. A separate anonymous-mailbox product + covers "sign up on services without leaking a real address".

+
+
+

Metadata resistance is good, not perfect

+

NIP-17 hides sender and content from relays. Relays still see the + recipient pubkey, timing, and your connection IP unless you route + over Tor.

+
+
+

Relays are Nostr's soft spot

+

A message lives only while some relay keeps it. We run one relay + + write to a handful of public relays for reach and redundancy.

+
+
+
+ +
+

Try it

+

+ Open the web messenger right here, or install Theseus for the full + experience (persistent history, sidebar entry, keyboard shortcut).

+
+ Open Messenger + Get Theseus + Brand kit +
+
+ +
+ + + + + diff --git a/messenger/index.html b/messenger/index.html index f007064..37320fd 100644 --- a/messenger/index.html +++ b/messenger/index.html @@ -1,242 +1,242 @@ - - - - - -hermes.x/messenger — browser messenger (preview) - - - - - - - - - -
- -

Messenger

-

Hermes in a browser tab — end-to-end encrypted DMs over Nostr, - addressed by on-chain registered name. The desktop client has - the richest flavour; the web messenger meets you where you are.

-
- -
-
-
- 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
    • -
-
- Get Theseus -
-
-
-

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 Hermes -
-
-
-
- -
-

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. -
  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. -
  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.
    4. -
-

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

-
- Get Theseus - Brand kit -
-
- -
- - - - - + + + + + +hermes.x/messenger — browser messenger (preview) + + + + + + + + + +
+ +

Messenger

+

Hermes in a browser tab — end-to-end encrypted DMs over Nostr, + addressed by on-chain registered name. The desktop client has + the richest flavour; the web messenger meets you where you are.

+
+ +
+
+
+ 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
    • +
+
+ Get Theseus +
+
+
+

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 Hermes +
+
+
+
+ +
+

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. +
  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. +
  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.
    4. +
+

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

+
+ Get Theseus + Brand kit +
+
+ +
+ + + + +