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). 

 I realize I just wrote a bunch of garble, but this is what I mean: https://how-nostr-works.pages.dev/#/outbox 

 That's a nice resource. A clear way of visualising it. 

 when sound button?  

 I look at the first four characters after npub to quickly ID my pub key 

 and we wouldn’t have had the duplication between nprofile and nevent, but the great centralized nostr nips council deemed it so and call npub a “horrendously bad idea”. Come on 🙄 

 Are you coming back to inline imeta as well? :) 

I have the exact same feeling about it. 

 I never had a problem with it, other than weird url parser differences 

 I hate the fact that people copy paste image urls outside of our clients (we could bring imeta together) and all the imeta info is gone. 

 yes that is a nice benefit 

 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.  

 I don’t do any blossom stuff yet so works for me 

 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. 

 yes, bech32 makes sense for a binary key, but there's not a strong reason to encode the text-based data within the bech32 data 

 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 

 needs some work…

I’m leaning toward nostr: npub?r=relay.damus.io https://i.nostr.build/SneWOs8RHPpd3wpM.jpg  

 This is gonna look like shit in every client that implements nostr:npub though 😅 

 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 

 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 

 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 

 I haven’t noticed repeated param keys on URLs in practice, which made me form an incorrect assumption

If it works, then I agree having repeated “r” query entries is a good syntax! 

 I kind of like this. I would be hesitant to add another encoding format but this seems cleaner than nprofile 

 I'll probably do it. it's pretty simple to implement 

 Yeah, but if I put my  nprofile in an article, or someone mentinos me, 5 years later its not useful, or am i not understanding this correctly? 

 They need to update your relay when creating the nprofile. Apps shouldn't just blindly copy-paste the address without checking if the your/your post is still there.