it's HNMD (hypernote md, my special language for writing hypernotes -> hypernote (defined in OUTPUT.json but might be outdated somewhat) -> renderer.tsx (take in the json, wire up the queries and event creators, render with a big switch statement on the different elements)
the goal is to make the renderer as simple and foolproof possible because that's what clients will have to implement. if you have a good way to create nostr events and subscribe to filters, you have most of the "logic" solved. and then rendering is pretty simple, a strict subset of web ui basically that should be expressible in most ui frameworks.
right now "tool_call" is a special case that I'm working to eliminate so I'm just generic and people can do whatever (needed to figure out "dependent" event creation basically... watch for something tagged with the eventid of what you just published, and act on THAT)
Ideally this will soon be in a good way to make fun little UIs for any contextvm tools out there!
Login to reply
Replies (1)
> Ideally this will soon be in a good way to make fun little UIs for any contextvm tools out there!
Yes, that sounds amazing! You could also take the inverted approach: from a contextVM server, see what hypernotes use it. I think it's going to be a lot of fun exploring these ideas.
Regarding the wire up, do you already have a specification for the HN JSON output? Additionally, do you think it would be worthwhile to add a registry of supported UI elements? This could help avoid naming convention issues and assist other developers in adhering to a common set of UI elements