@PlebQR your service is a fantastic idea! I just vibe coded on Claude a draft of PlebDCA, a bot that would let you set a daily amount of Sats to acquire and go out and scan and pay the fiat bills until the limit is reached. This is basically an unstoppable exchange with no market makers and no kyc! It would be great to build something like this via a PlebQR API =)

Claude

PlebDCA: Automated Bitcoin DCA Bot for Thai Merchants

Automate Bitcoin dollar-cost averaging through PlebQR. Set daily THB budgets, auto-accept orders from Thai merchants, and earn sats while staying w...

Thanks for the great call @david @Jon Gordon @Vitor Pamplona @Avi Burra and everyone else present! #wotathon I had a question I was trying to put together at the end of the call but couldn't formulate it fast enough during the live call, I'll write it here: In the context of the Nostr "flat space of encrypted signed notes" is there ever a need for a universal time based source of trust? Meaning since anybody could spoof a note "created_at" field I guess the current spam protection is set on the individual relays filtering capabilities? If the relays are filtering the notes based on the current time when processing it the whole system seems to be very dynamic and maybe this is good enough but I'm not sure about how solid or fragile such system could be. I've been thinking about this in terms of creating a "universal id" that would not require a domain name (because DNS is a centralized service) but instead having just a handle like for example '@fabio' and that handle could simply be everything needed for someone to have their "universal id", meaning that would be all that is needed to link to an npub/nsec pair. The only way I can wrap my head for solving this in a truly decentralized way would be to use a chronological source of truth with a first come first served logic like this: 1) A foundational layer with a "timechain" record (think for instance at a hash in the OP_RETURN field of a Bitcoin transaction) (no need to get into the Knots vs Core debate on this one because the original 80 bytes would suffice for a hash 🙂 ) 2) A layer of "federated relays" acting as a cache so the amount of timechain or blockchain transactions would be minimal, like let's say just once every 24 hours. In this way it would always be possible to have a proof of authority from history with a chronological first come first served logic that would be written in stone and always verifiable forever. Would this be something useful or am I missing something and this is already a non issue with the Nostr relays ecosystem? Thank you, Fabio

Amazing how Cloudflare just became The Internet's single point of failure.

"Some people grumble that roses have thorns, I am grateful that thorns have roses" - St. John The Baptist