Thanks for the writeup here. Just some passing thoughts:
I think your revised projection function is in alignment with the original definition, yes. There’s a lot of nuance here in general which we haven’t fully unpacked (and will need to figure out soon). For example, I imagine that some applications would want to process historical state changes (transactions) in addition to current state (resources), so we might want to amend the projection function definition to allow them to do that. That’s just a type change, though - the difficult parts will mostly lie in figuring out how to analyze these functions, construct the right indexes, and route data around the network in an efficient manner.
Regarding error handling and sanity checking, this discussion on proofs is relevant - whatever services we query from, we should request proofs (which may often just be signatures) - and there should be a service commitment in place such that if a computational result is found to be invalid, proof that the service commitment has been broken can be published (and perhaps an operator slashed). There’s a separate question about how to figure out that we have actually queried all of the relevant state, which is not a trivial problem as the state is typically distributed around the network. If we’re just querying created but not yet consumed resources, we can get a proof (at least in principle) that all of the resources have been iterated over and checked (by whatever the filter function is). For more general state / history queries this isn’t possible in the same way - we should probably construct a little taxonomy of query type vs. what kinds of “completeness guarantees” we can get.