[RFC] IO-powered commit, hide and open

[arthurpaulino]

I just realized that we can merge .lurk.commit, .lurk.hide and .lurk.open with their meta counterparts by giving them IO powers. And as a consequence, we'd be able to get rid of .lurk.meta.commit, .lurk.meta.hide, .lurk.meta.open and .lurk.meta.fetch, which would make the UX easier/simpler.

The idea is straightforward:

1. Make .lurk.commit and .lurk.hide always persist commitments
2. Make .lurk.open always search on the file system if the requested commitment is not in memory

Pro:

• The user doesn't have to worry about fetching persisted commitments because .lurk.open can do it just fine in provable Lurk, if needed

Con:

• Even though commitment files aren't large, the file system usage just grows and grows

[porcuquine]

This doesn't work for multiple reasons, which mostly boil down to 'the current design is intentional'. But for the sake of being more expansive (at the risk of just restating your proposal in negative terms):

• Lurk evaluation is computational and shouldn't have side effects apart from emit.
• The current behavior in which emit also prints its output is a nod to that single, explicit side-effect.
• Whether or not commitments are persisted, and where, is a security property of the system.
• Defining the core language such that all commitments are just automatically persisted 'somewhere' and all requested openings are serviced if at all possible by seeking data from 'somewhere' would be extremely bad.
• We need to never introduce primitives that would have this property, or even provide tools that make it easy for applications to get this wrong.
• Using meta commands that force the user to explicitly declare intention and manage its execution is a reasonable compromise for now.
• We should eventually have more fine-grained control allowing compartmentalization of private data by application/instance.
• Remember: knowledge is power and data secrecy is not only a 'privacy' issue in Lurk, but also a fundamental security property. It must be possible for programs to use inability to open commitments as a guarantee that proofs cannot be created.
• Put differently, proof of knowledge (of commitment openings — or of Lurk data content more generally) must remain a strong guarantee of Lurk proofs that imply it.
• Any facility that makes 'all knowledge known to the system' available to 'all programs running on the system' would subvert this property.