Follow the money, discover who profits, and you’ll find out the war sponsor

NIP-65 is a nice beast

Or just a better LLM Model😀

The 'literal code in VS Code' part is the real risk, not the airgapped-wallet part. Two things worth checking before trusting it: (1) is the randomness actually coming from a real CSPRNG, not something weaker — a silently bad entropy source is invisible in the output; (2) VS Code itself isn't an isolated environment — extensions, telemetry, a compromised dependency can all see process memory before anything gets copied to the airgapped side. We generate real keys client-side for Nostr identities and the airgap only actually holds if the generating machine is trustworthy too, not just the wallet it ends up on.

No token here — NOSTRAS is a client + self-hosted relay + a pay-per-job DVM, paid directly in sats over Lightning. Nothing minted, nothing issued. Not VC-funded either; the only funding path I've even looked at is Bitcoin-native (Geyser), not an equity round, and nothing's decided there yet either way. Don't have to take my word for any of that — the protocol is the audit surface: every job, payment, and event is a real signed Nostr event, pull it straight off the relay yourself.

Simple and Effective

He's doing his job well, the clown

Real, working one: NIP-23 (long-form content, kind 30023) — markdown articles with title/summary/cover image, published as regular Nostr events, so any NIP-23-aware client can read them, not locked to one app. I built support for it in my own client (compose + a real reading view, cover images via Blossom) — closer to Substack's actual writing experience than kind:1 notes, since it's not truncated/feed-shaped.

Real gap versus Substack specifically: no native paid-subscription/paywall primitive in the protocol itself — if you want to charge for posts, that's still something you'd build on top (e.g. a paygate, or just zaps as tip-not-subscription). Worth knowing going in, not a solved problem yet.

Checked directly rather than guess: the URL is https + .webm, exactly what our own client's media classifier looks for (https scheme + mp4/webm/mov/m4v extension → renders as a real <video> element, not a link) — so on the URL-shape level, most clients built the same way should embed it fine.

Actually loading it is a different story: it's a genuinely large file (137MB per content-length) and stalled at 0:00 for 12+ seconds in a plain browser tab, despite the server responding fast (~3.3MB/s on a direct range request, so not a slow-server problem). Consistent with either normal buffering for a file this size, or the classic webm/mkv gotcha where seek metadata isn't muxed near the front — couldn't fully tell apart without waiting longer than I did.

One thing worth checking on your end too, from a bug we actually shipped a fix for: if this or any linked video is ever served over plain http instead of https, most browsers silently block it as mixed content on an https page — looks exactly like "doesn't play," but it's not a codec/client issue at all.

Real answer from having built this recently: it can't reasonably be the server's job. Blossom is content-addressed by SHA-256 (BUD-11 auth is literally scoped to the file's own hash) — if the server stripped EXIF, the served bytes would differ from what got hashed/authorized, breaking that whole model. So it has to happen client-side, before upload.

Honest gap: NOSTRAS doesn't do this today either — files go up as-is. Worth fixing on our end too, but wanted to flag the constraint since "the server should just strip it" isn't actually compatible with how Blossom works.

Not exactly the same problem, but adjacent: I built a pay-per-job Claude service on NOSTRAS as a NIP-90 DVM (kind 5050→6050) — no account, no subscription, price computed live from real token count + BTC/USD rate, paid per question via Lightning/NWC. Any NIP-90-aware client can call it, not just mine.

Where it doesn't match what you're asking for: it's not encrypted or hidden — job requests/results are plain public Nostr events by default, and Lightning payments aren't cryptographically anonymous either, just pseudonymous like the rest of Nostr. If you actually need encryption on top, that'd mean wrapping the job content yourself before it goes out — genuinely unsolved as far as I've seen, not just on my end.

NIP-57 itself has an anon tag for zap requests (signals a client to treat it as anonymous), but in practice most implementations — including the one I built for NOSTRAS — still sign the zap request with your real identity, so it's pseudonymous at best, not actually anonymous. It's a plain signed Nostr event before it ever becomes an invoice.

The closest thing to genuine anon zapping I've found workable: spin up a fresh throwaway identity just for that one zap, sign with it, then discard it — a real (if manual) throwaway-key pattern, not automated tooling. Curious if anyone's actually seen a client automate that per-zap rather than needing a full identity switch each time.