A lot of open-source projects by Nanobox look awesome, but most don't have any documentation or demos :-(.<p>I'm most interested in:<p><pre><code> [Hooky D](https://github.com/nanopack/hookyd) - Remote hook execution layer
[Butter](https://github.com/nanopack/butter) - Git based deployment system
[Shuttle](https://github.com/nanopack/shuttle) - Transparent TCP proxy for web</code></pre>
As a point of clarification (I work at Pagoda Box/Nanobox). Pagoda Box uses an older suite of similar tools (<a href="https://github.com/stormpack-core" rel="nofollow">https://github.com/stormpack-core</a>) mostly written in Erlang. This newer project (written in Golang) is part of a group of tools (<a href="http://nanopack.io/" rel="nofollow">http://nanopack.io/</a>) being written for <a href="https://nanobox.io/" rel="nofollow">https://nanobox.io/</a>
This looks like a great project! I'm curious about the following caveat from the readme, however:<p>"Data flowing through mist is NOT touched in anyway. It is not verified in any way, but it MUST NOT contain a newline character as this will break the mist protocol."<p>I haven't read the code yet, but my gut reaction is that this suggests it would be possible to inject commands using malicious user input. Given the caveat, this may be allowed for by your threat model, but it may be worth some effort to mitigate.<p>EDIT: To clarify, this may not be the case at all, in which case I'd be curious to hear why this restriction is in place.
> Messages are not guaranteed to be delivered, if the client is running behind on processing messages, newer messages could be dropped.<p>> Messages are not stored until they are delivered, if no client is available to receive the message, then it is dropped without being sent anywhere.<p>Not sure in which use cases can I use this ? Doesn't this defeat the purpose of having a message queue.
Struggling to see when I'd use this over, say, rabbitmq. Feels a bit like "not invented here" syndrome, though glad to be proven wrong. Also curious that this replaces previous tooling written in erlang, be interested to here what prompted the move to golang, I would think a message broker was right in erlang's wheelhouse
Curious how this compares to gnatsd: <a href="https://github.com/nats-io/gnatsd" rel="nofollow">https://github.com/nats-io/gnatsd</a>
Also to clarify (and yes I also work at Pagoda Box on the Nanobox project), this service was initially intended to provide push capabilities for rails and other web frameworks that can't natively provide a push socket layer. It has successfully filled that niche and has expanded to fill other needs as well.