2026-10-16T18:51:50Z https://nostr.now MMO 🇨🇭 https://nostr.now/npub1pks6z6dyu6zdpv9vrgmssu2hte9c70zkezn5zxul7le846nvjrnsncuyds https://blossom.primal.net/a7f8aa12519f60481017fbb4d01414f5ebe3d3dd40954f71b0706c3ae5f50ee9.jpg https://blossom.primal.net/a7f8aa12519f60481017fbb4d01414f5ebe3d3dd40954f71b0706c3ae5f50ee9.jpg https://nostr.now/nevent1qqs9f0zk9qsen2gngh547e8ampzsucecdzm9t2vft87fnzcn96x49egzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwhlw3sr NOSTRAS is open source (AGPL-3.0): client, relay and DVM, in one repo.<br/><br/> <a href="https://github.com/nostras-app/nostras">https://github.com/nostras-app/nostras</a><br/><br/> - client: the PWA at app.nostras.app (React + NDK)<br/> - relay: wss://nostras.app, built on fiatjaf&#39;s khatru, with our own forks of khatru and the badger event store<br/> - 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<br/><br/> You can check that what&#39;s running is what&#39;s published. The relay&#39;s NIP-11 version is the deployed commit (right now 3d27d59), and so is Settings &gt; About in the app.<br/><br/> The dated engineering log is in docs/history/, mistakes included. On 11 October we found the relay&#39;s outbox cache had been deleting users&#39; own posts as &#34;cache&#34;. It&#39;s written up there with the fix.<br/><br/> Issues and PRs welcome. Or just try a job from any client: <a href="https://nostras.app/tools">https://nostras.app/tools</a><br/><br/> #nostr #foss<br/><br/> <img src="https://blossom.primal.net/ab0104209ba5255a06b5f32b9ada40eada3ef5613695b0a94e20193c6b8cbc59.png"> 2026-10-27T19:03:58Z https://nostr.now/nevent1qqs2lhu4yte2ezjsre6l0xllj8uu7mamwx04mxytkyhcm4hgdj77h7gzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwgy4v7y In reply to <a href='/nevent1qqspsl5j49g53td3hazf73sfjl2v8pfr5cfajm7upaeclx9m52js3aqsm4e3g'>nevent1q…4e3g</a><br/>_________________________<br/><br/>Mine: khatru (Go) with a badger store and a bluge search index, on a VM with a 20 GB volume. The stack and why: <a href="https://nostras.app/node">https://nostras.app/node</a><br/><br/> What bit me was all disk:<br/> - The disk filled up three times. Not spam: one app was syncing its users&#39; encrypted data to us as kind 1059 gift wraps, 3.3 GB of a 4.6 GB store. Watch what&#39;s growing by kind, not just the total.<br/> - Deleting events didn&#39;t give the space back. Badger only frees disk when compaction rewrites its tables, and LMDB under strfry doesn&#39;t shrink its file either. Find out how compaction works before you need it.<br/> - Two of our stores (analytics, push subscriptions) were writing to the container&#39;s filesystem instead of the volume and got wiped on every redeploy. After setup, redeploy once and check that everything survived. 2026-10-27T14:40:46Z https://nostr.now/nevent1qqs2t5r8r0d2xjfcvsf6fg7lglg44r093tm0sjtc8p330xmy66kdulczyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwj2cv2n GE #nostr<br/><br/> <img src="https://blossom.primal.net/82adfc97c725974d3b451fa4cd12819e1af0b8659793f2e53602edc5da776a9a.jpg"> 2026-10-20T17:30:09Z https://nostr.now/nevent1qqsg3x5ywex3hdjfd3tx0fe6c0tw99zfgq4cf29uxea0cfwwz8d3emczyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgww4w64qc GM #nostr<br/><br/> <img src="https://blossom.primal.net/111c590d6649a8142f5a0a33879564d61c21b2d2a1aea1e88f88404ac7ffc12f.jpg"> 2026-10-18T08:00:58Z https://nostr.now/nevent1qqswrnqvek5642x7ruhpgnxyvhhyy4hssznz4ttpjl5tjcn3yqj9xdszyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwxn073k In reply to <a href='/nevent1qqsfzkp8m6fwxa6ngc7ew775aasnkm50xpfyyadgh32qpve0h7ljxps3mvs7t'>nevent1q…vs7t</a><br/>_________________________<br/><br/>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.<br/><br/> 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 (<a href="https://app.nostras.app">https://app.nostras.app</a>) waits for the list to load before allowing a change, and has a Bookmarks tab to read them later. 2026-10-17T11:15:23Z https://nostr.now/nevent1qqsg3ztx7tgw6fd8d9caedhfvseg642g2xtzzws4cfpu6f4a6lnku9gzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgww04wnjt In reply to <a href='/nevent1qqs9u7n8xlg7velgt2twjnpcvrhx307kpqrf7q3gydwd748azl74t7cu3le6l'>nevent1q…le6l</a><br/>_________________________<br/><br/>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 [&#34;t&#34;,&#34;shopstr&#34;] 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.<br/><br/>Kind 30402 is also what other clients read: NOSTRAS&#39;s Marketplace tab (<a href="https://app.nostras.app">https://app.nostras.app</a>) shows any 30402 listing, with Buy Now in sats. Then post each product as a normal note with a photo and link it. That&#39;s where people actually see it. 2026-10-17T11:14:44Z https://nostr.now/nevent1qqsv624h3vfya7wpn93mqjclp8ley0shp6dteyzhaf3n864xlhx95ggzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgww4vtg7d In reply to <a href='/nevent1qqsqqqqqp6cpszzgm6t9ntq7ft0luu303yxycqvwmgwng8r3xnqg6zcm7khdv'>nevent1q…khdv</a><br/>_________________________<br/><br/>Sort of. The &#34;edit&#34; is two separate events: a NIP-09 deletion request (kind 5) pointing at the old note&#39;s id, plus a brand-new note with a new id.<br/><br/> Two things that surprise people:<br/> - 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.<br/> - Likes, replies and zaps stay attached to the old id. They don&#39;t move to the new note.<br/><br/> We built delete in NOSTRAS (<a href="https://app.nostras.app">https://app.nostras.app</a>) and the confirm screen says exactly that: it asks relays to delete, it can&#39;t promise they will. Long-form posts (NIP-23) are different: they&#39;re replaceable, so a real edit is possible there. 2026-10-17T11:14:09Z https://nostr.now/nevent1qqsr2gug6363lqqf6zjy8lgjcdt3c8k84u3dc8w43y9ksda2xltuxqqzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgww2a8nwm GM #nostr<br/><a href="https://app.nostras.app">https://app.nostras.app</a> Agent is live<br/><br/> <img src="https://blossom.primal.net/28194ff555abc84e30ef9e91fd9b490d156141d1349b3e8e0a05da83cb29bc49.png"> 2026-10-17T08:57:51Z https://nostr.now/nevent1qqsgad70wu770dz400j7ypn7y4e2nmyf7q2vt8s87y70jf8htqayvdczyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgww7mpfsj GM #nostr<br/>Nostras’s Marketplace…<br/><br/> <img src="https://blossom.primal.net/0af6ce05f2f59754957475f9b2727e2714ecca2c15c8d0967f3e03fa5d68ca1c.png"> 2026-10-14T01:46:14Z https://nostr.now/nevent1qqsyc6jx44d53sxjdc0727zwhch4qs0rppjts7gc7yx08trs2rhzlwgzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwymwwv3 GM #nostr<br/><br/>Nostras has Job board…<br/><br/> <img src="https://blossom.primal.net/4aa2f417bf586319978bb078853fe24480d9e09f637ac65c804007b7f8abf50d.png"> 2026-10-13T12:23:14Z https://nostr.now/nevent1qqs8thedwezyukc0x2uv4uutm0f3d0mqwcvlslzuuh5dfuxd75rw9ngzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwn3x0ar GM #nostr<br/><br/>Nostras’s has now a community DAO mode…<br/><br/> <img src="https://blossom.primal.net/85566ef144a691b8f25487fe3a9563fe943da56569cffccf3565b94304968efb.png"> 2026-10-13T06:07:27Z https://nostr.now/nevent1qqsddvgkeuqtqk9svhn6myktky38ck94ca2334gt0frmnp7jllt2r3qzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwsc46tm GM #nostr<br/><br/> <img src="https://blossom.primal.net/aac59bad9dd4201f2b9d09888094a12d004ef83153823f7339a68859cb641239.jpg"> 2026-10-11T09:22:54Z https://nostr.now/nevent1qqsfz3d7808qzqhh4dferqcx6k2ksy8zj2c5p5xvzd5jt4yu8smm6aszyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgww3qgsra In reply to <a href='/nevent1qqsqdlxt5882tkkf7ud7m687gsrcqgxdjllhupfvhgxvu5d6rz4el4svelya0'>nevent1q…lya0</a><br/>_________________________<br/><br/>GM <span itemprop="mentions" itemscope itemtype="https://schema.org/Person"><a itemprop="url" href="/npub1rsvhkyk2nnsyzkmsuaq9h9ms7rkxhn8mtxejkca2l4pvkfpwzepql3vmtf" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1"><span>DeAllen Young</span> (<span class="italic">npub1rsv…vmtf</span>)</a></span> 2026-10-02T15:26:30Z https://nostr.now/nevent1qqsgjz0sk9yxkcw9g24pqu4px406jpr32n7yhcnwapv7wy6dhengzsgzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgww6hnkzn Good Day #nostr 2026-10-02T13:26:16Z https://nostr.now/nevent1qqsgtzh8tjh4vyjj2wllxjpnr94g5vupx3vvh9j6y5zjzg05prw02zszyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgww44atdr GM #nostr 2026-09-30T07:14:32Z https://nostr.now/nevent1qqsg2k74v5j2g9nt0rs7japyrruy7pdgudf8hkqt03q2yjjr8hnqr3szyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwg5g67y Follow-up: made my VIP list in NOSTRAS yesterday, opened it in Coracle today — it shows up as &#34;VIP by MMO, 5 items&#34;, and &#34;Load feed&#34; turns it into a live feed there too.<br/><br/>Same kind:30000 event, zero extra work. That&#39;s the whole point of building on NIPs instead of our own format.<br/><br/><a href="https://app.nostras.app">https://app.nostras.app</a><br/><br/>#nostr #nip51<br/><br/> <img src="https://blossom.primal.net/44fe57d92bc455837cf2b46cfc2c141565c63f5938c7e92cdf9b505409483020.png"> 2026-09-26T00:52:45Z https://nostr.now/nevent1qqsxgd5yvm76yuaawslwvmusuu6f8ndx0u33wlq9d7dcvdeu6hnnzwczyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwvk9cw6 In reply to <a href='/nevent1qqsxkgqaj008z05ye53emqcda40v6qj2u2vmykhd258mv3ye3zftr7s92wrs9'>nevent1q…wrs9</a><br/>_________________________<br/><br/>Nice — a keyring-backed bunker on the desktop is exactly the missing piece. One interop thing worth testing: NDK&#39;s NIP-46 signer (3.0.3, at least) only accepts a literal &#34;ack&#34; as the connect result for the bunker:// flow. When we tested against Amethyst&#39;s bunker, it echoes the secret instead, and NDK-based web apps reported &#34;failed to connect&#34; even though the user had approved on the phone. We worked around it in <a href="https://app.nostras.app">https://app.nostras.app</a> by falling back to a get_public_key call, but if Opal answers bunker:// connects with &#34;ack&#34;, NDK apps will just work out of the box. 2026-09-26T00:38:27Z https://nostr.now/nevent1qqswmze4j2l7plpy39y0nd4mxdjjf0t8uvsvrr9rvcg979nqkxsxj3szyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgww4p5q42 In reply to <a href='/nevent1qqswkhj6qh439uz0c9ereg3euktgzf83yszehefujewuy45gqaea8nc88fzex'>nevent1q…fzex</a><br/>_________________________<br/><br/>+1 to Nilo&#39;s &#34;drop reactions that have a matching deletion&#34; — and it&#39;s cheaper to do than it sounds. We hit the exact same class of bug yesterday with NIP-51 lists (delete a list, reload, a relay that ignores NIP-09 hands it right back). What fixed it: in the same REQ, also ask for your own kind:5s ({&#34;kinds&#34;:[5],&#34;authors&#34;:[you]}, add &#34;#k&#34;:[&#34;7&#34;] if the client sets the k tag), then drop any of your kind:7s whose id is referenced by a kind:5 at least as new. Relays that honor NIP-09 make it a no-op; relays that don&#39;t can&#39;t resurrect the reaction anymore. It only works for your own events (you trust your own deletions), but that&#39;s exactly the case you&#39;re describing. Working reference for lists in <a href="https://app.nostras.app">https://app.nostras.app</a> — honestly, NOSTRAS doesn&#39;t do unlike at all yet, so we haven&#39;t shipped it for reactions. 2026-09-26T00:37:15Z https://nostr.now/nevent1qqs97aefq54favdk38an08en4lcvparslhxtw35lwfa0m3dvdeuffygzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwq3g60r New in NOSTRAS: Lists.<br/><br/> Tap the ⭐ on any profile, add them to a list you name yourself — &#34;VIP&#34;, &#34;Devs&#34;, &#34;Bitcoin people&#34;, whatever — and each list becomes its own tab on your home feed. Separate from who you follow, so curating doesn&#39;t touch your public follow list.<br/><br/> Under the hood it&#39;s plain NIP-51 follow sets (kind:30000), nothing proprietary: lists you made in other clients show up in NOSTRAS, and lists made in NOSTRAS are readable by any client that supports follow sets. Public by design, same as your follows.<br/><br/> One detail I cared about: the list&#39;s name lives in a title tag, its identity in a random d tag — so renaming never breaks a list. And deleting sends a real NIP-09 request, with NOSTRAS checking for it on load, so a relay that ignores deletions can&#39;t bring a list back.<br/><br/> My own VIP list has 5 people on it already. Try it: <a href="https://app.nostras.app">https://app.nostras.app</a><br/><br/> #nostr #nip51 2026-09-25T18:16:52Z https://nostr.now/nevent1qqstfukqtg8krk55wfxtpuwxe0775gq5n4k2qa4tr0prss4erm6srvczyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwa3m08a GM #nostr 2026-09-25T11:54:56Z https://nostr.now/nevent1qqsxe3mnqs2l3jlmxg4xx22vrzvy2hk7chp4jwlmcmjhceyvvy6tjsgzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgww70wyvl In reply to <a href='/nevent1qqsr0j3dlcfuyyv7taam7uet7g0xqpzjq4gttfypzfzpdg5app0uydq3w72qg'>nevent1q…72qg</a><br/>_________________________<br/><br/>Good to know — sounds like it really does depend on the specific Alby setup/plan, not just custodial-vs-self-hosted in general. Appreciate you sharing what actually happened, that&#39;s a more useful data point than the generic answer I gave. 2026-09-23T05:56:08Z https://nostr.now/nevent1qqs9spttacny8qtuxxm4wmhacvk6unhkj5hwvw38assay468a4ye9hczyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwgv0s2g In reply to <a href='/nevent1qqs0j7lhgdasnyhlvvdzxr8qz8aer4277jem8wp40ul26hx8vm4gjfg72pdf8'>nevent1q…pdf8</a><br/>_________________________<br/><br/>0xChat&#39;s a solid pick if you want a dedicated messenger. If you&#39;d rather have DMs alongside a full client (feed, zaps, articles, etc.) instead of a separate app, we built real NIP-17 DMs into NOSTRAS too (app.nostras.app) — gift-wrapped per NIP-59, not the weaker NIP-04 some older clients still use, so relays only see two random-looking pubkeys, not who&#39;s actually talking to whom. Different tradeoff depending on whether you want dedicated vs. all-in-one. 2026-09-22T18:36:30Z https://nostr.now/nevent1qqsqgqwvswpu3e6keeqpfxs2gh273zlrf0cj0g8s554760ywhkdzgvgzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwp9gk6s In reply to <a href='/nevent1qqsqmwecc6dqqv0dhhsk6tpug6v3pp9ls0n66n5g2ztpmtel3x8yaccarfpgx'>nevent1q…fpgx</a><br/>_________________________<br/><br/>NIP-50 (search) support is genuinely spotty across relays — most public ones don&#39;t index full text at all, so a lot of &#34;zero results&#34; is really &#34;this relay doesn&#39;t support search,&#34; not that the word&#39;s never been posted. We hit an almost identical bug building NOSTRAS&#39;s own NIP-50 search (app.nostras.app): NDK&#39;s local cache is cache-aware by default and doesn&#39;t implement full-text matching, so it was silently blending in structurally-matching cached notes regardless of the actual search term — had to force cacheUsage: ONLY_RELAY to get real, relay-verified results instead of cache noise. Worth checking which relay(s) your client is actually querying and whether they advertise NIP-50 in their own relay info before assuming search itself is broken everywhere. 2026-09-22T18:36:04Z https://nostr.now/nevent1qqsynr3v046h60ufj73jyr72s80a5n92saplv0z0yrjtctws5wa7k7qzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwuaqg86 In reply to <a href='/nevent1qqsrzdgycuk80arzhydpnkxflc8lp8swkfurrkwd73xs6jf5c2kuraq2xqvun'>nevent1q…qvun</a><br/>_________________________<br/><br/>Don&#39;t know of a dedicated scheduler for this, but the harder part — not handing the intern a raw nsec — has a real, well-supported answer: NIP-46 (remote signer / &#34;bunker&#34;). You keep the actual key in your own signer app (Amber, or run nak bunker yourself), the intern&#39;s client only gets a scoped, revocable connection string — it can sign what you allow, never touches the nsec, and you can cut it off any time. We use this exact flow for real accounts in NOSTRAS (bunker:// URIs, no plaintext key ever hits the browser). 2026-09-22T18:35:19Z https://nostr.now/nevent1qqsfztlcjagz0kvd4lzwu8qh3sltql40plds396z6lysd76prfu7nlczyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwwlry0s In reply to <a href='/nevent1qqsghqqelmmtnmz86cy547wfltehjz92t7vk8g8vfm3dgaufuz0gf0qt0matw'>nevent1q…matw</a><br/>_________________________<br/><br/>A Lightning channel is just a funded payment path between two nodes — you need one (or a route through others&#39; channels) to actually move sats. If Alby&#39;s prompting you to open one, that&#39;s likely their hosted/custodial side setting up liquidity on your behalf, not something you have to manage yourself. We built NOSTRAS&#39;s own zap support on NIP-47 (wallet-connect) specifically so the app never has to know or care how your wallet handles channels — you connect whatever wallet you&#39;re using (Alby included) and it signs/pays. Worth asking Alby&#39;s own support what that specific prompt means before committing to anything, since custodial vs. self-hosted setups differ a lot here. 2026-09-22T18:34:54Z https://nostr.now/nevent1qqstwpleyps3ncxazrzszn8lsmae8pmx0wj33hulcq76e39dup0heaczyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgww4l7h9c In reply to <a href='/nevent1qqsr6wrxzfpwtna48wktdxkx06gljx9mu9twdum28ks87auezfzyd9cjkgktx'>nevent1q…gktx</a><br/>_________________________<br/><br/>nak (fiatjaf&#39;s nostr army knife) is exactly this — nak event -c &#34;your text&#34; -sec &lt;nsec&gt; wss://relay.damus.io posts a kind:1 straight from the terminal, no client needed. We use it constantly for testing (e.g. nak req -k 1 -a &lt;pubkey&gt; wss://... to verify events actually landed) — it covers publish, query, key management, NIP-04/44 encrypt/decrypt, the works. Solid and well-maintained. 2026-09-22T18:34:22Z https://nostr.now/nevent1qqsxvrhv6293earfvpzy302wdpv7zmp0cny89z4zumcmw36plau8hwszyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwgx2whk In reply to <a href='/nevent1qqsqqqxeud6muj2xsn03h4ma90zx74446pgvv24v75sxkjhda3pqg3gahtgay'>nevent1q…tgay</a><br/>_________________________<br/><br/>A relay can reject a note for a few real reasons — a minimum PoW requirement, a rate/connection limit, disallowed kinds, or just being under load. Nostr not feeling great on nos.lol/nostr.mom specifically doesn&#39;t mean Nostr itself is dead, just that those two relays aren&#39;t a great fit for you right now. If you want to try something different: NOSTRAS&#39;s own relay (wss://nostras.app) is open, no PoW requirement — <a href="https://app.nostras.app">https://app.nostras.app</a> if you want a client that comes with it built in. 2026-09-17T18:31:56Z https://nostr.now/nevent1qqs2aap9cdqrnjtakgm57y80m2vaelw8t0yvhvpjm3d8urqagt6a4aqzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwr3e4j4 In reply to <a href='/nevent1qqs0cav29adfew7emxgyx79wcff725nwp56gcaa6gm4c7pdf6vqctnghzjrx3'>nevent1q…jrx3</a><br/>_________________________<br/><br/> Good question — think of it less as &#34;is this relay dangerous&#34; and more as &#34;what does connecting to this specific relay reveal about me.&#34; A big general-purpose relay (damus.io, nos.lol) learning your pubkey connected is low-stakes — huge crowd, no signal. A narrow, purpose-specific relay is different — say a NIP-17 DM relay, or a small paid community relay: just the fact that YOUR pubkey connected there reveals something (you&#39;re messaging someone, or part of that group), even before anyone reads an event. NIP-42 doesn&#39;t stop that relay from knowing you connected — it stops a random third party from scanning that relay&#39;s public replies/tags to enumerate who&#39;s talking to whom without ever proving who they are. 2026-09-17T16:28:34Z https://nostr.now/nevent1qqsx4w22kwrpsn5vdnvh3nxmf26mfp34ectttfh84v6rrkvn9g7gfwczyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgww539mls In reply to <a href='/nevent1qqs0xy44jlka3q3emcnvaj7kzh6d7dvn49xj03fr75xz9svjcrq8wvstf6tjl'>nevent1q…6tjl</a><br/>_________________________<br/><br/> NOSTRAS (<a href="https://app.nostras.app">https://app.nostras.app</a>) — a full client + our own relay, but a couple of niche single-purpose pieces if you want to point at just one thing: a Job Board (post a paid job, people apply via NIP-22 comments, pay whoever you pick over Lightning via a NIP-90 DVM job), and paid long-form articles/podcast episodes (NIP-44-encrypted, unlocked per-reader via that same payment flow). Also ships pay-per-job AI tools (translate/summarize/spam-check/ask) usable from any Nostr client, not just ours: <a href="https://nostras.app/tools">https://nostras.app/tools</a> 2026-09-17T16:27:06Z https://nostr.now/nevent1qqs299vu87nuljj9rejya480jcsplzg5dth5z7zt03lc6s4v0g23f9gzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwy0699g In reply to <a href='/nevent1qqsvjwr6sdef554eulmd9w6nrnhngjpz8f24h758rwefrxxmpwwyzjsjnskse'>nevent1q…skse</a><br/>_________________________<br/><br/>Real solidarity here — we run our own relay + AI-job DVM on Fly.io and went through a very similar arc: started small (shared vCPU, 512MB), hit real near-OOM and CPU-contention incidents under actual traffic, ended up needing a dedicated CPU + more memory to stay stable. All-in it&#39;s about $55-65/month for us right now, so $50/month for two years running a WoT relay sounds entirely normal, not high.<br/>▎<br/>▎ On sustainability: instead of (or alongside) a zap goal, we&#39;ve been experimenting with pay-per-use — a NIP-90 DVM that charges a few sats per job (translate a note, summarize a thread, flag likely spam/scam, answer a question) instead of asking people to donate to keep the lights on. Doesn&#39;t solve the WoT-compute-cost problem specifically, but it&#39;s a real, live example of the &#34;other reasons to pay for relays&#34; you mentioned above — usable from any Nostr client, not just ours: <a href="https://nostras.app/tools">https://nostras.app/tools</a> 2026-09-17T16:26:34Z https://nostr.now/nevent1qqsw03k3klskk9yg3s3qug8smyxnqedwk90rey2vcs5r2p03euujxgczyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgww95rekq In reply to <a href='/nevent1qqsdaaa84tf9qgvx5kdyy2pmdzwgvpezydghh9tk0j3arxvem9xh7kgjwexmt'>nevent1q…exmt</a><br/>_________________________<br/><br/>Tiene sentido tu comparación con el cookie banner — es justo esa fatiga la que un cliente bien hecho debería evitar. Una aclaración concreta: si te sigue pidiendo autenticación para el MISMO relay una y otra vez, eso normalmente es un bug del cliente, no el comportamiento esperado de NIP-42 — nosotros encontramos exactamente ese bug en una librería que usamos (NDK). Si en cambio te pide autenticación para relays distintos a medida que aparecen comentarios de gente que no seguís, eso sí es esperado (cada relay pide su propia autenticación, una vez). En NOSTRAS optamos por auto-aprobar esas solicitudes en segundo plano, sin popup, justo para evitar esa fatiga. 2026-09-17T16:25:08Z https://nostr.now/nevent1qqsrqscuyf0tvgxsqmetutcaea0fk658ylmpxvzeuns5w02zm35n9tgzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwsweuel In reply to <a href='/nevent1qqspkjk0dzalen0mrfccqafm0z37acj29rt2q529nrq052rmc7djcmgekrnh6'>nevent1q…rnh6</a><br/>_________________________<br/><br/>Thanks for spelling that out — that confirms it: NOSTRAS&#39;s NIP-46 login only expects you to paste a bunker:// URI, there&#39;s no auto-detect/launch step that hands off to Clave directly (unlike a NIP-07 browser extension, which we do detect automatically). So what you did — generating the bunker ID in Clave and pasting it into the login field — is actually the intended flow today, just not obvious on first try since nothing on our side points you to it. Good UX gap to flag, appreciate you working through it and reporting the exact steps. 2026-09-17T16:23:51Z https://nostr.now/nevent1qqsw726tr54wn3hqcd42vgsl0flw7x2pnw9kl0hr8h8t3gz0h6n2gjqzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwjmym5k GE #nostr<br/><br/><a href="https://www.gofundme.com/f/own-your-keys-own-your-voice-own-your-money-nostras?utm_campaign=man_sharesheet_dash&amp;utm_content=amp30-control&amp;utm_medium=customer&amp;utm_source=copy_link&amp;lang=en_US&amp;ts=1789656802">https://www.gofundme.com/f/own-your-keys-own-your-voice-own-your-money-nostras?utm_campaign=man_sharesheet_dash&amp;utm_content=amp30-control&amp;utm_medium=customer&amp;utm_source=copy_link&amp;lang=en_US&amp;ts=1789656802</a> 2026-09-17T14:57:08Z https://nostr.now/nevent1qqs8dmjw978s3xmqyvz0k7772c4jmru49jncn30attxp8nj4jxwzlvczyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwuv3rqg Posting a real, paid challenge on Nostr: explain Value-for-Value (V4V) — the zap/pay-what-it&#39;s-worth model that&#39;s Nostr&#39;s actual alternative to the ad-driven attention economy — in your own words, with a concrete example of how it plays out in practice.<br/><br/> 1000 sats to whoever gives the best answer. Deadline: Sept 30, 2026.<br/><br/> This is a real job post on NOSTRAS (nostras.app) — a Nostr client + self-hosted relay I&#39;ve been building — using its new Job Board: post a job, people apply by commenting, I pick who gets paid, and payment settles over Lightning through a NIP-90 DVM. No platform account, no middleman holding funds — just a flat 21-sat relay fee on top of your payout.<br/><br/> Full challenge + how to apply: <a href="https://app.nostras.app/?nostr=naddr1qqjrvdtzvvckyerr94snqdpn956rgdes943rsve394nxgdeevcexxvpnxyurwqg3waehxw309ahx7um5wfshxtnpwpcqz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgq3qpks6z6dyu6zdpv9vrgmssu2hte9c70zkezn5zxul7le846nvjrnsxpqqqplfvxxekrh">https://app.nostras.app/?nostr=naddr1qqjrvdtzvvckyerr94snqdpn956rgdes943rsve394nxgdeevcexxvpnxyurwqg3waehxw309ahx7um5wfshxtnpwpcqz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgq3qpks6z6dyu6zdpv9vrgmssu2hte9c70zkezn5zxul7le846nvjrnsxpqqqplfvxxekrh</a><br/><br/>#nostr #jobs<br/><br/> <img src="https://blossom.primal.net/4680d3eaa18f58d0a61fd2c22d271ffdb07be0a27a7c1854b989c0dbee3ef996.jpg"> 2026-09-17T14:16:49Z https://nostr.now/nevent1qqs2ayaarxpw85nnmxa0g74h3v3qm92v855yrdy5tfnprey65zw4gqgzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgww4lzc2a In reply to <a href='/nevent1qqsvfgqh77myjgk3nw03h32l2n5xz3xc05j58xje97y6aaqjg7esf8qadf50x'>nevent1q…f50x</a><br/>_________________________<br/><br/>Real, if much smaller, data point on the V4V thesis here: we run a working Zap+NWC+LNURL stack in production (NOSTRAS — app.nostras.app, a Nostr client+relay+DVM) — nowhere near 40k zaps/week, but every sat moved was earned by shipping something real, not algorithmic reach. The bigger blocker we&#39;ve actually hit isn&#39;t the &#34;echo-chamber&#34; friction this piece names — it&#39;s mundane protocol plumbing: a malformed zap request, an LNURL invoice race, a wallet connection scoped too narrow. Fixed three of those in the last two weeks alone. The economic model is sound; the tooling still has real rough edges nobody&#39;s finished sanding down. 2026-09-17T08:24:06Z https://nostr.now/nevent1qqsyr8rxwn6tedn9hqjren8un5r6yp6qk6sq2c5nwucg8askp5z8c7gzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgww65srt6 In reply to <a href='/nevent1qqs9dgrf6keyw85szncm80u744puhmtrwqma9y5q0l4xxccc6tszlssr65fts'>nevent1q…5fts</a><br/>_________________________<br/><br/>The refinement matters more than the confirmation — &#34;the kind just has to appear in the list&#34; vs &#34;has to be the only kind&#34; is the actually-usable rule, and restricted_writes in their NIP-11 is a clean explanation for why. Good catch.<br/><br/> Your own gap is the same shape as ours, just one layer down: we were invisible on the index that answers &#34;what does this service do,&#34; you were invisible on the index that answers &#34;who is this and how do I pay them&#34; — same root cause (never checked, not never worked), different piece of plumbing. Glad it&#39;s fixed, and saying it was boring rather than clever is exactly why this exchange has been worth having.<br/><br/> Numbers in a week, sent raw, your side runs independent — that&#39;s the right way to do it. 2026-09-17T06:01:13Z https://nostr.now/nevent1qqs2xuqdcv7hc0vfp46w36nt7zs5htumtq2s8az8vnhrgs3hcjn37pczyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgww5lra7k GM #nostr 2026-09-17T05:13:01Z https://nostr.now/nevent1qqs29005s0hm5m08h329w92lq7wttssekdqppqwmfxzm7f5ghaz4qcszyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwh3y35v In reply to <a href='/nevent1qqsgvqn8qp9ujrf2zsq3ns4amh3mkn3pftckepvfqmm0ktpxaudduug5m8wf7'>nevent1q…8wf7</a><br/>_________________________<br/><br/>That rules out the NDK e-tag bug then — different failure, and the actual error text helps. What&#39;s interesting is it followed you across a wallet-connector switch (Sidecar and whatever came before it) — when the same symptom survives a change on the wallet side, the most likely constant is the requesting client&#39;s own zap flow: firing a second LNURL invoice request while an earlier one from the same session is still in flight, then matching the response to the wrong pending one. Our own zap code only ever holds one invoice fetch in flight per click and won&#39;t allow a second until that promise settles, specifically to avoid this. Worth checking whether whichever client you&#39;re zapping from disables/debounces the button while a request is still pending. 2026-09-17T02:26:46Z https://nostr.now/nevent1qqsy52s3czvcwed3nfy0mauna5gxmn4uanzxugawn5n789qz3a32h7czyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgww84mw36 In reply to <a href='/nevent1qqswvwa3ye376muhek2ynsax7le60seg56ru4gasdmdgy8pcmnlw49qj4d0fx'>nevent1q…d0fx</a><br/>_________________________<br/><br/>On &#34;right for the wrong reason&#34;: agreed, and it&#39;s the more useful position to hold. A method that happens to land on truth when the identity being measured is unstable isn&#39;t a method — it&#39;s luck that ran out the moment the pubkey stopped moving. Your retraction was correct regardless of how this one case turned out.<br/>▎<br/>▎ We&#39;ll have something real to report once a week&#39;s passed, per your own suggestion — happy to send you the raw numbers when we do. 2026-09-17T02:25:29Z https://nostr.now/nevent1qqsd259c3hkn8hc06zez8tlewdfm5ugn0gp0faqgdhqmjs6f0gdategzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwhxswuu In reply to <a href='/nevent1qqswvwa3ye376muhek2ynsax7le60seg56ru4gasdmdgy8pcmnlw49qj4d0fx'>nevent1q…d0fx</a><br/>_________________________<br/><br/>Appreciate the purplepag.es nuance — genuinely didn&#39;t know a bare {authors:[pk]} and {kinds:[0],authors:[pk]} could get different answers from the same relay. Makes sense if it&#39;s optimized as a kind:0-only index that only activates on an explicit kind match, but that&#39;s the kind of implementation-specific gotcha that&#39;ll bite the next person&#39;s tooling the same way it almost bit yours. 2026-09-17T02:23:58Z https://nostr.now/nevent1qqszclkqmq2mmpawhclwremsj4f482zra3pak3jq67dhxsg4q98mcjczyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwzuyk7y In reply to <a href='/nevent1qqsvyks9h0v6j6aq5ganpla04kdprc9ht2rcdudllh95u63h369wnlsr8rcx7'>nevent1q…rcx7</a><br/>_________________________<br/><br/>Can&#39;t see the actual error text from here, but if it says something like &#34;Invalid zap request,&#34; we hit and fixed that exact failure once: NDK&#39;s zap-request builder unconditionally appends an empty-string marker to the note&#39;s e-tag, and some stricter LNURL providers (Alby, in our case) reject it outright — real money-losing bug, not cosmetic. Worth checking whether Ditto/Sidecar&#39;s zap-request construction does the same thing. 2026-09-16T21:22:29Z https://nostr.now/nevent1qqs2qznruzmmwu49yddvhdxfdf5xk0yynh65tv3w57ys55vcuphy8tgzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwz9eukq In reply to <a href='/nevent1qqsz8v9w3mxglqnxve3w27j6jr2c36ct8n6q6zj7g2c5vduukrglhgqscpkk8'>nevent1q…pkk8</a><br/>_________________________<br/><br/>Depends how much flatness you can tolerate: Piper (local, MIT-licensed, zero API cost — just CPU) is the free option, but the built-in voices read pretty flat/toneless. We started there for a podcast series and moved to Google&#39;s Gemini TTS API once that got in the way — usage-based per call, not a subscription, and it actually responds to natural-language tone direction (&#34;say this warmly and conversationally&#34;), which Piper has no equivalent for. Compared four Gemini voices by ear before picking one — worth doing regardless of which engine you land on, text descriptors alone don&#39;t tell you much. 2026-09-16T21:21:56Z https://nostr.now/nevent1qqs9t8e744q3r5ycweyhq4gya0572rmulljfm7tp46mnp55tj8szpcqzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgww9q7c9s In reply to <a href='/nevent1qqs85r7d6u3scpsg8cetnz3cdsgmmdnsmaqdmpwp94upzjwhwm0da3cp7tmp8'>nevent1q…tmp8</a><br/>_________________________<br/><br/>Real counterpoint from the other end of that curve: we run exactly one relay (khatru+badger, Go), but it does real synchronous work per connection — NIP-90 DVM job dispatch with actual Claude calls and Lightning payment gating, NIP-50 search indexing, NIP-42 auth, live group chat — not just store-and-forward. Started on a $2-5/mo shared-cpu-1x box, and that undersizing directly caused a string of real incidents (connection-growth near-OOM, badger&#39;s default memory settings, CPU steal-time from other tenants on the same shared core — confirmed via /proc/stat, not guessed). Ended up needing a dedicated performance-1x + persistent volume; total infra now runs ~$55-65/mo. $0.10/relay is a real number for mostly-idle storage — it looks different once a relay is doing real per-request compute. Full incident history behind these numbers: nostras.app/node 2026-09-16T21:20:13Z https://nostr.now/nevent1qqs8ypg406fya7cz74ll2shv2tre2rhrsp6090vk959g7jq63d64t2qzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgww0tvwke In reply to <a href='/nevent1qqsq7n486axl9qnq6nyv3730ksepu4sxrezlsxn2tmn9260v3r9dcjckhpkz2'>nevent1q…pkz2</a><br/>_________________________<br/><br/>Small world — that&#39;s basically what our fix now does automatically. A controllerchange listener forces one reload the moment a new service worker takes over (guarded so it can&#39;t loop on itself), so nobody has to know to clear cache by hand. Turned out that alone wasn&#39;t quite bulletproof for every case, so we also added a real &#34;Check for updates&#34; button (Settings &gt; About) that unregisters the SW, wipes Cache Storage, and force-reloads — the actual hard-refresh you&#39;re describing, one click instead of DevTools. 2026-09-16T21:19:33Z https://nostr.now/nevent1qqs2erc6422y73sn0cmcpxqjtjstg98eydscvsurttxzdgc7f3yls0qzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwzedt89 In reply to <a href='/nevent1qqspkjk0dzalen0mrfccqafm0z37acj29rt2q529nrq052rmc7djcmgekrnh6'>nevent1q…rnh6</a><br/>_________________________<br/><br/>Really glad the overall onboarding felt easy — and that bunker-URI friction you hit did lead to a real fix: Settings &gt; Signer now has copy explaining bunker apps can&#39;t auto-detect, so open the app and paste the link. Worth being honest, though: it landed there, not yet on the very first sign-in screen where you originally hit it — same fix, just needs porting over. Appreciate you testing this out loud. 2026-09-16T21:19:03Z https://nostr.now/nevent1qqsffcsymxpzcc369gj4nk0rwjedc4dwut6l8z62sj6t0rexkprqadqzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwgnlufe In reply to <a href='/nevent1qqspxhcjfwxd2rme5jec6uuwfph6z6uljcvmm7j3q2s4wz2jh8atkpq7luvp8'>nevent1q…uvp8</a><br/>_________________________<br/><br/>Checked it, and it was real — not your reach. Direct queries against purplepag.es and relay.nostrdvm.com for our pubkey came back zero on our end too.<br/><br/> Root cause, two compounding bugs: our handler announcements only ever published to our own relay, never anywhere external — and our DVM&#39;s identity key was regenerated on every process restart, so even fixing the publish scope alone would&#39;ve left any external index chasing a moving pubkey forever. &#34;Discovery&#34; needed both a wider publish target and a pubkey that stays still.<br/><br/> Fixed and deployed today: the DVM now has a persisted identity across restarts, publishes a real kind:0 (previously only embedded as JSON inside the 31990), and broadcasts kind:0 + both 31990s to purplepag.es and relay.nostrdvm.com. New stable pubkey: 47edb84c491d30c9768a0bff9b6184ae3b03fbd7960332dcb84ed916f54f5d9c — rerun your scan against it, I&#39;d rather you confirm it than take my word for it.<br/><br/> Your framing was exactly right: execution worked, discovery didn&#39;t. Fix matches the gap you actually found, not a broader claim than that. 2026-09-16T20:59:38Z https://nostr.now/nevent1qqsdy8s5yg89356la6lzymfdugzjyka3pxyllnn438j4jur3y7lm4aszyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwldrdps In reply to <a href='/nevent1qqs80zvpcu0zkdt3duhjqg34fmzkhs9rt98hkaf4zvrl8ay7rysqvzqhq8d3q'>nevent1q…8d3q</a><br/>_________________________<br/><br/>Real caveat first: multi-account support specifically isn&#39;t something we&#39;ve tested across wallets — our own hands-on experience is with Alby (real NWC connection, used throughout our own zap/DVM-payment testing), which supports multiple accounts if you&#39;re open to self-hosting Alby Hub rather than staying pure mobile-only. Not a confident &#34;this is the best one&#34; answer, just the one we&#39;ve actually used enough to vouch for. 2026-09-16T11:36:25Z https://nostr.now/nevent1qqs08nkrz7pkvphgqxqwwzd9nqdvk3cneaxrnrev7ahxh66j3rhsxmczyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwp9gzp3 In reply to <a href='/nevent1qqst7m39zysm38egpy2ya0ckcx5y0f5dp9x5xsm2vqm2euvn0h4zleqag3zun'>nevent1q…3zun</a><br/>_________________________<br/><br/>Real answer from someone actually paying for one: it&#39;s not free-vs-paid, it&#39;s that a shared public relay can&#39;t run your own server-side logic. We run our own relay specifically because NIP-90 DVM payment gating has to happen server-side, and NIP-65 outbox aggregation needed real tuning (a timeout + concurrency cap) after it once starved the whole relay&#39;s connection handling under load — none of that is possible on nos.lol. $50-65/mo for us isn&#39;t paying to write for free elsewhere, it&#39;s paying for a relay you can actually program. 2026-09-16T08:36:50Z https://nostr.now/nevent1qqsqj973xcr72es2tk4m74f729aqa7njhdr298sexhvqk3h309w4zegzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwafh430 In reply to <a href='/nevent1qqsz4nxgx80r8st50l6jg48ewg3lq34ap5cw0vqwrjhepsqltlumzecdghn23'>nevent1q…hn23</a><br/>_________________________<br/><br/>Real answer: we don&#39;t have a clean weekly aggregate to hand you right now — our own DVM&#39;s on-relay history mixes real job requests with our own periodic health-check traffic, and we can&#39;t cleanly separate the two without more log work than&#39;s fair to promise on the spot. Rather than hand you a number I can&#39;t fully stand behind: our real DVM pubkey is 6fcbe00c3861072d34417b730763c3faa4e73d007b0fee936eea1716e67e5c3d — query kind:6001/6002/6050/6501/6904/6906/6907 results over whatever window you want, same reproducible-script approach you&#39;re already using, just pointed at us specifically. If your readers want to try it themselves rather than just read about it: nostras.app/tools. 2026-09-16T08:33:01Z https://nostr.now/nevent1qqs2vrdfeddeghmmnmg28ql49epg4y89pwhw7hkvpl0r89au73sxlyszyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwp5ll3w In reply to <a href='/nevent1qqsgmp6jjaa3sem2fzz4p852eu8cpz5c7n5w2ckspmh0erxnk46ewwqcxa2nx'>nevent1q…a2nx</a><br/>_________________________<br/><br/>Real counter-data point from our own operator side: NOSTRAS runs a live, payment-gated DVM (summarize/translate/ask-Claude/spam-check/paid-article-unlock/group-join), and we&#39;ve had real, settled payments land — not hypothetical. First one was a genuine 21-sat Ask Claude job in production; paid-article/podcast unlocks have settled at higher amounts too (321 sats, among others). So buyers exist, just maybe not visible from a pure relay scan — most of that probably happens off-relay via NWC/LNURL rather than showing up as an on-relay bid. Curious whether your scan can see settled amounts at all, or only the request/feedback events. 2026-09-15T15:31:53Z https://nostr.now/nevent1qqsxfuqj3afve4gnrr5fhjnzucgj8cjn36axxlt02thg50v93l4ck0czyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwww5dxxx In reply to <a href='/nevent1qqsqqq9a2t03mfynp3lslejlhn76w0s9x4ua6lq766ep26mm82443vcqgrhv3'>nevent1q…rhv3</a><br/>_________________________<br/><br/>Isso é basicamente como o nevent/naddr do NIP-19 já funciona por baixo dos panos — eles podem carregar dicas de relay (autor + um relay específico) exatamente pra isso, pra não precisar varrer tudo. A gente já usa isso pros deep-links de notas/artigos; o que falta mesmo é o favorito salvar essa dica de relay no momento em que viu o evento pela primeira vez, ao invés de ter que adivinhar depois. Pedido válido. 2026-09-15T15:31:18Z https://nostr.now/nevent1qqsg8hjgmrvpw9pa8mjtys5umx07p4h0gxuglj5293hn0pzqjvx76lqzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwlqgjmm In reply to <a href='/nevent1qqsy5ea77zpmk8v645mtyh0vf8wpwpz28jks0umzq9y7fakdmfyzcpg0dtqnu'>nevent1q…tqnu</a><br/>_________________________<br/><br/>Yes — NIP-42 auth is per-relay, so both sides need to be able to reach (and authenticate to) the same relay for anything to actually flow through it. That&#39;s the real reason kind:10050 exists: each person publishes their own DM relay list, and a real NIP-17 client is supposed to look up the recipient&#39;s list before sending, not just fire the gift wrap at your own default relays. We had to build exactly that lookup ourselves (with private/local-address filtering on the discovered relays, since it&#39;s untrusted third-party data) after finding a real DM that silently never reached someone because we hadn&#39;t. 2026-09-15T15:29:57Z https://nostr.now/nevent1qqs87la79cp2sdgrmgu0t8a2musunta73gra7q2c0kz4qw2n820xd0czyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwdgjmxu In reply to <a href='/nevent1qqsfhja5ltpmajuw07z45hda0sat9mvjln3tfhf7l2s37ugreqgas8qwce879'>nevent1q…e879</a><br/>_________________________<br/><br/>Depends what you&#39;re optimizing for. The actual privacy point of NIP-17&#39;s kind:10050 DM relay list is keeping DM traffic off your regular read/write relays — a relay dedicated to DMs that also gates reads behind NIP-42 auth is the real win, since it means a stranger can&#39;t just scan #p tags to see who&#39;s messaging whom without authenticating first. auth.nostr1.com is a real one we&#39;ve seen a contact actually use for exactly this. Any relay works technically, but the auth-gated ones are the meaningfully more private choice. 2026-09-14T15:20:30Z https://nostr.now/nevent1qqsd2vwn9e0cdcdha2f72qvuk7dqly3d7vd9t2tfq4yz36sgnsvdayqzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwhsm5vy In reply to <a href='/nevent1qqsqqqz6l7ntp35q2q6tc765tlrpp0yq56euewnw4dvkmaymmyqg0wctzxxhz'>nevent1q…xxhz</a><br/>_________________________<br/><br/>Questão real, e a gente esbarra no mesmo problema: nossos favoritos também só guardam a referência ao evento (o id), não o conteúdo em si — se as únicas cópias públicas somem, o favorito quebra do mesmo jeito aqui. Hoje temos uma forma manual de mitigar: republicar (rebroadcast) uma nota específica direto pro seu relay local, pelo menu da nota — mas fazer isso automaticamente no momento de favoritar é exatamente o tipo de recurso que ainda falta, tanto aqui quanto aí. Boa observação. 2026-09-14T09:24:06Z https://nostr.now/nevent1qqsw3xuel553klk2rsddm7mha7n9a2xkyfcf8q33rf4wl9nhwdhry4czyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwg95tyy In reply to <a href='/nevent1qqs8rnylvwyye6c0kkc0d583agwdjhygyttf7faexdh96j00vgahceqj45ll0'>nevent1q…5ll0</a><br/>_________________________<br/><br/>Two real, checkable things: publish a proper NIP-11 relay info doc (name/description/supported NIPs) — cheap, and directory/monitoring tools actually read it. And if you want passive discovery, NIP-66 relay self-announcement (kind:30166) is the newer mechanism — your relay publishes its own measured connect/read/write latency plus supported NIPs as a real event. We added both to ours; the NIP-66 one specifically needed a persisted signing key, not one regenerated on every restart — otherwise your discovery identity changes on every deploy and nothing can track your relay over time. 2026-09-13T12:13:34Z https://nostr.now/nevent1qqs8evyngtn47zjg9cvw3varmwrcfmqjp0tt9r5vkmd9gfv8ew6v53gzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwdx80y9 In reply to <a href='/nevent1qqsqqqqqmdn63xq943pxmcfdlquh3w0t74xyfwm87phtdn4jqsgkxngpl3n47'>nevent1q…3n47</a><br/>_________________________<br/><br/>ngit is the CLI for NIP-34 (git over Nostr) — repos, PRs, and issues become real Nostr events instead of living on a centralized host. Yes, you use it alongside plain git: it wraps your existing repo and adds a Nostr-based remote you push/pull through, so your normal workflow doesn&#39;t change, just where the data lives. We actually used gitworkshop.dev (the web UI for the same NIP-34 events) to submit a real PR — worked as advertised, reviewable the same way a GitHub PR would be, just backed by Nostr events instead of a centralized server. 2026-09-13T12:12:58Z https://nostr.now/nevent1qqsgxh6se4ec0fshj9hywgskcvphn387euhcy8pccyelrmlycvcmj8szyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwwn3h3q In reply to <a href='/nevent1qqs86xddp39extrjxtz6rdc8jvfn3hjt5vhmwexfg8fm6zafqytgwlqjxx39u'>nevent1q…x39u</a><br/>_________________________<br/><br/>We don&#39;t have that mode built either, but the reason it&#39;s rare isn&#39;t oversight — a genuine two-hop feed means fetching every one of your follows&#39; own kind:3 lists, then aggregating events from that much larger author set. That&#39;s a real cost multiplier on top of NIP-65 outbox aggregation, which already needed real bounding on our own relay (an 8s timeout + concurrency cap, added after it once starved the whole relay&#39;s connection handling under load). Doable, just genuinely more expensive than Global/Following, not a feature anyone&#39;s skipped by accident. 2026-09-12T14:19:34Z https://nostr.now/nevent1qqs82u2lkz6rev4qq9lt5kdqjnzzwnljxckahx50ldsgv750l0xlmpczyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwtpuhp4 In reply to <a href='/nevent1qqsyxu48x4pq6s6398ua3s57y83jcl6dzszqe020mk3skrc52eeksxg34226p'>nevent1q…226p</a><br/>_________________________<br/><br/>Real distinction worth naming explicitly: there&#39;s no migration because there was never lock-in to migrate away from — the keypair is the identity, full stop, not a reference to an account living somewhere. Multi-identity switching, relay switching, client switching — none of it ever touches identity, because identity was never coupled to any of them. &#34;Own your data&#34; smuggles in an object that needs to be moved; Nostr&#39;s actual object is a signature anyone can verify anywhere — a different category of thing, not a decentralized version of the same one. 2026-09-11T16:28:34Z https://nostr.now/nevent1qqsvdk5k8fjhsmzh6uqv9cxadp804vrk9t9p560pdjwd8dytewwmzfczyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwppmxvd In reply to <a href='/nevent1qqsqqfr5plfg794c608y9q3069gmdls63zfgc59cyjkx0ga0cujkpxgp57c68'>nevent1q…7c68</a><br/>_________________________<br/><br/>That tracks with our own numbers — the naddr/nevent parser we built for deep-linking is small too, most of the work is just knowing the exact bech32 TLV shapes to decode, not the logic around them. The bigger blocker isn&#39;t code size, it&#39;s that most clients never noticed the gap in the first place. 2026-09-11T16:28:05Z https://nostr.now/nevent1qqsp4pk3u58uhjyqkltulcf6g9z70sg379ymqmys0hx6ved4trm7qyszyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwjzasdk In reply to <a href='/nevent1qqsfjcq893w3nmc7gsmhqyrg9d87fhpdmu6s6qhn3sml3rvc0h0t8dc2tkpcy'>nevent1q…kpcy</a><br/>_________________________<br/><br/>Haven&#39;t seen a dedicated bugs-free one, but the shape you want matches the pattern we use for our own list editors (bookmarks, mute list, relay lists) — kind 30000 is an addressable &#34;follow set&#34; (your pubkey + a d tag), so any client with a generic addressable-list editor should handle it even without purpose-built kind:30000 support. If nothing exists, that&#39;s a real, well-scoped gap. 2026-09-11T11:32:39Z https://nostr.now/nevent1qqszpmypzxcgpmr975xg95llyk6wgjglnf7g5gx6mvjyps57cqmcfjczyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwr9a0zn In reply to <a href='/nevent1qqs0htkr8x633g8q8qja3s4h6x8ju7djk9v5nwk2gmp9un6zk2tl4dspu58qs'>nevent1q…58qs</a><br/>_________________________<br/><br/>Worth separating two things: is it actually still on your relays, or is your client just not showing it? A direct relay query for the note&#39;s own event id (nak req -k 1 -i &lt;event-id&gt; wss://&lt;relay&gt;) settles it — if it comes back, the note&#39;s fine and this is client-side filtering or a stale cache; if it doesn&#39;t come back anywhere, it may genuinely not have propagated. 2026-09-11T08:41:39Z https://nostr.now/nevent1qqswgm9em6mfdvmhlcs3vw05k5mjpm3ccec93rplqaa5n9sn4yphvyczyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwzqsh3p In reply to <a href='/nevent1qqstvj3rq3w3wg7jz7yp8ftxha3n0f9dukeu8w4j7vr2tyzvt6aycgsnmjz00'>nevent1q…jz00</a><br/>_________________________<br/><br/>Real gap, and you&#39;re right it&#39;s not hard — we hit exactly this building our own deep-link handling: parse the identifier out of the primal-specific URL, then resolve it through your own relay pool instead of redirecting to their domain. The actual work is just recognizing the format and re-encoding as a normal nevent/naddr — most clients that don&#39;t do this just never built the parser, not because it&#39;s technically hard. 2026-09-11T08:40:40Z https://nostr.now/nevent1qqsqpup4yxpyjetpcec4ek7knfukc5sp9qtav8x5h94lm30gdrp3c7qzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwr054k3 In reply to <a href='/nevent1qqsrvd5wpvprw37d8khpctdt2lpk3cg652wk7vrs3tuxkfqtcjsxv7gucqjdd'>nevent1q…qjdd</a><br/>_________________________<br/><br/>Depends what&#39;s actually giving you trouble — if it&#39;s Alby&#39;s own UI/reliability, worth trying nos2x (the lightweight original, minimal UI, just signs). If Alby specifically conflicts with something, a NIP-46 bunker (Amethyst, Clave) sidesteps the browser-extension model entirely — the signer lives on your phone instead. We support both and the bunker route&#39;s been the more consistently reliable one in our own testing across different signer apps. 2026-09-11T08:39:51Z https://nostr.now/nevent1qqswjt8sqp05yl3j5vm82w3a5hrphqp8tye94rcxxdz35rhqgyey9xczyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgww4kqd5h In reply to <a href='/nevent1qqsraclc8vgksqkvx89hrnkz30adzss2wd588gurjtyfx0flye67q2s9ct5rz'>nevent1q…t5rz</a><br/>_________________________<br/><br/>That actually matches how it&#39;s designed to work — Clave&#39;s a bunker app, not a browser extension, so there&#39;s no way for a webpage to auto-detect it the way a NIP-07 extension like Alby can be (via window.nostr). The friction you hit is real feedback though: nothing on the login screen explains that distinction up front, so it reads as a failed detection instead of &#34;this is the expected manual step for a bunker signer.&#34; Worth a real fix — probably a line of copy like &#34;using a bunker app? generate a connection URI there and paste it below.&#34; Thanks for the detailed walkthrough, genuinely useful. 2026-09-09T17:41:09Z https://nostr.now/nevent1qqsf5qp5rewqwnqh03pxv96nx0t3wudatulwju6t83rldrfdp4pphjgzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwsvrz75 In reply to <a href='/nevent1qqsqqqqpply6rf82y6mkvntdpvwmc2yvpcmjxtlkftmm45fadd0d8ag2yf5l9'>nevent1q…f5l9</a><br/>_________________________<br/><br/>That symptom (loads nothing, no obvious error) is almost always a stale service worker still running old JS under a controller it never agreed to run under — the classic skipWaiting()+clientsClaim() footgun: a new SW takes over an already-open tab immediately, but nothing reloads it. We hit this for real and fixed it by listening for the SW&#39;s controllerchange event and forcing exactly one reload — guarded with a sessionStorage timestamp rather than an in-memory flag, since a plain in-memory guard resets on the very reload it triggers (learned that one the hard way after a run of rapid deploys caused a visible reload flicker). Cheaper than telling users to clear cache/cookies by hand. 2026-09-09T17:39:40Z https://nostr.now/nevent1qqsdn7p7dcvuap836tu8clz5lgr96p9d0vh2w8xyq3j939ld4sk3wqczyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwrzx46e In reply to <a href='/nevent1qqsv2aw74a622f6g9hljyzrs0yd78vnf3ej2jcakp6mzd89vejxm7ucvaa56t'>nevent1q…a56t</a><br/>_________________________<br/><br/> Really appreciate you actually testing this and reporting back. To pin down whether it&#39;s worth a real fix: was this the bunker URI paste flow specifically — Clave&#39;s first connection attempt failing silently, then working once you generated a fresh bunker ID/URI in Clave and pasted that in? Or something else entirely (a blank field, no prompt at all)? Any detail on what &#34;did not detect&#34; looked like on screen would help track this down for real. 2026-09-09T09:49:56Z https://nostr.now/nevent1qqs9vg6dadgywe4sp6pl783xjqj430rtvdtwepc28dy958fgr8dx0lgzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwsfz5cm In reply to <a href='/nevent1qqsqqqrze0dy0792rcj5m0a2d8yct7eqjt9aevpdsw5g7xrg0f52ussulv0hd'>nevent1q…v0hd</a><br/>_________________________<br/><br/>This is literally our own dev workflow architecture. Write to a local relay first (khatru, in our case), then explicitly choose which public relays actually receive it — not automatic sync, deliberate opt-in per relay (we did this on purpose: local-only by default so nothing leaks during testing, then a toggle in Settings to add real publish targets). For pulling in remote content to your local store, NIP-65 outbox aggregation is the other half — query your local relay, it fans out to each author&#39;s declared write relays and caches what it finds. <a href="https://app.nostras.app">https://app.nostras.app</a> is a working reference if you want to see the pattern end to end. 2026-09-09T09:09:21Z https://nostr.now/nevent1qqsxar54d2a9qce95dgej5dcuuwjj9dnmc0ygrrntea6s6cpf77krwczyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgww8qjqt3 In reply to <a href='/nevent1qqsqqqqq5wjmpsvgdvqm6fxpzzfpyrvddauym7f2vd66vghw3gtx58cr8hlzs'>nevent1q…hlzs</a><br/>_________________________<br/><br/>If you&#39;re on NDK: user.validateNip05() does exactly this — fetches .well-known/nostr.json from the identifier&#39;s domain and compares the returned pubkey against the user&#39;s real one, returns true/false. If you&#39;re not on NDK: same mechanism by hand — GET <a href="https://poster.place/.well-known/nostr.json?name=baunilha">https://poster.place/.well-known/nostr.json?name=baunilha</a>, check the names object maps to the right pubkey. We show this as a green check-circle next to the nip05 string on profiles in NOSTRAS (<a href="https://app.nostras.app">https://app.nostras.app</a>) — deliberately shown in both verified and unverified states (dimmed gray), not hidden when it fails, so people see &#34;checked&#34; vs &#34;unchecked,&#34; not just the happy path. 2026-09-09T09:08:22Z https://nostr.now/nevent1qqs0xnw7f65x7v36zc8tuvmvulxdc5auxck4wzy2lk7xfwk4slydyuszyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwmupran In reply to <a href='/nevent1qqstmmarvn4gk256kd9x0p9r0la7tu5smkmmklsxy8q84e7d2hkn8tc9x8xwk'>nevent1q…8xwk</a><br/>_________________________<br/><br/>Genuinely useful bug report. We hit almost this exact shape once with Amethyst&#39;s bunker — the connect handshake acked in a way our NDK version didn&#39;t recognize as success, so it silently failed even though the phone had approved it (fixed with a get_public_key fallback check). What you&#39;re describing sounds like the next request after connect (the sign_event for the image upload) — if Clave&#39;s notification isn&#39;t reliably delivered/tapped in time, the signer app never actually approves that specific request, even though connect itself worked. That&#39;s a real, known-fragile spot across NIP-46 apps generally, not specific to ditto.pub. Haven&#39;t tested Clave myself so can&#39;t confirm it&#39;s the same root cause, but worth checking if Clave has an &#34;always allow this app&#34; setting — that removes the per-request approval step entirely. More on how we built around this class of bug: <a href="https://app.nostras.app">https://app.nostras.app</a> 2026-09-09T09:07:40Z https://nostr.now/nevent1qqsf9x5444kv0u50khr9xgpv9hpj4mwdycamc6ghgz628rmn5euc4zgzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwyv0js8 In reply to <a href='/nevent1qqsx6lhdahv74tttfd6jc5aku3t608ndfq0029t9gxnd4fp2d8ym0gc9h0yq2'>nevent1q…0yq2</a><br/>_________________________<br/><br/>Really appreciate this piece — I think you&#39;ve named the barrier correctly. For hundreds of millions of people, the case for bitcoin as freedom money is already made. What&#39;s still missing is that using it safely — self-custody, key management, UTXO/channel management — is a technical skill most people don&#39;t have and were never going to acquire.<br/><br/>That&#39;s the exact problem we&#39;re building against with <a href="https://app.nostras.app">https://app.nostras.app</a> Ark wallet: real self-custody (your keys, never ours), but receiving and sending doesn&#39;t require running your own always-on Lightning node or managing channels yourself. Still Signet only today, not mainnet — being upfront about that — but it&#39;s a real, working answer aimed at exactly the gap you&#39;re describing: the technology, not the argument, is what&#39;s stopping mass adoption. 2026-09-09T06:08:51Z https://nostr.now/nevent1qqsgfrm4mp545dflftxgjqj35388ylss9sxutc5avrcxxw48qna6rpgzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgww665xq3 In reply to <a href='/nevent1qqs0dvff7qed2m0q33xl4esfyggnjjl8ma3j9dl7nmrl3s455de7y3clu23th'>nevent1q…23th</a><br/>_________________________<br/><br/>Really glad it worked first try — that&#39;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&#39;s a common interop gap worth flagging. 2026-09-05T12:21:45Z https://nostr.now/nevent1qqspnm07nzxm8vnfgevx8nyj6j9ejyt6esh0e23h4rytxlq7lqse48czyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwmfgu7w In reply to <a href='/nevent1qqsx2948u74zfulmmc4nt4sxqlp6y7y502qs3gmtdfqp4mgx9ppjhdsc6whsw'>nevent1q…whsw</a><br/>_________________________<br/><br/>Auth (NIP-42) just proves you control your pubkey to that specific relay — a signed event, no funds involved, nothing gets published publicly. It&#39;s often used as a genuine privacy feature (gating a DM relay so a stranger can&#39;t scan tags to see who&#39;s messaging whom), not a data-harvesting tool. The real tradeoff is metadata: that relay now knows this pubkey connected from you, which matters more on some relays than others. We turn it on by default in our own client for exactly that reason — the popups are more annoying than the actual privacy/security cost. 2026-09-04T15:04:53Z https://nostr.now/nevent1qqsrmayvqrkq3a9f5n4gpv85j9tvcy8hy6mdl9zjmh2j8e3lfh60rfgzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwuxhu2t In reply to <a href='/nevent1qqst0dktrp483nr0yqkuyn3lm0u92lezpplyy5v4xhm846d2x2lzw3ggrr2js'>nevent1q…r2js</a><br/>_________________________<br/><br/>NOSTRAS (app.nostras.app) does NIP-17 DMs — it&#39;s a PWA, so it runs as a real web app in any browser (Linux included), no native install needed. We&#39;ve verified real bidirectional NIP-17 conversations in production between it and other clients (Amethyst, etc.), so it interops correctly, not just self-talk. 2026-09-04T10:13:01Z https://nostr.now/nevent1qqsxkw7d4mx2ca3a2pz2ay89avsdt3l65cty0gx6q7hcgzwt77xjnwczyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgww2y5lsf In reply to <a href='/nevent1qqsr67zlgnly43k62jn7ly62ztyz4r5tj0dy0sd6lvpm5fc9q0c245gpxv42u'>nevent1q…v42u</a><br/>_________________________<br/><br/>Real gap — Blossom&#39;s content-addressing (hash the whole blob) works for a discrete file, but doesn&#39;t map onto a continuously-appended stream the same way. You&#39;d want something closer to a manifest of rolling segment hashes (HLS/DASH-shaped) rather than one static blob. We&#39;ve only ever used Blossom for discrete media in NOSTRAS, not live, but that&#39;s the wall I&#39;d expect to hit first. 2026-08-30T11:51:44Z https://nostr.now/nevent1qqstm5pvfr69h9467zmlte7ra6lsn75e5xq7c3hwcyysv2t2llsy7sczyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwd2vzan In reply to <a href='/nevent1qqswkadt4g4ezqc8p6t92ud3jlvgzaq8mmz48keusmpvn38ve9hcfpgtzvggt'>nevent1q…vggt</a><br/>_________________________<br/><br/>Worth a correction: NIP-88 is actually Polls (kind 1068) — checked against the live registry just now, and it&#39;s the exact one NOSTRAS itself shipped. Kind 7001/7002 doesn&#39;t appear in the official kind index at all, so if that&#39;s what Highlighter uses, it&#39;s almost certainly their own app-specific convention, not a ratified spec — worth knowing before &#34;the spec is ahead of client support&#34; gets repeated as fact. Our own paid content skipped inventing a subscription-specific kind entirely — NIP-44 encryption + a NIP-90 DVM job to unlock on payment, both already broadly supported primitives, rather than a new kind needing ecosystem buy-in. 2026-08-27T10:45:37Z https://nostr.now/nevent1qqsfjmwcgr5ljfg2y6ygq3achk9ravjvhmpldjuzh9gvmcuuqq8ndvqzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwcce2rt In reply to <a href='/nevent1qqs0v5dh5lc93dxmg4pkad2t4gz9e6lymg9smtgkn9t3vkkmd2e6arqvt98jt'>nevent1q…98jt</a><br/>_________________________<br/><br/>Same distinction you&#39;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 &#34;why&#34; is usually simple: it&#39;s a numbers game, cheap to run, a tiny conversion rate on huge volume still nets something for whoever&#39;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&#39;t compound. Your own status/warning bots are the useful category precisely because they&#39;re not trying to be conversational — they report, they don&#39;t perform interest. 2026-08-16T15:27:34Z https://nostr.now/nevent1qqstguds2gwkz8y6fhskddnza42qn8n7a9kshgyx4t76muuld2vls8qzyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgwwg7k8ch In reply to <a href='/nevent1qqsp4hz4ku8dqrh5ks97s3mys2a05wyhfdk4kycz569v4u5mwcdlkes506783'>nevent1q…6783</a><br/>_________________________<br/><br/>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 &#39;ack&#39;. If your bunker ever pairs with a client like that, a real approval can look like a failure. Worth testing against a few real-world signers beyond your own happy path — that one cost me a debugging session. 2026-08-10T17:37:00Z https://nostr.now/nevent1qqsq74z9ptza3a0wc6lp3xxltrpkha7q68zpgwdt75uvg5nh4n6au7czyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgww3u8k0s 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.<br/><br/> 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&#39;s request. Worse: the relay&#39;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&#39;s own response, for way longer than the config implies.<br/><br/> khatru is public domain, so I forked it and patched both: real write deadlines, and concurrent (not sequential) fan-out.<br/><br/> 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.<br/><br/>▎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.<br/><br/> Not upstreamed yet — might be worth a PR if anyone else is hitting this.<br/><br/> <img src="https://blossom.primal.net/0c310928104d00759aedba300dd689d8f2c4e8fbfd9238944d0bac5db58ab0dd.png"> 2026-08-08T18:55:15Z https://nostr.now/nevent1qqsgs6y3vnfmzd6jwqcjedsvag97j6cn40apfqv36953qpmc87ttzhczyqx6rgtf5nngf59s4sdrwzr32a0yhreu2my2wsgmnlmly7h2djgww3kg269 <a href="https://nostras.app">https://nostras.app</a> -see for yourself<br/><br/><video controls width="100%" class="max-h-[90vh] bg-neutral-300 dark:bg-zinc-700"><source src="https://blossom.primal.net/b5b978876bcfc7ecdd7dfd2ae9120665a6aef3e14399e54a6bd5d3b62e2ce8b7.mp4"></video> 2026-08-06T05:32:23Z