Overview

Repositories structure

Diagram above shows overall structure of repos and wrappers both low-level and high-level. Github links: High-level SDKs:

  • duo-flutter-sdk (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.)

  • silent-shard-flutter-sdk (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:

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 duo-flutter-sdk 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:

Last updated