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
- client: the PWA at app.nostras.app (React + NDK) - relay: wss://nostras.app, built on fiatjaf's khatru, with our own forks of khatru and the badger event store - DVM: the NIP-90 AI service (summarize, translate, ask, spam check). It runs on any OpenAI-compatible backend, so you can point it at your own local model: docs/local-ai.md
You can check that what's running is what's published. The relay's NIP-11 version is the deployed commit (right now 3d27d59), and so is Settings > About in the app.
The dated engineering log is in docs/history/, mistakes included. On 11 October we found the relay's outbox cache had been deleting users' own posts as "cache". It's written up there with the fix.
Mine: khatru (Go) with a badger store and a bluge search index, on a VM with a 20 GB volume. The stack and why: https://nostras.app/node
What bit me was all disk: - The disk filled up three times. Not spam: one app was syncing its users' encrypted data to us as kind 1059 gift wraps, 3.3 GB of a 4.6 GB store. Watch what's growing by kind, not just the total. - Deleting events didn't give the space back. Badger only frees disk when compaction rewrites its tables, and LMDB under strfry doesn't shrink its file either. Find out how compaction works before you need it. - Two of our stores (analytics, push subscriptions) were writing to the container's filesystem instead of the volume and got wiped on every redeploy. After setup, redeploy once and check that everything survived.
Bookmarks on Nostr are a standard list (NIP-51, kind 10003), so they live on relays, not in one app. Any client that supports the bookmark list reads the same one, and some keep private bookmarks encrypted inside it too.
One trap worth knowing, because we fixed it in NOSTRAS: that list is a single replaceable event, so a client that saves a new bookmark before it has loaded your existing list can overwrite the whole thing. NOSTRAS (https://app.nostras.app) waits for the list to load before allowing a change, and has a Bookmarks tab to read them later.
They are, small but real. One gotcha we hit the hard way: when we tested Shopstr in May, it did NOT show NIP-15 stalls/products (30017/30018) at all. It reads NIP-99 listings (kind 30402) from its own database, so a listing only appeared after it was cached by Shopstr, carried a ["t","shopstr"] tag, and had at least one image. Without an image the card silently never rendered. Worth checking your listings actually show up there before promoting them.
Kind 30402 is also what other clients read: NOSTRAS's Marketplace tab (https://app.nostras.app) shows any 30402 listing, with Buy Now in sats. Then post each product as a normal note with a photo and link it. That's where people actually see it.
Sort of. The "edit" is two separate events: a NIP-09 deletion request (kind 5) pointing at the old note's id, plus a brand-new note with a new id.
Two things that surprise people: - The deletion is a request, not a guarantee. Relays that honor it drop the old note; others keep serving it, and a client that already fetched it may keep showing it. - Likes, replies and zaps stay attached to the old id. They don't move to the new note.
We built delete in NOSTRAS (https://app.nostras.app) and the confirm screen says exactly that: it asks relays to delete, it can't promise they will. Long-form posts (NIP-23) are different: they're replaceable, so a real edit is possible there.
aboutShipping 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_CIT
