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

[Melvin Carvalho <[e-mail]>]

čt 23. 7. 2026 v 19:29 odesílatel <alex=[e-mail]>
napsal:

> Hi,
>
> I'd like to request provisional registration of the 'nostr' URI scheme,
> per RFC 7595. Template below.
>
> Scheme name: nostr
>
> Status: Provisional
>
> Applications/protocols that use this scheme name: This scheme name is
> used by Nostr [1], an open protocol for decentralized social networking
> based on cryptographic keypairs and relays, to reference public keys,
> events and profiles for linking and sharing between applications. The
> scheme is specified in NIP-21 [2], with the identifier formats specified
> in NIP-19 [3].
>
> Contact: Alex Gleason ([e-mail])
>
> Change controller: Alex Gleason ([e-mail])
>
> References:
>     [1] https://github.com/nostr-protocol/nostr
>     [2] https://github.com/nostr-protocol/nips/blob/master/21.md
>     [3] https://github.com/nostr-protocol/nips/blob/master/19.md
>
> Examples:
>     nostr:npub1sn0wdenkukak0d9dfczzeacvhkrgz92ak56egt7vdgzn8pv2wfqqhrjdv9
>     nostr:note1fntxtkcy9pjwucqwa9mddn7v03wwwsu9j330jj350nvhpky2tuaspk6nqc
>
>
> nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gpp4mhxue69uhhytnc9e3k7mgpz4mhxue69uhkg6nzv9ejuumpv34kytnrdaksjlyr9p
>
>
> nostr:nevent1qqstna2yrezu5wghjvswqqculvvwxsrcvu7uc0f78gan4xqhvz49d9spr3mhxue69uhkummnw3ez6un9d3shjtn4de6x2argwghx6egpr4mhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet5nxnepm
>

Hi Alex,

Thanks for putting this together.

Please also note the related work being undertaken by the W3C Nostr
Community Group on the `did:nostr` method:

https://nostrcg.github.io/did-nostr/

Version 0.1.0 was published on 30 June 2026 as a Draft Community Group
Report, and the method is listed in the W3C DID Methods registry.

There appears to be substantial overlap between `did:nostr` and the
proposed `nostr:` URI scheme, particularly for public-key identifiers. It
would be helpful for the registration or its referenced specification to
describe their intended relationship and division of use.

There is also a question concerning the canonical identifier
representation. NIP-19 describes its Bech32 encodings as formats for
display, copying, sharing and user input, rather than for use in the core
protocol. It recommends that keys and identifiers be represented internally
as hexadecimal or binary values. NIP-21 nevertheless places those NIP-19
encodings directly into `nostr:` URIs.

In earlier discussions, we considered a potential canonical protocol-level
forms such as:

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

The published `did:nostr` 0.1 draft currently covers public-key identifiers
in the form:

`did:nostr:<64-character-lowercase-hex-public-key>`

We have also discussed extending that identifier space with forms such as:

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

That extension is not part of the current 0.1 report, but it illustrates
the architectural overlap. These identifiers are primarily names for Nostr
entities rather than network locations, even where an encoded
representation may also contain optional relay hints.

For example, `nostr:event:<hex>` and `did:nostr:event:<hex>` might be
intended to identify the same underlying Nostr event, but they would remain
distinct URIs unless their equivalence, canonicalization and resolution
semantics were explicitly specified.

Could the registration or NIP-21 therefore clarify:

1. Whether the NIP-19 Bech32 form is intended to be the canonical URI
representation;
2. How implementations should compare or normalize it against the
underlying hexadecimal identifier; and
3. How the `nostr:` scheme relates to the existing and prospective
`did:nostr` identifier forms?

Clarifying this now would help avoid two parallel URI identifier systems
developing incompatible representations for the same Nostr entities.

Best,
Melvin



>
> Thanks,
> Alex Gleason
>
> _______________________________________________
> Uri-review mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>