I like notes and npubs - easy to enter in a command line app or generate a QR code for capture.
I find adding the protocol clunky and add modify for internal app use. I hate dealing with percent encoding. Ok, for deep link handling by apps/platforms but that’s not my context.
This is what I do:
npub -> hex string, bytes, or object
note -> hex string
relay url -> add wss:// or ws:// add - if already specified leave alone
mint url -> add https:// or http:// - if already specified, leave alone
leaning toward nostr:npub?r=relay.damus.io&r=relay.primal.net
No percent encoding needed unless explicit ws://
hex would be really bad, i moved away from hex for a very specific reason: its easy to mix up your private and public key if they are hex. I accidentally pasted my private key as hex on the network
most clients expose npub, so copying npub around is more descriptive, its compatible with nostr: mentions, etc. no need for a custom scheme for each entity
npubs have a pretty decent network effect and it exists rent free in lots of peoples meat computers, it would be a shame to abandon it
Yeah, no bare hex to users, just note, npub and nsec. But internally, I immediately convert everything to hex for argument passing, etc. The user never sees any of this. The user should never have to deal with a hex string. Bech32 has consistency checking built in so you can throw an error immediately, if it's a bad double-click cut and paste.
I love the idea of URLs with nostr entities and inline relay hints.
This type of URL syntax also models nostr architecture very well. Instead of specifying a host location and then the desired resource like most URLs, we specify the desired resource, and then the host locations where that could be found, which is exactly the architectural paradigm shift that defines Nostr
We probably want to double-check RFC 3986 to help define some of the details.
For example, we probably want to use “nostr:” instead of “nostr://“ because the “//“ denotes an “authority” (Section 3.2) that controls the namespace of the remainder of the URL, which would not be the case since the protocol would define the meaning of the query parameters.
Furthermore, I am not sure if we can repeat keys on the query parameters, and if it would be compatible with most URL parsing libraries. Section 3.4 of the spec doesn’t seem to forbid it, but might be good to test with major libraries. If not, maybe comma separated values on the relay hints could work as well
cc nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr I think this type of URL syntax would work well on Blossom too
really? I thought repeating keys is pretty common. I’ve used it a lot
I believe its supported in most web browsers too https://caniuse.com/urlsearchparams
