It's a very good point. I plan to add automatic discovery where every speaker and listener maintains a current list of the communication topography. I figure

It's a very good point. I plan to add automatic discovery where every speaker and listener maintains a current list of the communication topography. I figure I'll use this space to explain "why" messenger.js even exists. One reason I wrote messenger.js is because I find it easy to install, work with, and deploy over using RabbitMQ in node. Personally I was using zeromq with node-zeromq. This means, I need to install zmq, install the node module for it, and anything else that it may need to work properly. In addition I have to do this on dev and production. On top of that, I also have to write an abstraction over it similar to how the messenger.js listener works right now. To me, there seems to be too many moving parts to the puzzle just to get some simple communication going. I fell in love with the DNode API at one point, but I have to start my servers first and clients second. It doesn't appear to be a way to capture error events and try to auto-reconnect. There is a ticket for it but it seems neglected. For me, I don't want to worry about that. I want that abstracted away. I also wanted it in TCP, not HTTP. Of course, the benefit of RabbitMQ is in a separate language, someone probably already wrote the adapter for you to communicate with services of different languages. I'm not trying to compete with RabbitMQ here though. Just trying to get node.js communication to work in a scalable fashion with a 1 line install that just works.