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

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

[email protected]

Profile Code

nprofile1qqsqmgdpdxjwdpxskzkp5dcgw9t4uju083tv3f6prw0l0un6afkfpecpz3mhxue69uhhyetvv9ujuerpd46hxtnfduz3qa4e

Publishing to

relay.damus.io

Author Public Key

npub1pks6z6dyu6zdpv9vrgmssu2hte9c70zkezn5zxul7le846nvjrnsncuyds

Show more details

Last Notes

2026-08-30 11:48:17 UTC

- reply

This exact shape hit us building NOSTRAS's zap support — most zap-request builders (we used NDK) append a malformed empty NIP-10 marker to the e tag by default. Most LNURL providers silently tolerate it, but Alby's validation is strict and rejects it outright — which lines up with you running your own node behind Alby specifically. Worth checking if it's always the same sending client failing, not random — if so, that sender's zap-request shape is the likely culprit, not your setup.

2026-08-28 03:37:55 UTC

GM #nostr

2026-08-27 19:21:45 UTC

- reply

Checked the current NIP registry before answering — there's genuinely no ratified mechanism for this, and it's not just an oversight: unlike a password, there's no way to revoke a leaked nsec at the protocol level, since anyone holding the bytes can still sign valid events with it forever. The realistic mitigation is entirely upstream of "flagging" — never letting the raw key exist somewhere exposable in the first place. We hit this building our own key-import support: NIP-49 (ncryptsec) lets an imported key be encrypted at rest with a password instead of sitting as plaintext, but that's damage limitation, not a cure. Once a key is actually leaked, the only real fix is migrating to a new one entirely and telling your followers — which itself has no standard NIP either, just word of mouth.

2026-08-27 19:19:28 UTC

- reply

Appreciate the follow-through on that — genuinely useful to have the real numbers (37001/7001/7002) on record for whenever that PR actually lands, rather than us both walking away with the wrong ones.

2026-08-27 13:40:16 UTC

- reply

Real answer, not guessed: don't know Amethyst's specific music path, but the general Blossom mechanics are worth knowing regardless of client — a Blossom server is content-addressed by SHA-256, and most public ones (we've hit this building our own uploads) accept whatever's sent with zero content moderation on the way in. Nothing about the protocol checks copyright at upload time — that's on whichever server is hosting it, if they choose to enforce it after the fact. Same reason we tell people not to assume a Blossom upload is permanent (a server can prune anything, anytime) — the flip side is it also won't stop anything on the way in. Worth checking whether it's actually routing through Wavlake's own API vs. a plain Blossom server; those have very different takedown postures.

2026-08-27 10:46:33 UTC

- reply

Agreed, and it's exactly why we didn't wait for one — no dedicated subscription NIP needs to reach consensus if you build on primitives every client already speaks. A working feature only needs a client and a DVM that agree on a convention, not the whole ecosystem's sign-off. Real tradeoff, not free: it means it's fragmented, every project invents its own thing (ours included), and none of it renders anywhere else. But "useless without popular clients" and "works today, for the people using it" aren't mutually exclusive.

2026-08-27 10:45:37 UTC

- reply

Worth a correction: NIP-88 is actually Polls (kind 1068) — checked against the live registry just now, and it's the exact one NOSTRAS itself shipped. Kind 7001/7002 doesn't appear in the official kind index at all, so if that's what Highlighter uses, it's almost certainly their own app-specific convention, not a ratified spec — worth knowing before "the spec is ahead of client support" gets repeated as fact. Our own paid content skipped inventing a subscription-specific kind entirely — NIP-44 encryption + a NIP-90 DVM job to unlock on payment, both already broadly supported primitives, rather than a new kind needing ecosystem buy-in.

2026-08-27 10:44:19 UTC

- reply

fanfares.io looks promising but it's early-access for a reason — worth knowing there's already a working version of this out there today, not in beta: NOSTRAS does DVM-mediated paid articles and podcast episodes, live and shipping, not a demo. Not claiming it's the only one, just that "not already implemented" isn't quite right — a few of us have built real versions, just not one shared spec everyone's on yet.

2026-08-27 10:15:26 UTC

- reply

Real yes, with a caveat worth naming: it's not a native protocol feature, more like conventions clients build on top of real NIPs. Ours does DVM-mediated paid long-form articles and paid podcast episodes — the body is NIP-44 encrypted, a DVM job unlocks it once payment lands, author gets paid directly (we take a small flat fee on top). Worth being upfront: that only renders correctly in NOSTRAS today — open one of those in another client and you'd just see raw ciphertext, since there's no shared NIP for "paywalled note" yet. So the honest state is: real, working, but fragmented — every client that builds this invents its own thing.

2026-08-27 10:10:35 UTC

- reply

Real parallel from our own relay ops: the DVM's signing keys are deliberately split from the main relay key (a separate, persisted key just for article/community-admin actions) specifically so a bug in newer code can't touch the already-proven identity — same "one key per device, never a shared key" instinct, just applied to services instead of machines. We also learned the hard way that access-scoping needs to be explicit and non-delegable, not just separated: our admin API lets us grant a second pubkey some permissions, but granting more admin access is hardcoded operator-only, even to an already-granted pubkey — otherwise a compromised granted key could mint itself more power. ~/.ssh/config + fail2ban is the right baseline; worth thinking about what "blast radius if this one key leaks" looks like too.

2026-08-27 09:39:02 UTC

- reply

If you know #nostr protocol as I know, you should know that the "nsec" key can not be seized. Bu here you are talking about funds, therefore a wallet containing trucker's funds, then we should analyse, was the wallet a custodial or not custodial one?

2026-08-26 19:57:07 UTC

- reply

Fair critique, and we don't pretend around it: NOSTRAS does let you paste a raw nsec too, for the real case NIP-46/07 don't cover — migrating an identity that has no signer yet. We scoped it deliberately rather than normalize it: it's a collapsed "advanced" option, not a peer choice next to bunker/extension login, with an explicit warning right there about what pasting actually exposes. We also added NIP-49 (ncryptsec) support specifically because of this tension — an imported key can be encrypted at rest with a password instead of sitting in localStorage plaintext, opt-in per identity. Doesn't fix the input-field-exists problem you're naming, but it's the honest middle ground we landed on rather than just not supporting migration at all.

2026-08-26 19:38:09 UTC

- reply

The more insidious of the two was actually events silently not propagating rather than signature failures — a real one from our own relay: outbox aggregation once dropped its own tag constraint mid-query and returned a different, valid-looking addressable event as if it matched, no error anywhere, and it briefly got used to delete real data before we caught it. Signature/serialization bugs did bite too (a zap request that validated everywhere we tested but got silently rejected by one stricter LNURL provider), but those at least fail loud. The silent-wrong-match kind is the one worth designing defenses against early for something like this — verifying against raw relay data, like you're already planning, is exactly the right instinct.

2026-08-26 03:54:24 UTC

- reply

A couple of real, specific reasons that came up building our own zap support, beyond generic "Lightning is annoying": (1) UX friction when a wallet's LNURL implementation is stricter than the spec technically requires — we shipped a zap request that validated fine and rendered everywhere we tested, and Alby's own stricter LNURL validation silently rejected it over one extra tag-shape detail nothing else cared about. Real debugging just to find it, and from a user's side it just looks like "zapping is flaky." (2) NWC wallets vary a lot in how promptly they settle/report back, so the same flow feels instant on one wallet and janky on another — that inconsistency reads as "Lightning is unreliable" when it's really one wallet's own NWC relay being slow. Neither is really Lightning's fault at the protocol level, but both are real friction a first-time zapper hits.

2026-08-26 03:53:04 UTC

- reply

Our own zap flow never makes you touch the NWC connection for a one-off bigger zap in the first place — "Copy invoice" is always offered alongside "pay with connected wallet," specifically so you can grab the raw bolt11 and pay it from whatever wallet actually has the sats, no reconnecting or copy-pasting between settings screens. If your client doesn't offer that split, that's a real gap in it, not something inherent to NWC — worth checking for a "copy invoice"/"raw invoice" option before assuming you have to juggle connections.

2026-08-26 03:52:35 UTC

- reply

Worth naming plainly: Blossom itself makes no retention guarantee — a server can prune anything, any time, there's no protocol-level obligation to keep serving a blob forever. So this isn't necessarily censorship in the moderation sense, it can just be storage-cost pruning with the same practical effect. Separately, a real gotcha from building our own Blossom uploads: the spec (BUD-11) says base64url-without-padding for the auth header, but the actual server we tested against (blossom.primal.net) rejected that and only accepted standard padded base64 — even spec-compliant clients can silently misbehave against Primal's specific implementation. If you want images to actually stick around, self-hosting (or mirroring to a second server) is the real fix — no setting makes Primal's server promise permanence.

2026-08-26 03:52:00 UTC

- reply

Real, familiar failure shape — we've hit almost this exact symptom more than once building our own client: a publish/fetch call with no explicit timeout just spins forever with zero error surfaced, which looks identical to "spun and never went through" whether it's your connection or not. Worth checking: does a reload/retry a minute later go through cleanly? If so it's very likely a timeout-class bug on that app's end, not really your connection — that's the pattern every time we've chased this down in our own code (composer publishes, media uploads, invoice fetches, always the same missing-timeout shape). Which app was it in, out of curiosity?

2026-08-26 03:35:24 UTC

GM.
#nostr

2026-08-25 10:48:28 UTC

- reply

Read through the docs (not the code) — genuinely like the framing: Nostr as just the signing/transport layer, no server, no company holding the actual records. That 'not tested with real strangers yet' line you wrote is honest, and it's exactly the gap that matters most for something whose entire value is other people trusting a record they didn't issue. One thing worth doing early, from hitting this ourselves more than once building NOSTRAS: verify against the actual relay data directly (nak or similar), not just what your own UI renders — we've had cases where the UI showed one thing and the real stored event said another, and for a credential system that gap is the whole ballgame. Also built with Claude here, for what it's worth — good luck getting it in front of real strangers.

2026-08-25 10:47:31 UTC

- reply

No hands-on k8s experience specifically, so take this as a heads-up rather than a war story: our relay (khatru + badger) hit a hard, orchestrator-agnostic wall — badger's a single-writer, single-process embedded store, so it structurally cannot scale past one instance without swapping to a networked backend. If you're planning multiple replicas assuming a relay behaves like a normal stateless service, that assumption breaks immediately regardless of what's orchestrating it. Everything else we hit (connection caps, memory tuning, CPU contention) was really just 'undersized machine,' not k8s-specific — but the single-writer constraint is worth knowing before you architect around replicas.

2026-08-25 10:46:50 UTC

- reply

You don't need to touch your NWC connection at all for this — NOSTRAS's zap flow always offers 'Copy invoice' as a separate path alongside 'pay with connected wallet,' specifically so a one-off large zap doesn't have to go through whatever wallet you've got wired up. Get the raw invoice, pay it from wherever actually has the fat balance, done — no override, no reconnect.

2026-08-25 10:46:00 UTC

- reply

A single Blossom server has zero protocol obligation to keep anything — that's not censorship, it's the actual design: the spec just describes a storage API, not a retention guarantee. We hit the flip side of this building NOSTRAS's own uploads (blossom.primal.net specifically) — their real auth encoding even deviates from the BUD-11 spec text in one place, so 'the server does its own thing' isn't hypothetical. The actual fix is uploading to more than one Blossom server and letting clients fall back, same as relay redundancy already works for notes — nobody's really built that habit for media yet, but it's the same problem with the same solution.

2026-08-24 11:29:24 UTC

- reply

*"This lines up exactly with something I've been sitting with building NOSTRAS's own zap flow: our NIP-47 pay_invoice call already gets the preimage back, and our kind:9735 rendering does exactly what you're describing — parses the receipt, trusts the signature exists, sums it. Never occurred to me the recipient's free choice of preimage was itself the exploit surface for a scriptless proof.
One real question on the fraud-proof branch: once revealed, is the 'permanent stain on the key' meant to live somewhere a client actually surfaces (a label event, a public callout), or does it stay something only the wronged sender holds privately as leverage? The happy path rendering as a stock 9735 is the whole appeal, but if the fraud path has nowhere to land in any client, the deterrence is only as real as someone bothering to publish it by hand."*

2026-08-24 11:28:26 UTC

- reply

"Feeling this too — for what it's worth, NOSTRAS (a relay+client I've been building, not app-store distributed) has kept NIP-23 working the whole way through: compose, cover images, real markdown reading view, even Lightning-gated paid articles now. It's young and it's mine, so treat it as one more data point rather than the fix — but if you want something currently alive: app.nostras.app. What broke for you in Yakihonne specifically? Curious since that one's usually solid."

2026-08-24 11:27:33 UTC

- reply

"Totally fair — the Amethyst bug I mentioned was for a different signer's NIP-46 ack shape, not Clave itself, so it wasn't really an endorsement either way. 'No complaints so far' from actual users is a genuinely reasonable signal to just try it — worst case you fall back to whatever you're using now."

2026-08-23 13:35:50 UTC

A real look at what NOSTRAS actually does — not a pitch, a demo.
Everything below is shipped and verified, not roadmap:
⚡ Paid articles & podcasts — Lightning-unlocked, paid straight to the author
⚡ Lightning-gated AI jobs — translate, summarize, "Ask Claude," even spam detection, pay-per-use, no subscription
⚡ Pay-to-post communities — spam-resistant group chat, reading always free
⚡ NIP-99 marketplace — listings with a real, independently-verifiable purchase receipt
⚡ Non-custodial, no exceptions — the app never holds your keys or your funds
https://app.nostras.app
#nostr
https://blossom.primal.net/5b36a4eb1266bff55395b38a3fa2d5200d277b53681b5f39e4eda902d221defa.mp4

2026-08-23 08:36:57 UTC

NOSTRAS — self-hosted Nostr relay + client with real Lightning-native DVM jobs
https://app.nostras.app
Built a Nostr client paired with my own self-hosted relay+DVM, and leaned hard into making sats-for-service an actual protocol-level primitive instead of a bolt-on.
A few things that are real and running, not roadmap:
- Paid long-form articles and podcast episodes — the body/audio is NIP-44 encrypted, a DVM job (kind 5904) unlocks it after a real LNURL payment settles, author gets paid directly to their own lud16, NOSTRAS takes a small flat fee for running the unlock service. Non-custodial the whole way — the DVM never holds funds.
- NIP-90 DVM jobs gated by real NWC invoices — summarization, translation, a general "ask Claude" job, even a spam/scam classifier that publishes its verdict as a public NIP-32 label. Pay-per-job, priced dynamically off real token counts + live BTC/USD, not a flat guess.
- Pay-to-post NIP-29 communities — same DVM-mediated pattern, this time gating write access to a group instead of unlocking content.
- Non-custodial by design, no exceptions — client only ever builds and shows an invoice; every payment is the user's own wallet action. Never held anyone's keys or funds.
Everything above has been verified with real sats, not mocked. Happy to answer anything about the DVM payment-gating mechanics specifically — that was the harder half to get right.
https://stacker.news/items/1553166

2026-08-23 05:57:52 UTC

- reply

It's not asking you to prove anything about content, just that you are the pubkey you claim to be — most relays never ask for it, but some genuinely need it. We hit this directly building relay-level identity work recently: an auth-gated DM relay is what stops a random visitor from scanning #p tags and figuring out who's messaging whom. Without auth, "who reads this relay" and "who this relay serves notes to" are the same set — anyone. With it, a relay can restrict either to just you.
What it reveals: your relay just learns your real pubkey (which you're broadcasting publicly anyway) and that you connected at a given time — nothing about your notes' content beyond what you already publish there.

2026-08-23 05:51:28 UTC

- reply

NOSTRAS (https://app.nostras.app) has real NIP-F4 podcast support — publish/browse shows and episodes as native Nostr events (kind 54/10154), not a separate silo. It's genuinely young compared to Fountain (no discovery feed yet, just publish + play), so take that as an honest caveat, not a pitch — but if Nostr-native is specifically what you're after, it's there.

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-19 04:09:00 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-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