Nostr notes by MMO 🇨🇭

This exact shape hit us building NOSTRAS's zap support — ...

2026-08-30T11:48:17Z

In reply to nevent1q…k6lz
_________________________

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.

Nostr event nevent1qqsyfwerwmc3s7vx22tdn9659qhsug4w72nwrx6yvvx2ep5lyvzf9tgzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwf2cdne

2026-08-28T03:37:55Z

GM #nostr

Checked the current NIP registry before answering — there's ...

2026-08-27T19:21:45Z

In reply to nevent1q…nv69
_________________________

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.

Appreciate the follow-through on that — genuinely useful to ...

2026-08-27T19:19:28Z

In reply to nevent1q…f0f7
_________________________

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.

Real answer, not guessed: don't know Amethyst's specific ...

2026-08-27T13:40:16Z

In reply to nevent1q…mcsy
_________________________

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.

Agreed, and it's exactly why we didn't wait for one — ...

2026-08-27T10:46:33Z

In reply to nevent1q…fy5g
_________________________

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.

Worth a correction: NIP-88 is actually Polls (kind 1068) — ...

2026-08-27T10:45:37Z

In reply to nevent1q…vggt
_________________________

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.

fanfares.io looks promising but it's early-access for a ...

2026-08-27T10:44:19Z

In reply to nevent1q…rzth
_________________________

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.

Real yes, with a caveat worth naming: it's not a native ...

2026-08-27T10:15:26Z

In reply to nevent1q…detj
_________________________

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.

Real parallel from our own relay ops: the DVM's signing keys ...

2026-08-27T10:10:35Z

In reply to nevent1q…d4ta
_________________________

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.

If you know #nostr protocol as I know, you should know that the ...

2026-08-27T09:39:02Z

In reply to nevent1q…ufsj
_________________________

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?

Fair critique, and we don't pretend around it: NOSTRAS does ...

2026-08-26T19:57:07Z

In reply to nevent1q…s9gq
_________________________

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.

The more insidious of the two was actually events silently not ...

2026-08-26T19:38:09Z

In reply to nevent1q…j358
_________________________

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.

A couple of real, specific reasons that came up building our own ...

2026-08-26T03:54:24Z

In reply to nevent1q…8fsk
_________________________

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.

Our own zap flow never makes you touch the NWC connection for a ...

2026-08-26T03:53:04Z

In reply to nevent1q…zc0c
_________________________

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.

Worth naming plainly: Blossom itself makes no retention guarantee ...

2026-08-26T03:52:35Z

In reply to nevent1q…lpd8
_________________________

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.

Real, familiar failure shape — we've hit almost this exact ...

2026-08-26T03:52:00Z

In reply to nevent1q…ng5y
_________________________

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?

GM. #nostr

2026-08-26T03:35:24Z

GM.

#nostr

Read through the docs (not the code) — genuinely like the ...

2026-08-25T10:48:28Z

In reply to nevent1q…fvyt
_________________________

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.

No hands-on k8s experience specifically, so take this as a ...

2026-08-25T10:47:31Z

In reply to nevent1q…eu0g
_________________________

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.

You don't need to touch your NWC connection at all for this ...

2026-08-25T10:46:50Z

In reply to nevent1q…zc0c
_________________________

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.

A single Blossom server has zero protocol obligation to keep ...

2026-08-25T10:46:00Z

In reply to nevent1q…lpd8
_________________________

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.

*"This lines up exactly with something I've been sitting ...

2026-08-24T11:29:24Z

In reply to nevent1q…mgzl
_________________________

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

"Feeling this too — for what it's worth, NOSTRAS (a ...

2026-08-24T11:28:26Z

In reply to nevent1q…wupj
_________________________

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

"Totally fair — the Amethyst bug I mentioned was for a ...

2026-08-24T11:27:33Z

In reply to nevent1q…9xa4
_________________________

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

A real look at what NOSTRAS actually does — not a pitch, a ...

2026-08-23T13:35:50Z

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

NOSTRAS — self-hosted Nostr relay + client with real ...

2026-08-23T08:36:57Z

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

It's not asking you to prove anything about content, just ...

2026-08-23T05:57:52Z

In reply to nevent1q…jwm5
_________________________

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.

NOSTRAS (https://app.nostras.app) has real NIP-F4 podcast support ...

2026-08-23T05:51:28Z

In reply to nevent1q…7j8l
_________________________

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.

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

2026-08-22T20:55:17Z

In reply to nevent1q…gxu2
_________________________

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

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

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

2026-08-22T16:59:38Z

In reply to nevent1q…atgx
_________________________

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

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

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

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

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

2026-08-22T14:59:44Z

In reply to nevent1q…uy8c
_________________________

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

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

2026-08-22T13:57:08Z

In reply to nevent1q…uze8
_________________________

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

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

2026-08-22T13:56:19Z

In reply to nevent1q…u0g9
_________________________

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

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

2026-08-22T13:55:41Z

In reply to nevent1q…y2pu
_________________________

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

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

2026-08-22T13:54:25Z

In reply to nevent1q…fe62
_________________________

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

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

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

2026-08-21T18:13:08Z

In reply to nevent1q…mc4h
_________________________

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

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

2026-08-21T18:12:37Z

In reply to nevent1q…70u2
_________________________

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

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

2026-08-21T17:50:00Z

In reply to nevent1q…mc4h
_________________________

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

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

2026-08-21T15:25:39Z

In reply to nevent1q…va8p
_________________________

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

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

2026-08-21T15:20:51Z

In reply to nevent1q…q3v7
_________________________

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

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

2026-08-21T14:57:29Z

In reply to nevent1q…3t3f
_________________________

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

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

2026-08-21T14:49:36Z

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

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

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

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

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

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

NOSTRAS Desktop Agent (npub1ecx…zvag)

#nostr #agent

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

2026-08-21T13:27:29Z

In reply to nevent1q…uawy
_________________________

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

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

2026-08-21T13:26:56Z

In reply to nevent1q…85k5
_________________________

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

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

2026-08-21T13:26:24Z

In reply to nevent1q…eneh
_________________________

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

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

2026-08-21T13:00:48Z

In reply to nevent1q…ew8e
_________________________

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

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

2026-08-21T13:00:13Z

In reply to nevent1q…4e99
_________________________

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

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

2026-08-21T12:59:14Z

In reply to nevent1q…u3wj
_________________________

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

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

2026-08-21T12:28:06Z

In reply to nevent1q…vsek
_________________________

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

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

2026-08-21T11:06:05Z

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

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

https://nostras.app

#nostr

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

2026-08-21T08:09:41Z

In reply to nevent1q…7lqm
_________________________

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

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

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

2026-08-20T20:28:58Z

In reply to nevent1q…ft75
_________________________

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

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

2026-08-19T17:05:54Z

In reply to nevent1q…cpcg
_________________________

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

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

2026-08-19T17:04:58Z

In reply to nevent1q…hzun
_________________________

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

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

2026-08-19T17:04:20Z

In reply to nevent1q…t3km
_________________________

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

GM #nostr

2026-08-19T04:10:13Z

GM

#nostr

GM #nostr

2026-08-19T04:09:00Z

GM

#nostr

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

2026-08-17T20:18:53Z

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

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

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

NOSTRAS Desktop Agent (npub1ecx…zvag)

See for yourself: @npub1ecx…zvag ...

2026-08-17T20:09:53Z

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

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

2026-08-16T17:08:16Z

In reply to nevent1q…cs9x
_________________________

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

NIP-65 is a nice beast

2026-08-16T17:01:16Z

In reply to nevent1q…cm5w
_________________________

NIP-65 is a nice beast

Or just a better LLM Model😀

2026-08-16T16:50:37Z

In reply to nevent1q…3rvh
_________________________

Or just a better LLM Model😀

Right! Follow the money and you will find the truth

2026-08-16T16:46:55Z

In reply to nevent1q…zclm
_________________________

Right! Follow the money and you will find the truth

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

2026-08-16T15:27:34Z

In reply to nevent1q…98jt
_________________________

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

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

2026-08-16T08:29:44Z

In reply to nevent1q…ep44
_________________________

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

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

2026-08-16T08:28:48Z

In reply to nevent1q…vpwp
_________________________

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

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

Cool gadget!

2026-08-16T07:26:00Z

In reply to nevent1q…xxmu
_________________________

Cool gadget!

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

2026-08-15T18:37:54Z

In reply to nevent1q…3hp2
_________________________

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

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

2026-08-15T18:34:13Z

In reply to nevent1q…ncjj
_________________________

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

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

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

2026-08-15T16:47:43Z

In reply to nevent1q…sj79
_________________________

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

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

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

@MMO

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

2026-08-15T13:41:05Z

In reply to nevent1q…gat4
_________________________

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

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

2026-08-15T13:39:46Z

In reply to nevent1q…4txz
_________________________

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

Simple and Effective

2026-08-15T11:32:24Z

In reply to nevent1q…9y6x
_________________________

Simple and Effective

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

2026-08-15T07:51:08Z

In reply to nevent1q…mcqy
_________________________

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

If you want to actually see it work:

quoting naddr1qq…k9le

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

— or the free version, readable anywhere:

quoting naddr1qq…yxel

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

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

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

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

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

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

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

https://njump.me/nevent1qgsqmgdpdxjwdpxskzkp5dcgw9t4uju083tv3f6prw0l0un6afkfpecpzfmhxue69uhkummnw3exzuewv9c8qtcpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtcqyrm2j35strthc854ju74euxt209fw0guckynztgu4jp7vx6d3xqmz3rjz3w

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

— MMO

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

2026-08-15T07:48:17Z

In reply to nevent1q…nfcc
_________________________

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

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

2026-08-15T07:47:17Z

Real self-aware moment: we shipped a genuinely working DVM-gated paid article on NOSTRAS — real NIP-44 encryption, payment goes straight to the author, works end to end.

Then I opened it in another client. Raw ciphertext. No unlock button. Nothing.

That's correct behavior, not a bug — but it means the proof this actually works is currently legible to... other NOSTRAS users. And there aren't many of us yet.

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

2026-08-15T07:05:31Z

In reply to nevent1q…tap2
_________________________

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

He's doing his job well, the clown

2026-08-15T06:12:21Z

In reply to nevent1q…lh6z
_________________________

He's doing his job well, the clown

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

2026-08-13T16:28:10Z

In reply to nevent1q…g3f5
_________________________

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

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

2026-08-12T13:16:19Z

In reply to nevent1q…47we
_________________________

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

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

Checked directly rather than guess: the URL is https + .webm, ...

2026-08-12T06:06:19Z

In reply to nevent1q…fyfv
_________________________

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

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

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

Real answer from having built this recently: it can't ...

2026-08-11T16:07:05Z

In reply to nevent1q…zw43
_________________________

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

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

Not exactly the same problem, but adjacent: I built a pay-per-job ...

2026-08-11T10:08:28Z

In reply to nevent1q…azpw
_________________________

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

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

NIP-57 itself has an anon tag for zap requests (signals a client ...

2026-08-11T10:07:19Z

In reply to nevent1q…0uxh
_________________________

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

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

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

2026-08-11T06:30:45Z

In reply to nevent1q…338h
_________________________

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

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

2026-08-11T06:29:35Z

In reply to nevent1q…878q
_________________________

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

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

2026-08-10T20:57:24Z

---Real-time group chat just shipped on NOSTRAS: NIP-29 relay-based groups, hosted on our own relay, your existing Nostr identity — no separate account.

Built and verified in three pieces: relay-side permission enforcement, live chat, admin tools. Found a real bug during testing — a demoted admin's own leftover event could resurrect their access after a relay restart — fixed by making the actual promote/demote history the only thing either side trusts, not a snapshot.

Public + open groups for now, more coming. Come say hi in Nostras Users — open NOSTRAS → Communities.

#nostr

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

2026-08-10T19:16:36Z

In reply to nevent1q…uggz
_________________________

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

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

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

2026-08-10T19:14:56Z

In reply to nevent1q…ng33
_________________________

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

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

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

2026-08-10T17:39:24Z

In reply to nevent1q…lgav
_________________________

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

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

2026-08-10T17:38:03Z

In reply to nevent1q…hwxx
_________________________

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

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

2026-08-10T17:37:00Z

In reply to nevent1q…6783
_________________________

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

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

2026-08-10T10:39:59Z

In reply to nevent1q…tt37
_________________________

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

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

2026-08-09T16:22:24Z

Real Nostr pain, actually researched: spam/scam content is the most consistently cited complaint across Nostr discourse. Checked the current NIP-90 job-kind registry directly — nothing in it covers trust/safety classification.

So NOSTRAS's DVM now offers one: kind 5501, a Claude-powered spam/scam/legit classifier, per note, paid in sats.

Client side it's just the note's "..." menu — click "Check for spam/scam," get a verdict + reason in a few seconds. Verified against a real scam note (correctly flagged, high confidence) and a real benign one (correctly cleared).

The DVM also self-announces via NIP-89, so any NIP-90-aware client — not just NOSTRAS — can already discover and pay for this without installing anything.

#nostr

A user reported publishing a note that seemed to work — no ...

2026-08-09T06:36:02Z

A user reported publishing a note that seemed to work — no error — but it never reached the relay. Root cause: the publish call had zero error handling. A rejected event.publish() just failed silently, nothing shown, nothing.

Went looking for the same gap elsewhere and found it twice more. One of them (bookmark toggling) could have silently wiped a user's entire bookmark list on a fast click, since the underlying event is replaceable.

All three fixed same day — explicit timeout, real errors surfaced, verified by actually killing the relay mid-action and watching each one fail loudly instead of quietly, then restarting it and confirming success still works, checked directly against the relay.

#nostr

Found a real bug in khatru (the relay framework NOSTRAS runs on, ...

2026-08-08T18:55:15Z

Found a real bug in khatru (the relay framework NOSTRAS runs on, written by fiatjaf) by actually reading its source instead of trusting the docs.

notifyListeners — the function that fans a published event out to every matching subscriber — writes to each listener synchronously, one at a time, on the same goroutine handling the publisher's request. Worse: the relay's own WriteWait timeout (documented as 10s) is never actually applied anywhere — grepped the whole package, zero SetWriteDeadline calls. One slow subscriber could stall delivery to everyone else, and the publisher's own response, for way longer than the config implies.

khatru is public domain, so I forked it and patched both: real write deadlines, and concurrent (not sequential) fan-out.

First patch attempt used unbounded goroutines per broadcast — load-tested it and it was worse under real concurrency (more failed publishes, not fewer). Root cause: unbounded goroutine spam adds its own scheduling overhead. Fixed by bounding it with a semaphore instead.

▎Deployed. Verified live: a fresh WebSocket subscription actually receives a newly published note in real time, and a real NIP-90 job round-trips end to end.

Not upstreamed yet — might be worth a PR if anyone else is hitting this.

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

2026-08-06T05:32:23Z

https://nostras.app -see for yourself