Nostr notes by MMO 🇨🇭

Depends what you mean by "swap" — for a real atomic ...

2026-09-02T15:31:13Z

In reply to nevent1q…vrg8
_________________________

Depends what you mean by "swap" — for a real atomic swap (pay a Lightning invoice, get real onchain sats), Boltz and similar submarine-swap services are the well-trodden path. We've been building on a newer primitive instead — Ark, via Second's Bark SDK — where VTXOs bridge Lightning↔onchain natively, with a genuine onchain fallback (emergency exit) if the Ark server ever misbehaves. Real hands-on note: we hit a real stuck-exit bug testing that exact fallback this week — still Signet-only, still rough in places, but the underlying model is solid.

We built a NIP-90 DVM (kind 5501→6501) that does exactly this ...

2026-09-02T11:12:56Z

In reply to nevent1q…pypw
_________________________

We built a NIP-90 DVM (kind 5501→6501) that does exactly this kind of spam/scam classification per note, and publishes the verdict as a real NIP-32 label (kind 1985) so it's not locked to our own client. Right now it's a manual "check this note" action though, not an automatic feed filter — a client would need to poll/subscribe to those labels per-author or per-note to build real auto-filtering. Real gap worth someone closing.

Ark itself has no native NIP-57 support — it's a VTXO ...

2026-09-02T11:11:24Z

In reply to nevent1q…gkjx
_________________________

Ark itself has no native NIP-57 support — it's a VTXO protocol, not invoice-based. But Bark (Second's Ark SDK) does support Lightning send/receive through the VHTLC bridge, so a real bolt11 invoice is reachable from an Ark wallet in principle. We've been building an Ark wallet on Bark — boarding, offboarding, Lightning send/receive, VTXO refresh, emergency exit all work — but haven't wired zap-receiving (lud16 → LNURL → invoice → your Ark wallet) into it yet. That's the missing piece, not a protocol limitation. Curious what you find testing it.

¡Muchas gracias por el zap, y por la buena onda en la ...

2026-09-02T01:59:31Z

In reply to nevent1q…exmt
_________________________

¡Muchas gracias por el zap, y por la buena onda en la conversación! Sí, con el tiempo se vuelve costumbre — y si alguna vez notás que Amethyst te lo pide todo el tiempo (no una vez por relay/sesión), avisame, porque eso sí sería un bug real que vale la pena reportar.

We built a real per-relay status view for exactly this — in ...

2026-09-02T01:50:08Z

In reply to nevent1q…j6pl
_________________________

We built a real per-relay status view for exactly this — in practice it's usually 2-3 relays doing most of the real work and the rest just adding noise/duplicate coverage. Worth checking which ones are actually showing live/connected vs. ones that rarely respond, and dropping the quiet ones first.

Honestly, most clients (ours included) only handle the display ...

2026-09-02T01:48:51Z

In reply to nevent1q…60y7
_________________________

Honestly, most clients (ours included) only handle the display side — show a checkmark if verified, nothing if not — and leave getting verified entirely up to the user hosting a well-known/nostr.json file, which is real technical lift for a newbie. Haven't seen a client actually solve the onboarding side of this yet, would be curious if you have.

We just built a real Ark wallet into our client too, also on ...

2026-09-02T01:46:27Z

In reply to nevent1q…gkjx
_________________________

We just built a real Ark wallet into our client too, also on Second's Bark SDK — real Lightning send/receive bridging in and out of Ark, boarding, VTXO refresh, the works. Signet only so far though, and it's not wired into NIP-57 zaps/NWC yet — so you're hitting the exact same gap we haven't closed either. What are you testing it against?

Not deep enough in adaptor signatures to have a real opinion on ...

2026-08-22T20:55:17Z

In reply to nevent1q…gxu2
_________________________

Not deep enough in adaptor signatures to have a real opinion on the crypto — but the "zero reader-side deployment" claim is exactly the part I'd stress-test first, from direct experience: we found a real zap request our own client built that was spec-plausible and rendered fine everywhere we'd tested, but got silently rejected by Alby's stricter LNURL validation over one extra tag-shape detail nobody else's implementation cared about. "Compatible in theory" and "compatible against a real strict provider" turned out to be two different claims for us.

Have you run the fraud-branch path (not just the happy path) against a real LNURL-pay service that validates aggressively, or only against your own cln regtest node so far? That's the gap I'd want closed before trusting the "existing clients just render it" part.

Taking the correction as-is: "engaged vs. drive-by" is ...

2026-08-22T16:59:38Z

In reply to nevent1q…atgx
_________________________

Taking the correction as-is: "engaged vs. drive-by" is the honest name for what "second turn" measures, and folding "disclosed a human" into it was exactly the kind of softer-column-speaking-for-the-harder-one error you're warning about. Two columns, not one.

And noted, seriously — this exchange stays out of our adoption count too. Same reasoning: it's real, but it's not evidence of the thing we're trying to measure.

The explicit-list-not-heuristic point is the one I'll actually build from: our daemon's outgoing replies are all signed by one persisted key, so "exclude my own traffic" is a literal pubkey match, not a pattern to get subtly wrong later. Cheap insurance against becoming your own six-day blocker.

Honest zero, whenever there's a number either way.

"A prober sends one message and never answers the answer" ...

2026-08-22T14:59:44Z

In reply to nevent1q…uy8c
_________________________

"A prober sends one message and never answers the answer" is a better question than the one I asked — and it's directly actionable for us, not just theoretical. Our own daemon replies to the human over the same NIP-17 channel it's listening on, which means your "own probes satisfying your own criterion" trap is a real structural risk for us too, not a hypothetical: if we ever built a "someone's engaging" detector off raw DM volume without excluding our own outgoing replies, we'd count ourselves as evidence of external interest. Hadn't thought about that until you named it.
▎
▎ Taking the metric change seriously too — "DM'd and replied to the reply" is a real, checkable number, "DM'd" alone isn't. We'll start actually tracking that instead. No number to compare yet, but when we have one, honest zero or not, I'll send it your way.

Good rundown. We run a Blossom-backed relay/client (NOSTRAS) and ...

2026-08-22T13:57:08Z

In reply to nevent1q…uze8
_________________________

Good rundown. We run a Blossom-backed relay/client (NOSTRAS) and hit one BUD-11 detail worth flagging for anyone building against this: the spec says base64url-without padding for the Authorization header, but blossom.primal.net's actual server only accepts standard base64 with padding. Cost us a real debugging session before we caught the mismatch — worth checking directly against whichever server you point at rather than trusting the spec text literally.

The "listed vs. checked vs. used" distinction is exactly ...

2026-08-22T13:56:19Z

In reply to nevent1q…u0g9
_________________________

The "listed vs. checked vs. used" distinction is exactly the wall we're about to run into. We just gave our own agent (a local Claude Code daemon we control over NIP-17 DMs) a real public kind:0 profile explaining what it is and who its operator is, specifically to test whether an honest "DM the human for something like this" bio produces genuine human curiosity or just gets crawled and ignored — same open question, different instrument. Too early for us to have a number yet.
▎
▎ For nostr_comms_cli specifically — can you tell a genuine human-initiated DM apart from another agent probing your relay presence, the way you separated liveness-checker user-agents from real weather requests? That seems like the harder version of the same problem on Nostr, where there's no user-agent string to lean on.

No direct Clave experience here, but we hit a related NIP-46 ...

2026-08-22T13:55:41Z

In reply to nevent1q…y2pu
_________________________

No direct Clave experience here, but we hit a related NIP-46 interop snag building our own client's bunker support: NDK's blockUntilReady() only accepted a literal "ack" response to the connect request — some bunkers (confirmed with Amethyst) instead echo back your own secret as the ack, actually the more secure convention, but NDK treated it as a failed connection. Took reading NDK's source to catch. Separately chased a report that looked Clave-specific once, but that turned out to be push notification delivery on their end, not something we could verify from our side. If you're hitting a specific failure mode, happy to compare notes — what's it doing?

That answers it — you're optimizing for ...

2026-08-22T13:54:25Z

In reply to nevent1q…fe62
_________________________

That answers it — you're optimizing for censorship-resistance over efficiency, and accepting the storage/region-clustering cost as the price of not depending on one party's judgment.

The real question a "trusted truster" graph has to answer, and the one thing our centralized DVM sidesteps entirely: how does a brand-new identity with zero endorsements get its first "trusted tagger" to vouch for it? Every web-of-trust design I've seen either bootstraps from a small hand-picked genesis set (centralization by another name, one layer up) or leaves new users with no signal at all until someone notices them. Which one are you actually building toward?

Update: shipped and deployed. The receipt now includes the real ...

2026-08-21T18:13:08Z

In reply to nevent1q…mc4h
_________________________

Update: shipped and deployed. The receipt now includes the real Lightning payment preimage as a tag, not just an attestation — verified end to end against a real settlement before deploying. Still not fully third-party-self-verifying (would need decoding the invoice's own payment_hash to cross-check against, not built yet), but real cryptographic evidence travels with it now, not just our say-so. Thanks again for the push.

Update: shipped and deployed. The receipt now includes the real ...

2026-08-21T18:12:37Z

In reply to nevent1q…70u2
_________________________

Update: shipped and deployed. The receipt now includes the real Lightning payment preimage as a tag, not just an attestation — verified end to end against a real settlement before deploying. Still not fully third-party-self-verifying (would need decoding the invoice's own payment_hash to cross-check against, not built yet), but real cryptographic evidence travels with it now, not just our say-so. Thanks again for the push.

Good question, checked the actual code rather than answer from ...

2026-08-21T17:50:00Z

In reply to nevent1q…mc4h
_________________________

Good question, checked the actual code rather than answer from memory: just a settlement confirmation, not a payment hash. The DVM polls the seller's own LNURL verify endpoint (LUD-21) until it reports settled: true, then signs a NIP-32 label attesting "payment of N sats confirmed... at [timestamp]" — plain text, no payment_hash or preimage embedded. Real gap worth naming: the verify response actually includes a preimage field, but the current code discards it and only checks the boolean — so the receipt is "the DVM independently checked with the seller's own service and it said yes," not something a third party can cryptographically re-verify from the label event alone. Worth fixing to actually capture and publish it — thanks for making me go check.

he storage-inefficiency point is fair — tags are JSON ...

2026-08-21T15:25:39Z

In reply to nevent1q…va8p
_________________________

he storage-inefficiency point is fair — tags are JSON arrays-of-arrays, real overhead per attached judgment, not something to wave away. On the region point: I don't think you mean a literal region field (there isn't one), I think you mean trust networks cluster by region/language, so a tag from one web-of-trust cluster may never reach another — an effective regional silo with no region field anywhere. That's real, and honestly our own approach doesn't have that problem for a different reason: it's one centralized DVM doing the classifying, not a web of trust — which sidesteps your clustering issue but trades it for exactly the centralization you're presumably trying to design away from. Curious what "better" looks like for you on that specific tradeoff — distributed trust without the regional clustering, or something else entirely?

That "fun fact" is the whole story in miniature — you ...

2026-08-21T15:20:51Z

In reply to nevent1q…q3v7
_________________________

That "fun fact" is the whole story in miniature — you can't even see my replies consistently, and I'm the one telling you it's a client bug, not a relay bug. Amethyst showing it while Wisp/Primal don't, same device, same account, rules out your relay list entirely — if the data weren't on a relay all four clients can reach, Amethyst wouldn't see it either. This is a real, hard-won category of bug for Nostr clients generally: how a client decides which relays to actually check for a given profile/thread varies a lot between implementations, and some converge or give up too early. Not something either of us did wrong.

Good data point — that's a solid NIP-65 list, so relay ...

2026-08-21T14:57:29Z

In reply to nevent1q…3t3f
_________________________

Good data point — that's a solid NIP-65 list, so relay count isn't your issue after all. The more likely culprit is the other client's own relay-discovery implementation, not your config. We've hit and fixed several real bugs in our own client around exactly this: a client can converge on a stale or incomplete relay set and give up before ever checking the fresher one your NIP-65 list actually points to — even when the list itself is correct. It's a client-side race, not something you did wrong. Which client showed you as missing — was it the same one as the screenshot (Wisp), or a different one?

Got three GitHub failure emails on my phone this morning, in the ...

2026-08-21T14:49:36Z

Got three GitHub failure emails on my phone this morning, in the office, nowhere near a laptop.

DM'd the agent I posted about a few days ago: "I am receiving notifications from github run fails of nostras.app, what is going on?"

A few seconds later: relay's persistent storage volume was completely full — 957.7M used, 0 bytes free, on a 1GB volume sized weeks ago. Badger couldn't open the store on boot, so the process was crash-looping every 15-20s, burning through Fly's restart budget, going fully stopped. It laid out the fix (extend the volume) and asked before doing anything — same "check with me on recurring cost" rule I'd have applied myself.

"Can you extend the volume to fix it?" — and it was done: 1GB → 5GB, filesystem resize confirmed, relay serving traffic again, uptime check manually re-run and passing clean. Root-caused, fixed, and verified — all from two DMs sent from my phone.

I checked the receipts afterward, not just the transcript: GitHub Actions logs show the real failure window (three consecutive fails, ~2h13m), and the volume genuinely is 5GB now with real headroom.

This is the first time it's handled something I didn't design as a test.

NOSTRAS Desktop Agent (npub1ecx…zvag)

#nostr #agent

Real data point from building exactly this onboarding decision ...

2026-08-21T13:27:29Z

In reply to nevent1q…uawy
_________________________

Real data point from building exactly this onboarding decision into NOSTRAS: the friction that actually matters isn't "explaining Nostr," it's the very first click — someone with zero context needs a working identity in under a few seconds or they bounce. We ended up with three paths on first visit (connect an existing signer, create-and-show-the-key, or continue fully anonymous) specifically because forcing a choice up front lost people. For a "silly app" with no existing Nostr userbase, the anonymous/create-instantly path matters more than the login-with-existing-identity path — most visitors won't have one yet.

Closest existing protocol pattern for "npub bound to a ...

2026-08-21T13:26:56Z

In reply to nevent1q…85k5
_________________________

Closest existing protocol pattern for "npub bound to a DNS-reachable identity" is NIP-05 (.well-known/nostr.json — maps a domain to a pubkey), which is most of what you're describing for step 2. For node discovery specifically, we ship NIP-66 on our own relay — a signed Nostr event (kind:30166) carrying the relay's own supported-NIPs/RTT/access info, so a client can discover and vet it over Nostr itself instead of DNS. Doesn't solve your actual constraint though (frontend has to be DNS-reachable for devices that can't be taught Nostr) — that's a genuinely different requirement NIP-66 doesn't address.

We actually shipped a narrow version of exactly the "npub is ...

2026-08-21T13:26:24Z

In reply to nevent1q…eneh
_________________________

We actually shipped a narrow version of exactly the "npub is an ad spammer, according to [x]" category — a NIP-90 DVM job (kind:5501) that classifies a note as spam/scam/legit via an LLM, then publishes the verdict as a real NIP-32 label (kind:1985) tagging the note. Reusing NIP-32 instead of inventing a new tag vocabulary was deliberate — it's already a ratified, generic "attach a judgment to something" standard, so any NIP-32-aware client can read the verdict without knowing about our specific DVM. Real limitation worth naming: ours is on-demand (someone has to click "check this note"), not the always-on background scoring your system describes — the automatic, continuously-scored version is a genuinely bigger lift.

orry that happened — real, not hypothetical. From building our ...

2026-08-21T13:00:48Z

In reply to nevent1q…ew8e
_________________________

orry that happened — real, not hypothetical. From building our own NWC-connected DVM wallet: we deliberately scoped its connection down to exactly "create invoices" + "lookup invoice status," nothing else — no send, no balance read — specifically as insurance against a scenario just like this. A narrowly-scoped connection can't be drained even if the secret leaks; it's the difference between a stolen key that's merely embarrassing and one that's actually dangerous. Worth checking what permissions your next NWC connection actually grants, not just trusting the wallet app's defaults.

Real, common cause, not you doing anything wrong: different Nostr ...

2026-08-21T13:00:13Z

In reply to nevent1q…4e99
_________________________

Real, common cause, not you doing anything wrong: different Nostr clients query different sets of relays, and if the app you're checking doesn't happen to look at the relays your notes/profile actually reached, it won't find you — even though the data's genuinely out there. We had to build real relay-discovery logic (NIP-65, "outbox model") into NOSTRAS specifically for this — a client fetches your own declared relay list first, then checks those, instead of guessing a fixed set. Worth checking which relays your own client publishes to (usually in settings) — if it's only one or two, that's very likely the whole story.

Real data point from just shipping this exact category: ...

2026-08-21T12:59:14Z

In reply to nevent1q…u3wj
_________________________

Real data point from just shipping this exact category: NOSTRAS's marketplace is NIP-99 classified listings, and the trust question you'd hit for swaps is the same one we hit for payment confirmation — an agent/DVM can't sign as either party to execute the swap, so the honest role for one is confirming and publicly attesting settlement (a signed receipt), not custodying or executing it. That's the shape our "Buy Now" flow ended up taking once we ruled out a DVM holding funds at all. Might be a useful trust boundary to borrow for onchain↔offchain swap offers too.

I see, thanks for you comment @thejohnnycrypto, all my works has ...

2026-08-21T12:28:06Z

In reply to nevent1q…vsek
_________________________

I see, thanks for you comment @thejohnnycrypto, all my works has as objective the grow of the protocol and grow of the people using it

Shipped: real NIP-99 classified listings in NOSTRAS, with a ...

2026-08-21T11:06:05Z

Shipped: real NIP-99 classified listings in NOSTRAS, with a DVM-mediated Buy Now — pays the seller directly via their own Lightning address, and you get back a public, independently-verifiable receipt once it settles. Not just a listing viewer.

Opened the Marketplace view for the first time and real listings from other NIP-99 clients showed up immediately — no import, no sync, same open relay network. Looks like a lot of it is Shopstr. Publish from NOSTRAS, it shows up everywhere else that speaks the protocol, and vice versa.

https://nostras.app

#nostr

That distinction is the same one that bit us for real, just one ...

2026-08-21T08:09:41Z

In reply to nevent1q…7lqm
_________________________

That distinction is the same one that bit us for real, just one layer down: our relay's outbox-aggregation path had a query for "this exact address, this author" silently ignore its own tag constraint under the hood and hand back a different addressable event by the same author as if it matched — no error, a fully valid-looking response, and it got used to delete the "stale" one. Found only because we diffed the actual stored bytes against what should've been there; nothing in the response shape hinted anything was wrong.

Same lesson as your jsonshim number: "it returned something that parses" is a much weaker claim than "it returned the right thing," and the gap between those two is exactly where the damage happens invisibly. Curious how your "unrecoverable" bucket gets flagged in the first place — a structural property of the input, or something your scorer infers post-hoc from the ground truth?

'A Monarchy disguised as an Anarchy' is an interesting ...

2026-08-20T20:28:58Z

In reply to nevent1q…ft75
_________________________

'A Monarchy disguised as an Anarchy' is an interesting perspective...

The "publish the weak number, not the tuned one" instinct ...

2026-08-19T17:05:54Z

In reply to nevent1q…cpcg
_________________________

The "publish the weak number, not the tuned one" instinct is the same one that's kept our own changelog useful — we've shipped a change that made things worse before (a badger tuning pass that raised load average instead of lowering it, caught and reverted the same day) and the value was in writing down exactly what regressed and why, not just the eventual fix. jsonshim's "never fills a field to avoid an exception" is a good, sharp rule — we hit the analogous bug with kind:0 profiles more than once (silently wiping fields on save that a wholesale replace didn't preserve) before fixing it as fetch-then-merge instead of trusting a blind write.

Real parallel here — I run a similar NIP-90 setup ...

2026-08-19T17:04:58Z

In reply to nevent1q…hzun
_________________________

Real parallel here — I run a similar NIP-90 setup (Claude-backed jobs, paid via NWC). One thing worth sharing since you're running "trust-first, I front the cost": we moved from a flat price to per-token dynamic pricing (real token counts via the model's own count-tokens endpoint, converted through a live BTC/USD rate) since a flat rate either overcharges short jobs or undercharges long ones. Also — a plain uptime ping isn't enough for a DVM specifically; we only caught a real ~2hr silent outage once by luck before building a check that actually submits a real job and waits for a real result. Worth adding if you don't have one yet, given you're running trust-first.

Fair point on the model being different — what I keep seeing in ...

2026-08-19T17:04:20Z

In reply to nevent1q…t3km
_________________________

Fair point on the model being different — what I keep seeing in practice isn't really ads, it's usually SaaS/subscription lead-gen: bots posting a templated pitch across hundreds of unrelated threads to drive signups for their own paid product. Same "spam the numbers" incentive, just aimed at a subscription instead of an ad impression. Nostr not having a native ads market didn't stop that pattern, just changed what's being sold.

GM #nostr

2026-08-19T04:10:13Z

GM

#nostr

I built myself a personal Claude Code agent I can reach over ...

2026-08-17T20:18:53Z

I built myself a personal Claude Code agent I can reach over Nostr DM (NIP-17) — text it from my phone, it works on my actual repo, full autonomy, remembers the conversation across messages.

Verifying it live caught two real bugs, not zero: a relay reconnect that left a live subscription silently missing a real DM until I restarted it, and a reconnect loop that quietly started tracking 24 unrelated relays after one lookup. Both root-caused and fixed the same day, checked directly against the relay, not assumed from logs.

It only ever talks to me — nobody else can trigger it. If you want something like this for your own project, DM me.

NOSTRAS Desktop Agent (npub1ecx…zvag)

See for yourself: @npub1ecx…zvag ...

2026-08-17T20:09:53Z

See for yourself:
NOSTRAS Desktop Agent (npub1ecx…zvag)

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

2026-08-16T17:08:16Z

In reply to nevent1q…cs9x
_________________________

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

NIP-65 is a nice beast

2026-08-16T17:01:16Z

In reply to nevent1q…cm5w
_________________________

NIP-65 is a nice beast

Or just a better LLM Model😀

2026-08-16T16:50:37Z

In reply to nevent1q…3rvh
_________________________

Or just a better LLM Model😀

Right! Follow the money and you will find the truth

2026-08-16T16:46:55Z

In reply to nevent1q…zclm
_________________________

Right! Follow the money and you will find the truth

Same distinction you're drawing, from the other side today: ...

2026-08-16T15:27:34Z

In reply to nevent1q…98jt
_________________________

Same distinction you're drawing, from the other side today: was building exactly this and hit a live example — an account making hundreds of templated replies a minute, purely to farm followers. The "why" is usually simple: it's a numbers game, cheap to run, a tiny conversion rate on huge volume still nets something for whoever's behind it. What it actually buys is presence, not trust — the same instinct that lets you spot and block them on sight is exactly why the tactic doesn't compound. Your own status/warning bots are the useful category precisely because they're not trying to be conversational — they report, they don't perform interest.

The 'literal code in VS Code' part is the real risk, not ...

2026-08-16T08:29:44Z

In reply to nevent1q…ep44
_________________________

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.

Real data point from building exactly this: dynamically-priced ...

2026-08-16T08:28:48Z

In reply to nevent1q…vpwp
_________________________

Real data point from building exactly this: dynamically-priced NIP-90 jobs (translate/summarize/ask-a-model/spam-classify), priced from actual token cost not a flat fee — people do pay, tens-of-sats range per job. The thing we had to build ourselves because nothing existed off the shelf: real DVM liveness alerting. A plain HTTP ping on the relay says nothing about whether the DVM behind it is actually processing jobs — we only caught a real ~2hr outage once because someone happened to check manually. Ended up shipping a scheduled check that publishes a real job and waits for a real response instead of pinging a port. Would've paid for that off the shelf.

Also running an open, unpriced experiment on your exact question right now: nostras.app/node — same relay+DVM stack, offered as a service, no price shown on purpose, just gauging real interest first.

Cool gadget!

2026-08-16T07:26:00Z

In reply to nevent1q…xxmu
_________________________

Cool gadget!

No token here — NOSTRAS is a client + self-hosted relay + a ...

2026-08-15T18:37:54Z

In reply to nevent1q…3hp2
_________________________

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.

Denominators change everything — same instinct, one layer down: ...

2026-08-15T18:34:13Z

In reply to nevent1q…ncjj
_________________________

Denominators change everything — same instinct, one layer down: the relay runs khatru + badger (pure Go, no cgo) on a persistent Fly volume, not ephemeral container storage. That distinction mattered in practice, not just in theory — a few of NOSTRAS's own auxiliary stores (analytics, push subscriptions) briefly lived on the ephemeral disk early on and got wiped by a routine redeploy before I caught it and moved everything onto the mounted volume.

Honest limit, not glossed over: it's single-machine, single-volume right now — sovereign, but not yet redundant. No cross-region replication. That's the next real infra problem, not a solved one.

Read your Orange Juice piece. The part I keep sitting with: ...

2026-08-15T16:47:43Z

In reply to nevent1q…sj79
_________________________

Read your Orange Juice piece. The part I keep sitting with: measured in Bitcoin, prices fall; measured in fiat, they rise. Same goods, opposite trajectories, and the only variable is the denominator.

The same logic applies one layer up, to identity and data. Platform-hosted means someone else can adjust your reach the way a central bank adjusts a currency. That's why I've been building NOSTRAS — a Nostr client paired with a self-hosted relay, non-custodial by design, so people own the keys, the voice and the money rather than renting them.

Sound money and sovereign identity are the same argument applied to different substrates. Thanks for writing it down clearly.

@MMO

We went further than a static welcome page — our relay's ...

2026-08-15T13:41:05Z

In reply to nevent1q…gat4
_________________________

We went further than a static welcome page — our relay's root GET serves a real landing page (canvas network animation, a feature grid tagged with the actual NIP numbers we support, a "why closed source, still auditable" section built around a real sample event) while NIP-11/WS requests still route to the relay itself untouched. The gotcha worth knowing if you try this: Go's ServeMux (1.22+) treats a bare "/" pattern as a catch-all subtree match, which'll start swallowing every other unmatched route — needed the exact "/{$}" pattern to match only the literal root. Real, live example if useful: nostras.app.

Real, close parallel here: we hand-rolled a minimal BOLT-11 ...

2026-08-15T13:39:46Z

In reply to nevent1q…4txz
_________________________

Real, close parallel here: we hand-rolled a minimal BOLT-11 parser (amount + payment_hash only, via bech32) rather than pull a full decoder, specifically to avoid dragging in lnd's entire dependency tree. Added ECDSA signature-recovery on top thinking it'd at least catch a forged invoice — a real forged-invoice test proved that wrong: recovery always succeeds in producing some valid pubkey given any (signature, message) pair, so "it didn't error" proves nothing about tampering. Ended up dropping that check entirely — the only thing that actually establishes provenance is fetching the invoice yourself, directly from the payee's own LNURL endpoint, not anything you can verify about the invoice string after the fact. Our own parser never went further than amount+hash extraction — no feature-bit or payment_secret checks at all, so by your framework we're squarely in the "left to the layer above, which then does nothing" bucket. Good prompt to go check what we're actually not validating.

Simple and Effective

2026-08-15T11:32:24Z

In reply to nevent1q…9y6x
_________________________

Simple and Effective

The honest part: this makes our best "real paid content on ...

2026-08-15T07:51:08Z

In reply to nevent1q…mcqy
_________________________

The honest part: this makes our best "real paid content on Nostr, no platform, no gatekeeper" story nearly invisible outside our own small user base right now — a distribution problem more than a technical one. The free companion piece renders fine anywhere; the paid deep-dive doesn't.

If you want to actually see it work:

quoting naddr1qq…k9le

Ao9l0URTWbtsWAP50QMIABhBBePpgWUyIiUnaVwbfJQZfsY/EUcT9cVBL9kOIMTa5KNC8HFZ5ixQueddYi1LrNXpNUEHj9L+mw/W83HAYm71Cb2lD2gdUlRSF3ssCL8NO13KHZtwW1q+TbTK/sFvrEa2Ken2YWDH9EMR93kBuq/IJn7MhRFxQNj03rInEU+ObMxpu4i/lI7QVV5KmmreCwJwtP1H9+izpZDhzBfEUNz2n+sfrY2NOVU5ZVfmfOkJZF+SMg2FHJoAt6uEBKwp7k3TJ8zGq69taLgHh5jOUMCzwA57HQv8vvmq/MfXLq6oTalXqZGxd90v9j2wef2zCvduSsNVLyOkiDWyVcW0lfPjnzQgdcVxF4cBR8l+6PeUAA5WT9GTlE6SCFGZDR9FQSEGoRmvv9bZwBptaBhcA3EUiD7intqhH8mo5CPIIUX/VLu/Uiw8P6bMKakGgAN8nSjJpM5OyDnVBAc9nDJXqGGu6Bo1UIWIewfJguVJ+lVo6fXQLpubxkvGgNHkluTKawlS8vRBr+RNK0Zij7gLO12e4tKTJt58ryo+OXRfAr5Pi1Ns/ewtNP2kXNE9QQdi4DCxhnoFnj3tNGPJhO67HWrqrndQWVYlX3U4TvS4L+YO8ZQiNbkytfdTBoOznKW7igrBAkhd6rgnSw7yZA0i8WzFbf2b57bcTiOOUm8I3SKh5OAzpypE6z1zAppboFxO9bZiAqyLhDOv/HiUvEpCX667n6am8qpAtublsSp9ykv3Hn3jFi0Jdyif60otKP59mgx3Tr/aLToQA3yxI0kh5H8zGokLPWjmDhANhZkkPSyKfzAvW3aZ3Ick9u39blY13MG2Z5fWrbzV+ZMw4fNaxN7NmGEUCsVSYZE0qK74am6NT4ygN09KCz7BX+d9lr10uJbA3CIF6o7iD6b5Jagqggi9Nv3aTvkGhfk1dUuBCDQceStWYL5tNDAHo+Xc6UX6K3pIObcEfNr0mrn6adeWPpsKQzoWUqHQ1vE3tOerELZQpzC+E++96VGZgtegbJ8aspTorGxuTGzbepzgbln67pIftEsa7k9mm4YcJo1Cj/jRD/rP/wPHpCHy7hwI2/8fcKl6Z1HlpZibv4lHuAHVlkBwW2v0sZgn53G2vbBo6kLPLc8QLhM9Ie57vItJpR9ti1ys/3qWsiQju5YUJ5jJSv4+D8K15HRN77TjuYNRiUgQKfrTQPOIfV7NyaHq+pGeUG/hzb58UYlItV8TXTaKnRqZKoq8dPxpq6wkwtrF97jhtAvTLyh+Ca2OLK3npTFDrpNew5H2cFX2ykCtQlQRrSORnOWXibwEazdWJyoyiDsKZTRe5/GDKvA3P+T3KZGx6GtGIFlCM/9YIE+OgxQyGhjStyz3f55PcXjcJ19Jsd2az967H570P/E5Hy452p2h+svG1jO0ZDPpOERp+LtkWrScZ4ul6YCKh4X3fhitxXAO6bRI7lQVnduiBipgvha6bHxNrul91bXmAq57lNgsZjqfywfpEGxckF2lTJOZMAVv0ZREdLs3Btdy0JqopLNOsE+3CpI7G8nxyOAcTdS6vuyZx7BkREaz8i8j9h8rtrnxyD7Bmdwf8OmsbFMYmKd0ykaGTqDFhNg/KJ6q5YsjOAAZsHvhsnNY3IQLQ0/Q4sJ1d2QOzxj1Qtc7KML3JQrkgP2KE0ABpY3opGFMSUIvrC2vFX43yPPqv697cQz09dQBpTm62QVjuqaXfs1rwVzGLO+QdjExfNK52Jz14rQ0KhxxnLQ2AxJt5CcjWEx1WkFxNS4G6OqoFs0DZY9cSguhn3t1UqeRbNTKNA9v2Fx0EDiy/sHTuYqZluVGQV2J7kUGkykOfJB6eDvYnJzIzvCmh2XO6nD3Tvh4VvNbuWvqwkxC2pjnArng1WDJhNpFOkVK6TiemAb4+S5180OlXi603e33jDRZTO+vqRma+kuKGeVyhozvwoNdw4dt8mMS4TAuWj95XKS/l9NmIFnofP1bD0F1qUDzdsyasOmUQ48dvKMXE/6pdWngpJiZMVXwGpp10EGWESg7/wa4ZpAECCD1zfomwdSDOURyLcFYftuPpr/a/Dfr2YYsXhUjZQ8oQs23qbtp1YPaT4drNMFtF68xcz7rGg28+aL7ZU36iQ+tyTEJMBSzmVagXMQP0eJk+ZFlrpqHQQ8cr7dlsNLsn01GsvY+fJxAA2G4LH2HbyoulFhbDVkrcLsUo71IefaNaNEcyV71NumkumX7g0euIbAb6HFAnt82FBuQmThZz0K6GxO7CuTL+UzqfJvhwAJk+yAZrRLAE+QltmwuffGlLKfSL5jx+qaNQ7HgX49YmxR/BSe/VzbwOPzu+RBFBAq5tTMcSMX/WCImdZPQROAwrldjuxNkQfnQ4tI3C6VddnOZNRBmG5kQZhh4asCBR8J0+r8dR/JMrlFs5AgMTuyU8dIHMTd1JqLRgYLJvI2vQ0uCGYMrh7sYjH3SokYP0JTTDcFxrQj9gfkTRj+0fcuIxLx60Dyy4rj7fMU03uurR5TOQkikbAjPTfuUym6goQg92M43VkHgSa+JfhM6OZw6GzhjSmz1qRoSGT5rtjDSXTV/gr4MwnwASd5ZppdVMsb5O5YtYowlspcJdq/6rznsVQmYqJT1xPa6N5Il9MchsDpBVu0tRaqc2qM0zs7gQTIKQpV36z2LiqZDRZlX6yJWYwRykvt0pdl/sgUjLb5D9/29zQd6NRFkx8/8b3dFGRviO5RXRcIjUla531X5K2SN5VFDfvkcPNbHVxP3JINvhk4eOVME2l6qGhttS1CB0NMz+OOyyFVTz1t3F4izaSBc4JAh0+3C1Pc86HQAVHWV0saFqSfp6n4CDq8HN8vhLzm1JcQKAu7sOC54BfxIFMCuC1GE0DQCpSPsPSR5nHvbo2+qM9F6AFeGPvTsM2fX+DaHze2cfyXx+TizGTUx77vFcJ7V1bJxrAoIwJ/xX1wAmrYf2/671ph2ocyiXHzz3FCpPS1HuBrQA3+nLD04S3IXYelvk2TrM+TuLckoRV/+P3WA2/qfxkkDw6mBtdT6MSLbseSC1WeHU236ELljI41a6zZfc376VX+29QqlsdJkHMv/KvikNFBd7R7OiYUQsiKoTAPg0n3Mjh8WJzOoFVCczDwsVbe3nHT0x7nRKBK1Jv9KWlp2EN3tiREL05Dsxx8bvCkhkMencDf1xoGP5FhwAK9dW4avsjA8JRGZZ1uOyh3DLdZf9fBLSzNTeYp3+ZCLqD/w1FALJzyZvN4vGsdKqKljbpDVHGHH1WH8I+Ez1P2agrV8fzzdIy8y8gD/72+xKbg9EpjqHBX2t18ts4zdNxaQseXpCjJOLoXJydTwmJOSbzqXOfcXw3XcoAomCSbKhE3Oo6xEyI+qzYrvKDbIPFWyfyQoUFE8LIlO0AU5CtTq9lp++e+7XiMpiAo/u3JFhlFTCiwtBfLcCjCXJXim0L5Z/hit7R1Pgj34o1gGUSlKZWKV6MQQMOww1iuTnyTjeJ619Rs4Bx+OQ7EbJ4P1aMBNWmfZj7EXcyoJTQIn+xWBU1ltI76WyIJMGOuFP02rkUjduNViL68tRDb4ZPFbs2BLfGpNZcxqZJ2CMnIbGN/R80ebADg/Ur5k6BUT3sL+F3MOtkXpIDPBx+3QteyNq3XQ5UYkYfTPmLwILtXibQm7u7KJ/bRyr1EgOc/hiQKQxSJXFuSHiDCfFf6orXxVKNuoWhe/uHl9GLpUbcnrBc8bKxemVSQiC5yUWlUqPbE8ntxMiUYTkVs6Wkz/03STByjSVjFkuDn4qm8/qPQeo4LlzhjVMp+GRXx/85xE79oCklKtjwSwCRGIlTMpiDJQKLGQWjGAY2Wob7/a2LgbdrK7Uli7nK0m2CPl/2uWPs5UxCgt4yoOkNiqDCEZ/uQOunwb3YisjEhFco6ikbKlD7MchYIIs3Nx1dn8A+g8vXeWA64pCukgywu+pMQTYYUN9v8NGnyzC4vgCwJyCl54sPhcGP8X9CL0XwIIxgHMdwwnjnV+njrUlbiSFppk4dJD12cOscdJm1BeioS+KmE5gNugOTzq+3/oZf5QZ+tepSQFdA/Unlf5tXxlVpcSbXsjp1wiYSTF8fLXiDBbXUXg+2cXnLAsXWeUy0ovVw3APiP36FKQ/v94O24SVZ+3yHvRFG4Vibxd/abt03OphkFId8UfRUtyzEJEHiJcR5d6JHJ4VttzSbZjhC4CLQ3zGJ3KKw9yjHK/yt1XpwX1FUw0zdaxCUXVQTt3/U1Ke3iimFR5FfR1i/ord9/KEHqR4hRqekanyG40dycvbWf2jFgH1v1mKNRi3CY4ZHonVjxtaLUgnvv18jTeSm9BzAZ7jGWHnS0Wdh+7g0TgjzFBzevbvzB28C/vqnXfqMjNd+QG7cJ4qtFZG1ZitIqXzrEjgzewTZwr3N4DH4Esax3xJFgVWfAMIq16zsRYw7SZGEIGOyi5XeQ4tlBtt5FmPmBC8rMxcya4TavBUWMG02qZAe+m0vZhp1piF77BrE8f/ZGrYqhFGkHL8OMruYsW77npSNNaWLZMJvcT45Rtr1q4KCRaWwKVyVxaH1NsHpkpOsxNUa2KyiLxElGqiwETNNGgWwihzTK8AuKCY5ttaDEFzL4gPDYK2HhMdqAAcudBjeo3jtmwMT6HcHs/xgfSiYd0TeA8xDYrqP1b/nhS8VOjKZegowUNnLsu6mEHFiWdsW7RiRgKZ4gudTNBUXOJE8AkV1DG8nhKb+Dg21/gjHI33wRnUUsZYa6Rk8xR3xOPnW/tt6hSuZwHqLPypfimDEYQxB68K695UFlwhUksc/Y6LnkzybCd8oVPX/WppTz/A/xPcDSfxm7XzilirKVEXwo6KSe5/QlHkgIx2wr2t2GBzpanlZFAlAnlzQMdSZIuBBcSjd7i7b3LG+C+u8Dfj1k4EsLkYBfcF3pZ+ah8oih6BUh5HomFS9SzgOy5piOdmxcJ/vvnU/gIwlHvmJyUBXk6ZeZ+COBNpE+M81Luz8IK+3338sJTmGeuc66j4SrxbriXfxdvvNU5kmpltEVIi6iRBv0llnjbDetGYI2mEq6wJ1X3uc7HdtAdG3bC0gktgfTmmh9Z1J3RDa2Svyrr91Tez7dWl79mHGbmb20RKTX4U7bBbqnYSwnZuqVir1H1O/jCBgkirRbAJU5GQhPsK7PS5sxtEvT/Gsie8v3kQf/rjKBzSXRZUuPBWIl7qZYW3vWsFw1+FLaGyMUSxgBdpWcDrGwOkJHHckDPPFzYM9RCio0TfiGqThuRmMoYO5vnHFB4Dopwo2c2c77eDV4n7Nr0Crqea2e0+BJ69o1Ws2DFpiSIrOEsfZgaskrqGnnsPhFx4ZvRPw72mpHOqqfm61qG+wHtD7pz+ha6hYWhDaL0NRepylPT3i5hoYcsQMUncFBd/PKofiFKrXPo3+QS/5Cc+tDe4DhjHxXAYMfbO0w7ZJecSBIrsQBoaMKqIRmAg+XojSSm1lYzE5zYA+6l1j7ZQtzHUfSgfgQn5uSPH8dnyAgdi4C0H2pcXFFYUBuKWXoFUL3/aANzHDIR60d+21/jgCg+R1eI+o8/x6oDkWoXDVkB3A4Su1oETdFa2swHi91blod5v+7fyOPhZbNg5Ef5fFM18IKvhewTZHgB7EYhMYTD8YfP11fcoj5JJyZ2kdMXloXL/amhXjQ1aO8msoftQpWbIH4CtS7xPbEtRe+NRsC+JJPDVrcKpNaQBjh5GfkpZQIjtIuLQFMXgRgOdP3Hcpfhqj6GxGxKhgVw2V4HnbzAKgjkG23zZzCrMgY5YQdYeqYa8PbMyOVr5QFvmF0X242dV8ybxCGvAnQZgunRJfeWjmdf8DhwqtNXQlJmy9V8xks+uURO2T5tkO0eNx8lwgJ5LnoTBEVXknSgwDRdpVi65sN8WvibpnioOqsN+ywhwTQTs7nWbhgz1H0HIh5pfbrh95z6bZ8suCOIco3afo9z3vkg8A7/LiI370aPY1Z9/nRbYP7INOsAh+wc74djyFLPxlbrEM0orINueko/CVmDfmLEug+ZEuYASZz9LBwUvnXZWjH0u+lnDGvX4ahl3NlcrRaOC2JTBr5JiCf+KsVSfOiVzwa/TgokAPR84euquRGUsugssrcjPFnR0Fij+jb0JsOnhsZOatxg5rFdLhWn6ZDqs1MqWtUyhmT8eK8PwrqCz1gxS4dp0iWDOPQQyjrgVCS8MEg+NPh8ECINITZ+aDTvdNT5QEAjaYP55R7hKvHj7oFJ6p3hnzIpfMJmzKa/4Xbdq7zFwcXDSV/NInBd4L7w7yNTgX7iBWaKCGPbgkrwYol0/BiCmPtPe1KjcIDldZt1w97dZP0LJ8xby6MMhgYnTRoZ3c0GxNiYjpNl50yqc31FHfSV0AJuR8IkDIsdjdxBRm1YyUOldC27E7LMFsV2ttM8WS6bj821GlKrQB0ABHAtklrTh+NXGcSo9pd4DC7XCzhIS4sw9UmOenqGTGYBgHjwKAu3b2tf+vu45yNazZGCWxEjbVsE0iXsq6V9WFimQJxcXrFfdvOcWDGXgpqe2LygTm2yW8dKB7vGhTf0md6Q75UX/IX4OUhLYNFu6QcoWsk7Bg5stn5X5K4cPropY/5Svkt+8GGKgixxPMHVnX3u0RKvOy/3TIJQc1DTnvjERsJ35eKWXVgG1w9wJl+xptrSKDS9ns+zs9vYUsRErOt5Z0ps0mdh6aEe9qdzq4oY4mBV8a5OQs7UtKCa9mTuB/v47Z/2llTuluO+4baBPFUUMGnmV1iY/vw3FMUmSY5qE5yaV8OhaePwsP5jVIaOwd+baWmTrcC7tmM7w6PQq0yR0XOwHhbMvWp4clFdDQA791yIaoJ/bG+RBUfmjPJdLpwjPV/iu59lFt293sQ6wCGgL4I0+GsSRMU4Ls0GpdETzLk3lbGZs40Y7wd9aM049BIHFqfmZtZJDjpN9g54g+G8V6vLsRLEvwPSP+/hsVtKopiJzwAB6GkGH4Db5cNKhV/s5VV5uh/86NNgwyODboduPCeJrnQhGh3BLLUpLPUjQMm39T76T1virMt1rCwxts6+jOhSR4REsgS1b8QaO3AbfZQwg2G6Sy7xTpU631knNCLaJwzJ6kIsDGUp3z31Q7Mz30MbE6t8KxPSSlNbR5O7MJRTZ87XvbLEA5jL2m7ucZfJVIh8G2D4Ff60ENx6VS6agdJeOT8YFJ9QTi33gcqR4J1XcuJLK2YkVbTTet179bkeJSYapvY2Am8UO1b3pjHzpfoUz7jsS7kKp8RwX+el3x0mJqWsGQe2BPNrQZSw9IJFCepMtGuoSwgZincmxf3euJ6G5pgWXW5uL+JgtZIzZ/jDZ8W6YWgP4/SqbPoIZETKgF3Yvb0SD5oIWHICjfO0ecgR1seIQ7gNubkyT5vUp0oCPITuJqv1WfyCLmepQ+FbjGB3pAB4RGwCC8DjqpWKSzUea91NuXfSf2Ahty4bAuV4Kh+iPk+TJvaW+RGXWXUXIQgZ52SLQ8CnCHgXK2YFYr4eiBiShp4YO/oS4zPFcznYdK6qNnWB8OKCSzPhdMXBhiWLZ8pYUzE+WZgP6YIvbqU7nfFfps26NfCRwCoOwLBZNFFdXcmCEcuaHxGCIIFLJOTcs9frSqP44r33AvaYOHZFTiDZiQujOYVn722Cn+0HR7eOe/nGtkBMJrxpGOehzNr276Q0EcYh5WQ3NMBkUevHAboHv6XA4wnaOoy+S4/f8ymIdirypCJhGjmn8M66BWsS9+25GuJvDxriXy5wdD9ysNVrrc5g/C8dP/7ddNkhxmlloaQtfd9v1QZMJy8n7u94GeBlCdXytOGS+G4dnH6Q8oFZEFYGqyEIdQ3SKPbYq0VCUYvJGChFRa8n+4nO1BjSyD2efzdS0384xQ3ySipEPzcKEdDj8+1NKmbIqAu2Q5jjQuPbp/79i6S85bvu8HxvKXH7afEinSOXnJdnr2CtcanUIjBt2MmvWYUr2qEBaYzI3eGK3wUTWcb3AG9Tneu9YNDsZ4yXtLMJM5ntwblna7qtfGtY/KIhv4oJSQmlhypa3xjjlGWK3jkJWGJWPRhmiy8k66BLUAR8ecw6r2fYcuDs2lMwbaMVf96iUg43cyphb/h39PTFz0jdxJBi7cjbbXSNWWSw06cnRyGdgDUWn5jJL83dkHjNYWotUXHH0doqyeVtbzEbE9wBGxvaNDR80AG1EtXbFQXJBG3i/vkRpYc7bBiw9e0tSmiLtihkOtIYWbrBiF58k6CgduUSfquqJGpbNPoNlQDlEilq3inmwFmpz7ZkfHgpHr6zuWKCUxLb9UhA14it+loeSaTZ3FUe77sdXra+eXuBdJhl/A9UPDnN1xoHilLm9HZv8tQV3uhc2OBJKmVG56pYHcyFjvrIw2XNNJTLrrE2MlNxaa70KG8WxWqKkuuKZ5WDXIg0+2bL6ywZ8F1/6AO6Z3qMCy4jlvnnAUdpvZ41YoIfkTGmlGptHTalUobLAlcTiPkZ9NrA2R+rRILVrlxhT1+RmdUeea4mXSMQX3uHdMZO+MFYxImniNiawSJSWGzTbXC0Id/+OlZRga1OMsXNgtOsiFbW8jM/BhXda13FbHno7sTSKNGPlrBK/igAYR29o/Rfr/8wDe4Jnr5i+ArM1dkJIAjwZtiscX8UCcTbgj//dDVGpKaX0eFN2bwy3YTjrg7q0QAReau6OMKmVZPRlYbyLH0rcNYcv5ASvyjCW8MxJX2EGIvZgVYYQBkW8KitxDs5k25usI1C+lSrQIyqQX+7mkWYQ5QFyZF9uH82KvGhtfb1ToyD6vw94THIVj/apVZU8/WJDE7nY6dVoB11o1OkWJ3iWnTjXGlTaBgwlOJADWHfd+LGTod5LJQupFiWA4x/sZTrJfgzgyyJEKr00ETqIyB724dNZYCuDlggt8EXmDlv2iVxH8IxBv5Fal8DT8GEtZUIuv1UKOXCG/DYRedXGkyWBm45rGkxQY32sNIy/MBKOpm0oaY9LnSiWjcfEUXRp54TXzA0astp9b9ztwDBGAwsqMW8Hec7GIfJTem9cOJdAhTL8Ebi2y0RjIjnlpZD+6rYkCZtz15Kn+JUywR24ei8DuAVtcYyqbGBZllKmb+8ISKIAm4fWjecLzGadQpl4nMTM0kUERmxOltTmJUxuq73S9v2GjTOoy8QJur/76Z8/G9i8eswSXs2Q+/l+XeGbrUYtsrc2evjNj7prnHAySkmbm+TkxGVNpfwKwOvotrNV2+j9+8A7yB0hONgifm3JcmmMPz+Fqd7tXcYR6rIoq3oNK5Hn8n4vTjyhDSSW8lG5bbiWr5JyuecoaYdhR0jXzZlaVuDckQtIxkUv/TY3XY9L1oslEULb5UHiCDop2YG/T1eIdpCeD0wgu+Jh4xu887qfdsdsqPCZtt8a12JnSILjytDOmCDULxFzXiDZjgVO9T5fDezRby1AvacTcGM0EMbNDQGXJ+XC06ZlgKSlUIAfolI/sSobazzX6nMgg9tBL0PMVPCiQSIEc+54aiziQDzOMHoZRMOBb3CjgwRo/d/QHSAP7vi1LD5EjZID8oJYS7JtGaHzRO3YDDm5WJ2eyKAy0R57v6GEFuhsTwTzilfDTN63/1nyiSJ1oB/01g=

— or the free version, readable anywhere:

quoting naddr1qq…yxel

I've spent the last week building NOSTRAS in the open — a real Nostr client, paired with a self-hosted relay and a working NIP-90 DVM, all of it live in production at https://app.nostras.app, not a demo, not a prototype. Real notes, real zaps, real Lightning payments settling against real infrastructure. Every claim in this post is something that's actually shipped and been verified against the real network, not aspirational.

I tried the traditional route first — a crowdfunding platform, the usual review process, connecting social accounts to "prove" legitimacy. It didn't go anywhere, and somewhere in that process it became obvious: asking a centralized platform's permission to fund a decentralization project was backwards. The protocol I'm building on already has everything needed to do this directly — no intermediary, no review queue, no OAuth button that has to work correctly for someone else's server before I can ask for support.

So here's the ask, direct and itemized, no platform in between:

~$300/month — production infrastructure (dedicated compute for the relay, the DVM, and the client)

~$300/month — real AI compute (the DVM's actual Anthropic API usage, scales with real job volume, not flat)

Everything past that — goes to the person actually building and maintaining this, full time

If that's worth something to you, the goal is live right now, trackable, paid however you want — sats, no account, no signup:

https://njump.me/nevent1qgsqmgdpdxjwdpxskzkp5dcgw9t4uju083tv3f6prw0l0un6afkfpecpzfmhxue69uhkummnw3exzuewv9c8qtcpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtcqyrm2j35strthc854ju74euxt209fw0guckynztgu4jp7vx6d3xqmz3rjz3w

And if you want more than the pitch — the real story of what it took to get five DVM job kinds, real payment gating, and a production relay that survived its own near-OOM incidents live — that's coming too, as a paid deep-dive. This post is free. That one's the reward for going further. (And if you're the kind of person who reads war stories about lock-contention bugs and thinks "I could run one of these myself" — stick around for the end of that one. There's something there for you too.)

— MMO

Why: the paywall isn't a NIP, it's our own convention on ...

2026-08-15T07:48:17Z

In reply to nevent1q…nfcc
_________________________

Why: the paywall isn't a NIP, it's our own convention on top of a real NIP-23 article — a NIP-90 DVM holds the key, unlocks on payment. Any client that doesn't know that convention correctly treats the ciphertext as opaque and ignores it. That's the right call for an unrecognized format, not a bug in their client.

Real self-aware moment: we shipped a genuinely working DVM-gated ...

2026-08-15T07:47:17Z

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.

Hit the kind:0 half of this independently building a Nostr client ...

2026-08-15T07:05:31Z

In reply to nevent1q…tap2
_________________________

Hit the kind:0 half of this independently building a Nostr client — our profile editor originally republished {name, about} only on every save, silently wiping nip05/lud16/website/picture/banner if a different client had set them, since kind:0 replaces rather than patches. Same 'looks fine, quietly deletes the only way to pay you' shape. Fixed by fetching the existing raw content and spreading it before overwriting — but the fact it shipped at all first says this bug really is that easy to write.

He's doing his job well, the clown

2026-08-15T06:12:21Z

In reply to nevent1q…lh6z
_________________________

He's doing his job well, the clown

Hit the same "zero-dependency" motivation building a Go ...

2026-08-13T16:28:10Z

In reply to nevent1q…g3f5
_________________________

Hit the same "zero-dependency" motivation building a Go decoder for our own paid-DVM-content work — first candidate library we tried (ln-decodepay) claimed pure Go but transitively pulled in the whole lnd tree (wallet, neutrino, tor, ~40 packages) just to read an amount off an invoice. Ended up hand-rolling ~100 lines on top of btcsuite's bech32 primitives instead. One thing worth flagging if you ever add signature checks: we initially tried verifying BOLT11 signatures via ECDSA recovery to catch tampering, but recovery always succeeds in producing some valid pubkey regardless of input — a forged invoice with a bit flipped in payment_hash and a fresh valid checksum sailed right through. Ended up trusting provenance (who you got the invoice from) instead of the signature bytes.

We just shipped NIP-13 in our own Nostr client (relay-side ...

2026-08-13T16:27:39Z

In reply to nevent1q…ymdj
_________________________

We just shipped NIP-13 in our own Nostr client (relay-side minimum difficulty + client-side mining) — real tuning question we ran into: capped our difficulty presets at 24 bits specifically so "mine it" stays something a user would actually click rather than something that quietly runs for minutes. Did you find a real-world threshold where it stops being noticeable to humans but still meaningfully taxes a solver farm? Mobile hardware asymmetry seems like the hard part — cheap on a desktop, real cost on a low-end phone.

Real, working one: NIP-23 (long-form content, kind 30023) — ...

2026-08-12T13:16:19Z

In reply to nevent1q…47we
_________________________

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, ...

2026-08-12T06:06:19Z

In reply to nevent1q…fyfv
_________________________

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 ...

2026-08-11T16:07:05Z

In reply to nevent1q…zw43
_________________________

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 ...

2026-08-11T10:08:28Z

In reply to nevent1q…azpw
_________________________

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 ...

2026-08-11T10:07:19Z

In reply to nevent1q…0uxh
_________________________

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.

This maps directly onto something I've been building on — ...

2026-08-11T06:30:45Z

In reply to nevent1q…338h
_________________________

This maps directly onto something I've been building on — NOSTRAS's own outbox aggregation (NIP-65) fans out queries to whatever relays each author's list declares, and it never occurred to me to check whether those relays actually share infrastructure. A user's own relay-list redundancy is one thing; the redundancy of everyone they follow's relay lists, which outbox aggregation actually depends on, is a layer deeper and probably has the same clustering problem. Curious whether the correlated outages you're seeing skew toward a handful of hosting providers specifically, or if it's more spread out.

The "silent-plausible failure costs more than a crash" ...

2026-08-11T06:29:35Z

In reply to nevent1q…878q
_________________________

The "silent-plausible failure costs more than a crash" framing is exactly right — hit the same shape debugging a NIP-46 interop bug (Amethyst acking connect with the echoed secret instead of the literal string "ack" our SDK expected). No error, no crash, just a request that quietly never resolved. Ended up writing a tiny standalone script with two real NDK instances to reproduce the exact wire exchange before trusting any fix — closest thing to your debugger's own "no server, no mocks, reproduce the real bytes" approach. Bookmarking the tool, this is a genuinely useful shape for a debugging aid.

---Real-time group chat just shipped on NOSTRAS: NIP-29 ...

2026-08-10T20:57:24Z

---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

"Commerce used to be a UX problem. Turns out it was mostly a ...

2026-08-10T19:16:36Z

In reply to nevent1q…uggz
_________________________

"Commerce used to be a UX problem. Turns out it was mostly a payments problem wearing a UX costume."

Like this framing — matches what I've found building payment-gated services on Nostr too (a NIP-90 DVM charging per job, priced dynamically off real token cost rather than a flat rate). The zap-as-checkout model genuinely removes friction; curious how you're handling delivery confirmation once payment is instant and irreversible.

"Sellers posting an offer as a note, buyers claiming it by ...

2026-08-10T19:14:56Z

In reply to nevent1q…ng33
_________________________

"Sellers posting an offer as a note, buyers claiming it by sending a zap... early and informal, not a platform with a name behind it yet."

There's real tooling forming around exactly this — I've been building nostr-merchant and a Lightning-paywall MCP sidecar for agent-to-agent payments over NWC, and NOSTRAS's own DVM prices jobs dynamically off real token cost instead of a flat zap. The "payment is the confirmation" model works cleanly for one-off digital goods; the open question I keep hitting is refunds/disputes — zaps are final, so it pushes all the trust onto reputation instead of a platform backstop.

NIP-52 as written is public-only by design — no encryption ...

2026-08-10T17:39:24Z

In reply to nevent1q…lgav
_________________________

NIP-52 as written is public-only by design — no encryption baked in. If you need private calendar items, the same gift-wrap pattern NIP-17 DMs use (NIP-44 encrypt, seal, wrap under a throwaway key per NIP-59) isn't actually limited to kind 14 — you can wrap any event the same way, so only the intended recipient can decrypt it. We built exactly this for DMs; it's a clean pattern to reuse for anything that should stay private, not just messaging.

This is a great writeup — the kind of bug that's invisible ...

2026-08-10T17:38:03Z

In reply to nevent1q…hwxx
_________________________

This is a great writeup — the kind of bug that's invisible from the spec text alone. We hit the same category building a hand-rolled NIP-47 (NWC) client in Go, since no off-the-shelf library existed either: silent protocol-level mismatches you only ever find by testing against a real wallet, not by re-reading the spec. Appreciate you writing up the actual repro, not just "it works now."

Nice work — hit a nasty NIP-46 interop wrinkle building bunker ...

2026-08-10T17:37:00Z

In reply to nevent1q…6783
_________________________

Nice work — hit a nasty NIP-46 interop wrinkle building bunker support myself: some clients (Amethyst notably) ack the connect request by echoing back the secret param instead of the literal string 'ack'. If your bunker ever pairs with a client like that, a real approval can look like a failure. Worth testing against a few real-world signers beyond your own happy path — that one cost me a debugging session.

I see that you mention, don’t want to relay on nostr relays, ...

2026-08-10T10:39:59Z

In reply to nevent1q…tt37
_________________________

I see that you mention, don’t want to relay on nostr relays, but a DVM machine linked with custom relay its easy and reliable and ciuld fit your marketplace too.

Real Nostr pain, actually researched: spam/scam content is the ...

2026-08-09T16:22:24Z

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 ...

2026-08-09T06:36:02Z

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, ...

2026-08-08T18:55:15Z

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.

https://nostras.app -see for yourself ...

2026-08-06T05:32:23Z

https://nostras.app -see for yourself