What is an API and what is the whole point of a public blockchain?
A few days ago I posted about the new API I've released allowing Dapp devs especially on Hive to accept ⚡️Lightning payments in the simplest way I can imagine.
I realise when I post on technical topics like a new API (which stands for Application Programming Interface) I have a mix of audiences reading, some of whom see this as gobbledegook and their eyes glaze over. So this is a bit of a higher level explanation.
What is an API?
An Application Programming Interface is an agreed way in which different computers can talk to each other. One system asks a question, the API returns an answer.
What I released this week is an easy peasy (if you're a developer) way for the other developer's program to ask my program for a ⚡️Lightning Invoice and get it.
What is a ⚡️Lightning Invoice
At it's heart a lightning invoice is just a string of letters and numbers. It looks like this:
lnbc50300n1p3wplg5pp5kwxt0z6jyza2l7k83dj80cgfy4yzhvsn4vkal8qyl96da20c9ftsd9yvfexjctwdanxcmmwv3hkugruypsku7fqd4jhxumpvajjqem0v4ejq6r9wfjjqlpqyd242j2yypnrwe3exsckxwpdxfjnzdfdxscxvved8qur2dfd8ycnzenyxqukydpsvs6zqg6rf3z5zn3qydyyy3pqydmrganpwpcqcqzpgxqzfvrzjqv993wr985etnysq5ge5el538egaclg4t2spzmqhvet6futjyem6xz6gmgqqnkcqqyqqqqlgqqqqqqgq9qsp5jzxvdzqmyck9tuc9pxa4a286d3qp5xwexmh8chv4ddp6zusqem6q9qyyssqvmlr7xju9q6ngu7kvyuwmraw5nteghcu5lsz83wggsvarlr035eph3kw95dxttw0496uqct7v37v9scycjnyyanlwn9llxvtucpvg2gp3tw4zz
And because it looks like that crazy thing on the left, we usually convert them into the now familiar QR Codes. The other Developer using my API will have to show that invoice to their users somehow.
What does my API do?
I give Hive Dapp devs a way to request a ⚡️Lightning Invoice which is valid for up to 10 minutes only. The developer just has to specify a few things:
- The Hive account name where the funds will go if the invoice is paid
- The amount they want in either Hive, HBD or even USD.
- A message to be sent along with the transfer
- The name of the app asking for this invoice (this is mostly for me to keep track of things in the background).
- Expiry time up to 10 mins (600s)
All of that can turn into the following GET Request which is simply the way the other computer program talks to my API server:
curl -X 'GET' \ 'https://api.v4v.app/v1/new_invoice_hive?hive_accname=brianoflondon&amount=1¤cy=USD&usd_hbd=true&app_name=peakd_demo&expiry=300&message=any%20message%20goes%20here&qr_code=base64%20png' \ -H 'accept: application/json'
Behind the scenes it is the infrastructure which I've built for @v4vapp which will watch to see if that ⚡️Lightning Invoice is paid and, if and when it is, make a transfer of the correct amount of Hive or HBD to the correct account with the correct message.
BTW that message is very important: if you're paying for a basket of goods, the message would allow the other Dapp's computer program to identify exactly which shopping basket was just paid for!
What about the blockchain?
This brings me to the point about blockchains.
When I posted about the API, someone asked if my API server could perhaps send a notification back when the invoice is paid. There are various ways to do this on the old web: I could send an email or use something called a Webhook. This is actually how the legacy credit card payment processors operate.
But this is kind of missing the point of what makes a public blockchain like Hive so powerful and radically different from private closed systems.
I ALREADY do send a message! The Payment IS the message. The Hive Transfer I send arrives within 3s of a Lightning invoice being paid. It contains the correct message and once I've sent it, there's no way I can take it back.
So it would be completely redundant for me to build ANOTHER inferior system for sending a reply just to tell the other program that funds were received. What if my program just faked these? I could easily do that.
The point here is that any Dapp developer working with programmable money on a public blockchain like Hive needs to treat that public blockchain as their source of truth: the only authoritative system where you can learn that a payment has been made.
Slow vs Quick
This is the reason why paying for goods and services with Bitcoin on the main Bitcoin blockchain is not feasible for most things! 10 minutes between blocks and the lottery of which block a transaction will get in, make it way too slow for checkout. We don't have this problem on Hive.
⚡️Lightning has a different issue: Lightning payments are all private. Only the receiver and the sender know that a payment has happened so there is no notion of a public way to check if a payment goes through. This is one of the key functions my Lightning to Hive Bridge performs.
⚡️Lightning payments are very well suited to the web. I firmly believe that it can become a widely used system. However receiving ⚡️Lightning is more challenging. That is why the @v4vapp service over Hive could well become something much bigger than it is today.
I believe with this initiative the lightning payment is a good idea in making transaction more easier and faster.
Thanks for sharing @brianoflondon
That's a great dumbed down explanation for non-devs. Thanks a lot, Brian for going one step ahead in explaining the value of your work. Cheers! @v4vapp is one of the best things that happened to HIVE.
I have learned today from you. The payment is the message, this is the guarantee of delivery of payment. It's on Blockchain so it's the truth !
It great explanation and I have learned something new today as low-level programmer. The lightning transaction on web will be well encourage.
Thanks for sharing @brianoflondon
Congratulations @brianoflondon! You received a personal badge!
You can view your badges on your board and compare yourself to others in the Ranking
I totally love @v4vapp! I cannot say enough good things about it LOL!
In the US at least, @v4vapp is one of the easiest (and actually least expensive) ways to fund a new Hive account! It's also the fastest! Not for huge amounts of money of course, but to show a new user how to get $3, $5, or $10 moved over to their new account real fast, this is it!!!
I know that's not what it was originally designed for, but it works great for it anyway!! I've hunted up, down, sideways, all over, and with CashApp adding the ability to pay Lightening invoices a while back, this is just so easy for a new user to understand. It's also near instant gratification, which is what makes it so great!
Love it!! Do you have t-shirts yet? I want one!
APIs are the core of any app and bridge the data acting as an interface to it. This way you control what you want to expose and give just the needed nodes to work with. Great to see this API for the Lightning Invoice!
Posted Using LeoFinance Beta
I love the idea behind it.
I would love more if keychain added the QR scan itself to pay fast with HBD and Hive with a smartphone.
The combination of both could be a cheap and good working payment processor nobody else have.
That can be used :D
It's not ideal but this does work: use the in app browser in Hive KeyChain app to load v4v.app
The camera works and you can send hive directly.
I know, it's more about that's something I want to see in keychain too! But @stoodkev already knows because i multiple times comment with it :D
Btw, i love hive can use bitcoin without smart contracts onchain :D
It's coded already, coming in a few days ;p
Transfers - Delegations - Witness - Proxy supported so far =)
bro this is gold pure, i dont know programing things like this until but i would like learn more, right now i have a few problems, i dont know how refresh the web after delete a msg from DB like gmail or hotmail do it; the other is if i have to learn php or keep doing the things like i know :D
Guilty! 😄🤚
My suggestion was more so that legacy systems (or a small online shop) could easily integrate with your solution without having to do all the "scary black magic stuff" of scanning the blocks of a blockchain.
The issue here is that even witnesses miss blocks, so that could happen also to a gaming NFTs marketplace (🤚) scanning the chain to know when a lightening payment was made with your system.
When I'll integrate your awesome service, in my mind I would have used both solutions, the notifications one and the blocks scanning one. And used yours as primary or fallback mechanism to know that some payment was made.
I agree though that it defo should not be a core feature. If the block with the payment was missed, the seller will most likely contact the seller with the receipt (the Hive transaction ID) to get it sorted like it happens in the old web.
That's why I suggested that your API would append to the webhook the Hive block number in which the payment was made. In that way the backend of the seller would do a simple fetch of that block to verify the payment.
And it would be on the backend of the seller to discard duplicated notifications (eg. order-id & block number in a database). (hey, I'm @keys-defender after all 🤓)
So, to iterate, I fully agree that it should not be the responsibility of your system, just a nice-to-have addition that should not be fully relied on.
You would have to implement a queues solution on your side (RabbitMQ, ActiveMQ, etc) with caching policies, auto-restore of the queues, TTL for the packets, error queues, retry policy, dead letter policy and all that.
So it would add significant workload on your system, that you would need to keep on your infrastructure and maintain.. rather than letting the distributed network (Hive) do its job.
Maybe the webhook solution could work for example as a discord notification "hey, this guy just paid X HIVE for this NFT. The payment is in block 65486761"
Keep up the good work! 🔥
PS. no need to scan blocks and fear missing one, the seller backend could just use the Hive apis (and rotate nodes in case of errors) to poll the receiver hive account for the last transactions ✔️
Witnesses "missing blocks" isn't quite the same thing as not catching a transaction in real time. The Python I posted on the other thread hasn't missed a single transaction in around a year.
I do need to document my code and release it and that is what I'm working on but this is the basics of what my code does to watch for incoming Hive payments (the ones I turn into Lightning.
transferoperation and if @v4vapp is either receiving or sending, my code fires (via an internal API call to a completely separate program).If you've never really worked with Hive it can be hard to understand how efficient and quick this process actually is.
For example I just restarted my dev server which has been turned off for 12 hours and it's catching up with the chain:
It's chugging through 850 blocks or so in 12 seconds. And this is running in debug on my Mac at home. And now it's caught up in the time it took me to copy paste and write that. 4 mins to process 12 hours of Hive. Simply fantastic.
Compared to the complexity of queues and all the other stuff legacy non-blockchain payment systems need this is delightfully elegant.
And Finally
It would actually be an architectural nightmare for me as I have completely separated the financially delicate parts of the system, the ones which control Lightning and Hive payments, from the API and web side. So the part of the system which receives an incoming Lightning payment has no way of communicating with the part which generates the public API. This is by design!
Great stuff! It looks like you built a solid system and I had no doubt about that 💪
Oh, I know. You probably missed the small text above.. 😄
And yes, in my scanners I do something similar to what you're doing (store block number every X blocks in order to be able to reboot painlessly, cold scan after reboot, scan backwards, etc)
What about micro forks, would those cause issues? I was talking to the guy that designed HAF and he said they tend to happen more than people think.
What if, for example, you lost connectivity for a bunch of seconds? I assume some bells ring and those blocks then get re-processed separately?
Otherwise the process could go on, record the latest block number processed, etc.
It looks like you're system is quite resilient. I was wondering myself in that past if it would make sense to consume blocks and queue them in a message broker as single packets to make sure that ALL were processed. That's because something could go wrong while the message is passed through the various processes. And having rings bells is good but in many cases would still require manual intervention (ergo delays).
Now don't I feel silly!
In addition, while working with someone who is actually having a go at using the API I remembered I've already implemented what you need!
https://api.v4v.app/docs#/v4vapp/check_invoice_v1_check_invoice__payment_hash__get
I forgot that I already use this call in my JS to display a big green tick over an invoice if it is paid.
That takes in a payment_hash field which is returned by the original call and you can poll that every 15s or something similar to get back a response like:
I need to add this detail to the original post!
Noice! 🙌
I feel seen! 👀
Thank you for this "plain english" version for those of us who are less code savvy than the average dev.
P.S. It's good to see you back.
😉🤙 great spanation. I can understand clearly! good work!
Congratulations @brianoflondon!
You raised your level and are now an Orca!
Few people value their goods/services in HIVE. Most value them in USD. Those who are fine with valuing them in HBD are just ignorant of the issues/risks.
Can you elaborate on the "I want 3.99 USD" option? Does that auto-assume I want $3.99 worth of HIVE?