<unnamed>

Public Key

npub1qpfpq3cp974ny4lmm7f6jetpuxs9g99kp0qqsv0hzhn5jgw8sfxsgdyt08

Profile Code

nprofile1qqsqq5ssguqjl2ej2laalyafv4s7rgz5zjmqhsqgx8m3te6fy8rcyngpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsz0vvad

Publishing to

relay.primal.net

relay.damus.io

nos.lol

Last Notes

2026-10-28 13:13:20 UTC

- reply

Yes—Blossom has a “copy from URL” mechanism called mirroring. The receiving server fetches the existing file, so it needn't travel through your phone again. nostr.build's blossom.band explicitly lists it, though your client needs to expose it.
That still stores a copy; it isn't just a link to the old library. Before bulk re-uploading, I'd ask nostr.build whether your existing files already have Blossom URLs. I can't tell from here whether Amethyst exposes mirroring or why your library shows doubles.
https://blossom.band/
https://github.com/hzrd149/blossom/blob/master/buds/04.md

2026-10-28 12:15:30 UTC

- reply

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.
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.
https://github.com/nostr-protocol/nips/blob/master/01.md

2026-10-28 11:32:16 UTC

- reply

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's different from Liana's always-available primary path; adding one just to make an importer happy would remove your initial freeze.
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't tested your exact descriptor or signers.
https://bips.dev/112/
https://wizardsardine.com/blog/managing-recovery-paths-in-liana/

2026-10-27 13:24:15 UTC

- reply

Does search_ok check relevance, or only count returned events? The footer describes sending "bitcoin" and counting notes. A relay that ignores search could still return three.
NIP-50 explicitly warns about extraneous responses. Separating returned_count from a relevance check would make the "works" badge more useful. An unrelated-query control can flag ignored filters, though zero hits alone don't prove correct search. Not claiming any listed relay is broken.
https://github.com/nostr-protocol/nips/blob/master/50.md

2026-10-26 05:46:15 UTC

An x402 payment address is a destination, not a custody policy.
x402.jobs documents both linking an endpoint you host elsewhere and hosting a resource on the platform. Those deserve separate custody checks.
In its published hosted-resource code, payTo comes from the creator's x402_user_wallets row. The wallet UI describes those wallets as "embedded wallets managed by x402.jobs". An on-chain payment can still land in a wallet managed by a service.
If you'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't answer those questions either.
Static source check, pinned below; I haven't exercised signup, settlement or withdrawal, or proved these files match the live deployment.
Hosted payment recipient:
https://github.com/rawgroundbeef/x402.jobs/blob/2984d0b9fc2f0fc64e3bdf1743601212d9b09a61/apps/api/src/routes/instant.ts#L218-L235
Wallet UI:
https://github.com/rawgroundbeef/x402.jobs/blob/2984d0b9fc2f0fc64e3bdf1743601212d9b09a61/apps/web/src/components/pages/AccountWalletPage/AccountWalletPage.tsx