21 Makes Bitcoin Useful to Developers(21.co)
21.co
21 Makes Bitcoin Useful to Developers
https://21.co/features/
61 comments
> Any business which intends to last longer than a hackathon would get a greater long-term advantage by developing such queries in-house.
That reminds me of this challenge Heroku is currently facing (http://go.theinformation.com/884b08):
> When an app hits a certain scale, the cost of Heroku can be many times that the cost of cutting out the middlemen and running on AWS directly.
> For that reason, Heroku finds it tough to attract big companies. They know they’re going to operate at a large scale, and they’re open to taking the trouble to cut out the middleman of a Heroku if the savings are great enough.
That reminds me of this challenge Heroku is currently facing (http://go.theinformation.com/884b08):
> When an app hits a certain scale, the cost of Heroku can be many times that the cost of cutting out the middlemen and running on AWS directly.
> For that reason, Heroku finds it tough to attract big companies. They know they’re going to operate at a large scale, and they’re open to taking the trouble to cut out the middleman of a Heroku if the savings are great enough.
Isn't that why Heroku and other PAAS do custom pricing for their larger customers?
That's one possible solution, with a major challenge being that Amazon regularly cuts AWS prices (51 times as of January). Competing with Amazon is rarely a winning strategy, although Salesforce has similarly razor thin margins despite having been publicly traded for more than a decade.
I don't get it - are these just API wrappers with (more expensive) bitcoin pricing?
Correct. And it is tauted as a feature since you don't need "credit card, signup, or API key."
https://medium.com/@21/buy-50-apis-with-bitcoin-in-the-21-ma...
https://medium.com/@21/buy-50-apis-with-bitcoin-in-the-21-ma...
[deleted]
Right, but isn't it replacing that functionality with the additional need of an embedded bitcoin wallet?
The command line example in that article requires a $400 bitcoin device.
The command line example in that article requires a $400 bitcoin device.
I think you missed the one-line terminal command that installs on any linux-based device. You can get the tools set up in just a few minutes, and for free, actually.
For now, they just launched.
Right now, developing your own paid rest service is a huge pain in the ass. You have to sign up to process credit card payments / paypal, manage sales and so on.
Because of that it's possible that many people don't consider building them (and some people do it for free, but it's another matter).
If there is a simple system to charge for such services, we might soon see a situation in which there are literally thousands of available services. And it's not a choice between using CC and using Bitcoin, but a choice between using the few services that handle CCs, or a plethora of services that use bitcoin.
Because of that it's possible that many people don't consider building them (and some people do it for free, but it's another matter).
If there is a simple system to charge for such services, we might soon see a situation in which there are literally thousands of available services. And it's not a choice between using CC and using Bitcoin, but a choice between using the few services that handle CCs, or a plethora of services that use bitcoin.
I think the marketplace itself is the most interesting part. The sample APIs for sale are probably just examples they built to demonstrate usage.
The test I use to understand most "but with Bitcoin!" ideas is simple: imagine the application "but with dollars".
In this case, 21 isn't using Bitcoin is some way that makes it substantially different than what could already be done. If a person wanted to, they could create an API marketplace just like this, and charge 1 cent, or fractions of a cent, per transaction. Rather than turn your computer into a bitcoin mining botnet node, you load your account with a larger credit card payment to pay for it. Meanwhile, the marketplace collects the fees and distributes it to the various API owners' accounts, which can then be withdrawn once the account reaches some threshold, say $5.
Here, 21 is essentially doing the same thing. Although they discuss being able to do on-chain or off-chain transactions, putting a tx on the blockchain for every $0.01 zipcode lookup is completely ridiculous and the success of such an application would essentially gridlock the blockchain, so accomplishing these types of micropayments has to be done off-chain. They're ultimately acting as a middle man between payer and payee, just like most fiat marketplaces are.
21's strategy doesn't seem terrible if you make a lot of assumptions about what role Bitcoin will play in our future. I personally think they're substantially off-base and that a world where devices have to constantly mine Bitcoin and send and receive micropayments to accomplish trivial things seems like more of a burden than a benefit.
I should also say that you have to think quite a bit about what 21 is doing and make a lot of additional assumptions on their end in order to even say their strategy looks good. So far, they've released a very expensive Raspberry Pi with a hideous miner attached to it and this API marketplace where their featured API is a $0.01 zipcode lookup. I've been working on a side-project that requires me to do lookups on zipcode data and it took me all of 10 minutes to download that for free from the internet and drop it into a database. I get that they're trying to ship, but why no ship with something people would actually want to use?
In this case, 21 isn't using Bitcoin is some way that makes it substantially different than what could already be done. If a person wanted to, they could create an API marketplace just like this, and charge 1 cent, or fractions of a cent, per transaction. Rather than turn your computer into a bitcoin mining botnet node, you load your account with a larger credit card payment to pay for it. Meanwhile, the marketplace collects the fees and distributes it to the various API owners' accounts, which can then be withdrawn once the account reaches some threshold, say $5.
Here, 21 is essentially doing the same thing. Although they discuss being able to do on-chain or off-chain transactions, putting a tx on the blockchain for every $0.01 zipcode lookup is completely ridiculous and the success of such an application would essentially gridlock the blockchain, so accomplishing these types of micropayments has to be done off-chain. They're ultimately acting as a middle man between payer and payee, just like most fiat marketplaces are.
21's strategy doesn't seem terrible if you make a lot of assumptions about what role Bitcoin will play in our future. I personally think they're substantially off-base and that a world where devices have to constantly mine Bitcoin and send and receive micropayments to accomplish trivial things seems like more of a burden than a benefit.
I should also say that you have to think quite a bit about what 21 is doing and make a lot of additional assumptions on their end in order to even say their strategy looks good. So far, they've released a very expensive Raspberry Pi with a hideous miner attached to it and this API marketplace where their featured API is a $0.01 zipcode lookup. I've been working on a side-project that requires me to do lookups on zipcode data and it took me all of 10 minutes to download that for free from the internet and drop it into a database. I get that they're trying to ship, but why no ship with something people would actually want to use?
I've been talking about hooking cryptocurrencies up to APIs for a few years now. Today's startup business models are coarse to the point of being stupid. Worse, mistakes in the model cause user suffering later when pricing has to be implemented to take the company profitable.
Pay attention to these types of offerings that hook revenue up directly to code. They are the future of software development and "self hosting" of applications. I also think they will have far reaching implications on the more traditional VC startup models.
Pay attention to these types of offerings that hook revenue up directly to code. They are the future of software development and "self hosting" of applications. I also think they will have far reaching implications on the more traditional VC startup models.
Pay attention to these types of offerings that hook revenue up directly to code. They are the future of software development and "self hosting" of applications.
The problem with any "per query" cost is that it's inherently scary due to it's unpredictability - founders end up worrying about covering costs if they grow faster than they can build revenue. Using a service that charges a fixed, predictable amount is more attractive because you can sign up and just forget about it (to an extent).
The problem with any "per query" cost is that it's inherently scary due to it's unpredictability - founders end up worrying about covering costs if they grow faster than they can build revenue. Using a service that charges a fixed, predictable amount is more attractive because you can sign up and just forget about it (to an extent).
Well that depends. If you are operating under the same business model it's not scary at all. Say you need 3 calls to external apis to produce one api reply that you can sell. You just have to make sure that the total cost for the 3 calls is lower than what you earn when you sell a reply.
There could be another company that is in the business of risk management. It could sell unlimited or quotad amounts of api calls for a fixed price. There is no reason for these two to be the same company.
There could be another company that is in the business of risk management. It could sell unlimited or quotad amounts of api calls for a fixed price. There is no reason for these two to be the same company.
> If you are operating under the same business model it's not scary at all.
Total hogwash! It's super scary. Variable costs are something you keep to an absolute minimum in a business. A fixed price API (at least for a certain number of calls) is attractive precisely because it is not taking a chunk off your top line.
You want fixed costs to be low as well, but at least your revenue can grow independently so marginal costs decrease with each additional dollar you earn.
> It could sell unlimited or quotad amounts of api calls for a fixed price.
If you are an API provider, it is a great deal to offer fixed pricing. First, you have a more predictable line of revenue. Second, if you are a small player, you are not as exposed to fluctuations in demand. For the latter case, that means you don't need a lot of cash on hand to even out cash flow issues.
> There is no reason for these two to be the same company.
This is a classic middleman business. As the API provider, you need to make sure this does not happen, unless you are having serious sales problems. You'll just get the squeeze as the middleman eats your margin.
Total hogwash! It's super scary. Variable costs are something you keep to an absolute minimum in a business. A fixed price API (at least for a certain number of calls) is attractive precisely because it is not taking a chunk off your top line.
You want fixed costs to be low as well, but at least your revenue can grow independently so marginal costs decrease with each additional dollar you earn.
> It could sell unlimited or quotad amounts of api calls for a fixed price.
If you are an API provider, it is a great deal to offer fixed pricing. First, you have a more predictable line of revenue. Second, if you are a small player, you are not as exposed to fluctuations in demand. For the latter case, that means you don't need a lot of cash on hand to even out cash flow issues.
> There is no reason for these two to be the same company.
This is a classic middleman business. As the API provider, you need to make sure this does not happen, unless you are having serious sales problems. You'll just get the squeeze as the middleman eats your margin.
Variable costs are scary, but they are scary because they may change at a future date, not because they are variable. With a cryptocurrency backed API call, you can enter into contracts over variable periods of time to lock in price. This will give consumers of the API calls a way to predict costs moving forward. It essentially builds a futures market framework as well, and that's pretty well known to us by now. We can manage it with existing toolsets.
> Variable costs are scary, but they are scary because they may change at a future date, not because they are variable.
Pretty sure you are thinking of variable pricing. Variable costs are different. From Wikipedia: "Variable costs are costs that change in proportion to the good or service that a business produces." https://en.wikipedia.org/wiki/Variable_cost
Pretty sure you are thinking of variable pricing. Variable costs are different. From Wikipedia: "Variable costs are costs that change in proportion to the good or service that a business produces." https://en.wikipedia.org/wiki/Variable_cost
Do you think this business model has to necessarily use bitcoin as the vehicle?
It's much more difficult - if not impossible - with credit cards. With CCs you need to trust the receiver to not steal your cc details, and you have a chargeback risk.
Say you created an API that takes users' data and stores it on S3. Some random user then comes, pays you $10k to store his data, but a week later does a chargeback. You're left to pay the costs to AWS.
Finally, with CCs you need to strike deals with payment processors like Braintree. If you're a private developer it will be impossible. But even as a company - payment processors are not ready to process payments via command line. They will ask you where your terms of service are, what's your website, what's your refund policy and so on.
Say you created an API that takes users' data and stores it on S3. Some random user then comes, pays you $10k to store his data, but a week later does a chargeback. You're left to pay the costs to AWS.
Finally, with CCs you need to strike deals with payment processors like Braintree. If you're a private developer it will be impossible. But even as a company - payment processors are not ready to process payments via command line. They will ask you where your terms of service are, what's your website, what's your refund policy and so on.
The corollary is that you consume an API that charges you Bitcoin. You don't notice right away, but something goes wrong, and API returns bad or null data for thousands of requests, meanwhile you are still micropaying Bitcoin. You ask for a refund, but the company running the API doesn't respond to your emails.
The threat of chargebacks disciplines the market to provide reasonable customer service.
The threat of chargebacks disciplines the market to provide reasonable customer service.
This is why we'll be using ACs to pay for things. Load up an autonomous corporation with $5, make its job paying for API calls. If something goes South, it's last job is to pay an alert mechanism that triggers a human response.
These models turn existing models on their heads, so be aware of other pitfalls. Productive paranoia is good, but only practice it after you innovate first.
These models turn existing models on their heads, so be aware of other pitfalls. Productive paranoia is good, but only practice it after you innovate first.
The short answer is: No. I don't see how Bitcoin fits into IoT. We are working on the exact same usecase at IOTA (http://iotatoken.com), only our solution is scalable, lightweight and most importantly: there are no transaction fees.
If you have some reference code for IOTA, I'd like to see it. I'm firmly against any type of closed source Infrastructure code, so I'm hoping that's the plan here. I would also mention that we're not QUITE there yet with this stuff, so over engineering solutions to be scalable to trillions of devices is probably overkill. Giving a simple IOT device a small wallet to pay for its infrequent API calls is probably doable with Bitcoin, even with transaction costs. For other use cases, I can envision proxy devices with keys that represent the smaller, low power, frequent transmissions.
Any cryptocurrency will do, but it obviously requires the customer be wired up to send you the transactions. I have several models kicking around in my head for when we're going to need it. You may want to check out Bitcoin's microtransaction support. As you mention below, Ethereum may be a good candidate for this as well, given it can auto post transactions at a certain date.
What else would it use? USD doesn't have it's own online transaction rails. You need a 3rd party to do that. Which requires a boatload of arbitrary fees.
Not sure -- I was asking in earnest (although competing cc's like ethereum come to mind). Just wondering if there is not a way to hook up payments to APIs using existing infrastructure and currencies.
"21 is free software that implements the Payment Required HTTP status code and much more besides. It makes it easy to (a) send and receive micropayments over HTTP and to (b) write new kinds of programs that use this basic technology as an intrinsic primitive, like machine-payable APIs and intelligent agents."
"Free software": I don't see a GitHub repo. And they have non-free terms of use. The admin should use a better word, like gratis, to describe a proprietary service.
They're only required to deliver source to anyone they give a binary to. Having a "github repo" isn't any part of the open source/free software definition.
Unless I am misunderstanding how Bitcoin works, doesn't this make the whole Bitcoin mechanism a bit centralized since every transaction would have to go through the 21.co servers?
Yes (though unlike traditional third party intermediaries, there is no third party custodian for money you receive, meaning you don't have to trust 21 to not steal/freeze funds you've received). The innovative component of this that Bitcoin brings to the table is that the payment system linking the users to the developers is open/non-proprietary, with no registration walls encumbering usage.
I don't know how 21 actually works but it could be built in a way that the example code on their home page works without ever talking to their servers. That could code manage the transaction directly with the block chain.
Similar to the internet and AOL in the late 90's..
Let me see if I have this right, using an example we all know:
1. Build Twitter
2. Gain critical mass[1]
3. Place APIs behind Bitcoin transaction[2]
4. Actually have a revenue model and be (maybe one day) profitable, without ever having to sell your users to advertisers?
5. Let others build whatever they like atop your platform without ever being bothered about it threatening your core business?
What have I missed?
Edit: formatting & footnotes
---
[1]: or don't wait, and start that way so it's not a surprise to people later
[2]: perhaps swap(2,3)
1. Build Twitter
2. Gain critical mass[1]
3. Place APIs behind Bitcoin transaction[2]
4. Actually have a revenue model and be (maybe one day) profitable, without ever having to sell your users to advertisers?
5. Let others build whatever they like atop your platform without ever being bothered about it threatening your core business?
What have I missed?
Edit: formatting & footnotes
---
[1]: or don't wait, and start that way so it's not a surprise to people later
[2]: perhaps swap(2,3)
Charging for API usage isn't as profitable as selling your users to advertisers. Otherwise twitter would already be living just off of selling the firehose.
First version of Twitter's API had no authentication, it was as free and open as it can get, so it got integrated everywhere. Everyone without technical knowledge could copy and paste a snippet into their WP powered blog or website, deploy it and enjoy the functionality. I think that was one of the primary driving forces behind Twitter's growth. Putting an API behind a paywall basically eliminates the majority of Average Joe's
Maybe not as profitable, but that seems to be a tangential issue. Just trying to understand what's being proposed here.
Problem is that when you sell your users to advertisers, it's reducing the value of your service in the users mind.
I value websites with heavy advertising to be less attractive to me and less valuable. As more users get turned off, the websites will be able to get less money from advertisers.
It can become a snowball effect that kills a service.
I value websites with heavy advertising to be less attractive to me and less valuable. As more users get turned off, the websites will be able to get less money from advertisers.
It can become a snowball effect that kills a service.
Most engineers and software developers don't click on ads or use advertising mediums [1]. Other user segments are less bothered by them.
https://medium.com/@robleathern/people-in-silicon-valley-don...
https://medium.com/@robleathern/people-in-silicon-valley-don...
Semi-related question:
What makes this more attractive, friendlier, and/or plausible than building a service whereby your users—that is, developers—place a CC on file (via Stripe or whatever), and then just charge them by total monthly API requests in one bill?
What makes this more attractive, friendlier, and/or plausible than building a service whereby your users—that is, developers—place a CC on file (via Stripe or whatever), and then just charge them by total monthly API requests in one bill?
One benefit of 21's API billing model is lower transaction fees. If the dev only uses $2 of API fees, using a service like Stripe would eat up 18% of the income.
Another benefit is that when you do net-30 usage based billing, you always have to be concerned that the card might be maxed out or invalid by the time the bill gets charged. With 21, you can be sure that the bill will get paid since the Bitcoin is locked up in escrow until the transaction is processed.
Another benefit is that when you do net-30 usage based billing, you always have to be concerned that the card might be maxed out or invalid by the time the bill gets charged. With 21, you can be sure that the bill will get paid since the Bitcoin is locked up in escrow until the transaction is processed.
You could always have them pay up front, which is what pretty much all telephony services like Twilio do, as fraud is high in that market. You could even have them pay up front with Bitcoin to avoid the CC fees.
Good point. Wasn't thinking about fees. Thanks.
With Bitcoin and 21 you can set up payments within hours, if not minutes.
If you wanted to set up a traditional CC, you'd need to write the whole billing and tracking system, and so on. Managing all this is cost-prohibitive for smaller solutions.
Oh, and with CCs there are chargebacks, so you can never be sure that the money will actually arrive on your account. This virtually rules out any kinds of services where it costs you real money to run. E.g. if you want to create mechanical-turk API, good luck. Someone will pay with a stolen CC, ramp up $10k in bills, and then do a chargeback.
If you wanted to set up a traditional CC, you'd need to write the whole billing and tracking system, and so on. Managing all this is cost-prohibitive for smaller solutions.
Oh, and with CCs there are chargebacks, so you can never be sure that the money will actually arrive on your account. This virtually rules out any kinds of services where it costs you real money to run. E.g. if you want to create mechanical-turk API, good luck. Someone will pay with a stolen CC, ramp up $10k in bills, and then do a chargeback.
Come on now. I specifically mention via Stripe, so suggesting a developer would have to write a billing and tracking system is a bit analogous to someone saying Stripe is better than 21 because a dev would have to write the whole of what 21 provides. Stripe is awfully quick to setup in many cases.
That said, your point about chargebacks is certainly a good one.
That said, your point about chargebacks is certainly a good one.
It's not so hard with gateways like braintree or stripe actually. If you have the experience, you can do it in hours / minutes. The other part is fraud prevention, which IMO is a more complicated problem per se.
There's some interesting APIs in the market like a Captcha solver for example. I could see that getting used. So I guess the blackhat market will get covered pretty quickly.
How, seriously?
Weird that the code uses 'two1', but the domain is 21.co and they have not registered two1.co...
Python module names cannot start with a number.
I know, this is true for more languages; just makes for a bad branding choice/planning.
How do I get the Bitcoin?
Either you own 21's embedded Bitcoin device which can mine Bitcoins itself or you buy them from one of the myriad of exchanges.
http://circle.com or http://coinbase.com for instance.
Also, "The easiest but most limited way to get some bitcoin with 21 is to run 21 faucet, which gives you a small amount of bitcoin to play with."
http://circle.com or http://coinbase.com for instance.
Also, "The easiest but most limited way to get some bitcoin with 21 is to run 21 faucet, which gives you a small amount of bitcoin to play with."
This service actually comes with a way to get bitcoins for "free" or mine with their hardware.
"The easiest but most limited way to get some bitcoin with 21 is to run 21 faucet, which gives you a small amount of bitcoin to play with."
https://21.co/learn/intro-to-21/#21-faucet-get-bitcoin-from-...
"The easiest but most limited way to get some bitcoin with 21 is to run 21 faucet, which gives you a small amount of bitcoin to play with."
https://21.co/learn/intro-to-21/#21-faucet-get-bitcoin-from-...
Coinbase.com, Bitmarket.net, Kraken.com to name a few exchanges.
Also, http://www.reddit.com/r/btc is a nice bitcoin community.
Also, http://www.reddit.com/r/btc is a nice bitcoin community.
Alternative opinion: /r/btc is full of cranks and conspiracy-theory credulists.
These guys are clearly flailing at this point.
Any business which intends to last longer than a hackathon would get a greater long-term advantage by developing such queries in-house. And most of those example APIs are available for free from IBM Watson/AlchemyAPI/Open Source anyways.