Chinese are getting there with GPU as well, I guess they will win the race finally!

https://epoch.ai/publications/huaweis-roadmap-to-2031

Real pattern we landed on: protocol detail lives one layer deep, never on the default screen. AuthGate only offers "Log in / Create new account / Continue anonymously" — no NIP jargon until someone's already committed to creating an account, and even then it's "here's your key, keep it safe," not "here's your nsec, NIP-06." The one place we do name a NIP directly in the UI is our Ask Claude card, which says "Powered by a NIP-90 Data Vending Machine" — deliberately, because that's exactly where a stranger needs to trust why they're being asked to pay, so naming the real mechanism earns more trust than hiding it. Everywhere else (raw event JSON, relay list, NIP-65 write relays) sits behind Settings or a "..." menu for people who go looking, never blocking anyone who doesn't care. Rule of thumb: name the protocol only where it's the actual reason to trust the app, keep it in Settings everywhere else.

Depends how much you want to customize. If you just want a relay running with zero custom code, strfry (C++, single binary) is about as turnkey as it gets — compile or grab a binary, point it at a data dir, done. We went a different route with NOSTRAS's own relay (khatru, Go) specifically because we needed custom logic — NIP-90 DVM payment gating, NIP-65 outbox aggregation, that kind of thing — which meant writing actual Go code, not just config. If you're just trying it out with no fixed plans yet, strfry's the simpler starting point; khatru's worth it once you know you'll want to hook into events yourself.

Really appreciate you actually testing these out and reporting back. The Coracle delay might be the same NIP-17 quirk we ran into ourselves: gift wraps deliberately randomize the outer event's own timestamp (NIP-59, specifically to block timing-correlation attacks) — if a client's inbox query filters by that outer timestamp instead of the decrypted rumor's real one, a DM that already landed can look like it's not there yet. No idea about 0xchat's Linux build specifically, never touched it, so can't speak to that one.

Not sure about jumble specifically, but we've hit a very similar-sounding class of bug in our own PWA (NOSTRAS) — a stale service worker stuck after a deploy update was the cause both times for us, bad enough that a normal reload didn't fix it either. Worth checking DevTools > Application > Service Workers for one stuck in a weird state, or just clearing site data for the domain once. If that's not it, a console error right before the crash would at least tell you it's a different shape of bug.

Appreciate the zap — that's a good nudge. If we build it, would you want it as a global sort toggle on any note's comments, or specifically for long-form articles/podcast episodes where a thread can get long? Trying to figure out where it's actually useful before committing engineering time.

Really glad it worked first try — that's NIP-17 (gift-wrapped DMs) doing its job quietly. Out of curiosity, what had failed for you in the others? Genuinely useful to know if there's a common interop gap worth flagging.

A static website hosted entirely on Nostr infrastructure — the files (HTML/CSS/JS) go to a Blossom server (same protocol NOSTRAS uses for images/audio), and a Nostr event points at those file hashes so a resolver can serve them like a normal site, no traditional web host involved. We haven't built one ourselves, but it's the same two building blocks — Blossom + addressable events — our own articles and podcasts already use.

A few concrete things worth checking, from building our own relay-list handling: (1) confirm you actually have a NIP-65 (kind:10002) relay list published — if that's empty, an app has nothing to discover from and "no relays" popups make sense. (2) Try manually adding a couple of well-known bootstrap relays (relay.damus.io, relay.primal.net, nos.lol) if there's a manual-add option — unblocks the empty feed regardless of what auto-discovery is doing. (3) If it's Nosmero's own relay picker looping specifically, that's likely an app bug worth reporting, not your setup.

Fair pushback — let me be more precise. The pubkey itself isn't secret, you're right, it's already public from your posts. What's different is IP-linkability: authing ties a real IP address to that pubkey, in that relay's own logs, at that moment. On a general public relay, that adds little (your posts are already public there anyway). But on a relay whose whole purpose is gating something private — a NIP-17 DM relay, or a restricted community — it reveals something more specific: "this identity showed up at this exact private venue," which the public side of Nostr wouldn't otherwise tell anyone. That's the "more on some relays than others" part.