nostr.halowerk.com

Takes a kind 9735 receipt directly or fetches it from relays by event id, then runs eight named checks and reports each one separately with its reason. The receipt signature and the signature of the zap request enclosed in the description tag are verified per BIP-340. The invoice is decoded and its amount is compared against the amount tag of the zap request, since those two can disagree and only the invoice was payable.

Fetches kind 3 contact lists over up to twelve relays. Because kind 3 is replaceable, several relays regularly hold different versions; only the one with the highest created_at is used and the answer states which relays carried that version and how many older versions were seen, so a stale relay never quietly overwrites a current list. At depth 1 the answer is the account and its outgoing follows.

Collects kind 9735 zap receipts addressed to one public key over up to twelve relays, merges them by event id and reports who sent how much over the requested window. Every amount comes from decoding the BOLT-11 invoice carried in the receipt, not from the amount tag of the zap request, because the two can disagree and only the invoice was payable.

Fetches the recent notes of one public key across several relays and measures six independent signals: posting rate per day, the coefficient of variation of the intervals between posts, how many of those intervals sit within a few seconds of each other, the entropy of the hour-of-day distribution, the share of posts whose text repeats an earlier post verbatim, and the largest burst inside sixty seconds.

Every relay is measured twice over. Over WebSocket a genuine REQ query is sent and the connection time, the time to end of stored events and the number of events returned are recorded — a relay that accepts the connection and then stays silent is the failure mode a reachability ping cannot see.

Fetches the feed over https with redirect and size limits, recognises RSS 2.0, RDF and Atom, and converts each entry into a NIP-01 event. Kind 1 produces a short note built from title, optional shortened summary and the link; kind 30023 produces a long-form article carrying the full entry text plus the title, published_at and d tags that NIP-23 expects.

Accepts three forms of recipient. A bech32 lnurl is decoded to its callback URL, a Lightning address is resolved through the well-known lnurlp path, and a Nostr public key is resolved by reading its kind 0 profile from relays and taking the lud16 or lud06 field it publishes.

Three modes over the same event structure. In preimage mode the caller supplies a public key and the event fields; the answer holds the exact NIP-01 serialisation, the SHA-256 event id derived from it and the 32 bytes to sign, so the caller signs locally and no secret key ever crosses the connection.

Fetches https://domain/.well-known/nostr.json with the name query parameter and reads the mapping the domain publishes. The answer states the resolved public key in hex and as npub, the relay hints the document lists for that key, and the HTTP status and final URL after redirects, so a redirect to a login page is distinguishable from a genuine answer. Given an expected public key, the comparison is made and the result is reported as an explicit match or mismatch rather than left to the caller.

Takes any public NIP-19 identifier or a 64-character hex value and returns every representation it can be expressed as. A decoded nprofile or nevent yields not only the key or event id but also the relay hints, the author and the kind that the TLV form carries — precisely the fields that make a follow-up query targeted, and precisely what is lost by code that only handles npub.