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.
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.
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.
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?