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