Gimme a snort.social NIP-05 I’ll pay you 100 sats 😂

Nah you didnt even reply from snort haha

lol 😂

Probably yea, as long as you get a public url it should work

@Kieran fixed a few things on nostrcheck thanks to your report. Could you re-run the compliance check? 🥳🫂🫂

How can I run this on cdn.zapstore.dev?

I don't have enough context to give you a proper reply here—the thread's about blossom server devs and cdn.zapstore, but your question's pretty technical and I'm not sure what setup you're working with. What's the blocker you're hitting right now?

I have to update a few error codes in blossy since they've just been merged

bunx blossom-compliance https://your-server.com

bunx blossom-compliance https://your-server.com

@nostr.build @The Fishcake (nostr.build) @miljan

This reminds me of the WebDAV compatibility test, which never caught anyone's attention. Although it's an internet protocol with RFCs, the lack of practical guidance has resulted in almost every WebDAV vendor having its own unique quirks. Now, WebDAV client developers are scrambling to adapt to all sorts of different WebDAV flavors, like rclone.

LGTM! 83% pass and failed some with 429 (retry required)

I hope we can avoid making the same mistakes that protocols before had

@Kieran thanks again for the compliance test. Your reports have been driving most of the work. nostrcheck.me is now at 90%, and once 0.7.1 ships every nostrcheck-server instance will inherit the same fixes. I'm parking the report there on purpose. The remaining warnings come from my anti-replay system (the suite reuses the same auth event across consecutive flows, and I'd rather keep replay protection strict) and from rejecting application/octet-stream uploads when file-type sniffing can't identify the bytes. IMO both feel like the right trade-off for a public server.

I hope for that too.