Roadmap to release

[chancehudson]

• [ ] move mopro-core logic into mopro-ffi
  • [ ] delete mopro-core
  • [ ] delete static/const embedded srs/zkey/vkey/etc.
  • [ ] accept path to constants when building proofs
• [ ] separate UDL interfaces for circom and halo2
  • [ ] remove conditional compilation for individual functions (#180)
• [ ] clean up examples
  • [ ] only store srs/zkey/vkey/wasm files - move the halo2/circom source to a different repo
• [ ] refactor cli
  • [ ] translate build_ios, build_android, build_core into rust (don't simply invoke shell scripts from rust)
  • [ ] delete TOML/mopro-config parsing logic
  • [ ] delete shell script cli implementation
  • [ ] delete circom build logic (delegate to mopro user)
  • [ ] export these functions as functions designed to be used in a build script
• [ ] write an example mobile app project in a separate repo
  • [ ] add a build.rs that calls the above rust implementations (build_ios, build_android, etc)
  • [ ] build mobile project using cargo build instead of mopro build
  • [ ] build lib_mopro_ffi.a from source, specify config in rust source
  • [ ] delete toml project config
  • [ ] copy zkeys/vkeys/srs/etc to app bundle
  • [ ] only use mopro cli for initializing projects
• [ ] build template from example project

[vivianjeng]

delete mopro-core

We can just call it mopro? if we will seperate mopro-cli or just src if it is not monorepo anymore

I agree with the idea to combine mopro-core and mopro-ffi they are too similar and not necessary to be seperated

delete TOML/mopro-config parsing logic

it will be controlled by feature flag or how to set the config?

delete shell script cli implementation

it means to implement with rust?

only use mopro cli for initializing projects

one other important features of mopro cli is to export bindings if developers already built their apps (e.g. anon aadhaar) instead of creating a new project, they might need only the moproFFI library https://zkmopro.org/docs/circom/ios#getting-started-with-exported-bindings if we can export moproFFI library without creating a new project it will be good (or even we publish moproFFI to https://cocoapods.org/ it will be good too)

[vivianjeng]

about

build template from example project

we can make developers to select circom or halo2 templates

[oskarth]

Discussed in chat but this is a lot of proposed changes. Too many to make sense of. Let's break this out into more minimal pieces with clear rationale for solving some specific problem.

[chancehudson]

We can just call it mopro?

I was going to leave it as mopro-ffi. We could make it a single package repo if the cli stuff were a module in mopro-ffi.

it will be controlled by feature flag or how to set the config?

We should be able to specify config in the Cargo.toml and in the exposed rust file. I need to play with the bindings compiler a bit to see how we can let the user write an implementation for a struct. The most primitive idea is to use macros to write the uniffi boilerplate and let the user define a list of zkeys. We'd take the zkeys and look for c witnessgen functions corresponding, and add the zkeys to the app bundles.

The macro would basically write generate_circom_proof and verify_circom_proof with support only for the listed zkeys.

if we can export moproFFI library without creating a new project it will be good

yep we'll definitely be able to export a static library or framework that an app can use

we can make developers to select circom or halo2 templates

or both

[oskarth]

This is not a well-formulated issue and doesn't reflect any "release scope" previously discussed. It reads more like a laundry list of random irks.

Please create separate issues for problems discussed above (I agree with many of them, but not necessarily with priority), along with problem, suggested solution and acceptance criteria.

Once we have that and are further along I agree a release check list issue would be useful, but this isn't it. Closing.