Customize UDL file

[vivianjeng]

Problem

Currently we fix the uniffi files and functions in bin/ios.rs and bin/android.rs And if we create a new app like test-e2e We cannot update the functions through mopro.udl because it will be overwritten by bin/ios/bin/android It will be difficult for applications that need to extend the rust package e.g. GPU research or if we will build other SDKs

Details

mopro-ffi

• remove fixed bindings: e.g. mopro.swift
• generate bindings in the script (bin/ios, bin/android): e.g. build_bindings.sh
• copy the bindings to the output folder (e.g.MoproiOSBindings)

test-e2e

• users can overwrite the src/mopro.udl file and output customized bindings with cargo run --bin ios and cargo run --bin android

Acceptance criteria

• The new bindings can be added in test-e2e/src/lib.rs
• both mopro-ffi bindings (e.g. generateCircomProof) and new bindings can be called in both iOS and Android

Next steps (optional)

• publish the new crate
• update mopro cli

[alxkzmn]

@vivianjeng what does it mean for to be difficult to extend? Could give an example of what is being extended?

[chancehudson]

I think we discussed this a bit before, but we should consider if we should recommend teams move to their own FFI implementation. Sorta like ejecting from an expo app, but ejecting from mopro.

For most simple cases they would use mopro, but if they want to customize the UDL (by adding new functions/types) it would be better for project to eject from mopro so they can edit things without abstraction.

[vivianjeng]

@alxkzmn I imagine that developers can use both functions in mopro-ffi e.g. generateCircomProof and also functions defined in like test-e2e e.g. YourStruct or like GPU example: https://github.com/zkmopro/gpu-acceleration/blob/main/guide-for-extending-ffi.md#extend-the-udl-file-for-custom-functions you can define your function after mopro.udl

// mopro-ffi/src/mopro.udl

namespace mopro {
  // ... other definitions

  [Throws=MoproError]
  boolean your_function(u32 a, u32 b);
};

dictionary YourStruct {
  u32 a;
  u32 b;
};

[vivianjeng]

@chancehudson I think we can make all implementations possible

1. use mopro-ffi and not customize UDL
2. use mopro-ffi and customize UDL (now it is not possible)
3. not use mopro-ffi and customize UDL

just to overwrite or copy the output new bindings without fixing the file path https://github.com/zkmopro/mopro/blob/61f6b364bf9052a8d83251a7a4104b9ff541dede/mopro-ffi/src/app_config/ios.rs#L7-L9

it would be better for project to eject from mopro so they can edit things without abstraction.

How does it work? I think they will still need to clone the mopro repo and write UDL?

[alxkzmn]

I think we can pass the custom udl as an option when building:

• cargo run --bin ios -- --custom-udl path/to/custom.udl - if run like this, will use the specified custom UDL. if no arg provided, will use the bundled UDL;
• Put a guard around this https://github.com/zkmopro/mopro/blob/61f6b364bf9052a8d83251a7a4104b9ff541dede/cli/src/template/init/build.rs#L6, so if the UDL exists it won't be overwritten. Does this look good to you?