[Uri-review] Re: Provisional URI scheme registration request: "nostr"

[Melvin Carvalho <[e-mail]>]

čt 23. 7. 2026 v 21:01 odesílatel <[e-mail]> napsal:

> Hey Melvin!
>
> Good to hear from you, and sorry I didn't give you a heads up before
> submitting this. Should have.
>
> Quick answers: the bech32 form is intentional. NIP-19 recommends hex
> for storage and the wire protocol, but URIs are the display and
> sharing case bech32 was made for (checksum, self-describing prefix).
> Clients compare by decoding to the underlying key or id, not by
> comparing strings. You are right that NIP-21 should say that
> explicitly and I'll propose it upstream.
>
> On did:nostr, I see them as complementary layers rather than competing,
> but I'd like to get the mapping right. Want to work out the text
> together
> in the did:nostr repo or the NIPs repo, whichever fits better?
>
> Best,
> Alex
>

Hi Alex,

Sounds like a plan.

I appreciate that forms such as `nostr:nevent...` are already deployed
across multiple clients, so the practical approach is to document their
existing semantics clearly. There may also be a separate question about
whether Bech32m would have been preferable to Bech32 for these encodings,
but changing that now may be difficult. It could still be worth documenting
the design choice and compatibility constraints.

Because the top-level `nostr:<NIP-19>` form was already in use, the idea
fiatjaf and I originally discussed was a non-conflicting structured form
such as:

`nostr:event:<64-character-lowercase-hex-event-id>`

The corresponding `did:nostr` form could potentially be:

`did:nostr:event:<64-character-lowercase-hex-event-id>`

At an architectural level, these are name-oriented identifiers rather than
network locations. In that limited sense, they occupy similar territory to
a form such as `urn:nostr:event:<event-id>`, although each URI scheme has
its own syntax and resolution semantics.

It would be good to align the representations, mappings and comparison
rules as far as practical. Happy to work in both repositories. Perhaps we
could open an issue in each, cross-reference them, and see how much common
language we can establish.

Best,
Melvin