Overview
Repositories structure
Last updated
Repositories structure
Last updated
Diagram above shows overall structure of repos and wrappers both low-level and high-level. Github links: High-level SDKs:
(Dart Cloud SDK on a diagram. Here phone serves as a part 1, there is a direct communication link between phone and a cloud node.)
(Dart Duo SDK on a diagram. Here phone serves as a party 2, no direct communication link, so more complicated transport.)
Low-level Dart bindings:
(ECDSA Dart bindings on a diagram)
(EdDSA Dart bindings on a diagram)
(yet another low-level bindings of another Rust repo, not present on a diagram. Used in latest , feat/dkls branch instead of and bindings)
Low-level repos are just wrappers on top of corresponding Rust repos which implement basic distributed keygen/signing algorithms via MPC. These Dart repos follow closely Rust API - but made more Dart-like. It works the following way:
Rust libraries have additional C compatibility shim layer on top the main codebase. It is compiled into binary C-compatible mode, and C bindings (header files) are generated with cbindgen.
Dart can import C libraries via FFI. We're also using ffigen - which generates low-level Dart bindings, code dealing with C pointers and stuff
Higher-level abstractions are created on top of low-level autogenerated code to make SDK more usable and Dart-native.
High-level repos built on top of low-level and the crucial distinction that it adds a transport part. We have 2 options here:
phone is party one, and can initiate the connection to the remote node (cloud), so there is a direct communication channel. Initially we have used HTTP calls, but later switched to WebSocket connection (feat/eddsa-support branch in the repo).
phone is party two, and there is no direct communication link because remote node cannot initiate the connection to phone. We have used Firebase as a transport layer, which adds a lot of complexity.
Rust repos: