NOSTRAS doesn't invent its own network — everything here is a real, spec-following Nostr event. What's different is how much of the spec actually renders, and two payment mechanisms nobody else has built. We tested the difference ourselves, against a real popular client, and wrote down exactly what we found.
Cross-client verified
Nothing below is a proprietary format — a poll is kind 1068,
a thread is kind 11, exactly as their NIPs define them. We
published each one for real, then opened it in Yakihonne — a genuinely
popular, independent Nostr client, not a strawman — three different
ways. All four came back empty.
A fundraising target with live progress summed from real zap receipts, updating as sats actually land.
Tested in Yakihonne, Aug 14 2026 — did not render at all.
A titled discussion post with flat, forum-shaped replies — closer to a real conversation than a single tweet-shaped note.
Tested in Yakihonne, Aug 16 2026 — permalink, profile feed, every tab: not found.
Single or multiple-choice, with live tallies from real votes — each voter's most recent choice counted, per spec.
Tested in Yakihonne, Aug 16 2026 — permalink, profile feed, every tab: not found.
A real show, real episodes, a native audio player — publish and listen without leaving Nostr.
Tested in Yakihonne, Aug 16 2026 — permalink, profile feed, every tab: not found.
Not a NIP — our own protocol, built on real ones
The title, summary, and cover image are ordinary public NIP-23 fields — any client renders those fine. The body is NIP-44-encrypted. Unlocking it means paying a NIP-90 job that holds the decryption key and returns the plaintext only once a real Lightning payment settles — straight to the creator, plus a small flat fee to NOSTRAS for running the unlock service.
This can't become portable just because another client "adds support" — there's no spec to add support for. The unlock mechanism is a convention we invented: specific tags, a specific DVM job kind, a specific two-step payment flow. A competitor could only interoperate by reverse-engineering our exact protocol, not by implementing a standard.
{
"kind": 30023,
"tags": [
["title", "..."], // public
["summary", "..."], // public
["encrypted"],
["price", "500"]
],
"content": "nQm7…" // NIP-44 ciphertext
}
NIP-90, self-announced
Each of these is a standard NIP-90 job. The DVM that runs them announces itself over NIP-89, priced from real token cost, paid per job over Lightning. Any NIP-90-aware client or tool could call the same service directly — what's actually exclusive to NOSTRAS is that it's already wired into the feed with one click, not the service itself.
Long note, one tap, the gist — priced by the actual job, not a subscription.
Pick a language, get a real translation back through the feed.
A always-visible box to ask anything — no account, pay only if the job completes.
Publishes a real NIP-32 label, so the verdict is independently queryable by any client — not locked inside ours.
Pay a NIP-99 listing's seller directly over Lightning, get back a public, independently-verifiable receipt — not locked inside our own UI.
Beyond NIP compliance
A few things here aren't about which events render — they're about what running your own relay actually buys you, independent of any single client's feature list.
Push notifications are gated by a real NIP-98 signature check against NOSTRAS's own relay — not a third-party notification service sitting between you and your mentions, DMs, and zaps.
Real NIP-66 self-discovery and NIP-43 membership — the relay describes and manages itself to the wider Nostr ecosystem, whether or not you're using NOSTRAS's client to look at it.
The client and the relay are paired by design. Your keys already leave with you if you ever switch clients — this is about your data and your node's behavior doing the same.
Methodology