You know as I know that our keys can not be seized, this is the reason why we are on #nostr. Concerning my annoying UX, I take the note, I developed Nostras core during a weekend, focusing on functionality vs cosmetics, but there is always room to improve.

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

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.