Your diagram is very close to my mental model, yes. I've diagrammed my model of the flow here: https://dropbox.dzombak.com/twimages/Scan%20Feb%2028%2C%202015%2C%2023.47.pdf (edit: oops, that rightmost path from "auth" to "return code" should be marked "catch error", too)
They key difference between this and your diagram is very small, but I think it's important. All the logging in ThingsHub is explicitly a side effect, added in
do* blocks; while the results are handled (and transformed into a return code) in the normal Reactive value-transforming way. My diagram just makes that a little clearer.
This distinction makes sense if you consider this program as a function, with one input (the state of the configuration on the filesystem) and one output: the return code with which the program exits.
Everything else—including most the useful work—is side effects, and at this high level they're modeled as such; the sync engine performs some work reports on progress, and side effects report on that progress, but the core flow of data through the program (config -> auth -> sync -> result code) is what I've modeled in my signal graph.