Live data from Hacker News

Show HN: Crowsnest – API for the Real World

crowsnest.io

31–39 of 39 posts

Re: Show HN: Crowsnest – API for the Real World

#31

Can someone clarify the value-add? Is it a polyfill for APIs? If the device already has an HTTP interface over the network, I don't know if it makes sense to pay per device for translation of your API calls... Also, this kind of thing, I would hope was free -- working towards adoption of a standard (i.e. if you make a jquery-level standard that unified so much functionality, at some point, people will forget the sema…

Not exactly polyfill, although the idea is related.

Crowsnest is trying to help reduce boilerplate for IoT / device-driven applications. Crowsnest provides cloud infrastructure, two-way communication with your devices that works across a NAT, and an ecosystem of plugins for devices that will work out of the box. Interacting with all of this is abstracted into an API where all you need to know is that "it is a light" and you can use the cloud API to "turn it on." Crowsnest takes care of the NAT traversal and the actual calls to the light on the local network, so that you can focus on building your application, rather than maintaining device infrastructure and integration.

As pointed out in another comment, it's hard to compete with existing standards, but we hope to act as a super set as much as we can, making use of existing standards in our implementation.

Re: Show HN: Crowsnest – API for the Real World

#32

Can someone clarify the value-add? Is it a polyfill for APIs? If the device already has an HTTP interface over the network, I don't know if it makes sense to pay per device for translation of your API calls... Also, this kind of thing, I would hope was free -- working towards adoption of a standard (i.e. if you make a jquery-level standard that unified so much functionality, at some point, people will forget the sema…

Not exactly polyfill, although the idea is related. Crowsnest is trying to help reduce boilerplate for IoT / device-driven applications. Crowsnest provides cloud infrastructure, two-way communication with your devices that works across a NAT, and an ecosystem of plugins for devices that will work out of the box. Interacting with all of this is abstracted into an API where all you need to know is that "it is a light"…

Thanks for the clarification

Re: Show HN: Crowsnest – API for the Real World

#33
post #24
post #23

are they charging $5 per device connected to the RPi, or per RPi? Is it monthly? Website is not clear at all.

We're currently charging $5 device per month that you've registered through the RPi. The first two devices are free. Granted, we're still getting a feel for what our pricing structure should be, do you have any feedback about our pricing structure currently?

So, if I built out 10 RPi based thermometers, that would be $40/month just to get a quick API?

If I added a humidity sensor, that would add another $50/month?

That's pretty steep. Granted, you could be targeting corporate and this starts to make some sense. That kind of pricing really does make it impractical for home users. You're already targeting an audience with some tech savvy and it doesn't take much to write a Python app to serve an API.

Re: Show HN: Crowsnest – API for the Real World

#34
post #5

I don't get it. API (i.e. standardization; XKCD #927 issues aside) part is understandable - except it's not really a standard at this point. But… why would one need an intermediate party who would merely act as a proxy? Or I'm not understanding what kind of service Crownest provides? Intro pages are quite scarce on real technical details on how the whole thing works under the hood. Sorry for skepticism, but I'd say i…

Sorry for skepticism, but I'd say it's certainly a better to invest the same money in making the same RPi (or alike device(s)) globally-addressable and accessible from the Internet. That's a nice idea, but unless you control the network - and if you're deploying devices for other people, you probably don't - it's just not feasible. You'll have layers of NAT and firewalls preventing it.

This certainly was an issue in early days of P2P, but I thought it was already solved for good.

Doesn't P2P works nearly literally everywhere nowadays and aren't there loads of NAT-piercing and/or tunneling libraries that Just Work™? (Well, possibly, unless put behind some truly abysmal corporate firewalls where even plain outgoing HTTP isn't working all the time — but that would be another story.)

Re: Show HN: Crowsnest – API for the Real World

#35
post #24

Earlier quoted context omitted.

We're currently charging $5 device per month that you've registered through the RPi. The first two devices are free. Granted, we're still getting a feel for what our pricing structure should be, do you have any feedback about our pricing structure currently?

So, if I built out 10 RPi based thermometers, that would be $40/month just to get a quick API? If I added a humidity sensor, that would add another $50/month? That's pretty steep. Granted, you could be targeting corporate and this starts to make some sense. That kind of pricing really does make it impractical for home users. You're already targeting an audience with some tech savvy and it doesn't take much to write a…

Thanks, this is great feedback. We are considering a community tier of pricing aimed more at hobbyists to suit what you're talking about. We're currently targeting startups who are building creative IoT apps and want to iterate quickly and for whom enterprise platforms don't make sense. We're trying to help them move as fast as possible while they optimize their product/market fit.

Re: Show HN: Crowsnest – API for the Real World

#36

Earlier quoted context omitted.

Sorry for skepticism, but I'd say it's certainly a better to invest the same money in making the same RPi (or alike device(s)) globally-addressable and accessible from the Internet. That's a nice idea, but unless you control the network - and if you're deploying devices for other people, you probably don't - it's just not feasible. You'll have layers of NAT and firewalls preventing it.

This certainly was an issue in early days of P2P, but I thought it was already solved for good. Doesn't P2P works nearly literally everywhere nowadays and aren't there loads of NAT-piercing and/or tunneling libraries that Just Work™? (Well, possibly, unless put behind some truly abysmal corporate firewalls where even plain outgoing HTTP isn't working all the time — but that would be another story.)

Indeed, NAT-piercing isn't new or even revolutionary. It's a small feature of our mission to make building IoT apps as painless and fast as possible.

Our main goal is to build an ecosystem of ready-to-use devices and a RESTful API around this ecosystem so devs can focus on building their awesome IoT application, rather than bothering with the infrastructure. This is a component of that effort.

Re: Show HN: Crowsnest – API for the Real World

#37

Earlier quoted context omitted.

Sorry for skepticism, but I'd say it's certainly a better to invest the same money in making the same RPi (or alike device(s)) globally-addressable and accessible from the Internet. That's a nice idea, but unless you control the network - and if you're deploying devices for other people, you probably don't - it's just not feasible. You'll have layers of NAT and firewalls preventing it.

This certainly was an issue in early days of P2P, but I thought it was already solved for good. Doesn't P2P works nearly literally everywhere nowadays and aren't there loads of NAT-piercing and/or tunneling libraries that Just Work™? (Well, possibly, unless put behind some truly abysmal corporate firewalls where even plain outgoing HTTP isn't working all the time — but that would be another story.)

I don't think NAT piercing works if both of the endpoints are behind NAT, which might happen in this case (e.g. RaspPi + controller app on smartphone).

You could run a server in the middle; but that's exactly what this is.

Re: Show HN: Crowsnest – API for the Real World

#38
post #24

Earlier quoted context omitted.

We're currently charging $5 device per month that you've registered through the RPi. The first two devices are free. Granted, we're still getting a feel for what our pricing structure should be, do you have any feedback about our pricing structure currently?

So, if I built out 10 RPi based thermometers, that would be $40/month just to get a quick API? If I added a humidity sensor, that would add another $50/month? That's pretty steep. Granted, you could be targeting corporate and this starts to make some sense. That kind of pricing really does make it impractical for home users. You're already targeting an audience with some tech savvy and it doesn't take much to write a…

Another Crowsnest founder here. We're bouncing around the idea of incentivizing contributors to be involved in the community with additional free devices (assuming we can mitigate abuse). For example, if someone contributes the integration library for a specific device then there number of free devices per month increases by 5. Good idea / bad idea? Hoping to get feedback on this.

Re: Show HN: Crowsnest – API for the Real World

#39

Earlier quoted context omitted.

This certainly was an issue in early days of P2P, but I thought it was already solved for good. Doesn't P2P works nearly literally everywhere nowadays and aren't there loads of NAT-piercing and/or tunneling libraries that Just Work™? (Well, possibly, unless put behind some truly abysmal corporate firewalls where even plain outgoing HTTP isn't working all the time — but that would be another story.)

I don't think NAT piercing works if both of the endpoints are behind NAT, which might happen in this case (e.g. RaspPi + controller app on smartphone). You could run a server in the middle; but that's exactly what this is.

> I don't think NAT piercing works if both of the endpoints are behind NAT

It does, in many cases even without on any third party. That is a (mostly) solved issue for at least 5 years or maybe even more. Here are examples of such tools: http://samy.pl/chownat/ and http://samy.pl/pwnat/

There are cases such tricks won't work (like overly conscious connection tracking engine and all ICMP traffic blocked - but without ICMP one would have PMTU issues and those ain't fun), but there're always STUN and TURN. The distinction is, those is not middleman, but just a NAT piercing helpers. They don't pass your traffic through and they're generic and useable with any service.

Post reply on HN