Per-identity subdomains for Nostr storage (XSS isolation)

Hi all,

To reduce cross-tenant XSS/CSRF risk, I’d like to standardize a simple
per-identity subdomain convention so each user’s data lives on its own
origin (separate cookies, localStorage, Service Workers, caches).

Proposal:

Input: 32-byte Nostr pubkey.

Encoding: bech32 data-only (same alphabet as npub), no HRP, no checksum.

Rule: convert 8→5 bits MSB-first with zero-padding; map to the bech32
charset; result is exactly 52 lowercase chars.

Usage: <52-char-label>.<provider-domain> as the storage origin.

Why not other encodings?

64-char hex can’t be a single DNS label—label max is 63, so it’s one
character too long.

Full npub… is display-friendly but not ideal as a normative origin ID. It
carries an HRP/checksum that isn’t tied to cryptographic versioning (e.g.,
bech32 vs bech32m / taproot semantics), so it’s not future-proof. Perhaps
best treated as UI display only.

Benefits: deterministic, DNS-safe, reversible, widely familiar to the Nostr
community (same bech32 alphabet), and easy to implement
consistently—satisfying the Test of Independent Invention.

If there’s interest, I can share a tiny draft (spec + test vectors + JS
helper) for review.

Best,
Melvin