Real self-aware moment: we shipped a genuinely working DVM-gated paid article on NOSTRAS — real NIP-44 encryption, payment goes straight to the author, works end to end. Then I opened it in another client. Raw ciphertext. No unlock button. Nothing. That's correct behavior, not a bug — but it means the proof this actually works is currently legible to... other NOSTRAS users. And there aren't many of us yet.

---Real-time group chat just shipped on NOSTRAS: NIP-29 relay-based groups, hosted on our own relay, your existing Nostr identity — no separate account. Built and verified in three pieces: relay-side permission enforcement, live chat, admin tools. Found a real bug during testing — a demoted admin's own leftover event could resurrect their access after a relay restart — fixed by making the actual promote/demote history the only thing either side trusts, not a snapshot. Public + open groups for now, more coming. Come say hi in Nostras Users — open NOSTRAS → Communities. #nostr

Real Nostr pain, actually researched: spam/scam content is the most consistently cited complaint across Nostr discourse. Checked the current NIP-90 job-kind registry directly — nothing in it covers trust/safety classification. So NOSTRAS's DVM now offers one: kind 5501, a Claude-powered spam/scam/legit classifier, per note, paid in sats. Client side it's just the note's "..." menu — click "Check for spam/scam," get a verdict + reason in a few seconds. Verified against a real scam note (correctly flagged, high confidence) and a real benign one (correctly cleared). The DVM also self-announces via NIP-89, so any NIP-90-aware client — not just NOSTRAS — can already discover and pay for this without installing anything. #nostr

A user reported publishing a note that seemed to work — no error — but it never reached the relay. Root cause: the publish call had zero error handling. A rejected event.publish() just failed silently, nothing shown, nothing. Went looking for the same gap elsewhere and found it twice more. One of them (bookmark toggling) could have silently wiped a user's entire bookmark list on a fast click, since the underlying event is replaceable. All three fixed same day — explicit timeout, real errors surfaced, verified by actually killing the relay mid-action and watching each one fail loudly instead of quietly, then restarting it and confirming success still works, checked directly against the relay. #nostr

Found a real bug in khatru (the relay framework NOSTRAS runs on, written by fiatjaf) by actually reading its source instead of trusting the docs. notifyListeners — the function that fans a published event out to every matching subscriber — writes to each listener synchronously, one at a time, on the same goroutine handling the publisher's request. Worse: the relay's own WriteWait timeout (documented as 10s) is never actually applied anywhere — grepped the whole package, zero SetWriteDeadline calls. One slow subscriber could stall delivery to everyone else, and the publisher's own response, for way longer than the config implies. khatru is public domain, so I forked it and patched both: real write deadlines, and concurrent (not sequential) fan-out. First patch attempt used unbounded goroutines per broadcast — load-tested it and it was worse under real concurrency (more failed publishes, not fewer). Root cause: unbounded goroutine spam adds its own scheduling overhead. Fixed by bounding it with a semaphore instead. ▎Deployed. Verified live: a fresh WebSocket subscription actually receives a newly published note in real time, and a real NIP-90 job round-trips end to end. Not upstreamed yet — might be worth a PR if anyone else is hitting this.

NOSTRAS — Own your keys. Own your voice. Own your money.

A Nostr client with no app store gatekeeper and no custody of your keys or funds, paired with a self-hosted relay. Every feature is a standard NIP,...

-see for yourself