[Feature]: ERC1155 Extension Implementations

[aapsi]

[Feature]: ERC1155 Extension Implementations

Description

Following the recent addition of URI management (baseURI + tokenURIs) to ERC1155Facet, this issue tracks discussion and implementation of additional ERC1155 extensions.

Design Philosophy: Add useful functionality to the main facet unless it significantly increases gas costs on transfers/mints/burns (similar to how ERC721Enumerable is separate).

[aapsi]

Hey @mudgen @maxnorm
I will start with the research and will propose my approach.

[beebozy]

Hi @mudgen could you assign me this.. I am about to implement it ?

[maxnorm]

Hi @mudgen could you assign me this.. I am about to implement it ?

Hi @beebozy, thanks for the interest.

can you explain what you want implement before? The tokenURI and everything said in the issue was merged in the recent ERC1155 PR.

this issue is to highlight additional extensions of ERC1155 worth supporting in Compose.

before implementing any code, please provide which extension and some details about how it's going to be implemented.

This issue is currently in research stage. You can do some research along side @aapsi on this.

[panditdhamdhere]

Hi are you still working on it ?

[aapsi]

Hi @panditdhamdhere
Yes, I will provide an update soon
@beebozy shall we connect to discuss our approach?

[big14way]

Hi I can implement this please assign me this issue

[maxnorm]

Hi I can implement this please assign me this issue

Hi @big14way, this is currently a research issue before the real implementation. We want to highlight all possible extensions/features worth supporting for the ERC1155. The goal is to have the more complete implementation out of the box.

@aapsi is already on it, but you can always consolidate your findings here.

Once this research part is done, we will evaluate all of proposition and assign people for the actual implementation.

[mudgen]

@aapsi @farismln @maxnorm @adamgall @isihin-3

Design Philosophy: Add useful functionality to the main facet unless it significantly increases gas costs on transfers/mints/burns (similar to how ERC721Enumerable is separate).

Correct. This is absolutely what I said. Fortunately we are still early in the composition of Compose, and I can still change its basic design principles (though I think that will be rare). I am changing how we are doing this.

We are no longer trying to pack as much useful functionality as we can in a single facet.

Prior design philosophy

The prior idea was that we could make Compose composable at the facet/contract level and at the function level. Function level composability means that a person can choose which functions from each facet to add to their diamond. Just because a facet has a number of functions doesn't mean a person needs to add all of them to their diamond -- they can instead add the ones they want to based on the functionality they want to have. That was the prior idea.

There are a few problems with this approach:

1. I think it will be harder for people to conceptualize, or understand their system at a function level. It is too fine-grained.
2. It will be harder to understand the source code of a deployed system since each facet contains all the function source code, not just the source code of the functions that they use. So the facets will contain a lot of source code not actually used by diamonds, since only some of the functions were added to the diamonds.
3. Larger facets are be harder to read and understand than smaller ones.
4. Organizationally it is harder to see different functionality if they are packed in facets. For example if a file directory (or any list of facets) shows a list of different facets by different extensions and functionality, people can easily see what functionality exists or is supported.

Our new and current design philosophy

We are no longer composing at the function level and facet level. We are composing at the facet level only.

1, Each facet is a self-contained, conceptual unit.
2, A facet is designed for all of its functions to be added, not just some of them.
3. The facet is our smallest building block.
4. Every extension of a standard should be implemented as a separate facet that composes with the standard functionality it works with.
5. A set of functions that represent a single unit of self-contained functionality should only be extended with a new facet that composes with that functionality.
6. The source code of a facet should only contain the code (including storage variables, if possible) that it actually uses.
7. A facet should reuse the structs and their diamond storage locations which are originally defined in other facets and facet libraries. But, if possible, it should only include the storage variables that it actually uses. Of course a reused struct must maintain the same storage layout as an originally defined struct. Reusing structs is done by copying structs, and modifying them as needed to remove unused variables.
8. Facets are self-contained code units. They do not import anything.
9. Facet libraries are self-contained code units. They do not import anything.
10. Facet libraries are used to initialize facets upon deployment, and in deploying upgrades. Facet libraries are also used by users of Compose to integrate custom facets with Compose facets.
11. Facet libraries can have an initialize function which is used to initialize storage variables defined and used by the corresponding facet during deployment.
12. Facets and facet libraries should not contain owner or admin authorization checks, unless absolutely required or a core part of the functionality being implemented.

I think this is the right level of onchain composability for creating the most organized, modular, and easy to understand onchain smart contract systems.

If you think there is some kind of exception to these design principles/rules/choices in some case, for some reason, then let me know so I can look at it and we can discuss.

[pellyadolfo]

Our new and current design philosophy

We are no longer composing at the function level and facet level. We are composing at the facet level only.

should we build a list of potential use cases to kick this facet vision? The skills to build these kind of facets are probably different, I guess that a roadmap is needed. This view is more about patterns discussion before implementation. Just my thoughts.

[aapsi]

@pellyadolfo Agreed!!