Bech32 encoded relay entities (NIP-19)

[Semisol]

the main purpose for this to be included as a nostr: URI.

some design choices:

• type 0 is reserved for relay since a relay type already exists (1)
• only one relay can be included in the encoded entity so that if metadata is added in the future there is no confusion on which relay it applies to.

[fiatjaf]

I don't know, it feels to me that using type 0 for the relay URL is better in this case.

Do you have a use case for this? Why not pass just relay URLs directly?

[Semisol]

Do you have a use case for this? Why not pass just relay URLs directly?

"the main purpose for this to be included as a nostr: URI."

Cameri proposed using a bech32 encoded entity. I don't know how we would do this without encoding. nostr+relay://nostr-pub.semisol.dev? nostr:relay:wss://nostr-pub.semisol.dev? just passing around raw URIs?

Also, with a bech32-encoded entity you could pass around things like if you recommend the relay to be just used for reading, if the relay should be kept secret (stored in an encrypted event), if there's a relay password and so on.

unrelated: we may want a spec for encrypted relay lists.

I don't know, it feels to me that using type 0 for the relay URL is better in this case.

I eventually intend on making each type have meanings based off of the prefix: type 1 could be something else for an entity that doesn't need relays.

[fiatjaf]

"the main purpose for this to be included as a nostr: URI."

I see, I haven't really read that part, sorry. I agree then.

I eventually intend on making each type have meanings based off of the prefix: type 1 could be something else for an entity that doesn't need relays.

Another reason to use 0 for the relay URL in this case.

[Semisol]

please squash merge, thanks

[barkyq]

ndelegationtoken? might be nice to have, presumably ppl will want to copy paste these between apps.