To Do
- @April 24, 2024 Listen to Optimystics Call on April 22nd again
- @April 25, 2024 Listen to Optimystics Call on April 22nd again
Consider if we should make Respect ERC1155-similar like Hats Protocol who also uses non-transferrable tokens
https://docs.hatsprotocol.xyz/for-developers/hats-protocol-overview/erc1155-compatibility
Reasons to Migrate to ERC-1155
Developer Accessibility and Legibility
- I think this is currently a bottleneck in several projects and a barrier to entry for developers to get involved because they don’t know how to interact with it, whereas they’d have an easier time grasping it if it used just ERC1155 standard
- For example, this may make it easier to integrate with EAS. I’m thinking about creating a schema See Follow up with Nestor about EAS for an example and details
- Several people have asked about the design and I’m not totally sure how to explain it without you being there
- Is it actually two different tokens right now or just that it’s viewable in two different interfaces?
Integration with Roles and Reputations
The Roles and Reputations front-end seems to use ERC 1155 as the reputation token. It seems quite well developed and useful for Optimism Fractal. It’s created by Jacob Homanics, who is supporting it’s further growth and joined Optimism Fractal in OF 24. You can learn more about this in Research Roles and Reputations System (from Jacob Homanics with ATX DAO)
Current Status of Respect Token
- We’re currently considering if we should migrate the Optimism Fractal Respect token to an ERC 1155 token standard.
- The current implementation of Respect uses a unique combination of ERC721 and ERC20 token standards which allows you to see Respect in both ERC20 (fungible) and ERC 721 (nonfungible) token interfaces.
- Here is the Github repository with the current Optimism Fractal smart contracts.
- Tadas said that the best and most recent explanation of the contract’s design can be found here. You can read the explanation in the ‘background’ section near the top of the page if you’re interested. Tadas wrote this page in February to explain the unique design of the contract and improve how Respect displays in block explorers. At the end of the page he also considered the possibility of migrating the Respect token to an ERC-1155 standard.
- For more details and rationale, you can see Tadas explain how the smart contract implements interfaces of both ERC20 and NFT standard for the Respect token in this video. If you’re interested in learning about the philosophy originally behind this design, you could also see this blog post and video clip for more details.
- I’m wondering if implementing Roles and Respect could make it easier for us to migrate to ERC-1155 by adopting an open-source and well supported standard that includes many helpful integrations out of the box.
- After Tadas wrote the explanations linked below, I did a lot of research wrote the following page: Consider migrating to ERC-1155. This page includes reasons why I think that we should migrate Respect to a ERC1155 token standard and questions about doing so
Questions about Roles and Reputation Token Standards
- Would Roles and Reputations work with the current implementation as well or only if we switched to ERC1155?
- We’re currently using a non-standard implementation of token standards for Respect where Respect can be viewed as both ERC721 and ERC
- We’re thinking about migrating Respect to an ERC1155, as you can see in this task: Consider migrating to ERC-1155
- Can the ERC1155 implementation accomplish all the same benefits as the current implementation with ERC721 and ERC20?
- Benefits of the current implementation include:
- Ability to set roles and permissions on a time basis (ie set councilors as top 6 respect earners over the past 12 weeks)
- This can also be flexibly used in other many ways too, such as sending awards or rewards to people who participated in OF Season 2 based upon the Respect earned in that season
- Ability to see total amount of Respect in addition to visible NFT for each token
- Would it make sense to use ERC 404 instead of ERC1155 or ERC721 and ERC20?
- I watched Jacob’s video about Trash NFT’s and learned about ERC 404. I organized details about ERC 404 in Consider implementing ERC 404 Token Standard for Respect.
- My intuition is that it’s probably better to use a more proven and supported standard like ERC1155 than ERC404, but the fact that ERC 404 uses a similar design to Tadas’ implementation is enticing….
- Does ERC404 token standard work with Roles and Reputations instead of ERC1155?
To Do
- This seems like another reason why it may be best to migrate to ERC 1155. It could make Respect more compatible with Reputations and Roles from Jacob.
- Related: Consider migrating to ERC-1155
Respect Game App where Each Players Can Give Each other Their Respect
- I’m thinking about building the Respect Game app where all players can easily give each other respect and it seems that a single token standard (ERC 1155) would be easier for many people to use than 2 token standards…
- I’m not sure about this, but we could embed code for Manifold.xyz or something else that already uses ERC 1155
- I think this could also make the manual or automatic token distribution easier?
- I want to make it as easy as possible for people to give each other respect right after playing and optionally provide a picture
- I think this has a lot of similarities with what we discussed in EdenFractal.com/61
- You can see the designs for this below
- Full Figma design in progress:
- What would be the functionality for this feature?
- Contract ownership…
- Each player gets the option to easily share their Respect with everyone who they play with
- Each player can quickly add a picture and text to their Respect if they want, which could be accomplished by using something like Manifold.xyz widget for creating ERC 1155 (if such code is open source)
- In the future it could also have in app art creation tool for quickly adding images, gifs, and stylized text
- So for example if you play with Mary, Todd, Joe, Kelly, and Anne… and you get level 5… then you can get 34 Respect for each of them….
Comparison
Comparison of Features between ERC-1155 and Current System
- It seems like ERC 1155 could accomplish what we are aiming to do with both non-fungibility and fungibility, while also being simpler and benefitting from standardization with the rest of the ecosystem.
- In what ways might ERC-1155 be inferior to the current design? Or put another way, why wouldn’t we switch to ERC-1155?
- If we did decide to migrate, how much time and work would this require?
When will we decide?
- Should we make a decision about whether to stay with current configuration or move to ERC 1155?
- Do you think it makes sense to migrate to ERC 1155 now or make any other changes?
Software to potentially switch to ERC-1155
Manifold Resources
https://docs.manifold.xyz/v/manifold-studio/case-studies/overview#case-studies
https://studio.manifold.xyz/829817072/tokens
Hey Tadas, here is video from Friday’s meeting. You can see us discuss more about Respect given by each player, giving Respect to people outside of event participants, and other exciting topics at this timestamp starting right after you left.
I also realized that I accidentally shared the wrong screen when I tried to show you the Give Respect button before you left. Below is the draft mockup of how a button that says “Give Respect” could be presented to each player right after they complete a game.
Other Software for ERC 1155
BitBond?
MintNite?
Third Web?
What others?
Related Pages
Improve representation of Respect on block explorers
Improve Visibility for Optimism Fractal Respect
Ask for update about ERC-1155?
- Maybe it would be good to ask Tadas or other developers about Bitbond, Manifold, MintNite, or other options
- Organize Plans for Personal Respect, Distributing after Respect Games, Respect Networks, and Synergies with Optimism Fractal
- Test out Manifold.xyz to allow people to give each other Respect in RespectGame.xyz
- [[mintnite
https://docs.hatsprotocol.xyz/for-developers/hats-protocol-overview/erc1155-compatibility