Taxonomies of Available Data, or: consequences of Information Flow Control for application developers

[cwgoes]

@degregat

It feels to me like the mechanism should be the same for forwarding TXs during the counterparty discovery process as well as managing data retrieval at other times: E.g. if these TXs can be forwarded to these entities, including the plaintext s.t. they can compute proofs, these entities should also be able to do that before or after counterparty discovery.

I might be missing something and the latter case needs some more functionality, but I think at least for TXs, this is a good start for DA IFC.

Hmm, I see what you mean, but there is definitely some nuance here - if I send my intent to a solver, I don’t want them to store the data and respond to requests to retrieve it forever, most likely - maybe I want to instruct them to do that (for specified requesters authorized by the predicate) for a little while, yes, but there is some distinction here (and maybe one which indicates that we really do need a more general framework with which we can express counterparty discovery related IFC as a specific case).

@degregat

For example for kudo balance calculation, the app dev should never assume any amount of data being available and just calculate a view of what can be accessed.

That’s true, but I’m not sure how the app would “assume” data being available anyways, since the read interface is just a projection function over state - apps do not specify how to retrieve data, or who to try to retrieve data from, merely what data should be retrieved, declaratively - it’s a separate choice of the user, or the GUI acting on their behalf (probably with some configuration and idea of who has what data, who has made what service commitments, etc.) to make those decisions. Also see this discussion, which is very relevant. Maybe the GUI or “application user interface” should not assume that all data is available, that I would agree with, so developers must consider this possibility in that sense. We need some clearer terminology for the distinction between “application definition” and “application user interface”, I think. I’ve been using “application” to mean “application definition”, but I wonder now if this might be too in conflict with the intuitive expectation, and maybe we should always explicitly disambiguate.

@degregat

If some function has strict data dependencies, an app dev would specify storage requirements and IFC policies, and if the assumptions do not hold for a specific observer, it reduces to error handling?

@degregat

I understand better now what you mean with, “observer dependent things should not happen at application level”, but it sounds like the app dev would still need to make choices (at least ofr defaults, which users could still change) on how a node should behave, i.e. how an error is handled.

Yes, the application user interface or GUI (whatever the user is using to help them craft intents, view state, etc.) would need to handle such exceptional cases, which could be considered to be errors. Furthermore, thanks to explicit service commitments, we should be able to provide specific information in every case as to which expectation was not in fact satisfied (e.g. I expected party P to store data D, and party P did not respond / did not have the data / etc.)