4 ms·

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

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 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. Indeed, this approach loses all fancy cloud buzzwords, but it brings much more practical value.

ianawilson 13y ago
While part of the service is to act as a proxy between the RPi and the Internet, we're also trying to help save devs from needing to build out the device integrations (eg, lightbulbs, cameras, etc). We're trying to take care of these more boilerplate and reusable things, so that developers can focus on building their new and creative applications, rather than communication and infrastructure. Even if the device integration someone needs doesn't exist, we're hoping to make it easier and faster to get moving along that path with our open source device integration framework (we also call this the plugin system). If you're curious for more technical details, there is some info in the docs (https://www.crowsnest.io/portal/docs/ https://www.crowsnest.io/portal/docs/). Or if that's not enough, I'd be happy to talk more about it, here or in our IRC channel (#crowsnest on freenode).
icebraining 13y ago
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.
- jamesbritt 13y ago
  Sure, but wouldn't it be better to reduce those when possible, rather than adding another one, especially yet another under the control of a third party?
  - icebraining 13y ago
    On the whole, yes, but that's not realistic if you're a developer and you want to deploy some devices. You can't just expect people to rearrange their whole networks for you.
- drdaeman 13y ago
  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.)
  - ianawilson 13y ago
    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.
  - icebraining 13y ago
    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.
    - drdaeman 12y ago
      > 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/ http://samy.pl/chownat/ and http://samy.pl/pwnat/ 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.
chch 13y ago
Perhaps this is just rephrasing ianawilson's reply, but it seems that if Crowsnest eventually supports fifty different cameras (or switches or thermostats or what have you), then (via the tumblr demo): crowsnest_data = request.json image = base64.b64decode(crowsnest_data['files']['image']['data']) would be an abstraction layer over the internal functions of all of the cameras. That way, if I wanted to, say, build an app that does mood lighting depending on how many people are in a room, I could use Crowsnest as my middleman, and then my app would support fifty different cameras and fifty different switches (hypothetically), instead of the one of each that I happen to own and test on. That way, I could swap out devices or distribute my code to others, without having to worry so much about hardware integration. That sounds valuable from my personal perspective. At least, I think that's how it works, from browsing the site and demos. Feel free to correct me, ianawilson. :)
- ianawilson 13y ago
  Yup, that's exactly it!
- jamesbritt 13y ago
  That way, I could swap out devices or distribute my code to others, without having to worry so much about hardware integration. That sounds valuable from my personal perspective. It is valuable, but has the downside of coupling to a closed-source third-party cloud. Perhaps a better goal would be to encourage a public collection of CoAP- or OSC-based interfaces for these various end-point devices. Crowsnest is encouraging people to write and submit such end-point code; better that it be workable with OSS infrastructure.
- bduerst 13y ago
  How would that work? Would there be a set of standard drivers that Crows Next interacts with, that you need to have for your devices? It would be nice if this turned out to be the "VLC Player" of home hardware, where you could fire it up and expect it to work with most devices. That would take a ton of work on Crows Nest's part though.
  - ianawilson 13y ago

ianawilson 13y ago

While part of the service is to act as a proxy between the RPi and the Internet, we're also trying to help save devs from needing to build out the device integrations (eg, lightbulbs, cameras, etc). We're trying to take care of these more boilerplate and reusable things, so that developers can focus on building their new and creative applications, rather than communication and infrastructure. Even if the device integration someone needs doesn't exist, we're hoping to make it easier and faster to get moving along that path with our open source device integration framework (we also call this the plugin system). If you're curious for more technical details, there is some info in the docs (https://www.crowsnest.io/portal/docs/ https://www.crowsnest.io/portal/docs/). Or if that's not enough, I'd be happy to talk more about it, here or in our IRC channel (#crowsnest on freenode).

icebraining 13y ago

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.

jamesbritt 13y ago
Sure, but wouldn't it be better to reduce those when possible, rather than adding another one, especially yet another under the control of a third party?
- icebraining 13y ago
  On the whole, yes, but that's not realistic if you're a developer and you want to deploy some devices. You can't just expect people to rearrange their whole networks for you.
drdaeman 13y ago
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.)
- ianawilson 13y ago
  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.
- icebraining 13y ago
  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.
  - drdaeman 12y ago
    > 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/ http://samy.pl/chownat/ and http://samy.pl/pwnat/ 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.

chch 13y ago

Perhaps this is just rephrasing ianawilson's reply, but it seems that if Crowsnest eventually supports fifty different cameras (or switches or thermostats or what have you), then (via the tumblr demo): crowsnest_data = request.json image = base64.b64decode(crowsnest_data['files']['image']['data']) would be an abstraction layer over the internal functions of all of the cameras. That way, if I wanted to, say, build an app that does mood lighting depending on how many people are in a room, I could use Crowsnest as my middleman, and then my app would support fifty different cameras and fifty different switches (hypothetically), instead of the one of each that I happen to own and test on. That way, I could swap out devices or distribute my code to others, without having to worry so much about hardware integration. That sounds valuable from my personal perspective. At least, I think that's how it works, from browsing the site and demos. Feel free to correct me, ianawilson. :)

ianawilson 13y ago
Yup, that's exactly it!
jamesbritt 13y ago
That way, I could swap out devices or distribute my code to others, without having to worry so much about hardware integration. That sounds valuable from my personal perspective. It is valuable, but has the downside of coupling to a closed-source third-party cloud. Perhaps a better goal would be to encourage a public collection of CoAP- or OSC-based interfaces for these various end-point devices. Crowsnest is encouraging people to write and submit such end-point code; better that it be workable with OSS infrastructure.
bduerst 13y ago
How would that work? Would there be a set of standard drivers that Crows Next interacts with, that you need to have for your devices? It would be nice if this turned out to be the "VLC Player" of home hardware, where you could fire it up and expect it to work with most devices. That would take a ton of work on Crows Nest's part though.
- ianawilson 13y ago