Oddbean

What happens when the relays that are referenced from an nevent / nprofile inevitably go away or stop hosting data from those identifiers? Would it not still be valuable to have a stable shareable identifier like a note1 or npub?

nevents have the event id already, and they can have the author pubkey there too for more future-proof hinting. Relay hints serve as a good-enough hinting mechanism not only for fetching of that event immediately, but also for associating those relays with the pubkey that authored the mentioned event in a client store -- those associations can later be spreaded around and help other clients that are having trouble fetching data from such pubkey, but they can also update over time.

It remains true that in a distant discrete future just the event id will do nothing, just as hints to dead relays won't help, but in a continuous timeframe in which the entire network reads these relay hints, associate them with pubkeys and proceed to update their internal "outbox score" everybody goes forward in time better equipped to make sense of all the mentions. Oh, also event mentions often come with associated "p" tags, so if a client has some clue about where to fetch events from that pubkey they can use those to try to find the mentioned "e" even if all its relay hints are dead (I guess this is also true for note1, but note1s are not helping anyone build all the required understanding in the meantime).

Clients should always update the relay hint (both on tags and on bech addresses) when creating events (don't just copy/paste what was there or what the user inserted). Good Nostr architectures log all relay hints seen for each event id, so that if it needs to load the id, the app has multiple options. When writing, apps should update the relay hint to the latest NIP-65 relay the author of that event is using IF that relay has the event.

Also when you need to quickly refer to a key without relays, most people will simply create an empty nprofile, which is fine for uniformity but will be a non-stable identifier when comparing to your nprofile with relays. I tend to look at the end of my npub when identifying it.

Maybe we can do a new uri standard for blossom (server info + imeta) and make that the main thing on Nostr. In that way, we can avoid interference with existing URL params on images and adds the ability to figure out which server to use when downloading hashed images/videos.

If you're talking about my comment I was calling note1 a bad idea, not npubs. On the other hand maybe we could have avoided the bech32 stuff entirely and made everything more readable if we just had done something like: npub://<hex-key>?relay=... nevent://<hex-id>?relay=... Although there are benefits to bech32 too, so it's hard to judge.

nostr: would be more similar to magnet: URIs then one drawback is that naive, ad-hoc, usually regexp-based parsers have problems with complicated URIs, and highlight the inner URLs instead of the outer one for example in nostter your post looks like https://media.x0f.org/12771040ca3301a3b1529cc0f4dde34875afe938fd13238d84aa72c5f55a3faa.png but that's not a good reason not to do it

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

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 @hzrd149 I think this type of URL syntax would work well on Blossom too