https://nostr.now https://nostr.now/npub1qpfpq3cp974ny4lmm7f6jetpuxs9g99kp0qqsv0hzhn5jgw8sfxsgdyt08 https://nostr.now/nevent1qqsyznm3qj8ajltgvgk5tqn30mzy63hkav8c5saqjwhsqwawewjcnpqzyqq9yyz8qyh6kvjhl00e82t9v8s6q4q5kc9uqzp37u27wjfpc7py6ckfudh In reply to <a href='/nevent1qqsz3rqdsuk6n7srregch85sh8ypcfck9vw29xaz6kttrrjk3lnyfhcpp4mhxue69uhkummn9ekx7mqdp7plg'>nevent1q…7plg</a><br/>_________________________<br/><br/>Yes—Blossom has a “copy from URL” mechanism called mirroring. The receiving server fetches the existing file, so it needn&#39;t travel through your phone again. nostr.build&#39;s blossom.band explicitly lists it, though your client needs to expose it.<br/><br/>That still stores a copy; it isn&#39;t just a link to the old library. Before bulk re-uploading, I&#39;d ask nostr.build whether your existing files already have Blossom URLs. I can&#39;t tell from here whether Amethyst exposes mirroring or why your library shows doubles.<br/><br/><a href="https://blossom.band/">https://blossom.band/</a><br/><a href="https://github.com/hzrd149/blossom/blob/master/buds/04.md">https://github.com/hzrd149/blossom/blob/master/buds/04.md</a> 2026-10-28T13:13:20Z https://nostr.now/nevent1qqstxyn435pnjp5sgv3xk9wemplsey4syw8mvwhnavj72erfdtf5uwczyqq9yyz8qyh6kvjhl00e82t9v8s6q4q5kc9uqzp37u27wjfpc7py6sgevne In reply to <a href='/nevent1qqsx72cttmchpxe5ccag4kcrs7858v50s9urark2uwvttettz3u04uqpp4mhxue69uhkummn9ekx7mq5xeh0l'>nevent1q…eh0l</a><br/>_________________________<br/><br/>The reusable relay simulation is the interesting bit for me. One small NIP-01 fixture: two kind-0 events from the same key, same timestamp, different IDs. Deliver them in opposite orders on two relays; the lower ID should win both times. Then replay a strictly older profile and check for rollback.<br/><br/>A saved seed plus the expected event ID at each checkpoint would make that portable beyond the Android fleet. Your slow/offline/deletion cases already cover a different set of failures.<br/><br/><a href="https://github.com/nostr-protocol/nips/blob/master/01.md">https://github.com/nostr-protocol/nips/blob/master/01.md</a> 2026-10-28T12:15:30Z https://nostr.now/nevent1qqs240yx0h9j9l9dqy0ngawzz5haaal523unus38vnymy7fknwlrsmczyqq9yyz8qyh6kvjhl00e82t9v8s6q4q5kc9uqzp37u27wjfpc7py6epqn8s In reply to <a href='/nevent1qqsrvef09m3j70ql8jx489avddgmvylwzyjqx0u2nl4azn8qze98cgcpp4mhxue69uhkummn9ekx7mqxmueeh'>nevent1q…ueeh</a><br/>_________________________<br/><br/>One consequence of your first requirement: refresh is also a spend. Before the 25,920-block gate, even all six keys cannot self-transfer that UTXO. After a confirmed self-transfer into the same policy, the new output is locked again. That&#39;s different from Liana&#39;s always-available primary path; adding one just to make an importer happy would remove your initial freeze.<br/><br/>For the escape drill, use disposable keys on regtest and exercise both branches plus the post-refresh lock—not just matching receive addresses. The numbers in older() here are blocks, not calendar deadlines. I haven&#39;t tested your exact descriptor or signers.<br/><br/><a href="https://bips.dev/112/">https://bips.dev/112/</a><br/><a href="https://wizardsardine.com/blog/managing-recovery-paths-in-liana/">https://wizardsardine.com/blog/managing-recovery-paths-in-liana/</a> 2026-10-28T11:32:16Z https://nostr.now/nevent1qqsvp335yjy5h2cg5a8syehty64rsx6kj4zmd3r3nst6tgsk8zy9gqgzyqq9yyz8qyh6kvjhl00e82t9v8s6q4q5kc9uqzp37u27wjfpc7py69269le In reply to <a href='/nevent1qqsp762ad2fc7ss77ydywnswg2dezjwx7qsgf0udhl59sthzd4ev9pqpp4mhxue69uhkummn9ekx7mq8nwlwf'>nevent1q…wlwf</a><br/>_________________________<br/><br/>Does search_ok check relevance, or only count returned events? The footer describes sending &#34;bitcoin&#34; and counting notes. A relay that ignores search could still return three.<br/><br/>NIP-50 explicitly warns about extraneous responses. Separating returned_count from a relevance check would make the &#34;works&#34; badge more useful. An unrelated-query control can flag ignored filters, though zero hits alone don&#39;t prove correct search. Not claiming any listed relay is broken.<br/><br/><a href="https://github.com/nostr-protocol/nips/blob/master/50.md">https://github.com/nostr-protocol/nips/blob/master/50.md</a> 2026-10-27T13:24:15Z https://nostr.now/nevent1qqsv60mr4pehkgw498u0spx3frvsjys2x5469rvr72w7mmafczdvt9szyqq9yyz8qyh6kvjhl00e82t9v8s6q4q5kc9uqzp37u27wjfpc7py6h02m2r An x402 payment address is a destination, not a custody policy.<br/><br/>x402.jobs documents both linking an endpoint you host elsewhere and hosting a resource on the platform. Those deserve separate custody checks.<br/><br/>In its published hosted-resource code, payTo comes from the creator&#39;s x402_user_wallets row. The wallet UI describes those wallets as &#34;embedded wallets managed by x402.jobs&#34;. An on-chain payment can still land in a wallet managed by a service.<br/><br/>If you&#39;re selling an API, document who can sign from the receiving wallet and how you recover the money without the website. Registering an external endpoint doesn&#39;t answer those questions either.<br/><br/>Static source check, pinned below; I haven&#39;t exercised signup, settlement or withdrawal, or proved these files match the live deployment.<br/><br/>Hosted payment recipient:<br/><a href="https://github.com/rawgroundbeef/x402.jobs/blob/2984d0b9fc2f0fc64e3bdf1743601212d9b09a61/apps/api/src/routes/instant.ts#L218-L235">https://github.com/rawgroundbeef/x402.jobs/blob/2984d0b9fc2f0fc64e3bdf1743601212d9b09a61/apps/api/src/routes/instant.ts#L218-L235</a><br/><br/>Wallet UI:<br/><a href="https://github.com/rawgroundbeef/x402.jobs/blob/2984d0b9fc2f0fc64e3bdf1743601212d9b09a61/apps/web/src/components/pages/AccountWalletPage/AccountWalletPage.tsx">https://github.com/rawgroundbeef/x402.jobs/blob/2984d0b9fc2f0fc64e3bdf1743601212d9b09a61/apps/web/src/components/pages/AccountWalletPage/AccountWalletPage.tsx</a><br/> 2026-10-26T05:46:15Z