Fix CI docker compose and clippy errors

.github/workflows/mysql.yml

@@ -35,7 +35,7 @@ jobs:
           command: build
 
       - name: Build the docker-compose stack
-        run: docker-compose -f docker-compose.yml up -d
+        run: docker compose -f docker-compose.yml up -d
 
       - name: Check running containers
         run: docker ps -a
@@ -57,7 +57,7 @@ jobs:
           args: --manifest-path Cargo.toml -p examples
 
       - name: Cleanup docker container
-        run: docker-compose -f docker-compose.yml down -v
+        run: docker compose -f docker-compose.yml down -v
 
       - name: Copy integration test logs for review
         run: cat examples/integration_test.log

akd/Cargo.toml

@@ -14,9 +14,10 @@ readme = "../README.md"
 whatsapp_v1 = ["akd_core/whatsapp_v1"]
 experimental = ["akd_core/experimental"]
 
+rand = ["dep:rand"]
 bench = ["experimental", "public_tests", "tokio/rt-multi-thread"]
 public_tests = [
-    "dep:rand",
+    "rand",
     "dep:colored",
     "dep:once_cell",
     "serde_serialization",

akd/src/directory.rs

@@ -276,9 +276,9 @@ where
     ///
     /// * `current_azks`: The current [Azks] element
     /// * `lookup_info`: The information to target in the lookup request. Includes all
-    /// necessary information to build the proof
+    ///   necessary information to build the proof
     /// * `skip_preload`: Denotes if we should not preload as part of this optimization. Enabled
-    /// from bulk lookup proof generation, as it has its own preloading operation
+    ///   from bulk lookup proof generation, as it has its own preloading operation
     ///
     /// Returns [Ok(LookupProof)] if the proof generation succeeded, [Err(_)] otherwise
     async fn lookup_with_info(

akd/src/lib.rs

@@ -30,12 +30,12 @@
 //! This library supports the following operations for the directory it maintains:
 //! - [Publishing](#publishing): Allows the directory server to insert and update new entries into the directory.
 //! - [Lookup Proofs](#lookup-proofs): Handles point queries to the directory, providing proofs of validity based on the server's
-//! public key and a root hash for an epoch.
+//!   public key and a root hash for an epoch.
 //! - [History Proofs](#history-proofs): For a given index in the directory, provides proofs for the history of updates to this
-//! entry, matched against the server's public key and a root hash for an epoch.
+//!   entry, matched against the server's public key and a root hash for an epoch.
 //! - [Append-Only Proofs](#append-only-proofs): For a pair of epochs, provides a proof to an auditor that the database has evolved
-//! consistently and in an append-only manner. These append-only proofs use a verifiable random function (VRF)
-//! to avoid leaking any information about the labels and their corresponding values.
+//!   consistently and in an append-only manner. These append-only proofs use a verifiable random function (VRF)
+//!   to avoid leaking any information about the labels and their corresponding values.
 //!
 //!
 //! ### Asynchronicity
@@ -470,12 +470,12 @@
 //! Utilities:
 //! - `public_auditing`: Enables the publishing of audit proofs
 //! - `serde_serialization`: Will enable `serde` serialization support on all public structs used in storage & transmission operations. This is helpful
-//! in the event you wish to directly serialize the structures to transmit between library <-> storage layer or library <-> clients. If you're
-//! also utilizing VRFs (see (2.) below) it will additionally enable the _serde_ feature in the ed25519-dalek crate.
+//!   in the event you wish to directly serialize the structures to transmit between library <-> storage layer or library <-> clients. If you're
+//!   also utilizing VRFs (see (2.) below) it will additionally enable the _serde_ feature in the ed25519-dalek crate.
 //! - `runtime_metrics`: Collects metrics on the accesses to the storage layer
 //! - `public_tests`: Will expose some internal sanity testing functionality, which is often helpful so you don't have to write all your own
-//! unit test cases when implementing a storage layer yourself. This helps guarantee the sanity of a given storage implementation. Should be
-//! used only in unit testing scenarios by altering your Cargo.toml as such:
+//!   unit test cases when implementing a storage layer yourself. This helps guarantee the sanity of a given storage implementation. Should be
+//!   used only in unit testing scenarios by altering your Cargo.toml as such:
 //!
 
 #![warn(missing_docs)]

akd_core/src/configuration/experimental.rs

@@ -108,6 +108,7 @@ impl<L: DomainLabel> Configuration for ExperimentalConfiguration<L> {
     /// - I2OSP(len(label) as u64, label)
     /// - A single byte encoded as 0u8 if "stale", 1u8 if "fresh"
     /// - A u64 representing the version
+    ///
     /// These are all interpreted as a single byte array and hashed together, with the output
     /// of the hash returned.
     fn get_hash_from_label_input(

akd_core/src/configuration/traits.rs

@@ -74,6 +74,7 @@ pub trait Configuration: Clone + Send + Sync + 'static {
     /// - I2OSP(len(label) as u64, label)
     /// - A single byte encoded as 0u8 if "stale", 1u8 if "fresh"
     /// - A u64 representing the version
+    ///
     /// These are all interpreted as a single byte array and hashed together, with the output
     /// of the hash returned.
     fn get_hash_from_label_input(

akd_core/src/configuration/whatsapp_v1.rs

@@ -117,6 +117,7 @@ impl Configuration for WhatsAppV1Configuration {
     /// - I2OSP(len(label) as u64, label)
     /// - A single byte encoded as 0u8 if "stale", 1u8 if "fresh"
     /// - A u64 representing the version
+    ///
     /// These are all interpreted as a single byte array and hashed together, with the output
     /// of the hash returned.
     fn get_hash_from_label_input(

akd_core/src/lib.rs

@@ -56,6 +56,7 @@
 //! - The label in bytes
 //! - A single byte encoded as `0u8` if "stale", `1u8` if "fresh"
 //! - A `u64` representing the version (starting at 1 for newly inserted labels, and incremented by 1 for each update)
+//!
 //! The resulting values are hashed together and used as the byte string (truncated to 256 bits) that is stored
 //! as the [NodeLabel].
 //!
@@ -136,7 +137,7 @@
 //! Let `n` be the current version, and let `m` be the largest power
 //! of 2 that is at most `n`. The [LookupProof] consists of:
 //! - The `commitment_nonce` corresponding to the value, which the client
-//! can hash together with the value to reconstruct the commitment
+//!   can hash together with the value to reconstruct the commitment
 //! - A membership and VRF proof for version `n` being marked as fresh
 //! - A non-membership and VRF proof for version `n` being marked as stale
 //! - A membership and VRF proof for version `m` being marked as fresh
@@ -153,7 +154,7 @@
 //! Let `n` be the latest version, `n_next_pow` the next power of 2 after `n`, and `epoch_prev_pow` be the power of 2 that
 //! is at most the current epoch. The [HistoryProof] consists of:
 //! - A list of [UpdateProof]s, one for each version, which each contain a membership proof for the version `n` being fresh,
-//! and a membership proof for the version `n-1` being stale
+//!   and a membership proof for the version `n-1` being stale
 //! - A (possibly empty) series of membership proof for past versions
 //! - A (possibly empty) series of non-membership proofs for future versions
 //!

akd_core/src/types/mod.rs

@@ -9,8 +9,8 @@
 //! to verify any of the following AKD proofs
 //!
 //! 1. Lookup
-//! 2: Key history
-//! 3: Audit (append-only)
+//! 2. Key history
+//! 3. Audit (append-only)
 
 use crate::hash::Digest;
 #[cfg(feature = "serde_serialization")]
@@ -402,6 +402,7 @@ pub struct NonMembershipProof {
 /// * committed in the tree,
 /// * not too far ahead of the most recent marker version,
 /// * not stale when served.
+///
 /// This proof is sent in response to a lookup query for a particular key.
 #[derive(Debug, Clone, PartialEq, Eq)]
 #[cfg_attr(
@@ -468,7 +469,7 @@ pub struct UpdateProof {
 /// Let `n` be the latest version, `n_prev_pow` be the power of 2 that is at most n, `n_next_pow` the next power of 2 after `n`, and `epoch_prev_pow` be the power of 2 that
 /// is at most the current epoch. The [HistoryProof] consists of:
 /// - A list of [UpdateProof]s, one for each version, which each contain a membership proof for the version `n` being fresh,
-/// and a membership proof for the version `n-1` being stale
+///   and a membership proof for the version `n-1` being stale
 /// - A membership proof for `n_prev_pow` (or empty if n is a power of 2)
 /// - A series of non-membership proofs for each version in the range `[n+1, n_next_pow]`
 /// - A series of non-membership proofs for each power of 2 in the range `[n_next_pow, epoch_prev_pow]`

akd_core/src/utils.rs

@@ -57,9 +57,9 @@ fn get_bit_length(input: u64) -> u64 {
 /// 1. Include the largest power of 2 that is less than start_version.
 /// 2. Include the largest element of MARKER_VERSION_SKIPLIST that is less than start_version.
 /// 3. Include at most a log_2(start_version) number of versions between start_version and the
-/// largest power of 2 less than start_version, determined as follows: For each bit position i
-/// in start_version, if the bit is 1, include the value of start_version with the ith bit set
-/// to 0 and followed by trailing zeros.
+///    largest power of 2 less than start_version, determined as follows: For each bit position i
+///    in start_version, if the bit is 1, include the value of start_version with the ith bit set
+///    to 0 and followed by trailing zeros.
 ///
 /// As a concrete example, if start_version = 85, the past marker versions would be [16, 64, 80, 84].
 /// Since:
@@ -73,12 +73,12 @@ fn get_bit_length(input: u64) -> u64 {
 /// The future marker versions are determined as follows:
 ///
 /// 1. Include all powers of 2 that begin from start_version, up until the smallest element in
-/// MARKER_VERSION_SKIPLIST that is greater than start_version.
+///    MARKER_VERSION_SKIPLIST that is greater than start_version.
 /// 2. Include all elements of MARKER_VERSION_SKIPLIST that are between start_version and epoch.
 /// 3. Include at most a log_2(start_version) number of versions between start_version and the
-/// smallest power of 2 greater than start_version, determined as follows: For each bit position i
-/// in start_version, if the bit is 0, include the value of start_version with the ith bit set
-/// to 1 and followed by trailing zeros.
+///    smallest power of 2 greater than start_version, determined as follows: For each bit position i
+///    in start_version, if the bit is 0, include the value of start_version with the ith bit set
+///    to 1 and followed by trailing zeros.
 ///
 /// As a concrete example, if start_version = 85, the future marker versions would be
 /// [86, 88, 96, 128, 256, 65536, 2^32] (potentially truncated depending on if any of these

examples/Cargo.toml

@@ -13,6 +13,9 @@ path = "src/main.rs"
 bench = false
 doc = false
 
+[features]
+# Collect runtime metrics on db access calls + timing
+runtime_metrics = []
 
 [dependencies]
 anyhow = "1"