Reassessing function types and visibility

To be fair, we’ll already need to have some sort of authorization for the dapp who’s making these “offchain” calls. So we could simply extend this permission to all txs initiated by the dapp, so if a contract in a tx calls an unconstrained function in another one, we have the PXE apply the same permission rule as if it had been the dapp making the query.

Still, this doesn’t work on every case. If the dapp initiates a tx, and the tx ends up calling an unconstrained function in a contract unexpected by the dapp (which may happen, yay composability), we need to accommodate for that. I get the impression that, from a UX perspective, this can be tackled using the simulating simulations approach: we make an initial simulated run of the tx, we show the user a dialog explaining 1) what permissions is the tx requiring and 2) what stuff is the tx accessing, and only then we execute and return control to the calling dapp.

But we’re getting derailed. I’d suggest we try picking a name for “offchain” functions that is not offchain, so we can name it independently of this decision. I don’t have good proposal though.

12 Likes