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

[degregat]

@cwgoes

In particular, the definition of IFC for resource machine transactions in the linked post says nothing about IFC for data availability - which concerns what storage requests a node storing a particular piece of data should or should not respond to - the definition in the linked post concerns only which other nodes a particular node should or should not forward a transaction to in the counterparty discovery process.

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.

@cwgoes

Developers should definitely not need to implement code paths for different cases of data being available, at least in terms of transaction data as you describe here. The application definition is independent of data availability - data available to a particular observer determines what that observer can see and do (e.g. in terms of computing proofs), but application definitions are independent of any particular observer.

It sounds to me that the app devs must make specific assumptions explicitly and then structure the application accordingly?
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.

@cwgoes

Developers may sometimes need to specify in application definitions (e.g. resource logics) what data should be stored by a particular party, and maybe even what IFC policies should be applied to that data - but this is still at the application definition level, not at the level of the view of a particular observer.

Another example regarding this setting:
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?

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.

@cwgoes

What semantics are you referring to?

After processing your answer I think the semantics for the different settings of data (un)availability can be treated by making assumptions of data dependencies clear and doing error handling (does that make sense: @Michael @paulcadman).

If I understand correctly, the transparent/shielded/mixed TX settings should really not be relevant to the app devs, but how the mixing would work is still unclear to me.
Do I just get a nullifier and a proof to plug in the slots of transparent predicates? Does the RM report talk explicitly about that? If so, can someone point me to the section (@vveiln ?). If not, do we consider this in scope of the RM, or a detail of node implementation?