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 <i>speed traps</i> 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 <a href="http://dweet.io" rel="nofollow">http://dweet.io</a>, 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.<p>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.<p>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.<p>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.<p>[1] - <a href="http://www.vroomtrap.com/downloads" rel="nofollow">http://www.vroomtrap.com/downloads</a><p>[2] - <a href="http://www.gartner.com/newsroom/id/2636073" rel="nofollow">http://www.gartner.com/newsroom/id/2636073</a><p>[3] - <a href="http://www.techempower.com/benchmarks/#section=data-r8&hw=i7&test=json" rel="nofollow">http://www.techempower.com/benchmarks/#section=data-r8&hw=i7...</a><p>[4] - <a href="http://jolira.github.io/backgrounder/" rel="nofollow">http://jolira.github.io/backgrounder/</a>