Request Network, an ethereum based invoicing and payments framework, has partnered with the French chapter of Wikipedia’s Wikimedia Foundation.
“The Wikimedia Foundation is one of the first organizations that will soon allow its donors to support projects with any digital currency. It is fundamental for Wikimedia to ensure that donor payments are as simple and secure as possible.
Through a strategic partnership with the Request Network Foundation, the organization provides donors trust and transparency, while making sure donations can be made seamlessly,” they say.
Currently, requests seem to be limited to ethereum only, but they plan to expand to all ERC20 tokens, as well as bitcoin and even fiat payments.
We thought to try it out for ourselves and get a “feel” for what’s in offer as this is the second big partnership following last month’s announcement they had partnered with PwC France.
To use it, you firstly of course need MetaMask, which is just a plugin you download on Chrome, Brave or Firefox (no Safari yet). The web3 site then updates itself with your MetaMask’s ethereum address.
At which point you’re greeted with a very simple form that asks you to choose the currency (for now only eth), to state what amount you are requesting and then, if you want, to give a reason or a message.
We did so. Pressing the confirm button on the form made MetaMask ask us to confirm because the request itself is an ethereum transaction.
We have to pay for this transaction, and the initial reaction is that it looks like quite a bit in fees. However, at 11 cents, a mere tenner would take us a long way.
Once we click submit, the web3 site changes and shows us a screen that is communicating with the ethereum blockchain and keeping us informed of what’s going on.
If you notice, there’s a clickable transaction hash just below the date. That was the most exciting part for us so far, so we quickly clicked it.
That’s because we wanted to see whether etherscan says “testing” on that box below, which would mean our not well thought out message would now be recorded forever. What we see instead is:
That’s while the transaction is waiting for confirmation. Now here, we’ve made an error. Or more correctly, the Request Network has.
That’s because Etherscan was kind enough to inform us we have to wait 8 hours for a confirmation.
We wondered whether that’s sort of like the estimates you get when downloading software, says 8 hours a minute then 5 minutes the next. So we wait a bit, then MetaMask tells us this is taking too long, do we want to retry?
Yes please! We’ve obviously entered a fee that is too low. But what fee should we enter in this second transaction? We could have, at this point, gone to Eth Gas Station with a pen and paper and done the calculations, but we thought to try 40 cent instead.
What happened next, from the point of view of us pretending to be some office admin, was a bit of a mess. That second transaction kind of showed on etherscan, then it said it wasn’t found, we now don’t know whether the first transaction will work. And we don’t know what happens next.
We could have, of course, just waited, but that’s besides the point as if everything goes well then presumably we’d be told in the second address that someone requested some eth, we’d confirm and the payment would be done.
But so far it was enough to get a “feel” of what it’s like to use it, and we have a few points to make. First, this is clearly beta front-end. It has just launched last month, so it is kind of bare-bones.
Secondly, the web3 site should certainly estimate gas usage itself. There’s no way humans should be bothered with that.
Peepeth does this estimation by asking you if you want a fast transaction or if you are happy to wait, giving a general idea how long each option would take, but a dapp could choose to default to the fast option if they wished. Request Network will probably likewise do so in the near future.
Secondly, we’re not very sure why MetaMask is offering us a bump-the-fee option. It clearly didn’t work in this case, presumably because eth sticks to the first seen transaction, but MetaMask could also incorporate the time estimating options dependent on gas usage.
Most important, however, is that this test run reminds us just how useful low confirmation times can be. Obviously waiting 15 seconds is not such a huge matter, but if confirmation times can be brought down to 2 seconds that would be better.
That’s because there are other things that might slow the web3 dapp and having slower confirmation times on top might simply be too annoying for some office worker.
But little of the above detracts from the idea here, or indeed the somewhat smooth execution of the base Request Network.
Obviously it needs a bit more refinement and there will be a lot of things done to it, but when we started out we couldn’t quite see why anyone would care to use this Request thing. Yet now we think it can be quite useful.
That’s because it does appear to have a few selling points. The simplest one is that the invoice is the payment. On the surface, that sounds like nothing, but we are sure there are courts sitting right now across the country and the world hearing two parties arguing about whether an invoice was paid or not.
Here, there would be no such argument because this is in effect turning invoices from paper to natively digital, or to code. Just like with code money, that means we can now do a lot of things with these code invoices.
We can tell the smart contract how much VAT it should charge, or if it is wages, then how much should be taken out in taxes.
For a business, presumably you could tell it a lot more things, such as how much of the received payments should go into a savings account, how much for costs, and so on. There can, in fact, be an entire ecosystem:
All of this automation could then nicely be presented on the web3 front-end. So we can easily know how much money we’ve made this month, how much we’re spending, on what, where can we save, what we’re paying in taxes for all the public services we get, and so on.
Basically, if we’re going to exaggerate slightly, the front-end becomes our accountant. That’s eventually, of course, but even for now having all payments in one front-end can be useful. With the ERC20 tokens, bitcoin, and fiat, it can become more useful. With the extension layers, it could become necessary, especially for businesses.
