Adding to my list of resources.
I need to learn how to use nak in general...
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.
Discussion
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.
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!