You are absolutely correct the propagation for us is O(n) as the graph is directed. But the problem there is multifold. Once a node receives propagation pulse it tries to figure out the affected subset using the dimensions received as propagation pulse. This requires joining, hence a chance to build a O(mn)cartesian product. If you see https://www.charts.com/muze/examples/view/crossfiltering-wit... example the contribution bars are drawn when the first chart is dragged requires joining follower by groupBy.

Which is why performing this in browser env even for low amount of data (say 10k) is nightmare. There are ways you can address this but while in browser you hit the limit pretty soon.

We wanted the concept to be validated first hence we have build it for browser only. But would love to hear / learn / discuss with you on this before we go ahead and build the data model in server.

Another ambiguity with the interaction is visual effect of interaction. Questions like do you really want all your chart to be cross connected. A in house survey showed us there is no certainty of the answer. And what kind of visual effect should happen on interaction differs person to person and is a function of use case. Which is why we have chosen go for chosen behaviour like

``` muze.ActionModel.for(...canvases) / for all the chart in page / .enableCrossInteractivity() / allow default cross interactivity / .for(tweetsByDay, tweetsByDate) / but for first two canvas in the example / .registerPropagationBehaviourMap({ select: 'filter', brush: 'filter' }) / if selection using mouse click or brushing happens filter data / ```

we are still writing docs for this. We hope to finish all the these docs in two weeks time.