Interesting idea but I would offer an alternative to JSON for device<-->dweet communication. JSON parsing on small embedded processors is often memory- and CPU-prohibitive. A small (preferably binary) protocol is lighter and faster to work with on these little microproccessors. When I built my Lightcube[1], I designed a binary protocol[2] that is easily parsed on the Arduino or even the smaller ATtiny microprocessors. Designing and implementing the protocol was a learning process for me but I ended up with something that didn't tax the CPU, leaving me more processing cycles to interact with my hardware.

[1] Lightcube: https://github.com/chrissnell/Lightcube

[2] Lightcube protocol: https://github.com/chrissnell/Lightcube#lightcube-protocol

Why does the API respond with keys like this?

    "this": "succeeded",
    "by": "getting",
    "the": "dweets"

    if(response['this'] == 'suceeded') print response['with']

Cool and good luck! I'd be cautious about the name sounding so close to Tweet, especially when you advertise it's "like Twitter." Less impact changing the name now than later.

Very cool. One suggestion for the product page is some simple use-cases for why you'd use such a service. Also, are there size constraints for the dweets?

This is awesome! It used to be somewhat inconvenient to set up a simple message-passing backend for my Arduino Ethernet. This is exactly what I needed to eliminate that mundane task. To the creator, my eternal gratitude!

Nice! One thing I would like to see is some way to reserve names so that only I can use them – right now if I'm publishing data to http://dweet.io/follow/outdoors , anyone can easily override that with http://dweet.io/dweet/for/outdoors?no=temp&for=you - so that'd be a neat feature. Unless the idea is that handles would be shared between devices...

BTW, I'm dweeting that outdoor temperature using SmartThings and this code - https://gist.github.com/alexking/8880479

So it's a pub-sub over HTTP. Attaching Twitter to the name makes it sound like something Web 2.0, I suppose.

I'm currently working on a similar system aimed at robotics. M2M is rapidly growing under the radar due to mobile phones making a lot of the technology needed cheaper. The interesting bit here is the protocol. Which still feels a bit off to me, but still works well. Designing protocols is not an easy task. Well done Bug Labs.

@jheising Send me an email. I'd like to get a friendly conversation going on. :)

I kind of like the HAPI concept but it feels strangely redundant. Especially in the responses, where almost half of the k/v pairs are just for "decoration" purposes. I concede that it does make things a slight bit easier to read, but are you guys sure it isn't bordering on redundancy for the sake of redundancy?

Very nice idea, by the way! Congrats!

This is the first time I've come across the HAPI spec. Does anyone know of other projects that are using that style of API?

Do you guys make any promises about latency between when a dweet is sent and when a following client will receive it?

Among other things, this seems like it could be a free pub/sub system.. If the latency is low that would make this incredibly useful.

Nice, but the API seems pretty non-RESTifarian.

/get/latest/dweet/for would more naturally be /get/dweet with a time parameter, or some such.

/for/[device] would more naturally just be a device parameter.

Etc.

Today we are launching dweet.io, an amazing IOT utility. We are giving it away for free, so please try it. Thank you!

So cool. Such a simple yet revolutionary concept to enable open and extensible connectivity for IoT.

Why on earth are you not using HTTPS?

Oh this is very cool. I am so going to plug this into my Electric Imp when I get home.

Would you all be interested on hosting a contest to do something cool with this?

Interesting idea. How about documenting the real-time updates protocol?

Maybe once a week does a website design make me smile. Thank you.

"What's the catch?"

The whole world sees your machines. :)

Using HTTP for this is ridiculous. CoAP or MQTT would have been the obvious choice, considering they were designed for exactly this use m2m use case.

WOW! Bug Labs, you guys are still around. I remember back in the Summer of 2006 when the BugBox was the hot product. I was trying to build a real-time geo-tagging service to tag speed traps using the BugBox[1]. Then 6 months later, Steven Paul Jobs came though with the hand of magic, announced the iPhone with all of the sensors that were in the bug box with a much better product and simultaneously erased the Bug Labs from my mind. As far as http://dweet.io, this looks like a very good implementation of a message bus. The two things I'm worried about with this project are performance and concurrency.

Lets start with performance. If you're trying to get a predicted 26 billion devices by 2020[2] on a Node.js/Socket.io Framework, you're going to need so many machines, the business case wont be viable. Socket.io is great for message passing, but at high throughput, it's going to fall short. Message busses like ØMQ (ZeroMQ) are a lot lighter and can bind to file descriptor without requiring spawning up an HTTP server. As for Node.js performance; It's great for JSON serialization (Which you're going to be doing a lot of), but it's far from the fastest. Node blows away languages/frameworks like Ruby/Rails and Python/Django in speed when it comes to JSON serialization (And almost anything else), but it's still in the 30th percentile for JSON serialization which is very low[3]. With this being one of your most performed operations, this is something that should be as fast as possible.

As far as concurrency is concerned; Node.js isn't an inherently concurrent language although it does have it's non-blocking I/O callback magic. Obviously, you can use modules like cluster, the native process spawning or backgrounder[4], but the weight of threads is going to be so expensive compared to the amount of work that's needed to be preformed. Supporting concurrent paradigms like RUN.At, RUN.Until, RUN.After, RUN.Every, RUN.WithTimeout, and RUN.BatchJobs are easy to do in Node.js, but then getting those individual processes to talk to each other in an orderly fashion using callbacks and Socket.io seems like duct tape and chewing gum over just using a language that supports concurrency natively.

Other than that, I love it, I understand the vision (because we're building something similar), and I'm very glad that you guys open sourced this project.

[1] - http://www.vroomtrap.com/downloads

[2] - http://www.gartner.com/newsroom/id/2636073

[3] - http://www.techempower.com/benchmarks/#section=data-r8&hw=i7...

[4] - http://jolira.github.io/backgrounder/