5 ms·

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,

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.

doctorcroc 10y ago
Do you think this business model has to necessarily use bitcoin as the vehicle?
- paavokoya 10y ago
  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.
  - doctorcroc 10y ago
    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.
- domsch 10y ago
  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 http://iotatoken.com), only our solution is scalable, lightweight and most importantly: there are no transaction fees.
  - kordless 10y ago
    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.
- kolinko 10y ago
  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.
  - krrrh 10y ago
    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.
    - kordless 10y ago
      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.
- kordless 10y ago
  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.
onion2k 10y ago
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).
- clemensley 10y ago
  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.
  - danielrhodes 10y ago
    > 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.

doctorcroc 10y ago

Do you think this business model has to necessarily use bitcoin as the vehicle?

paavokoya 10y ago
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.
- doctorcroc 10y ago
  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.
domsch 10y ago
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 http://iotatoken.com), only our solution is scalable, lightweight and most importantly: there are no transaction fees.
- kordless 10y ago
  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.
kolinko 10y ago
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.
- krrrh 10y ago
  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.
  - kordless 10y ago
    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.
kordless 10y ago
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.

onion2k 10y ago

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).

clemensley 10y ago
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.
- danielrhodes 10y ago
  > 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.