Deprecate note1 pls


火


Yes. nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hszxmhwden5te0wfjkccte9emk2um5v4exucn5vvhxxmmd9uq3xamnwvaz7tmhda6zuat50phjummwv5hsx7c9z9

Npubs as well.


Yes, please. That was a disgustingly horrible idea since the beginning.


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?


I think npub is cool just because it is stable and part of its characters can be memorized, and it's easy enough to get relays for a pubkey by using hardcoded indexers like relay.nos.social and purplepag.es in most cases, but note1 is completely unjustifiable.

I think npubs should be used in UIs when displaying a user pubkey, but in mentions nprofile is strictly better (apps can even display npubs in mentions after decoding the nprofile). But again, even npubs in mention is not that bad.


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.


Is this portuguese?


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.


Agreed


when sound button?


Agree, but it creates so much friction with users :(

It's hard to say "you can use nouns, but if you want to share the user, it must be an nprofile". Most people don't know the difference and maybe shouldn't know.


The client can replace it in place, but, again, just sharing the npub is not that bad.


Complicated tlv format was a horrible idea imo, could have just been a user editable url


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.


but note1 is pretty useless outside of this point, happy to let that die


I guess I can look at the start of my nprofile instead to eye it 🤔


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


> could have just been a user editable url

What does this mean, and how does it work?


like nostr://npub?r=wss://relay.damus.io&r=wss://relay.primal.io

User inspectable and editable


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 🙄


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


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.


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.


What do we have to use other than npubs? dont we need a persistant identified somewhere, somehow?


Nprofiles. It's the same as the npub, but includes the person's main relays in the code so that apps can find their info quickly.


Do they change if i change my main relays? I guess can i still share an old nprofile with an old relay i dont use anymore?


The npub has a stable checksum-like thing at the end that can be quickly eyed and checks the full npub, right? That was the entire point of bech32 and where the full value of npubs reside to me.


You will have to keep changing it as you move relays. All old posts will have your old nprofiles and thus link to your old relays. But apps should be smart enough to track relay hint changes and only use the latest ones.


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?


True. But what's the point of having that there if in the text or when sharing links around everyone is just using nprofiles? You don't need checksums on the app's internal stuff. Checksums are only useful if users can play with the address and we are making all users play with nprofiles instead of npubs.


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


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.


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 don’t do any blossom stuff yet so works for me


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 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 kind of like this. I would be hesitant to add another encoding format but this seems cleaner than nprofile


I believe its supported in most web browsers too https://caniuse.com/urlsearchparams


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


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!


このスレッドだよね、note1の話(長い)
nostr:nevent1qqs2cr9yzfcpf7892gymdwxsq6f33aa4mw7vqg4e0stp6yy8dn9jxasppemhxue69uhhjctzw5hx6ef0qgs8lft0t45k92c78n2zfe6ccvqzhpn977cd3h8wnl579zxhw5dvr9qrqsqqqqqp6pzvzd