Use new registry [part 3] - assets registry #952

Valentine1898 · 2024-04-18T13:59:51Z

No description provided.

Valentine1898 · 2024-04-23T12:03:28Z

apps/extension/package.json

@@ -20,7 +20,7 @@
    "@bufbuild/protobuf": "^1.8.0",
    "@connectrpc/connect": "^1.4.0",
    "@connectrpc/connect-web": "^1.4.0",
-    "@penumbra-labs/registry": "4.0.0",
+    "@penumbra-labs/registry": "^4.1.0",


Noticed that this package is published by the penumbra-labs organization, but is in organization's prax-wallet repository. I'm assuming this is intentional

Why this change to add the ^? Just general best practice?

Was mistakenly pinned before. The caret allows for minor/patch updates to be downloaded as well.

Valentine1898 · 2024-04-23T12:05:08Z

apps/minifront/src/components/ibc/ibc-loader.ts

-const getIbcConnections = async () => {
-  const chainId = await getChainId();
-  if (!chainId) throw new Error('Could not fetch chain id');
-
-  const registryClient = new ChainRegistryClient();
-  const { ibcConnections } = await registryClient.get(chainId);
-  return ibcConnections;
-};
-


interaction with registry moved to fetchers/registry.ts

Valentine1898 · 2024-04-23T12:25:06Z

packages/query/src/block-processor.ts

+  numeraires: Metadata[];
+  stakingTokenMetadata: Metadata;


numeraires and stakingTokenMetadata are passed at initialization to avoid registry dependency for the block processor

Valentine1898 · 2024-04-23T12:29:59Z

packages/services/src/view-service/delegations-by-address-index.ts

-              equivalentValues: [
-                {
-                  equivalentAmount: { hi: 0n, lo: 0n },
-                  numeraire: STAKING_TOKEN_METADATA,
-                },
-              ],


I could add a registry dependency for view-service, but I don't see much point in doing that just for the sake of adding zero equivalentValues

Hmm... this means, though, that the staking page will not show the equivalent value of 0 UM for delegation tokens that the user doesn't hold, which is needed as part of the staking page design. If we're pulling metadata from IndexedDB, we don't need to hit the registry — we could just query for the staking token metadata in our database.

In order to get metadata from indexed-db I need to know which metadata corresponds to the staking token. And at the moment, I can only get the assetId of staking token from registry. And this leads to the fact that I have to access the registry at some point.

Ahh, true. Hm. We do know that the display will always be penumbra though, right? So we could look for the metadata that has that property?

Or, we could hard-code the UM asset ID in code, since that should also never change, right?

Yes, it is.
But at the same time, Gabe suggested adding STAKING_TOKEN to the registry and now, it seems to me, we should consider the registry the only reliable source about STAKING_TOKEN

(actually, now I think this is quite redundant, and this PR would be much less if we had left STAKING_TOKEN just a constant)

we should provide assetid of staking token to view service as a HandlerContext item

we should provide assetid of staking token to view service as a HandlerContext item

Do I understand correctly that in this case we will pass the assetid of staking token as context key for all rpc calls, although it is used only in one?
I have my doubts about this way in general, as we may end up with a lot of context keys, which will always be passed but rarely used

In order to pass stakingTokenId as a context key you need to do a lot of work.
The thing is that service-worker cannot access registry because it has no chain-id, we get chain-id when initializing services through querier, and for that querier must be initialized.
I don't think it shouldn't be done, but I suggest to do it in a separate PR on HanlderContext refactoring

How will the design change in this PR:

Valentine1898 · 2024-04-23T12:35:05Z

packages/storage/src/indexed-db/indexed-db.test.ts

 import type { IdbUpdate, PenumbraDb } from '@penumbra-zone/types/src/indexed-db';

 describe('IndexedDb', () => {
  // uses different wallet ids so no collisions take place
  const generateInitialProps = () => ({
    chainId: 'test',
-    accountAddr: 'penumbra123xyz',


deprecated property

Valentine1898 · 2024-04-23T12:43:03Z

packages/ui/components/ui/tx/view/swap/index.tsx

+                <div className='font-mono'>
+                  {joinLoHiAmount(getAmount(claimFee)).toString()} upenumbra
+                </div>


How it looks now

Valentine1898 · 2024-04-23T12:44:03Z

packages/ui/components/ui/tx/view/swap/index.tsx

-const getClaimFeeValueView = (claimFee: Fee) =>
-  new ValueView({
-    valueView: {
-      case: 'knownAssetId',
-      value: {
-        amount: claimFee.amount,
-        metadata: STAKING_TOKEN_METADATA,
-      },
-    },
-  });


I believe that the ui package should not depend on registry. And also we should not pass additional data for rendering transaction view components
In this case I had to simplify the fee display and get rid of ValueView

Hmm, yeah, this is tricky. Can't think of a better solution for this either.

it looks like there is no metadata field on the Fee type. we are using tools from @penumbra-zone/perspective to prepare the view prop everywhere we use this component, including a metadata getter. so i think options are

pr core for a metadata field on Fee, and prepare it before using component, as now

add a function prop to get metadata, component now responsible for all metadata

add a static optional prop for staking token metadata, component nearly identical

i prefer 3 because staking token metadata is a chain-level special case, and it's minimal change. the current behavior in this pr is good and should remain as fallback if prop is undefined/absent.

this can be a separate issue not addressed in this pr.

Yeah, definitely doesn't need to be addressed as part of this PR

Re: point 1: I actually suspect that a better solution would be to represent the fee as a ValueView generated from the Fee, since Fee already contains both an amount and an asset ID. So e.g., in addition to the swapPlaintext.claimFee field, there could also be a swapPlaintext.claimFeeView field that's a ValueView. Thoughts?

(Again, though, out of scope for this PR.)

jessepinho

OK, I left a lot of comments, but almost all of them are about one thing: we should (IMO) populate our IndexedDB with asset metadata from the registry every time we detect a new asset type in the block processor. Then, instead of calling to GitHub in multiple places, we should call to the extension/view service to get the metadata we need.

Thoughts?

jessepinho · 2024-04-23T15:54:29Z

apps/minifront/src/components/shared/zero-value-view.tsx

+ * A default `ValueView` to render when we don't have any balance data for a
+ * particular token.
+ */
+export const zeroValueView = (metadata: Metadata) =>


This shouldn't really be in the components directory, but rather somewhere like apps/minifront/src/utils

jessepinho · 2024-04-23T15:55:00Z

apps/extension/package.json

@@ -20,7 +20,7 @@
    "@bufbuild/protobuf": "^1.8.0",
    "@connectrpc/connect": "^1.4.0",
    "@connectrpc/connect-web": "^1.4.0",
-    "@penumbra-labs/registry": "4.0.0",
+    "@penumbra-labs/registry": "^4.1.0",


Why this change to add the ^? Just general best practice?

apps/minifront/src/components/shared/asset-selector.tsx

jessepinho · 2024-04-23T16:32:36Z

apps/minifront/src/components/swap/swap-loader.tsx

@@ -89,10 +91,12 @@ export const unclaimedSwapsWithMetadata = async (): Promise<UnclaimedSwapsWithMe
 export const SwapLoader: LoaderFunction = async (): Promise<SwapLoaderResponse> => {
  await throwIfPraxNotConnectedTimeout();

+  const registryAssets = await getAssetsFromRegistry();


Hm — this means we'll be hitting GitHub every time we load the swap page, which is a privacy concern. Shouldn't we pull from the asset registry in the block processor (e.g., in identifyNewAssets), save them to the database there, and then get the assets from the extension here?

My understanding is that the extension should be the backend for minifront. Minifront shouldn't talk to any other services directly.

apps/minifront/src/components/staking/account/delegation-value-view/index.tsx

apps/minifront/src/state/staking/index.ts

jessepinho · 2024-04-23T17:17:57Z

apps/minifront/src/state/staking/index.ts

    set(state => {
      state.staking.unstakedTokensByAccount = unstakedTokensByAccount;
      state.staking.accountSwitcherFilter = accountSwitcherFilter;
    });
  },
  delegate: async () => {
    try {
-      const req = assembleDelegateRequest(get().staking);
+      const stakingTokenMetadata = await getStakingTokenMetadata();


should pull from extension instead of GitHub

jessepinho · 2024-04-23T17:25:10Z

packages/services-context/src/index.ts

@@ -99,10 +101,14 @@ export class Services implements ServicesInterface {
      sctParams: { epochDuration },
    } = params;

+    const registryClient = new ChainRegistryClient();
+    const { stakingAssetId, assetById, numeraires } = await registryClient.get(chainId);


Grab from IndexedDB if possible

I'm not sure I'm understanding your idea correctly.
The thing is that I get the assetById here just to pass to indexed-db for initialization.
On initialization indexed-db will pre-populate the asset table with these values.
And yes, this will happen every time indexed-db is initialized.

Regarding numeraires and stakingAssetId, I can create a table for them in indexed-db, but to populate that table with data I still have to go to registry, I don't really understand what problem this solves, at the same time we have to think about the fact that numeraires or stakingAssetId in indexed-db might be considered outdated

I might be misunderstanding something here, but let me explain what I'm trying to suggest and see if it sounds right to you.

So, at the moment, we generally avoid making calls to an RPC node (or any other server, like GitHub) whenever possible — except for in the block processor. In the block processor, we make calls to the RPC node whenever we need to, since that doesn't reveal anything about the user's intentions. Everyone who uses the Prax extension uses the block processor and thus makes the exact same RPC/API calls.

But if we use the ChainRegistryClient in both minifront and in the extension's RPC implementations, those calls will fire on an as-needed basis, which may leak information about the user's intentions.

Thus, my argument is that we should fetch data from the registry in the block processor here. That way, we're guaranteed to have an up-to-date set of asset metadata at any given time, since we'll always know about every asset type that's been traded/etc. on chain.

Let me know if my understanding is correct — perhaps my thinking doesn't apply to IBC, since we'll need to know about tokens that can be traded in/out of Penumbra, even if they haven't been yet?

That way, we're guaranteed to have an up-to-date set of asset metadata at any given time, since we'll always know about every asset type that's been traded/etc. on chain.

the saveAndReturnMetadata() function is called only for those assets that occur on the user's balance. This does not exactly guarantee that we will have a local copy of the metadata of all assets in the indexed-db

I can see some disadvantages to using a local copy of the asset registry

we do not know when the local copy was last updated and whether it contains an up-to-date list of assets

In addition to saving, we will probably have to make a mechanism for updating the metadata and deleting the metadata. (I've presented a case where the registry initially had the wrong metadata but was corrected afterwards, but the local copies will never be changed).

Also, it seems to me that there is no privacy issue in getting data from github because in fact we are reading all datadata from the registry (ibc, rpc, all assets metadata) on every call (one json file is being read) and it literally does not reveal any of our intentions.
Also, as far as I understand, Gabe has created a mechanism to cache the registry, meaning that the data will be read only once, and the next calls will use the cache.

And considering that we already use the registry to get ibc channel data, nothing changes from the point of view of the github worker who is watching us

chainId should not change often, and if it does our state is invalid - we query app parameters in order to verify it has not changed. i believe stakingTokenId should not change unless chainId changes.

there is no explicit stakingTokenId in app parameters, but i believe staking tokens should be present at the genesis block, so could detect it without using the registry client.

staking token id is generated in core repo from known values https://github.com/penumbra-zone/penumbra/blob/main/crates/core/asset/src/asset/cache.rs#L28

we may be able to expose this via wasm. https://github.com/penumbra-zone/penumbra/blob/main/crates/core/asset/src/asset/id.rs#L156

notably LP uses the same hash and technique, which is exposed via wasm https://github.com/penumbra-zone/penumbra//blob/main/crates/core/component/dex/src/lp/position.rs#L103

we may be able to expose this via wasm

Yes, but it doesn't improve anything because we would still need to get the metadata (from the registry or indexed-db) and we would still need to call the registry for other things (assets, numeraires)
Also, we probably don't want minifront to use wasm, and we need stakingTokenId there too

OK, gotcha. Well, my instinct is to say that it probably isn't a big concern if these requests are being sent to GitHub, since the RPC node has no access to GitHub's internal server access logs. But I'm still a little wary of approving it — this is probably a question for @grod220 since it's sort of a product issue.

So, at the moment, we generally avoid making calls to an RPC node (or any other server, like GitHub) whenever possible — except for in the block processor.

I think the principle is something like:

Do not make a request to node when we can locally serve the result from indexeddb

If making requests to node, do our best to ensure it doesn't leak privacy (aka query node for whole block instead of specific tx’s).

If there’s no way to obfuscate, make it opt in (e.g. swap estimations are triggered via button with a privacy notice)

In this case, querying the registry at initialization does not reveal any specific intentions besides wanting to use the system generally. I don’t see an issue with this.

However, as has been suggested in the review, minifront should be requesting asset denom data via rpc calls and not from github directly.

the saveAndReturnMetadata() function is called only for those assets that occur on the user's balance. This does not exactly guarantee that we will have a local copy of the metadata of all assets in the indexed-db

I agree, we should be able to utilize the registry to pre-populate at initialization and the block processor to add to the assets table if it discovers new ones.

I can see some disadvantages to using a local copy of the asset registry

we do not know when the local copy was last updated and whether it contains an up-to-date list of assets

Given this happens at service worker initialization, indexeddb should pretty much always have the latest from the registry.

In addition to saving, we will probably have to make a mechanism for updating the metadata and deleting the metadata.

Saving just overwrites the old, so this is probably fine. Not sure the use-case for deleting, but can revisit that later.

jessepinho · 2024-04-23T17:28:50Z

packages/services/src/view-service/delegations-by-address-index.ts

-              equivalentValues: [
-                {
-                  equivalentAmount: { hi: 0n, lo: 0n },
-                  numeraire: STAKING_TOKEN_METADATA,
-                },
-              ],


Hmm... this means, though, that the staking page will not show the equivalent value of 0 UM for delegation tokens that the user doesn't hold, which is needed as part of the staking page design. If we're pulling metadata from IndexedDB, we don't need to hit the registry — we could just query for the staking token metadata in our database.

jessepinho · 2024-04-23T17:30:24Z

packages/ui/components/ui/tx/view/swap/index.tsx

-const getClaimFeeValueView = (claimFee: Fee) =>
-  new ValueView({
-    valueView: {
-      case: 'knownAssetId',
-      value: {
-        amount: claimFee.amount,
-        metadata: STAKING_TOKEN_METADATA,
-      },
-    },
-  });


Hmm, yeah, this is tricky. Can't think of a better solution for this either.

jessepinho

Changing my review to "Comment" so it's not blocking if someone else approves

grod220 · 2024-04-24T06:54:58Z

apps/extension/package.json

@@ -20,7 +20,7 @@
    "@bufbuild/protobuf": "^1.8.0",
    "@connectrpc/connect": "^1.4.0",
    "@connectrpc/connect-web": "^1.4.0",
-    "@penumbra-labs/registry": "4.0.0",
+    "@penumbra-labs/registry": "^4.1.0",


Was mistakenly pinned before. The caret allows for minor/patch updates to be downloaded as well.

grod220 · 2024-04-24T07:17:59Z

packages/services-context/src/index.ts

@@ -99,10 +101,14 @@ export class Services implements ServicesInterface {
      sctParams: { epochDuration },
    } = params;

+    const registryClient = new ChainRegistryClient();
+    const { stakingAssetId, assetById, numeraires } = await registryClient.get(chainId);


So, at the moment, we generally avoid making calls to an RPC node (or any other server, like GitHub) whenever possible — except for in the block processor.

I think the principle is something like:

Do not make a request to node when we can locally serve the result from indexeddb

If making requests to node, do our best to ensure it doesn't leak privacy (aka query node for whole block instead of specific tx’s).

If there’s no way to obfuscate, make it opt in (e.g. swap estimations are triggered via button with a privacy notice)

In this case, querying the registry at initialization does not reveal any specific intentions besides wanting to use the system generally. I don’t see an issue with this.

However, as has been suggested in the review, minifront should be requesting asset denom data via rpc calls and not from github directly.

the saveAndReturnMetadata() function is called only for those assets that occur on the user's balance. This does not exactly guarantee that we will have a local copy of the metadata of all assets in the indexed-db

I agree, we should be able to utilize the registry to pre-populate at initialization and the block processor to add to the assets table if it discovers new ones.

I can see some disadvantages to using a local copy of the asset registry

we do not know when the local copy was last updated and whether it contains an up-to-date list of assets

Given this happens at service worker initialization, indexeddb should pretty much always have the latest from the registry.

In addition to saving, we will probably have to make a mechanism for updating the metadata and deleting the metadata.

Saving just overwrites the old, so this is probably fine. Not sure the use-case for deleting, but can revisit that later.

grod220 · 2024-04-24T07:19:11Z

packages/services-context/src/index.ts

+      stakingTokenMetadata: Metadata.fromJson(assetById[stakingAssetId]!),
+      numeraires: numeraires.map(numeraires => Metadata.fromJson(assetById[numeraires]!)),


Ah, our registryClient should be deserializing so consumers don't have to do this. I'll open a PR on the other repo to get your thoughts.

Valentine1898 · 2024-04-24T14:30:20Z

apps/minifront/src/fetchers/assets.ts

+export const getAllAssets = async (): Promise<Metadata[]> => {
+  const responses = await Array.fromAsync(viewClient.assets({}));
+  return responses.map(getDenomMetadata);
+};


now we get assets from view service instead of registry

Valentine1898 · 2024-04-24T14:35:47Z

apps/minifront/src/fetchers/registry.ts

+export const getStakingTokenMetadata = async () => {
+  const chainId = await getChainId();
+  if (!chainId) {
+    throw new Error('Could not fetch chain id');
+  }
+
+  const registryClient = new ChainRegistryClient();
+  const { stakingAssetId } = await registryClient.get(chainId);
+  const stakingAssetsMetadata = await getAssetMetadataById(stakingAssetId);
+
+  if (!stakingAssetsMetadata) {
+    throw new Error('Could not fetch staking asset metadata');
+  }
+  return stakingAssetsMetadata;
+};


now we get the stakingAssetId from the registry, and the metadata from the view service. (this makes no sense, but we should always favor local data for privacy reasons)

Gotcha — perhaps we can add stakingAssetId to AppParameters in the future.

Valentine1898 · 2024-04-24T14:37:56Z

apps/minifront/src/utils/zero-value-view.tsx

+ * A default `ValueView` to render when we don't have any balance data for a
+ * particular token.
+ */
+export const zeroValueView = (metadata: Metadata) =>


moved by Jesse suggestion

Valentine1898 · 2024-04-24T14:46:55Z

packages/services/src/view-service/delegations-by-address-index.ts

-              equivalentValues: [
-                {
-                  equivalentAmount: { hi: 0n, lo: 0n },
-                  numeraire: STAKING_TOKEN_METADATA,
-                },
-              ],


In order to pass stakingTokenId as a context key you need to do a lot of work.
The thing is that service-worker cannot access registry because it has no chain-id, we get chain-id when initializing services through querier, and for that querier must be initialized.
I don't think it shouldn't be done, but I suggest to do it in a separate PR on HanlderContext refactoring

How will the design change in this PR:

jessepinho

Great job! And thanks for all the inline comments which helped immensely with reviewing.

jessepinho · 2024-04-26T17:04:27Z

apps/minifront/src/fetchers/registry.ts

+export const getStakingTokenMetadata = async () => {
+  const chainId = await getChainId();
+  if (!chainId) {
+    throw new Error('Could not fetch chain id');
+  }
+
+  const registryClient = new ChainRegistryClient();
+  const { stakingAssetId } = await registryClient.get(chainId);
+  const stakingAssetsMetadata = await getAssetMetadataById(stakingAssetId);
+
+  if (!stakingAssetsMetadata) {
+    throw new Error('Could not fetch staking asset metadata');
+  }
+  return stakingAssetsMetadata;
+};


Gotcha — perhaps we can add stakingAssetId to AppParameters in the future.

Co-authored-by: Jesse Pinho <jesse@jessepinho.com>

…-view/index.tsx Co-authored-by: Jesse Pinho <jesse@jessepinho.com>

Co-authored-by: Jesse Pinho <jesse@jessepinho.com>

Valentine1898 self-assigned this Apr 18, 2024

Valentine1898 force-pushed the asset-registry branch 2 times, most recently from e78a11f to 2ff328d Compare April 23, 2024 12:00

Valentine1898 commented Apr 23, 2024

View reviewed changes

Valentine1898 changed the title ~~WIP: use asset registry~~ Use new registry [part 3] - assets registry Apr 23, 2024

Valentine1898 marked this pull request as ready for review April 23, 2024 12:45

Valentine1898 requested review from grod220, jessepinho, TalDerei and turbocrime April 23, 2024 13:05

Valentine1898 force-pushed the asset-registry branch from 8a61535 to cfcd1eb Compare April 23, 2024 14:49

jessepinho suggested changes Apr 23, 2024

View reviewed changes

jessepinho reviewed Apr 23, 2024

View reviewed changes

jessepinho self-requested a review April 23, 2024 23:31

grod220 reviewed Apr 24, 2024

View reviewed changes

Valentine1898 force-pushed the asset-registry branch from 0d425e9 to 31709f4 Compare April 24, 2024 14:26

Valentine1898 commented Apr 24, 2024

View reviewed changes

Valentine1898 requested a review from grod220 April 24, 2024 14:47

jessepinho approved these changes Apr 26, 2024

View reviewed changes

Valentine1898 added 11 commits April 26, 2024 21:25

rebase main

9e2cfdf

use registry for storage and block processor

27ce3ad

wip: add assets registry for minifront

ce82405

wip

21dbd6c

bump @penumbra-labs/registry

9a9544f

asset registry refactoring

12dba61

fix ui tests

cff6746

fix minifront tests

424c9de

refactor zero value view

0b95ca3

fix unbonding tests

b116698

fix storage tests

352f46b

Valentine1898 and others added 12 commits April 26, 2024 21:30

format

8801593

rebase main

831a5a6

Update apps/minifront/src/components/shared/asset-selector.tsx

9dff455

Co-authored-by: Jesse Pinho <jesse@jessepinho.com>

Update apps/minifront/src/components/staking/account/delegation-value…

83deb25

…-view/index.tsx Co-authored-by: Jesse Pinho <jesse@jessepinho.com>

Update apps/minifront/src/state/staking/index.ts

113e080

Co-authored-by: Jesse Pinho <jesse@jessepinho.com>

revert Jesse reduce suggestion

0616033

bump registry & use assets from indexed-db

24037d1

format

f3e7ad9

move zero-value-view & bump registry

4a088e5

wip

ebde4a5

remove equivalentValues

41c5fb0

rebase main

0d6eca9

Valentine1898 force-pushed the asset-registry branch from 31709f4 to 0d6eca9 Compare April 26, 2024 18:44

Valentine1898 merged commit 0dc3861 into main Apr 26, 2024
6 checks passed

Valentine1898 deleted the asset-registry branch April 26, 2024 18:51

turbocrime mentioned this pull request May 9, 2024

staking token asset id #1038

Closed

		stakingTokenMetadata: Metadata.fromJson(assetById[stakingAssetId]!),
		numeraires: numeraires.map(numeraires => Metadata.fromJson(assetById[numeraires]!)),

Use new registry [part 3] - assets registry #952

Use new registry [part 3] - assets registry #952

Conversation

Valentine1898 commented Apr 18, 2024

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

turbocrime Apr 23, 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

jessepinho Apr 23, 2024 • edited Loading

Choose a reason for hiding this comment

jessepinho 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

Valentine1898 Apr 23, 2024 • edited Loading

Choose a reason for hiding this comment

turbocrime Apr 23, 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

jessepinho 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

jessepinho left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

turbocrime Apr 23, 2024 •

edited

Loading

jessepinho Apr 23, 2024 •

edited

Loading

Valentine1898 Apr 23, 2024 •

edited

Loading

turbocrime Apr 23, 2024 •

edited

Loading