Ok my dudes, as promised REST support live on relay.zap.store
curl -X POST -H "Content-Type: application/json" -d '{"kinds": [1063], "search": "mutiny" }' https://relay.zap.store | jq
Posting is restricted but works exactly the same, a POST request with a JSON payload. Considered an EVENT if body.id && body.sig, or a REQ if ids, kinds, etc present
Tested quite a bit, hope it doesn't blow up
nostr:npub1zach44xjpc4yyhx6pgse2cj2pf98838kja03dv2e8ly8lfr094vqvm5dy5 nostr:npub1w4uswmv6lu9yel005l3qgheysmr7tk9uvwluddznju3nuxalevvs2d0jr5 nostr:npub1yx6pjypd4r7qh2gysjhvjd9l2km6hnm4amdnjyjw3467fy05rf0qfp7kza feedback on the API design, looks good like that?
I don't think we need to stucture things with ["REQ" ... etc]
It would be kind of cool to just make a GET request to the relay url
Ex: https://relay.nostr.com/?kinds=31922&kinds=31923&authors=1234...
Alternativly, it could also just be a POST with the body in this shape:
{
type: "REQ",
filters: [
{kinds: 31922,}
]
No reason to include a subscription ID in this case
See the post just above, I implemented what you said (but with POST and just the filter). Yes it would be cool to make it work with GET too
This actually might be hella better for clients to get a clean response and closure with relays instead of battling subscription ids and updates
Nice! Good work. What's funny is I just built something similar for a major update coming to Nosflare, but as a means for helper workers to communicate.
Nice work. Just tested this and it's amazing how much simpler it is compared to websockets
