nip19: implement nconnect1

[alexgleason]

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]

@pablof7z @v0l

[fiatjaf]

I like it.

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

[alexgleason]

LNURLs were a mistake. 😃

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]

This was just an experiment. Closing.