Milestone 3 summary

Requirements for evaluation analysis

uniffi-zcash-lib

Done

• ✅ Create new Account - the ZcashAccountId dictionary is published and available from all bindings.
• ✅ Parse and validate a Unified Address - API defines 2 methods (Ruby syntax used there):
  • ZcashUnifiedAddress#new that allows constructing unified address from orchard, sapling, and transparent address
  • ZcashUnifiedAddress::parse which allows parsing unified address from string representation
• ✅ Parse and validate a Sapling Z-address - ZcashPaymentAddress::parse function
• ✅ Parse and validate a Transparent T-address - ZcashTransparentAddress::parse function
• ✅ Get Unified Address from Z- or T- address - mentioned above ZcashUnifiedAddress#new
• ✅ Produce Payment requests - ZcashPayment dictionary/struct is available as well as all subtypes
• ✅ Create a new Unified Address from an Account

Extras

• Existing code was modified to utilize uniffi-rs interface/object feature
• There is elixir/ directory in the root of the project that provide example of an Elixir wrapper. It is just PoC that is not currently worked on

Postponed

• ⚠️ Parse and validate Payment disclosures - This functionality is not currently exposed by librustzcash so it won't be possible to implement it during the RFP implementation.
• ⚠️ Verify Payment disclosures - See above
• ⚠️ Parse Payment requests - See above
• ⁉️ Get a fee rate - there is no reasonable type that this function can return as floating point is not reasonable value

uniffi-rs

Done

Completed implementation of documentation comment extraction feature:

• ✅ Parsing of Rust documentation comment Markdown content to extract arguments and return value descriptions
• ✅ Resolved issue with multiline documentation comments not being extracted/attached in their entirety
• ✅ Implemented extraction/attachment of enum, object, method descriptions
• ✅ Implemented module traversal to support Rust bindings projects split into multiple modules

Further plans

Move to the Milestone 4

With the issues mentioned above moved to new milestone.

Merging projects

During work on this milestone we have found that there are some issues with transitioning structures between different UniFFI projects in case of Ruby and Python (and potentially other dynamically typed languages in future). It also could cause some issues with version mismatches and would needlessly extend compilation times for complex projects (as we would need to compile librustzcash library multiple times). Instead the proposed solution is to merge all projects into single huge project that will expose everything. It has some maintenance drawbacks (most importantly - huge UDL file, but we already work on an approach to split it into smaller pieces that will be reconstructed later). This should solve all of the mentioned issues.

See issue #57 for details

Discussion about providing idiomatic facade for each language

Currently the exposed API is often not fully idiomatic for given languages as it is autogenerated from UDL files that are shared throughout of the different languages that have different idioms and styleguides. So the proposed solution is to provide the idiomatic "front-end" for each of the languages we support right now (Swift, Kotlin, Ruby, and Python). This will require some expertise in given languages, but could provide more "seamless" adoption of Zcash in projects using that languages.