dskvr
commented
4 weeks ago Thanks for your report. The V1 API is legacy and I do not have the bandwidth to maintain it. Please use NIP-66 or wait for the V2.
NIP-66 Relays
wss://relay.nostr.watch
wss://relaypag.es
wss://history.nostr.watchNIP-66 Filters for online public relays (example in js)
{
"authors" : ["9bbbb845e5b6c831c29789900769843ab43bb5047abe697870cb50b6fc9bf923"],
"kinds": [30166],
"#R": ["!payment"],
"since": Math.round(Date.now()/1000)-60*60*1.5
}The relay url is on the d tag
About since
The JS returns a timestamp that is "1.5 hours ago" from when subscription is opened ... this monitor publishes every hour, so 1.5 hours provides a buffer for false negatives and gives time for a few retries. If the subscription remains open, then any new events (relays) are implicitly online.
Smaller events The monitor I provided publishes pretty large events, if you want smaller events (you don't require any of the data in those events), there are 6 other monitors from vairous regions that publish compact events containing only round-trip times. You can find them with the following relays and filters (Note: Not all monitor registration events returned will be from active monitors!)
wss://relay.nostr.watch
wss://relaypag.es
wss://history.nostr.watchFilters
{
"kinds": [10166]
}These events, "Monitor Registration" events, contain the parameters you should use for liveness determinations (namely frequency)
I have removed the public/paid/offline endpoints from the API documentation to mitigate confusion. I apologize for the inconvenience.
Describe the bug https://api.nostr.watch/v1/public isn't giving me back any result
To Reproduce Steps to reproduce the behavior:
https://api.nostr.watch/v1/publicExpected behavior see a list of public relays
Screenshots If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
Additional context The rest of the api calls seem to work