jheising

So there are some free sources I found for departure and arrival destinations, but they were wrong more than they were right, so unfortunately the only way to get reliable information is from a paid source. I may offer this at some point as a paid option down the road if popularity continues.

Very interesting! Most likely bad or incorrect altitude or position data from an aircraft transponder.

I LOVE the idea of applying Dolbear's Law, that would be such a cool touch.

It's meant to be relatively random. The idea is to show you some well known cities and landmarks so that you can get an idea where you are, but then some random curiosities just for the sake of exploring and seeing new things.

If you can tell me where you saw the wrong names for locations I would love to look into it. Thanks!

Thanks for the report, we'll look into it!

Great idea!

Somewhat. It currently simulates wind speed and direction for the movement of clouds. It also supports the ability to simulate cloud cover percentage (in the advanced options)— the reason it's not on by default is because we want users to get the best view of the sky no matter what the weather is like outside, so we default to 20%.

Other factors like rain could happen in the future.

I will look into this, thanks! In the meantime I'm going to implement a fallback to 2D tiles which has much higher quota limits. Try to stop the bleeding first.

Since I'm here, the why:

When I was a kid — back when travelling still felt new and exciting — I would see a plane crossing the early evening sky and try to put myself in it. Not to go anywhere in particular. I just wanted to know what the world looked like from up there, right then, to whoever was sitting by that window.

The feeling was strongest at sunset. I'd be watching a good one from the ground and think about how much better it had to be from up there, above the haze, with the light coming in level. The same sunset from a perspective I couldn't reach.

Travel has lost most of that. Airports, queues, delays: everything wrapped around flying has got steadily worse. But the flying itself hasn't changed. An hour into a clear evening flight, forehead against the glass, looking down at a world you almost never see from that angle, and it is still one of the quietly moving experiences I know.

Stowaway is that part, without the rest of it.

Hi all! I'm the creator of Stowaway.live and I really appreciate you posting it here.

All this attention has maxed out my Google 3D Tiles quota, so the ground textures in ride-along mode are being throttled. Everything else works — sky, aircraft and satellite tracking, sound — it's just the terrain that may come in flat or missing. I'm working on a caching layer and a proper fallback rather than just buying my way out of it, and I'd take suggestions if anyone's solved this before.

Thanks for checking it out!

The Maker Channel Action doesn't support authenticated requests, at least anything beyond something you could send in the URL or body of the message. We do this to prevent people from using it to spoof requests to public authenticated services that might view such behavior as slightly "shady". The Maker Channel is really meant for prototyping and experimenting and so we've limited the capabilities to keep the uses in that realm. Hope that helps!

Not exactly sure what you mean by long-polling in this context. Do you mean a client making calls to the API at regular timed intervals to check the status? Or do you mean the server making calls to an endpoint URI when an event occurs?

Hey azdle, thanks for the question and being honest. Do you mind me asking who you work for? Just curious more than anything.

To answer your questions about the alert code, yes it runs in a sandbox, but we also parse it and take it through a pretty lengthy pre-check process to weed out any code that might cause performance bottlenecks or general security problems.

As for websockets, we actually do support them (well, technically socket.io) but just don't make it very clear in the documentation. If you take a look at our open-source javascript client (https://github.com/buglabs/dweetio-client/blob/master/dweet....) you can see that we're actually using it there.

Hope that helps.

Yeah it's something that is browser dependent. I wouldn't call it a bug, but it is an annoyance. It's a decision we had to make in order to keep Freeboards secure for customers who don't want their data to be seen. But it does require the API to be available in HTTPS as well.

It's something we'll have to fix— maybe an option to turn off SSL for the freeboard, or like you say, create a proxy.

We'll look into it and have a solution soon.

Our core focus is read-only at the moment, but yes, command and control has been very much on our mind for a while and I think is going to be a next logical step. Technically you could implement C&C with a plugin right now, but we want to make it more of first-class feature at some point.

Yeah it's 100% client side.

Check the repository again. I just updated the Readme.md to add some more docs on loading and creating plugins. Let me know if this helps. Thanks!

donatj, I would expect that both of those would work, but I can check into adding this as a feature. A lot of times this is actually an issue with CORS. The API would need to add a CORS header for freeboard.io. Or if the API supports JSONP, you can overcome this without a CORS header.

Will do mate.

Hah! Never thought about it, but you are so right. HTTP is actually an M2M protocol at heart and is by far the most prevalent on the planet...

Right now there is nothing to protect because the API is inherently open (on purpose to make it easy). But next week we will be introducing a security token mechanism to be able to "lock" machines. In this case HTTPS will be important and will be required. So yes, it's coming...

Thanks for the feedback! To be clear, the node.js library is just a client-side library, so it should only be technically running on a single machine in most cases.

Also, we only use socket.io for real-time pubsub, but you could just as easily use a polling mechanism with HTTP to get similar results if you're worried about the performance and overhead it carries.

I think perhaps the most important thing is to be very clear about our goals here. Dweet.io is NOT built for super low-latency pub/sub. IMHO most devices in the future of IOT won't need to communicate to the cloud more than a few times every minute or at the most once per second. For the devices that need low-latency (sub-second) pub/sub, I agree, you should look at other protocols like MqTT. But if I were a betting man, I'd say the vast majority of IOT devices in the future will not need this level of performance to warrant the extra headache.

So let's not a call it a security issue then. Let's call it an "it's too easy to delete" issue. And if that's the case, then that's what we're going for— easy. Remember, if you were truly protecting something that was secure then you would require a security token parameter— which BTW is something we're planning in the next rev, for people who want to protect their machines.

If I was phishing to get you to click on a link to delete a resource, then I would need to know that token, and if I knew that token, then I could just delete it myself. Note that the HAPI spec discourages the use of cookies (which I agree could allow a phishing attack if you were using cookies as a security mechanism).

Yes and if I were a hacker, I could do the same thing with curl. Either way the only person who's likely to do it is someone who is technically savvy.

Seriously? Look at the HTTP protocol and tell me you really believe that.

Their way:

DELETE /something HTTP/1.1

My way:

GET /delete/something HTTP/1.1

Do you really think one is more secure than the other?

Yes this is by design to make it easy. Being able to lock things to make them private is an upcoming feature. No promises, but probably will be available this coming week.

Yeah that's pretty much it. We're not claiming anything earth shattering or new here— just something that is dead simple, and works.

Correct. Damned be the HTTP specs and REST because they are such a pain in the ass :) I built HAPI precisely because the current standards only work in a world where everyone knows how and enjoys using curl. I think you should be able to paste a URL for an API anywhere and it should just work.

For example: Here let me show you how to delete that resource using our API... Oh wait, damn. I can't show you because I have no way of sharing a link with you because it requires the DELETE verb. Just go read this documentation and get back to me when you're done. ;)

Agreed, in the code-readability sense it's a little on the strange side, but I wouldn't call it completely nonsense either. My thinking behind the design was that developers are a lot easier to deal with than end-users/laypeople who you might rely on to help debug things. Besides, it's easy enough to write wrapper functions or use DEFINE (in the case of C/C++) to make the code more code-readability-friendly.

Nothing is perfect for everyone, and I think the response is probably the least important aspect of HAPI. The biggest bang for the buck in my mind is self documenting URLs and support for only HTTP-GET verbs. Just my $0.02 :)

It might seem like it, but it's actually not that different from a lot of REST APIs I know of. Most REST APIs return a status (in our case "this":"succeeded"), and some sort of wrapper for the actual data (in our case "with":{}). The only thing that might be redundant is the "by" property, but I think it's useful to have in cases where you want to make doubly sure that the API did what you thought it was going to do.