LGTM, but breaks API to clients (e-pm) and eris-db.js; this is okay as 0.12.0 is a big transfer, but we need to coordinate. Hence Im holding off merging and will ping @dennismckinnon @NodeGuy

Contrary to what I had thought, 46657 did have a subscribe and unsubscribe websocket implementation here: https://github.com/eris-ltd/eris-db/blob/master/Godeps/_workspace/src/github.com/tendermint/tendermint/rpc/server/handlers.go#L331

This implementation only allows a single subscription to the same event from the same host. On the face of it that might seem okay, but it puts the onus on the client to maintain a global websocket connection pool per event and reuse/share the same one for the same event. This isn't terribly nice for writing less stateful Javascript apps and furthermore there is no warning that by re-registering the event will clobber any previous connections (they will no longer receive the event). This is because AddListener in go-events overwrites any existing callback:

func (cell *eventCell) AddListener(listenerID string, cb eventCallback) {
    cell.mtx.Lock()
    cell.listeners[listenerID] = cb
    cell.mtx.Unlock()
}

Your arguments are very strong; I will want to wait for develop to be green; then rerun this build and then Im happy to push forward on this.

I'm a bit worried about breaking compatibility, but using this approach the worst that happens is we break unsubscribe (they pass event name rather than subscription id, it's a no-op) -- something we have to rely on the clients doing anyway. Subscribe will work as before. And both methods have identical signatures so Unsubscribe will fail silently -- not the end of the world.

Actually I guess the JSON versions would break because the key name has changed from event to subscriptionId. The HTTP version will fail silently.

Rebased

LGTM