Updatable Metadata #3

samwise2 · 2023-06-26T04:48:48Z

This PR adds two new instructions update_metadata and update_metadata_collection_nft to Bubblegum which enable updates to cNFT metadata after mint.

High level overview of update_metadata:

name, symbol, uri, creators, seller_fee_basis_points, primary_sale_happened and is_mutable can all be updated.
update_metadata must be signed by the tree_delegate.
update_metadata can only be invoked for NFTs which are not linked to verified collections.
A creator cannot be verified by this instruction. New un-verified creators can be added, existing creators can be removed, but a new, verified creator cannot be added.
update_metadata CPIs to replace_leaf. Thus it requires the old hash of the leaf's metadata. Unfortunately, the ix cannot simply take old_data_hash as an argument because it needs to check the is_mutable flag to see if the metadata update is valid. For this reason, the instruction needs to intake the un-hashed form of the old MetadataArgs. Since MetadataArgs is a large struct, we've provided the optionality to pass it directly as an argument, or through data in an account, allowing the caller to make a decision regarding the tradeoffs between tx space and rent allocation.

High level overview of update_metadata_collection_nft:

Allows metadata updates for cNFTs which are part of verified collections.
A collection_authority must sign to authorize the metadata changes.
Otherwise identical to update_metadata

This PR adds two js-solita client tests to show the correctness of the ix's and demonstrate how they can be invoked.

c4b4d4 · 2023-08-05T16:41:32Z

wen merge 🪄

danenbm · 2023-08-30T21:33:19Z

wen merge 🪄

Reviewing now

danenbm

I've mostly looked at the contract changes, but haven't looked at the generated code or tests in detail yet. But I wanted to post my initial comments.

The code is looking great, I like the design and implementation, and I like the extra protection for items already in a verified collection. I'll post again if I have any more comments after looking at the rest.

clients/js-solita/package.json

programs/bubblegum/program/src/lib.rs

danenbm · 2023-08-31T22:57:43Z

programs/bubblegum/program/src/lib.rs

+        let no_new_creators_were_verified = creators
+            .iter()
+            .filter(|c| c.verified) // select only creators that are verified
+            .all(|c| {
+                old_creators
+                    .iter()
+                    .any(|old| old.address == c.address && old.verified)
+            });
+        require!(
+            no_new_creators_were_verified,
+            BubblegumError::CreatorDidNotVerify
+        );


I know it says we don't want to verify new creators, but we also need to make it check that we don't unverify previously verified creators. I need to study the logic more but I'm not sure if it does the second case.

Either way, could you create some tests specifically to make sure those two conditions will fail? The test is also important to make sure it doesn't regress in the future.

Yeah this check doesn't prevent the issuer of the update from un-verifying some creators. I can change the check to do that. Originally, I made the choice intentionally, since the tree_delegate has to sign-off on mints, I figured they could arbitrarily control creators for an NFT as desired, and then those creators can opt to sign and verify themselves or not. Under that premise, I thought it may be reasonable that the updater could unverify or even completely remove creators, if they desired (that is also permitted here).

It does seem possible though that two parties could agree for a specific address to be a creator for some period of time, and then want to remove them afterwards. I.e. two parties agree that A will be a creator (and receive royalties) for 3 months, after which they will be removed. I suppose their share could also be updated to 0, but they may want to replace that creator slot.

Let me know what you think about the above. I'll leave the check as-is for now, and only add a test that a new creator cannot be verified through this ix. But if after reading the thread above, you feel we still want to enforce the old creators cannot be removed/unverified I can add additional tests for that

The current behaviour for NFTs is that Update does not remove verified creators nor unverify them. This prevents the authority to unilaterally remove a verified creator from the creator array, although as you pointed out, they can set the share to 0. The only exception is when the authority itself is a creator.

I think we should follow the current NFT behavior, including not allowing removing verified creators unless the signing authority is the verified creator being removed. In general that is what people will expect from us.

Added code that prevents removing existing verified creators during metadata update.

Note: I added the exception cases for the transaction signer as well (tree delegate): the tree delegate can add itself as a new verified creator, or remove/unverify itself even if it is a currently verified creator.

Also added 4 tests to test these cases:
✓ Cannot verify currently unverified creator if not signer (14148 ms)
✓ Can verify currently unverified creator if signer (14143 ms)
✓ Cannot unverify currently verified creator if not signer (14547 ms)
✓ Can unverify currently verified creator if signer (14561 ms)

danenbm · 2023-09-01T00:14:32Z

Note initial design discussion was done here: metaplex-foundation/metaplex-program-library#1121

clients/js-solita/tests/main.test.ts

clients/js/src/generated/instructions/index.ts

programs/bubblegum/program/src/lib.rs

febo · 2023-09-06T21:16:37Z

@samwise2 I will have a look at the program in detail now, but I have a question regarding the update_metadata and update_metadata_collection_nft. Could you please elaborate on the rationale for having two update instructions? More specifically, the idea of having the collection authority to sign off metadata changes.

This is a bit different to how NFTs currently work, in the sense that you have the update_authority that controls the metadata and the collection_authority that controls which NFTs are part of a collection. Requiring the collection_authority to be a signer for update makes the collection_authority an "authority" of the cNFT in the context of metadata update, which might not be expected.

programs/bubblegum/program/src/lib.rs

febo · 2023-09-06T23:24:59Z

programs/bubblegum/program/src/lib.rs

+}
+
+#[derive(Accounts)]
+pub struct UpdateMetadataCollectionNFT<'info> {


I am not sure we need 2 separate Update instructions.

Will remove ``update_metadata_collection_nft` from our repo/branch as follow-on PR.

programs/bubblegum/program/src/lib.rs

samwise2 · 2023-09-09T19:36:41Z

@samwise2 I will have a look at the program in detail now, but I have a question regarding the update_metadata and update_metadata_collection_nft. Could you please elaborate on the rationale for having two update instructions? More specifically, the idea of having the collection authority to sign off metadata changes.

This is a bit different to how NFTs currently work, in the sense that you have the update_authority that controls the metadata and the collection_authority that controls which NFTs are part of a collection. Requiring the collection_authority to be a signer for update makes the collection_authority an "authority" of the cNFT in the context of metadata update, which might not be expected.

Yeah, I think the tricky bit here is that there is no update_authority in MetadataArgs, so we can't follow the same paradigm (to my knowledge). We could version MetadataArgs to include an update_authority but that seems very difficult for backwards compatibility, indexing etc. The implementation here suggests that cNFTs which aren't linked to collections are basically freely updatable by their owners (as long as they were minted with is_mutable = true). Otherwise, if they were linked to a verified collection, we look to the collection_authority in lieu of an update_authority.

One other thing to consider here is compress/decompress. I'm not super well versed in that part of the code, but from what I can tell, the way update_authority is assigned during decompress is as some PDA of Bubblegum. If we were to use some notion of update_authority here, and deployed the code, then decompress would start overriding update_authority due to its implementation -- leading to potentially unexpected results for users.

Super open to discussion here, but that was the initial thinking for creating two ixs. Technically, all of the logic here could be combined into one ix, with lots of optional accounts, etc. but that just makes the interface clumsier imo. With two ixs it is clear what has to be provided by the client depending on the kind of NFT they have.

danenbm · 2023-09-11T22:26:04Z

@samwise2 I will have a look at the program in detail now, but I have a question regarding the update_metadata and update_metadata_collection_nft. Could you please elaborate on the rationale for having two update instructions? More specifically, the idea of having the collection authority to sign off metadata changes.
This is a bit different to how NFTs currently work, in the sense that you have the update_authority that controls the metadata and the collection_authority that controls which NFTs are part of a collection. Requiring the collection_authority to be a signer for update makes the collection_authority an "authority" of the cNFT in the context of metadata update, which might not be expected.

Yeah, I think the tricky bit here is that there is no update_authority in MetadataArgs, so we can't follow the same paradigm (to my knowledge). We could version MetadataArgs to include an update_authority but that seems very difficult for backwards compatibility, indexing etc. The implementation here suggests that cNFTs which aren't linked to collections are basically freely updatable by their owners (as long as they were minted with is_mutable = true). Otherwise, if they were linked to a verified collection, we look to the collection_authority in lieu of an update_authority.

One other thing to consider here is compress/decompress. I'm not super well versed in that part of the code, but from what I can tell, the way update_authority is assigned during decompress is as some PDA of Bubblegum. If we were to use some notion of update_authority here, and deployed the code, then decompress would start overriding update_authority due to its implementation -- leading to potentially unexpected results for users.

Super open to discussion here, but that was the initial thinking for creating two ixs. Technically, all of the logic here could be combined into one ix, with lots of optional accounts, etc. but that just makes the interface clumsier imo. With two ixs it is clear what has to be provided by the client depending on the kind of NFT they have.

Yes during decompress the token-metadata update_authority assigned is a PDA of bubblegum. However, while the cNFT is still compressed, we have been treating the tree owner/tree delegate as the update_authority (i.e., in set_and_verify_collection we do this). One clarification that in this PR the items will not be updatable by the item owner, but by the tree owner/tree delegate. I want to quick chat with @febo and see if we want to make any changes to this viewpoint... either we want to continue viewing tree owner/delegate as update authority, or maybe we do want to require collection-level authority as you have already coded.

danenbm · 2023-09-12T17:24:33Z

@samwise2 I will have a look at the program in detail now, but I have a question regarding the update_metadata and update_metadata_collection_nft. Could you please elaborate on the rationale for having two update instructions? More specifically, the idea of having the collection authority to sign off metadata changes.
This is a bit different to how NFTs currently work, in the sense that you have the update_authority that controls the metadata and the collection_authority that controls which NFTs are part of a collection. Requiring the collection_authority to be a signer for update makes the collection_authority an "authority" of the cNFT in the context of metadata update, which might not be expected.

Yeah, I think the tricky bit here is that there is no update_authority in MetadataArgs, so we can't follow the same paradigm (to my knowledge). We could version MetadataArgs to include an update_authority but that seems very difficult for backwards compatibility, indexing etc. The implementation here suggests that cNFTs which aren't linked to collections are basically freely updatable by their owners (as long as they were minted with is_mutable = true). Otherwise, if they were linked to a verified collection, we look to the collection_authority in lieu of an update_authority.
One other thing to consider here is compress/decompress. I'm not super well versed in that part of the code, but from what I can tell, the way update_authority is assigned during decompress is as some PDA of Bubblegum. If we were to use some notion of update_authority here, and deployed the code, then decompress would start overriding update_authority due to its implementation -- leading to potentially unexpected results for users.
Super open to discussion here, but that was the initial thinking for creating two ixs. Technically, all of the logic here could be combined into one ix, with lots of optional accounts, etc. but that just makes the interface clumsier imo. With two ixs it is clear what has to be provided by the client depending on the kind of NFT they have.

Yes during decompress the token-metadata update_authority assigned is a PDA of bubblegum. However, while the cNFT is still compressed, we have been treating the tree owner/tree delegate as the update_authority (i.e., in set_and_verify_collection we do this). One clarification that in this PR the items will not be updatable by the item owner, but by the tree owner/tree delegate. I want to quick chat with @febo and see if we want to make any changes to this viewpoint... either we want to continue viewing tree owner/delegate as update authority, or maybe we do want to require collection-level authority as you have already coded.

Chatted with @febo and for right now we would like to skip the update_metadata_collection_nft. Even though this is an effective method for managing at collection-level and we may use it in the near future, before committing to this specific approach we want to spend some time separately designing exactly how additional update authority concepts will work in Bubblegum. So for the short term we should just limit this PR to using the tree authority/tree delegate as the initial metadata update authority.

Exception: allow verification/unverification during metadata update for the signer of the tx.

danenbm · 2023-09-20T00:02:59Z

@samwise2 I will have a look at the program in detail now, but I have a question regarding the update_metadata and update_metadata_collection_nft. Could you please elaborate on the rationale for having two update instructions? More specifically, the idea of having the collection authority to sign off metadata changes.
This is a bit different to how NFTs currently work, in the sense that you have the update_authority that controls the metadata and the collection_authority that controls which NFTs are part of a collection. Requiring the collection_authority to be a signer for update makes the collection_authority an "authority" of the cNFT in the context of metadata update, which might not be expected.

Yeah, I think the tricky bit here is that there is no update_authority in MetadataArgs, so we can't follow the same paradigm (to my knowledge). We could version MetadataArgs to include an update_authority but that seems very difficult for backwards compatibility, indexing etc. The implementation here suggests that cNFTs which aren't linked to collections are basically freely updatable by their owners (as long as they were minted with is_mutable = true). Otherwise, if they were linked to a verified collection, we look to the collection_authority in lieu of an update_authority.
One other thing to consider here is compress/decompress. I'm not super well versed in that part of the code, but from what I can tell, the way update_authority is assigned during decompress is as some PDA of Bubblegum. If we were to use some notion of update_authority here, and deployed the code, then decompress would start overriding update_authority due to its implementation -- leading to potentially unexpected results for users.
Super open to discussion here, but that was the initial thinking for creating two ixs. Technically, all of the logic here could be combined into one ix, with lots of optional accounts, etc. but that just makes the interface clumsier imo. With two ixs it is clear what has to be provided by the client depending on the kind of NFT they have.

Yes during decompress the token-metadata update_authority assigned is a PDA of bubblegum. However, while the cNFT is still compressed, we have been treating the tree owner/tree delegate as the update_authority (i.e., in set_and_verify_collection we do this). One clarification that in this PR the items will not be updatable by the item owner, but by the tree owner/tree delegate. I want to quick chat with @febo and see if we want to make any changes to this viewpoint... either we want to continue viewing tree owner/delegate as update authority, or maybe we do want to require collection-level authority as you have already coded.

Chatted with @febo and for right now we would like to skip the update_metadata_collection_nft. Even though this is an effective method for managing at collection-level and we may use it in the near future, before committing to this specific approach we want to spend some time separately designing exactly how additional update authority concepts will work in Bubblegum. So for the short term we should just limit this PR to using the tree authority/tree delegate as the initial metadata update authority.

I'm going to merge this PR with update_metadata_collection_nft and then remove it from our repo/branch.

febo · 2023-09-22T00:48:04Z

programs/bubblegum/program/src/state/metaplex_adapter.rs

@@ -102,3 +102,14 @@ pub struct MetadataArgs {
    pub token_program_version: TokenProgramVersion,
    pub creators: Vec<Creator>,
 }
+
+#[derive(AnchorSerialize, AnchorDeserialize, PartialEq, Eq, Debug, Clone)]


We should derive Default here, so we could have:

UpdateArgs { name: Some("New name"), ..Default::default() }

febo

Only a super minor comment.

danenbm

BPF tests pass.
Umi tests pass.
js-solita tests pass except for decompression one which needs the recent changes from main, which we will get in the update-metadata branch.

febo

LGTM

programs/bubblegum/program/src/lib.rs

* Fix binary name * Set decompressible on tree creation

* Removing deploy capabilities * Adding back program deploy. * Update collection verification checks * Add Umi tests around collection verification * Add deprecated log message (#2) * Set decompressible on tree creation (#3) * Fix binary name * Set decompressible on tree creation * Fix binary name * Revert "Removing deploy capabilities" This reverts commit c203069. --------- Co-authored-by: blockiosaurus <[email protected]> Co-authored-by: Fernando Otero <[email protected]>

Original design discussion PR: metaplex-foundation/metaplex-program-library#1121 Original merged PR: #3 --------- * fix protocol conflicts * allow updating creators without new verifications * cleanup * conflicts * conflicts * all tests included * regen solita and fix bugs * small fixes * nit * address code review, without additional test * added creator verification test * Regenerate js client * Rename old_metadata to current_metadata * Use UpdateArgs to group new metadata params * Prevent existing verified creators from being removed Exception: allow verification/unverification during metadata update for the signer of the tx. * Derive Default on UpdateArgs * Fix typo * Regenerate IDL, Rust client and Umi client * Regenerate js-solita * Add canopy to JS Solita test since it uses 2 nodes * Run CI on any PR * Removing SetDecompressableState from pub enum InstructionName * Remove `update_metadata_collection_nft` instruction (#47) * Remove update_metadata_collection_nft ix * Remove unneeded checks and errors * Regenerate IDL and clients * Update Solita test --------- Co-authored-by: Sam Orend <[email protected]>

* Update metadata (#44) Original design discussion PR: metaplex-foundation/metaplex-program-library#1121 Original merged PR: #3 --------- * fix protocol conflicts * allow updating creators without new verifications * cleanup * conflicts * conflicts * all tests included * regen solita and fix bugs * small fixes * nit * address code review, without additional test * added creator verification test * Regenerate js client * Rename old_metadata to current_metadata * Use UpdateArgs to group new metadata params * Prevent existing verified creators from being removed Exception: allow verification/unverification during metadata update for the signer of the tx. * Derive Default on UpdateArgs * Fix typo * Regenerate IDL, Rust client and Umi client * Regenerate js-solita * Add canopy to JS Solita test since it uses 2 nodes * Run CI on any PR * Removing SetDecompressableState from pub enum InstructionName * Remove `update_metadata_collection_nft` instruction (#47) * Remove update_metadata_collection_nft ix * Remove unneeded checks and errors * Regenerate IDL and clients * Update Solita test --------- Co-authored-by: Sam Orend <[email protected]> * Avoid inlining UpdateArgs (#50) * Adding LeafSchemaEvent struct to Rust client * Add leaf schema accessors to program and Rust client * Add InstructionName::UpdateMetadata to Rust client * chore: Release mpl-bubblegum version 1.0.1-beta.1 * Add borsh version range (#54) * Add borsh version range * Update lock file * chore: Release mpl-bubblegum version 1.0.1-beta.2 * Remove optional metadata buffer account from update_metadata * Update Rust and Umi JS clients, update IDL * Update js-solita client * Fixing rust client cargo lock after release downgrades it * chore: Release mpl-bubblegum version 1.0.1-beta.3 * Delete and regenerate rust client Cargo.lock after release downgrades borsh 0.10.3 * Add update_metadata_collection_nft * Regenerate clients * Regenerate Solita JS client * update Solita tests * Fix path to js test script * Remove signer req for tree delegate on update_metadata_collection_nft * Regenerate Solita JS client * Add tests for using correct ix based on if item is in collection * Combine update_metadata and update_metadata_collection_nft * Regenerate JS and Rust clients * Regenerate Solita JS client * Update Solita tests * Removed unneeded instruction name * Regenerate IDL * Clean up README and add update_metadata * Add updateArgs and fix links * Remove redundancies and clarify * chore: Release mpl-bubblegum version 1.0.1-beta.4 --------- Co-authored-by: Sam Orend <[email protected]> Co-authored-by: Fernando Otero <[email protected]> Co-authored-by: febo <[email protected]> Co-authored-by: danenbm <[email protected]>

Add canopy size check

samwise2 added 7 commits August 29, 2023 14:34

fix protocol conflicts

c718251

allow updating creators without new verifications

0494b7a

cleanup

922e3c5

conflicts

b1e970d

conflicts

fdc2fff

all tests included

c71ac65

regen solita and fix bugs

c8864df

samwise2 force-pushed the samwise2/updatable-metadata branch from 04ce25b to c8864df Compare August 29, 2023 19:33

small fixes

4855ed4

samwise2 marked this pull request as ready for review August 29, 2023 20:20

nit

3bd2532

danenbm self-requested a review August 30, 2023 21:33

danenbm requested changes Aug 31, 2023

View reviewed changes

danenbm requested a review from febo August 31, 2023 23:53

danenbm requested changes Sep 1, 2023

View reviewed changes

clients/js-solita/tests/main.test.ts Outdated Show resolved Hide resolved

clients/js/src/generated/instructions/index.ts Show resolved Hide resolved

programs/bubblegum/program/src/lib.rs Outdated Show resolved Hide resolved

samwise2 added 2 commits September 3, 2023 13:24

address code review, without additional test

a938436

added creator verification test

950aa74

samwise2 mentioned this pull request Sep 3, 2023

feat: Add ability to add creators to cNFTs #16

Closed

samwise2 requested a review from danenbm September 5, 2023 03:12

febo reviewed Sep 6, 2023

View reviewed changes

programs/bubblegum/program/src/lib.rs Outdated Show resolved Hide resolved

febo reviewed Sep 6, 2023

View reviewed changes

programs/bubblegum/program/src/lib.rs Outdated Show resolved Hide resolved

febo reviewed Sep 6, 2023

View reviewed changes

programs/bubblegum/program/src/lib.rs Outdated Show resolved Hide resolved

febo reviewed Sep 6, 2023

View reviewed changes

programs/bubblegum/program/src/lib.rs Outdated Show resolved Hide resolved

febo reviewed Sep 6, 2023

View reviewed changes

programs/bubblegum/program/src/lib.rs Outdated Show resolved Hide resolved

febo reviewed Sep 6, 2023

View reviewed changes

programs/bubblegum/program/src/lib.rs Outdated Show resolved Hide resolved

Regenerate js client

ec91fce

danenbm added 3 commits September 18, 2023 08:51

Rename old_metadata to current_metadata

bd82228

Use UpdateArgs to group new metadata params

2d65a4b

Prevent existing verified creators from being removed

0173305

Exception: allow verification/unverification during metadata update for the signer of the tx.

danenbm changed the base branch from main to update_metadata September 20, 2023 03:39

danenbm requested review from febo and blockiosaurus September 20, 2023 03:41

danenbm approved these changes Sep 20, 2023

View reviewed changes

febo reviewed Sep 22, 2023

View reviewed changes

febo suggested changes Sep 22, 2023

View reviewed changes

Derive Default on UpdateArgs

367d3f3

danenbm requested a review from febo September 22, 2023 23:26

danenbm approved these changes Sep 22, 2023

View reviewed changes

febo approved these changes Sep 23, 2023

View reviewed changes

blockiosaurus requested changes Sep 23, 2023

View reviewed changes

programs/bubblegum/program/src/lib.rs Outdated Show resolved Hide resolved

programs/bubblegum/program/src/lib.rs Show resolved Hide resolved

programs/bubblegum/program/src/lib.rs Show resolved Hide resolved

programs/bubblegum/program/src/lib.rs Show resolved Hide resolved

Fix typo

eb72750

blockiosaurus self-requested a review September 26, 2023 18:54

blockiosaurus approved these changes Sep 26, 2023

View reviewed changes

danenbm merged commit 256e6ee into metaplex-foundation:update_metadata Sep 26, 2023

danenbm pushed a commit that referenced this pull request Sep 28, 2023

Set decompressible on tree creation (#3)

26d7e93

* Fix binary name * Set decompressible on tree creation

danenbm mentioned this pull request Oct 2, 2023

Update metadata #44

Merged

danenbm mentioned this pull request Jan 9, 2024

Bubblegum: Updatable Metadata metaplex-foundation/metaplex-program-library#1121

Closed

2 tasks

StanChe added a commit that referenced this pull request Sep 20, 2024

Merge pull request #3 from n00m4d/feat/canopy-size-check

20478c6

Add canopy size check

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Updatable Metadata #3

Updatable Metadata #3

samwise2 commented Jun 26, 2023 •

edited

Loading

c4b4d4 commented Aug 5, 2023

danenbm commented Aug 30, 2023

danenbm left a comment

danenbm Aug 31, 2023

samwise2 Sep 3, 2023

samwise2 Sep 3, 2023

samwise2 Sep 3, 2023

febo Sep 6, 2023

danenbm Sep 7, 2023

danenbm Sep 19, 2023 •

edited

Loading

danenbm commented Sep 1, 2023

febo commented Sep 6, 2023

febo Sep 6, 2023

danenbm Sep 20, 2023 •

edited

Loading

samwise2 commented Sep 9, 2023 •

edited

Loading

danenbm commented Sep 11, 2023 •

edited

Loading

danenbm commented Sep 12, 2023

danenbm commented Sep 20, 2023

febo Sep 22, 2023

danenbm Sep 22, 2023

febo left a comment

danenbm left a comment

febo left a comment

Updatable Metadata #3

Updatable Metadata #3

Conversation

samwise2 commented Jun 26, 2023 • edited Loading

c4b4d4 commented Aug 5, 2023

danenbm commented Aug 30, 2023

danenbm 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

danenbm Sep 19, 2023 • edited Loading

Choose a reason for hiding this comment

danenbm commented Sep 1, 2023

febo commented Sep 6, 2023

Choose a reason for hiding this comment

danenbm Sep 20, 2023 • edited Loading

Choose a reason for hiding this comment

samwise2 commented Sep 9, 2023 • edited Loading

danenbm commented Sep 11, 2023 • edited Loading

danenbm commented Sep 12, 2023

danenbm commented Sep 20, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

febo left a comment

Choose a reason for hiding this comment

danenbm left a comment

Choose a reason for hiding this comment

febo left a comment

Choose a reason for hiding this comment

samwise2 commented Jun 26, 2023 •

edited

Loading

danenbm Sep 19, 2023 •

edited

Loading

danenbm Sep 20, 2023 •

edited

Loading

samwise2 commented Sep 9, 2023 •

edited

Loading

danenbm commented Sep 11, 2023 •

edited

Loading