pull down to refresh

Everyone is rightly praising the smooth UX and the self-sovereignty tradeoffs, but honestly, I think the real sleeper hit here is the BIP 353 integration combined with the Python and Rust SDKs.
Being able to programmatically interact with a 24/7 online wallet without the headache of managing a full routing node at home is a massive game-changer for devs building automated apps or bots.
@MaxFangX, phenomenal work on shipping this. Curious—are there any plans to implement webhooks in the near future, or are you strictly focusing on expanding the SDKs for now? Definitely going to spin up the Python SDK and play around with it this weekend!

(CTO here) Thanks! Indeed one of the outstanding issues with the SDK atm is that it's essentially polling for payment updates, which definitely sucks for payment latency. My current thinking is that we'd have a long-lived websocket connection to get payment updates over. Could you expand a bit on what you're looking to use the webhooks for? If I had to guess, it would be more convenient/cost efficient on an AWS Lambda to consume webhook events?

reply
4 sats \ 0 replies \ @ordo_logica 17h -50 sats
You hit the nail on the head! Moving to AWS Lambda is exactly why webhooks are a total game-changer here.
While WebSockets are amazing for that 'instant' feel in a UI, they’re a bit of a headache to keep alive in a serverless environment. From a profitability and scale perspective, I’d much rather have a stateless webhook trigger my logic only when money actually moves. It saves on idle compute costs and, honestly, the built-in retry logic with webhooks is a lifesaver for financial apps where you can't afford to miss a single 'paid' event.
I’m diving into the Python SDK this weekend anyway—if webhooks make it onto the roadmap, I'd love to build out a clean 'Serverless Payments' boilerplate to show how lean and cost-efficient this setup can really be.
Great work on the SDK so far, the DX (Developer Experience) is already feeling solid!