Replying to Avatar Dikaios1517

LOL! Note IDs, nevents, naddrs, and hex IDs... So many to try and keep straight!

I think I've got it now, though. So you are proposing making a mnemonic phrase out of the first 6-8 characters of the HEX ID of, well, anything you want to, right? Could be the hex version of a user's npub, the hex version of a bookmark list's ID, or the hex version of a book ID published to Alexandria, and as long as the Nostr client knows where to look for it, since relay hints aren't encoded into the hex, only the nevent or naddr, the client should be able to find it with just that mnemonic phrase.

And hex IDs are completely different from nevents and such. You can't just take the "nevent" prefix off of the front and what you are left with is the hex ID. It's a completely different set of characters.

Jumble is kind enough to allow users to see the raw event information if they want to, and I believe the hex ID of your reply is:

`a50bc29d3377e1b0f50a0f471ca7431d27489f013df620a90e313c5f10b1c2a9`

While the nevent is:

`nevent1qvzqqqqqqypzp68dx7vvdlltl7sg2qdv8838ze3tl5tq76y0jnz966fdsana6dz6qyt8wumn8ghj7mn0wd68yetvd96x2uewdaexwtcpr9mhxue69uhhwmm59e38y6t8dp6xymmvwshxuet59uqzpfgtc2wnxalpkr6s5r68rjn5x8f8fz0sz00kyz5suvfutugtrs4ffsug0m`

But we could have clients display an option to copy an "event seed" or some similar title for it, which is a mnemonic phrase of human readable words that represent the first 6-8 characters of the hex ID.

So, the question becomes, how will clients know where to find the referenced event without relay hints?

Do we have "indexer" relays that just record hex IDs and what relays they were seen on, so clients can reach out to the indexer to tell them where to look for the event? Or do we use a DHT for that? Or do we make the phrase 12 words, with the first 6 being a mnemonic of the author's pubkey and the last 6 the mnemonic of the event, and then the client can just check the author's kind 10002 relay list to see where to look for the event?

By the way, it's easy to convert n-entities to their raw components at https://nak.nostr.com

Just paste it into the box and it will be decoded for you. Then you can grab the raw event id, pubkey, etc.

Reply to this note

Please Login to reply.

Discussion

I didn't know there was a web version of nak! that's nice

Adding to my list of resources.

I need to learn how to use nak in general...

Nak is a really really awesome CLI tool. I use it every day

CLI is intimidating for us plebs, man! I am barely getting used to doing things in CLI since I switched to Linux last year. Forcing myself out of the GUI comfort zone.

I prefer CLI tools most of the time, but sometimes its just not practical to access them - and then having a web GUI is invaluable.

I hear ya! I used to prefer GUI but now prefer CLI for nostr protocol stuff. It's a slow descent into madness. Enjoy the ride

At least most CLIs are dark mode by default. 😉

same here

I essentially use it to "pre-prototype" a client. you can pretty ergonomically write a suite of unit tests just as a simple bash script to sanity-test a happy-path before writing any UI code.

case in point: https://github.com/vcavallo/khatru/blob/trim-kinds/examples/escrow/test.sh

Ah, dev-speak. I am not there yet... Maybe one day, one step at a time, I will understand all that.

I impress nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn often with the seeming contradiction of my depth of understanding of the protocol, somehow paired with my complete ignorance of how to write a single line of useful code.

We're all somewhere on the journey. I'm happy to answer questions any time if I happen to be further along a particular branch of the path.

In case it's interesting to you, what I meant in non-dev speak is:

Say I have some new Event Kind I want to introduce. I have in mind a handful of ways the kind might be used in an **eventual** app. I want to check that the design of the kind I have in mind will support those features. nak is basically a bare-bones nostr client - simple requests and simple responses all in text only - so if I have a relay running that understands my new Kind, I can use nak to make sure that the kind of requests I would send to the relay do what I hope.

Since it's a CLI tool, once I have a little collection of interactions tested out in nak, I can basically write those commands into a script (with a bit of extra diagnostic printout, etc.) and now when I run that script it either goes well: "okay great, the Kind makes sense, the relay handles it properly, and the user interactions work like I thought" or things fail and I can look into it further.

That "happy path" (the minimal actions a user might take in order to basically use the new features. not yet taking into account errors or weird edge cases, etc.) then acts as a kind of proof and assurance that "upgrading" those features into a client app UI is worthwhile and will work well.

In a nutshell: that "prototype with nak first" approach is like 1,000x faster to whip up than going straight from Idea -> UI. And sometimes you falsify some hypothesis you had really early and don't waste your time determining which color your buttons should be :)

That, sir, sounds incredibly useful for builders! Thank you for breaking it down that way!