ADR-41: Collection Items Approval Flow Enhancement

More details about this document
Latest published version:
https://adr.decentraland.org/adr/ADR-41
Authors:
menduz
pentreathm
cazala
nachomazzara
Feedback:
GitHub decentraland/adr (pull requests, new issue, open issues)
Edit this documentation:
GitHub View commits View commits on githistory.xyz

Statement of the problem

The Catalysts accepts only:

The first one is risky because the catalyst does not have a way to validate the content submitted and someone can submit as many contents as they wish flooding the storage. All the content submitted to the catalyst must be validated by content hashing.

Consensus changes

The consensus rules of the catalyst will modify the validations to the deployment of collection entities, that validation will now verify that:

Alternative A ✅

These two transactions will simulate an approve(hash).

Check here for further reference of smart contracts.

Create a Decentraland collection

sequenceDiagram
  participant C as Creator
  participant B as Builder
  participant PT as Builder Server
  participant M as Matic Collection Factory
  participant MC as Matic Collection

  C->>B: Create collection & upload items
  B-->>PT: Save collection & items
  C->>B: Publish collection
  B-->>M: Deploy collection
  M-->>MC: Create collection

Create third party Item

sequenceDiagram
  participant C as Creator
  participant B as Builder
  participant PT as Builder Server
  participant TPR as Matic Third Party Registry

  C->>B: Create collection & upload items
  B-->>PT: Save collection & items
  C->>B: Publish items
  B-->>TPR: Upload items

Create and update items

sequenceDiagram
  participant U as User
  participant B as Builder
  participant PT as Builder Server
  U->>B: Upload new version of item
  B-->>B: Edit item metadata
  B->>PT: Save item

Propagate deployments to Cataysts

sequenceDiagram
  participant C as Committee
  participant PT as Builder server
  participant B as Builder
  participant M as Matic Collection
  participant P as DAO Peer
  B->>PT: Fetch all \nitems from a collection
  C->>B: approve(content_hashes[])
  B-->>B: Create new deployments for the catalyst using\nspecific assets from content hashes
  B->>M: sendTx: approve(content_hashes)
  M-->>M: Update item hashes & approve collection
  M-->>B: txMined
  B->>P: Deploy entitities
  M-->>P: approved content_hashes[]
  P->>P: Check and accept deployments

Get (non-catalyst) content to test in-world

sequenceDiagram
  participant BS as Builder server
  participant E as Explorer
  E->>BS: fetch items

Change editable parameters from items (Decentraland Collections only)

beneficiary, price, name, description, category, body shapes.

sequenceDiagram
  participant C as Creators
  participant B as Builder
  participant M as Matic Collection
  participant BS as Builder Server
  C->>B: Update item\n price & beneficiary
  B-->>M: Send TX
  BS-->>M: Consolidate by fetching\nthe collection subgraph

Approve process (committee)

sequenceDiagram
  participant Ct as Creator
  participant B as Builder
  participant BS as Builder Server
  participant C as Committee
  participant M as Matic Collection
  participant peer as DAO Catalyst
  note over Ct: Play and upload collection
  Ct->>B: Upload new versions
  B-->>BS: save item
  Ct->>B: Upload new versions
  B-->>BS: save item
  Ct->>B: Upload new versions
  B-->>BS: save item
  Ct->>B: Upload new versions
  B-->>BS: save item
  Ct->>B: Item/collection ready to review
  Ct-->>M: Publish if needed(first time)
  B-->>C:Collection ready for review
  note over C: Review by committee
  C->>C: Approve hash1 + category
  C->>C: Approve hash2 + category
  C->>B: approve items with hashes
  B-->>M: sendTx: approve(content_hashes)
  B->>B: Wait for tx
  M-->>B: txMined
  note over B: Upload approved content to catalyst
  B->>peer: Upload hashed entity, using any signer
  peer->>M: Validate hashes

Alternative B

Using non-DAO catalyst with new flags to provide a decentralized way of storing the items instead of the builder-server.

This alternative is not needed for the time being cause the builder-server is already used when the collection items are not published yet.

Development proposed

Milestone 1

Milestone 2

License

Copyright and related rights waived via CC0-1.0. Living