MMO 🇨🇭
MMOnostr

Solo builder + AI cowork, no vibecoder, a real IT guy with more than 40 years of experience.
https://www.linkedin.com/in/mauro-moro/ | https://llmops.pro
I'd love to speak to anyone interested:
https://calendly.com/llmops/new-meeting

Shipping sovereign agent-payment rails on Lightning + NOSTR — nostr-merchant (PyPI) and five MCP servers (npm).
https://github.com/llmops-pro

The shop, the demos, and the voice live at @SOVEREIGN_CITIZENS → https://njump.me/npub1hdg932jvwc3jdvkqywgqv0ue4nn60exrf92asy8mtazt3hjg7d2s2yw0nw

Building NOSTRAS, a Nostr client with no app store gatekeeper and no custody of your keys or funds — paired with a self-hosted relay that does the heavy lifting so the client stays fast, wherever you install it.
https://nostras.app

Public Key

npub1pks6z6dyu6zdpv9vrgmssu2hte9c70zkezn5zxul7le846nvjrnsncuyds

NIP-05 Address

mmo@llmops.pro

Profile Code

nprofile1qqsqmgdpdxjwdpxskzkp5dcgw9t4uju083tv3f6prw0l0un6afkfpecpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds9hgrlx

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1pks6z6dyu6zdpv9vrgmssu2hte9c70zkezn5zxul7le846nvjrnsncuyds

Show more details

Last Notes

2026-09-02 15:31:13 UTC

- reply

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.

2026-09-02 11:12:56 UTC

- reply

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.

2026-09-02 11:11:24 UTC

- reply

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.

2026-09-02 01:59:31 UTC

- reply

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

2026-09-02 01:50:08 UTC

- reply

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.

2026-09-02 01:48:51 UTC

- reply

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.

2026-09-02 01:46:27 UTC

- reply

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?

2026-08-22 20:55:17 UTC

- reply

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.

2026-08-22 16:59:38 UTC

- reply

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.

2026-08-22 14:59:44 UTC

- reply

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

2026-08-22 13:57:08 UTC

- reply

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.

2026-08-22 13:56:19 UTC

- reply

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.

2026-08-22 13:55:41 UTC

- reply

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?

2026-08-22 13:54:25 UTC

- reply

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?

2026-08-21 18:13:08 UTC

- reply

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.

2026-08-21 18:12:37 UTC

- reply

2026-08-21 17:50:00 UTC

- reply

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.

2026-08-21 15:25:39 UTC

- reply

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?

2026-08-21 15:20:51 UTC

- reply

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.

2026-08-21 14:57:29 UTC

- reply

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?

2026-08-21 14:49:36 UTC

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.
@npub1ecx…zvag
#nostr #agent

2026-08-21 13:27:29 UTC

- reply

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.

2026-08-21 13:26:56 UTC

- reply

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.

2026-08-21 13:26:24 UTC

- reply

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.

2026-08-21 13:00:48 UTC

- reply

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.

2026-08-21 13:00:13 UTC

- reply

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.

2026-08-21 12:59:14 UTC

- reply

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.

2026-08-21 12:28:06 UTC

- reply

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

2026-08-21 11:06:05 UTC

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
https://blossom.primal.net/9a136b84b9c897d64a60e1c91bc9537cef11a5a63e86b9593ac4a619c58d9819.png

2026-08-21 08:09:41 UTC

- reply

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?

2026-08-20 20:28:58 UTC

- reply

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

2026-08-19 17:05:54 UTC

- reply

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.

2026-08-19 17:04:58 UTC

- reply

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.

2026-08-19 17:04:20 UTC

- reply

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.

2026-08-19 04:10:13 UTC

GM
#nostr

2026-08-17 20:18:53 UTC

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.
@npub1ecx…zvag
https://blossom.primal.net/76bec2baf8b267f6730b2c70b8e93e220dab5aa3e3e30975a60efc62ac33378b.png

2026-08-17 20:09:53 UTC

See for yourself:
@npub1ecx…zvag
https://blossom.primal.net/d247f9b5f7b5e28e9521b14a0f32257a48cc323430c41182ec8f6a74a8a34804.png

2026-08-16 17:08:16 UTC

- reply

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

2026-08-16 17:01:16 UTC

- reply

NIP-65 is a nice beast

2026-08-16 16:50:37 UTC

- reply

Or just a better LLM Model😀

2026-08-16 16:46:55 UTC

- reply

Right! Follow the money and you will find the truth

2026-08-16 15:27:34 UTC

- reply

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.

2026-08-16 08:29:44 UTC

- reply

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.

2026-08-16 08:28:48 UTC

- reply

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.

2026-08-16 07:26:00 UTC

- reply

Cool gadget!

2026-08-15 18:37:54 UTC

- reply

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.

2026-08-15 18:34:13 UTC

- reply

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.

2026-08-15 16:47:43 UTC

- reply

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

2026-08-15 13:41:05 UTC

- reply

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.

2026-08-15 13:39:46 UTC

- reply

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.

2026-08-15 11:32:24 UTC

- reply

Simple and Effective

2026-08-15 07:51:08 UTC

- reply

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: #naddr1qq…k9le — or the free version, readable anywhere: #naddr1qq…yxel

2026-08-15 07:48:17 UTC

- reply

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.

2026-08-15 07:47:17 UTC

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.

2026-08-15 07:05:31 UTC

- reply

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.

2026-08-15 06:12:21 UTC

- reply

He's doing his job well, the clown

2026-08-13 16:28:10 UTC

- reply

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.

2026-08-13 16:27:39 UTC

- reply

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.

2026-08-12 13:16:19 UTC

- reply

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.

2026-08-12 06:06:19 UTC

- reply

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.

2026-08-11 16:07:05 UTC

- reply

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.

2026-08-11 10:08:28 UTC

- reply

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.

2026-08-11 10:07:19 UTC

- reply

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.

2026-08-11 06:30:45 UTC

- reply

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.

2026-08-11 06:29:35 UTC

- reply

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.

2026-08-10 20:57:24 UTC

---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
https://blossom.primal.net/0d7d720caffb5de4e52c9b174c8b67bb73eebe21e12ea8c6c8f28a789fdd5c1a.png

2026-08-10 19:16:36 UTC

- reply

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

2026-08-10 19:14:56 UTC

- reply

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

2026-08-10 17:39:24 UTC

- reply

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.

2026-08-10 17:38:03 UTC

- reply

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

2026-08-10 17:37:00 UTC

- reply

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.

2026-08-10 10:39:59 UTC

- reply

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.

2026-08-09 16:22:24 UTC

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
https://blossom.primal.net/6433132449bd125276f619247ea8e1f9682066415cc0dcd339670fa25fc3c89e.png

2026-08-09 06:36:02 UTC

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

2026-08-08 18:55:15 UTC

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://blossom.primal.net/0c310928104d00759aedba300dd689d8f2c4e8fbfd9238944d0bac5db58ab0dd.png

2026-08-06 05:32:23 UTC

https://nostras.app -see for yourself
https://blossom.primal.net/b5b978876bcfc7ecdd7dfd2ae9120665a6aef3e14399e54a6bd5d3b62e2ce8b7.mp4