Add WebStore to miden-client #402

dagarcia7 · 2024-06-27T18:12:11Z

Summary

This PR adds the WebStore, a WASM-compatible implementation of the miden-client Store trait.

It uses IndexedDB as its backend storage method to provide dependable, high-performance, and persistent storage for web-based clients, enabling seamless interaction with the Miden node in web contexts.

The existing SqliteStore utilizes SQLite as its backend, taking advantage of its robust and efficient database capabilities for data persistence. SQLite is a widely-used, serverless, self-contained SQL database engine that offers stable storage and effective querying for applications.

However, SQLite is not compatible with WASM due to its reliance on native file system access and multi-threading, which are not available in the web environment. WASM operates within a restricted sandbox in the browser, lacking direct access to the underlying file system and threading capabilities that SQLite requires.

dagarcia7 · 2024-06-27T18:40:00Z

src/store/web_store/accounts/js_bindings.rs

+use wasm_bindgen_futures::*;
+
+// Account IndexedDB Operations
+#[wasm_bindgen(module = "/src/store/web_store/js/accounts.js")]


All of the js_bindings.rs files follow the same pattern, so I will write a few comments on this first file to point out a few things and it should apply to the rest.

Here, we're basically pointing to a .js file that implements all of the methods below. These js files will be responsible for storing or retrieving data from IndexedDB, and return a promise.

dagarcia7 · 2024-06-27T18:41:09Z

src/store/web_store/accounts/js_bindings.rs

+extern "C" {
+    // GETS
+    // ================================================================================================
+    #[wasm_bindgen(js_name = getAccountIds)]


By adding the module = line above, this allows us to specify the name of the function to be executed when the corresponding rust function gets called

dagarcia7 · 2024-06-27T18:47:37Z

src/store/web_store/accounts/js_bindings.rs

+        id: String,
+        code_root: String,
+        storage_root: String,
+        vault_root: String,
+        nonce: String,
+        committed: bool,
+        account_seed: Option<Vec<u8>>,


For the insert statements, I tried breaking down the information needed to be stored into simple, primitive types that can cross the rust/wasm boundary easily.

As a result, there is some difference with how some tables store things in SQLite vs. how I have it set up to be stored in IndexedDB. I'm assuming these interfaces will be refined as the codebase progresses, but think this is a good place to start.

dagarcia7 · 2024-06-27T18:53:03Z

src/store/web_store/accounts/mod.rs

+        let promise = idxdb_get_account_ids();
+        let js_value = JsFuture::from(promise).await.unwrap();
+        let account_ids_as_strings: Vec<String> = from_value(js_value).unwrap();
+
+        let native_account_ids: Vec<AccountId> = account_ids_as_strings
+            .into_iter()
+            .map(|id| AccountId::from_hex(&id).unwrap())
+            .collect();
+
+        Ok(native_account_ids)


Most GET methods follow this pattern:

Call indexed db method which returns a promise

Call JsFuture::from(promise).await to get the returned JsValue from the indexedDB call

use serde_wasm_bindgen::from_value to deserialize the JsValue into a Rust data structure.

Sometimes, there also needs to be some serializing before the indexedDB call is made to be able to pass the information down to JS (i.e. AccountID -> String representation of an AccountId). These parts of the code closely resemble/follow the serialize_{some_data} functions in the sqlite_store folder to prepare the data to be stored in SQLite.

Additionally, sometimes there needs to be some extra work after the indexedDB call is made and the JsValue is parsed back into rust to construct whatever the return value needs to be. These parts of the code closely resemble/follow the parse_{some_data} functions in the sqlite_store folder to reconstruct the native types once the stored data is retrieved.

dagarcia7 · 2024-06-27T19:01:04Z

src/store/web_store/accounts/mod.rs

+        insert_account_code(account.code()).await.unwrap();
+
+        insert_account_storage(account.storage()).await.unwrap();
+
+        insert_account_asset_vault(account.vault()).await.unwrap();
+
+        insert_account_record(account, account_seed).await.unwrap();
+
+        insert_account_auth(account.id(), auth_info).await.unwrap();


One thing to note here (and in some other places) is that right now these inserts are not atomic. With Rust + SQLite, you can create a tx object and interact with the DB multiple times, then call commit on the tx object so that it all happens atomically. In order to do this, I need to pass all the relevant data to one function in indexedDB, then can do something similar once I'm in the JS. I don't do this here yet, but I do this in other places (sorry for the inconsistency).

On my TODO list is to audit places like this where the updates are not atomic and refactor a bit to make it so.

dagarcia7 · 2024-06-27T19:02:04Z

src/store/web_store/accounts/mod.rs

Just want to point out here and throughout that my error handling when interacting with the indexedDB store is abysmal right now. I hope to add solid error handling in a following PR.

dagarcia7 · 2024-06-27T20:15:21Z

src/store/web_store/accounts/mod.rs

+    /// Fetches an [AuthSecretKey] by a public key represented by a [Word] and caches it in the store.
+    /// This is used in the web_client so adding this to ignore the dead code warning.
+    #[allow(dead_code)]
+    pub(crate) async fn fetch_and_cache_account_auth_by_pub_key(


This function is the only one implemented that is not defined in the Store, but is the solution we have for the issue discussed here 0xPolygonMiden/miden-base#705.

dagarcia7 · 2024-06-27T20:25:52Z

src/store/web_store/accounts/models.rs

+use serde::{de::Error, Deserialize, Deserializer, Serialize};
+
+#[derive(Serialize, Deserialize)]
+pub struct AccountCodeIdxdbObject {


For the GET functions, I usually wrap the data needed to be returned in an object and use serde for serialization/deserialization.

dagarcia7 · 2024-06-27T20:27:01Z

src/store/web_store/accounts/models.rs

+pub struct AccountCodeIdxdbObject {
+    pub root: String,
+    pub procedures: String,
+    #[serde(deserialize_with = "base64_to_vec_u8_required", default)]


This was my solution to deserializing Vec<u8>. Plan to revisit to see if there's anything easier or better, but this works well for now.

dagarcia7 · 2024-06-27T20:27:32Z

src/store/web_store/accounts/models.rs

+    pub account_seed: Option<Vec<u8>>,
+}
+
+fn base64_to_vec_u8_required<'de, D>(deserializer: D) -> Result<Vec<u8>, D::Error>


Probably should put these two in a shared place. I can probably do that in this PR.

dagarcia7 · 2024-06-27T20:28:49Z

src/store/web_store/accounts/utils.rs

In all my utils.rs files, I moved some code out of the main mod.rs file to make them easier to sift through. The splits I settled on feel natural to me, but open to dropping all of the utils code across the different mod.rss if we prefer all the logic in one place.

dagarcia7 · 2024-06-27T20:31:06Z

src/store/web_store/js/accounts.js

Across these .js files, I basically tried my best to follow as closely along to the schema set by the sqlite store as well as the queries. Obviously there's going to be some minor differences in approaches to storing some pieces of data, but for the most part if you read a query in sqlite and look for its counter part here in an indexedDB js file, they should read mostly the same.

dagarcia7 · 2024-06-27T20:34:28Z

src/store/web_store/sync/mod.rs

+            update_account(&account.clone()).await.unwrap();
+        }
+
+        let promise = idxdb_apply_state_sync(


This is one of those places where I attempted to make this update atomic by sending all the info needed to the JS side, and making the queries atomic there. If you follow the code all the way to sync.js in the function applyStateSync, you can see how I tried to make all the different updates under a single transaction.

Left some TODO's here because those updates happen independently for now. Need to lop them into this call eventually or figure out a different strategy in general.

dagarcia7 · 2024-06-27T20:35:40Z

src/store/web_store/js/sync.js

+    return db.transaction('rw', stateSync, inputNotes, outputNotes, transactions, blockHeaders, chainMmrNodes, async (tx) => {
+        await updateSyncHeight(tx, blockNum);
+        await updateSpentNotes(tx, nullifierBlockNums, nullifiers);
+        await updateBlockHeader(tx, blockNum, blockHeader, chainMmrPeaks, hasClientNotes);
+        await updateChainMmrNodes(tx, nodeIndices, nodes);
+        await updateCommittedNotes(tx, outputNoteIds, outputNoteInclusionProofs, inputNoteIds, inputNoteInluclusionProofs, inputeNoteMetadatas);
+        await updateCommittedTransactions(tx, transactionBlockNums, transactionIds);


This is how you would go about doing multiple updates across multiple indexedDB stores atomically under one transaction.

igamigo

Very cool! Leaving some comments for now, going to resume looking into the PR later. In general I think the code looks good even though I'm not too familiar with IndexDB and its workflows.

igamigo · 2024-06-27T20:07:08Z

src/store/web_store/chain_data/mod.rs

+        let promise = idxdb_get_block_headers(formatted_block_numbers_list);
+        let js_value = JsFuture::from(promise).await.unwrap();
+        let block_headers_idxdb: Vec<Option<BlockHeaderIdxdbObject>> =
+            from_value(js_value).unwrap();


Definitely not for this PR but it seems these could be generalized and collapsed into a function since this pattern occurs frequently.

Yes, good call! Will note that as a good thing to cleanup soon after merging this 👍

igamigo · 2024-06-27T20:15:24Z

src/store/web_store/js/accounts.js

+        if (mostRecentRecord.accountSeed) {
+            // Ensure accountSeed is processed as a Uint8Array and converted to Base64
+            let accountSeedArrayBuffer = await mostRecentRecord.accountSeed.arrayBuffer();
+            let accountSeedArray = new Uint8Array(accountSeedArrayBuffer);
+            accountSeedBase64 = uint8ArrayToBase64(accountSeedArray);
+        }


What's the limitation behind returning a base64 string as opposed to just returning a byte array? Are they serialized as strings and so this allows to compress data better?

Great question. I did it this way here and in multiple places mainly because passing a Uint8Array from JS to Rust via the WASM boundary wasn't working. So my approach here was to convert the Uint8Array to a base64 encoded string, pass that through the WASM boundary to rust, and then do something like this

#[derive(Serialize, Deserialize)] pub struct AccountRecordIdxdbOjbect { pub id: String, pub nonce: String, pub vault_root: String, pub storage_root: String, pub code_root: String, #[serde(deserialize_with = "base64_to_vec_u8_optional", default)] pub account_seed: Option<Vec<u8>>, } fn base64_to_vec_u8_optional<'de, D>(deserializer: D) -> Result<Option<Vec<u8>>, D::Error> where D: Deserializer<'de>, { let base64_str: Option<String> = Option::deserialize(deserializer)?; match base64_str { Some(str) => base64_decode(&str) .map(Some) .map_err(|e| Error::custom(format!("Base64 decode error: {}", e))), None => Ok(None), } }

to convert the base64 encoded string to a Rust Vec<u8> when use serde_wasm_bindgen::from_value; is called on the object returned from the JS function.

Doing a bit more research, I think you may be right and I think we may be able to return a Uint8Array directly and do something like this instead

#[derive(Serialize, Deserialize)] pub struct AccountRecordIdxdbObject { pub id: String, pub nonce: String, pub vault_root: String, pub storage_root: String, pub code_root: String, #[serde(deserialize_with = "deserialize_uint_8_array", default)] pub account_seed: Option<Vec<u8>>, } fn deserialize_uint_8_array<'de, D>(deserializer: D) -> Result<Option<Vec<u8>>, D::Error> where D: Deserializer<'de>, { let js_value: JsValue = Deserialize::deserialize(deserializer)?; if js_value.is_null() || js_value.is_undefined() { return Ok(None); } let uint8_array = Uint8Array::from(js_value); let vec = uint8_array.to_vec(); Ok(Some(vec)) }

to handle the deserialization properly. I think for now, I'll leave this since I know it works, and then in a follow up experiment with the other approach to see if it's more performant 👍

src/store/web_store/js/accounts.js

igamigo · 2024-06-27T20:21:22Z

src/store/web_store/js/accounts.js

+    try {
+        let accountSeedBlob = null;
+        if (account_seed) {
+            accountSeedBlob = new Blob([new Uint8Array(account_seed)]);


Seems like the seed is returned as a Blob here instead of a base64 string, is there a reason why they differ? If not we might want to track a work item to make them consistent

Yeah, good call out. My thought process here was that anything that could be stored as a Blob in IndexedDB probably should be since it's more performant in terms of processing and storage.

That being said, the lack of consistency when inserting into indexedDB as a Blob and needing to return back to Rust as a base64 is a good argument for just standardizing the insert and retrieval data type.

Additionally, there are some places where I'm also forced to insert as a base64 encoded string because I think indexedDB doesn't like matching Blob types when trying to do a lookup. So for certain tables that I know I'm going to have to look up based on a particular field, I also break this pattern and insert as a base64 string. I'm hesitant to change this now given that auditing the code and standardizing will take a bit of time and testing, but will do that quickly after this gets merged.

igamigo · 2024-06-27T20:29:27Z

src/store/web_store/notes/utils.rs

+    Ok(())
+}
+
+pub(crate) fn serialize_output_note(


I wonder if these util functions can (and should!) be shared between this and SqliteStore.

Yeah I agree that there is quite a good amount of code duplication here that should be looked at more closely. There are some places in the serialization process (and parsing) that differ, but can likely work around it in the name of DRYing some code up. The things I'm thinking of here mainly are when u64s are stored directly into the SQLite DB for things like IDs or other values. Because WASM doesn't natively support u64s, I convert these values to Strings in the serialization process and then handle the Strings returned from WASM accordingly during deserialization (i.e. converting back to u64 or other native objects using from_hex or something similar. I'll make sure to add this as part of cleanup tasks 👍

mFragaBA

Awesome work! I left some small comments / questions

It'd be nice if the comments describing the flow in the web store were added as doc comments, it'll probably ease it a bit for new contributors. if you plan to do a follow-up PR with documentation you can include it there.

Also one minor nit regarding note / transaction statuses is whether we should define them as constants instead of using the plain string, mostly to avoid typo errors.

src/store/web_store/js/schema.js

src/store/web_store/transactions/mod.rs

mFragaBA · 2024-06-28T15:19:55Z

Cargo.toml

@@ -30,13 +30,15 @@ async = ["miden-tx/async"]
 concurrent = ["miden-lib/concurrent", "miden-objects/concurrent", "miden-tx/concurrent", "std"]
 default = ["std"]
 executable = ["std", "sqlite", "tonic", "dep:clap", "dep:comfy-table", "dep:figment", "dep:tokio", "dep:toml"]
+idxdb = ["dep:base64", "dep:serde-wasm-bindgen", "dep:wasm-bindgen", "dep:wasm-bindgen-futures"]


should we enforce async feature with idxdb?

Yep - seems to me that async feature should be required for idxdb feature.

Oh, we should also update the build-wasm target in the Makefile to include the idxdb feature flag there

src/store/web_store/js/chainData.js

mFragaBA · 2024-06-28T15:45:43Z

src/store/web_store/chain_data/mod.rs

+    ) -> Result<BTreeMap<InOrderIndex, Digest>, StoreError> {
+        match filter {
+            ChainMmrNodeFilter::All => {
+                let promise = idxdb_get_chain_mmr_nodes_all();


besides this line, isn't the rest the same for ::All and ::List variants?

Good catch! Created a function in the utils.rs file for chain_data to DRY this code up a bit. In general, I'll be looking for other places with duplicated logic, etc. in a future PR!

another way without creating a separate function could be to pattern match only for the promis. So you'd end up with:

let promise = match filter { ChainMmrNodeFilter::All => idxdb_get_chain_mmr_nodes_all(), ChainMmrNodeFilter::List(ids) => { let formatted_list = ...; idxdb_get_chain_mmr_nodes(formatted_list) } } let js_value = JsValue::from(promise).await.unwrap(): // The rest of the code goes here ...

If you think the same logic will be used in other places I'm ok with moving it into a utils module though

src/store/web_store/js/sync.js

tomyrd

Haven't finished reading everything yet so it's not a complete review but I left a few comments.

src/store/web_store/js/accounts.js

src/store/web_store/js/chainData.js

bobbinth

Great work! Thank you! I only did a fairly high-level review and left a few small comments and suggestions for the future.

Overall, after some of the simpler comments above are addressed, we can merge, and address bigger comments/refactorings/code de-duplication in a follow-up PR.

bobbinth · 2024-06-29T21:29:14Z

Cargo.toml

@@ -52,12 +54,15 @@ rusqlite = { version = "0.30.0", features = ["vtab", "array", "bundled"], option
 rusqlite_migration = { version = "1.0", optional = true }
 serde = { version = "1.0", features = ["derive"] }
 serde_json = { version = "1.0", features = ["raw_value"] }
+serde-wasm-bindgen = { version = "0.6.5", optional = true }


nit: we usually don't specify patch version (e.g., we'd use 0.6 instead of 0.6.5).

Though, I see that some other dependencies here also have patch versions specified. @igamigo we should fix that in a different PR.

bobbinth · 2024-06-29T21:30:13Z

Cargo.toml

@@ -30,13 +30,15 @@ async = ["miden-tx/async"]
 concurrent = ["miden-lib/concurrent", "miden-objects/concurrent", "miden-tx/concurrent", "std"]
 default = ["std"]
 executable = ["std", "sqlite", "tonic", "dep:clap", "dep:comfy-table", "dep:figment", "dep:tokio", "dep:toml"]
+idxdb = ["dep:base64", "dep:serde-wasm-bindgen", "dep:wasm-bindgen", "dep:wasm-bindgen-futures"]


Yep - seems to me that async feature should be required for idxdb feature.

bobbinth · 2024-06-29T21:52:12Z

src/store/web_store/transactions/utils.rs

+type SerializedTransactionData = (
+    String,
+    String,
+    String,
+    String,
+    String,
+    Vec<u8>,
+    Option<Vec<u8>>,
+    Option<Vec<u8>>,
+    Option<String>,
+    String,
+    Option<String>,
+);


It might be safer to use a struct here and in other similar places - e.g., something like:

pub struct SerializedTransactionData { pub transaction_id: String, pub account_id: String, ... };

Instantiating and destructuring such structs should be nearly as easy as tuple types - but it would make mixing up fields more difficult.

Agreed! Didn't like the type. Changed it across WebStore, but might also want to something similar across SqliteStore 👍

bobbinth · 2024-06-29T22:09:40Z

src/store/web_store/transactions/utils.rs

+pub(super) fn serialize_transaction_data(
+    transaction_result: TransactionResult,
+) -> Result<SerializedTransactionData, StoreError> {


Conversions like this could be replaced with TryInto implementations - i.e., TryInto<SerializedTransactionData> for TransactionResult.

Great point here and below. I might hold off on refactoring these mainly because I know there's quite a bit of shared logic in these serialize functions and parse functions between WebStore and SqliteStore. I'm hoping I can extract most of the shared logic into helper functions and then implement these TryInto or TryFrom functions for each specific store type.

bobbinth · 2024-06-29T22:21:05Z

src/store/web_store/accounts/utils.rs

+pub fn parse_account_record_idxdb_object(
+    account_stub_idxdb: AccountRecordIdxdbOjbect,
+) -> Result<(AccountStub, Option<Word>), StoreError> {


Similar to my other comment, this could be replaced with a TryInto implementation.

Same as above. Definitely need a refactor here, but think it's part of a larger refactor to consolidate shared logic with SqliteStore so holding off for this PR.

tomyrd

Nice job with this implementation! Finished my review, left some more comments.

src/store/web_store/js/notes.js

src/store/web_store/js/sync.js

dagarcia7 · 2024-07-02T00:04:21Z

Addressed as much feedback as I could! Just a heads up, I'm seeing this when I run cargo build --features idxdb

error[E0599]: no method named `hash` found for reference `&Note` in the current scope
   --> src/client/transactions/mod.rs:252:34
    |
252 |                 .map(|note| note.hash())
    |                                  ^^^^ method not found in `&Note`

error[E0599]: no method named `hash` found for reference `&Note` in the current scope
   --> src/client/transactions/mod.rs:257:63
    |
257 |             .filter_map(|n| (!tx_note_auth_hashes.contains(&n.hash())).then_some(n.id()))
    |                                                               ^^^^ method not found in `&Note`

For more information about this error, try `rustc --explain E0599`.
error: could not compile `miden-client` (lib) due to 2 previous errors

I think this also shows up in regular, non WebStore builds too. Is this a known error?

bobbinth · 2024-07-02T00:07:23Z

I think this also shows up in regular, non WebStore builds too. Is this a known error?

Running cargo update may fix this.

dagarcia7 · 2024-07-02T00:15:58Z

I think this also shows up in regular, non WebStore builds too. Is this a known error?

Running cargo update may fix this.

Fixed!

Seeing this now in the integration tests

if [ -d miden-node ]; then cd miden-node ; else git clone https://github.com/0xPolygonMiden/miden-node.git && cd miden-node; fi
Cloning into 'miden-node'...
cd miden-node && git checkout "polydez-future-notes" && git pull origin "polydez-future-notes" && cargo update
error: pathspec 'polydez-future-notes' did not match any file(s) known to git
make: *** [Makefile:[8](https://github.com/0xPolygonMiden/miden-client/actions/runs/9752692487/job/26916774346?pr=402#step:6:9)4: node] Error 1
Error: Process completed with exit code 2.

Unsure what that could be as well!

bobbinth · 2024-07-02T00:18:21Z

Seeing this now in the integration tests

You probably need to rebase this branch from the latest next (if I'm reading the error correctly, it is trying to get miden-node code from a branch which has been merged into next already).

dagarcia7 · 2024-07-02T00:51:23Z

Seeing this now in the integration tests

You probably need to rebase this branch from the latest next (if I'm reading the error correctly, it is trying to get miden-node code from a branch which has been merged into next already).

I should be rebased I think 🤔 I tried to do this locally, but not sure if it's the same conditions given that I'm on a forked repo and there's funkiness with origin vs. upstream

tomyrd

LGTM!

mFragaBA · 2024-07-02T18:16:04Z

@dagarcia7 #407 got merged, it'll probably get some conflicts when you merge/rebase

igamigo

LGTM!

* Add WebStore to miden-client * Rebased off latest next * Rust docs command fix --------- Co-authored-by: Dennis Garcia <dennis@demoxlabs.xyz>

dagarcia7 commented Jun 27, 2024

View reviewed changes

bobbinth requested review from igamigo and bobbinth June 27, 2024 19:49

dagarcia7 commented Jun 27, 2024

View reviewed changes

igamigo reviewed Jun 27, 2024

View reviewed changes

dagarcia7 marked this pull request as ready for review June 27, 2024 20:36

mFragaBA reviewed Jun 28, 2024

View reviewed changes

tomyrd reviewed Jun 28, 2024

View reviewed changes

src/store/web_store/js/accounts.js Outdated Show resolved Hide resolved

src/store/web_store/js/accounts.js Outdated Show resolved Hide resolved

src/store/web_store/js/chainData.js Outdated Show resolved Hide resolved

src/store/web_store/js/chainData.js Outdated Show resolved Hide resolved

bobbinth approved these changes Jun 29, 2024

View reviewed changes

bobbinth mentioned this pull request Jun 29, 2024

feat: add re exports from base used in public api #394

Merged

2 tasks

tomyrd reviewed Jul 1, 2024

View reviewed changes

src/store/web_store/js/notes.js Outdated Show resolved Hide resolved

src/store/web_store/js/sync.js Outdated Show resolved Hide resolved

src/store/web_store/js/sync.js Outdated Show resolved Hide resolved

dagarcia7 force-pushed the add-web-store-clean branch from 3d151e7 to 85a6ff1 Compare July 2, 2024 00:41

tomyrd approved these changes Jul 2, 2024

View reviewed changes

dagarcia7 force-pushed the add-web-store-clean branch from 85a6ff1 to c7825fc Compare July 2, 2024 20:01

Dennis Garcia added 2 commits July 2, 2024 15:11

Add WebStore to miden-client

5f543a0

Rebased off latest next

42fea20

dagarcia7 force-pushed the add-web-store-clean branch from c7825fc to 42fea20 Compare July 2, 2024 20:18

Rust docs command fix

9639c94

igamigo approved these changes Jul 2, 2024

View reviewed changes

igamigo merged commit d0a0741 into 0xPolygonMiden:next Jul 2, 2024
7 checks passed

mFragaBA mentioned this pull request Jul 3, 2024

fix: update build-wasm target from Makefile #419

Merged

bobbinth pushed a commit that referenced this pull request Jul 5, 2024

Add WebStore to miden-client (#402)

eeeed5c

* Add WebStore to miden-client * Rebased off latest next * Rust docs command fix --------- Co-authored-by: Dennis Garcia <dennis@demoxlabs.xyz>

dagarcia7 mentioned this pull request Jul 12, 2024

Add Web Client #437

Merged

Add WebStore to miden-client #402

Add WebStore to miden-client #402

Conversation

dagarcia7 commented Jun 27, 2024 • edited Loading

Summary

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dagarcia7 Jun 27, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

igamigo left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mFragaBA left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mFragaBA Jul 1, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tomyrd left a comment

Choose a reason for hiding this comment

bobbinth left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tomyrd left a comment

Choose a reason for hiding this comment

dagarcia7 commented Jul 2, 2024

bobbinth commented Jul 2, 2024

dagarcia7 commented Jul 2, 2024

bobbinth commented Jul 2, 2024

dagarcia7 commented Jul 2, 2024

tomyrd left a comment

Choose a reason for hiding this comment

mFragaBA commented Jul 2, 2024

igamigo left a comment

Choose a reason for hiding this comment

dagarcia7 commented Jun 27, 2024 •

edited

Loading

dagarcia7 Jun 27, 2024 •

edited

Loading

mFragaBA Jul 1, 2024 •

edited

Loading