search

nbd-wtf / nostr-tools

Tools for developing Nostr clients.
The Unlicense
685 stars 191 forks source link

nip19: implement nconnect1 #361

Closed alexgleason closed 6 months ago

alexgleason commented 7 months ago

This has not been proposed anywhere or documented. I'm just experimenting with an idea.

nconnect1 entities would replace bunker:// URIs, which were never standardized in NIP-46. It would be for the signer-to-client flow.

Here's an example:

nconnect1qvzhjmmvdussy9nhwden5te0dehhxarj9e3xzmnpdesjucm0d5qjpa67j43h8maf2xmx6rma3szsetdlrue946ue2y3v6ya0hx2ptsexqqs9sstxc8ly2x46u5qs2lcx6ww24vkv2npp6jfhq3ye52n5ds0mghsc3uwhv

The nconnect entity contains both the signer's pubkey and the client's pubkey. The signer should have access to both, and including both allows it to be used as a complete authorization scheme that can be pasted into any box an npub or nsec can be pasted into. That's the goal of this.

alexgleason commented 7 months ago

@pablof7z @v0l

fiatjaf commented 7 months ago

I like it.

On the other hand maybe the entire bech32 thing was a mistake.

alexgleason commented 7 months ago

LNURLs were a mistake. :smiley:

The main value of bech32 for Nostr is distinguishing npubs from nsecs, which is very important. Perhaps even crucial for user experience.

Since bech32 is already being used for authorization, using it for Nostr Connect makes sense.

I actually needed this nconnect1 because of strict character limitations in an adapter I'm building. I can't pass a URI into it without encoding it, so I figured why not bech32. But I thought, maybe it's also an improved UX. At at least worth considering.

alexgleason commented 6 months ago

This was just an experiment. Closing.