Introduction
This page provides feedback and questions about Tadas’ candidate for the second iteration of Optimism Fractal’s software. The concept and implementation details of the candidate can be found below:
GitHub fractal/concepts/apps/of2 at concept-for-of28-1 · sim31/fractal
Table of Contents
- Introduction
- To Do
- Tadas’ Optimism Fractal 2
- Introduction
- OREC
- OREC and Council
- Education, Explanation, and Accessibility
- Attack Vectors
- OREC UI and Proposal Flow
- Visibility of OREC Proposals
- Parent Respect and Transition Plan
- Prior Respect
- Respect1155
- Roles and Reputations
- Respect Visibility
- Personal Respect
- OrNode and OrClient
- Front End
- Next Steps
- Documentation
- How can we help?
- Beta Testing
- Eden Fractal Deployment
- Onchain Summer
To Do
- It’s currently in the public Optimism Fractal notion site which I generally think is good…
Tadas’ Optimism Fractal 2
Introduction
- Anything else you’d like to introduce or share?
- Feedback and questions
- Zaal voted for OF2 to be discussed during yesterday event and we discussed it for 15-20 minutes, most of which was me giving presentation.
- If it’s helpful we can also publish it as separate video clip. I gave decent overview but wasn’t well versed in it yet
OREC
OREC and Council
How do OREC and Council work together?
- OREC makes decisions related to onchain actions and council makes all other decisions?
- Will there be likelihood of disagreement between council and OREC?
- What is the best way to explain the consensus process if there are two?
Education, Explanation, and Accessibility
- It would be helpful to define nomenclature to explain who is the governing body that uses OREC as it’s consensus process. OREC is a good technical name that describes the process, but it doesn’t describe the people who use the process and a name for this group would be helpful for explanations.
- Perhaps it makes sense to call it ‘the board’?
- Or perhaps ‘the house of respect’, parliament, congress….
- I think it would be good to keep it simple and casual to reflect the playful nature, similar to the naming of the Sages Council.
- What would be the best name for this body?
- The current document is written from a development perspective and we should create educational materials in the coming weeks that will enable the wider community and other nontechnical leaders of communities deploying the software to understand it more easily without needing to parse the technical overview on github.
- For example, many people may be confused by the idea of the old Respect Distribution as Rosmari explains here (which followed a detailed discussion to help her understand it):
Attack Vectors
- Possibility of spamming or making continual proposals to OREC
OREC UI and Proposal Flow
- Would OREC have it’s own UI for voting or would it use a voting app like Snapshot or Tally.xyz?
- How would the parameters of OREC be determined? I imagine that it’s voted by OREC, but how would non-technical users make proposals and ?
- Would there be a commit on Github that would be forked into the main branch of an Optimism Fractal organization on Github?
- This could potentially be configured with Hats Protocol and Guild.xyz, or perhaps there is a onchain alternative to Github for this
- I suppose that a simpler method for now could be that the OREC approves an offchain proposal to use a candidate such as Tadas’ from his repo in the deployment
Visibility of OREC Proposals
- How would we ensure that Respected community members can see proposals created via OREC?
- With only a 4 day period, then this is extra important that people can see proposals easily
- Could we use some API to make these go in the discord chat
- Can we use XMTP.org to send messages directly to people’s onchain accounts in a more decentralized, resilient, and open-source manner?
- Another option could be to automatically post the results into the Optimism Fractal farcaster channel.
- Farcaster introduced plan to make channels decentralized as part of the protocol (and recently raised $150m), so we could potentially give ownership of the channel to the OREC board.should be complete in the coming months. Hats Protocol is building a component for decentralized channel ownership and moderation. So we could integrate
- This could potentially be facilitated with neynar.xyz or airstack.xyz
Parent Respect and Transition Plan
Prior Respect
- At first glance, this doesn’t seem optimal because it could confuse people and make it difficult to vote with. After considering it more I see the benefits in this approach, but still think it will likely result in confusion unless we make it really clear in the front-end(s) and explain it well.
- Can we port/migrate/mint the existing Respect distribution for Optimism Fractal from first few seasons as well?
- Does snapshot or other voting apps allow voting with both deployments of respect?
- Can we also mint the prior respect as ERC1155 so we can mint the thumbnail and publish the episodes 1-35 while we make posts on Paragraph?
Respect1155
Respect1155 fixes main headaches with the current Respect contract of Optimism Fractal. It is ERC1155 contract with a fungible token representing fungible Respect and NTTs with value attribute that sums to balance of a fungible token.
- Does ERC1155 achieve fungibility and nonfungibility as well as original intention?
- What, if any, disadvantages are there in this implementation compared to the original implementation?
- Can you still see the total amount of Respect in a ERC20 interface like Blockscout or Etherscan?
- Can we still count past 12 weeks and create flexible
- Is it a standard ERC-1155 contract or are there any modifications?
- Tadas said that it is a standard ERC1155 contract that should work in any ERC1155 interfaces and it has some additional features.
- What additional features does this ERC-1155 have?
- Does it have the non-transferability feature implemented in the same way as Hats ERC1155?
- If so maybe we should explain it the same way in our documentation?
- Are you planning to make any additional documentation for Respect1155?
- How will the ERC1155 be implemented?
- Will each event have a collection? Or will each season be a collection? Or will each deployment/fractal be a collection?
- What will be the attributes of the collection?
- Can the attributes of the ERC1155 be used to create onchain EAS attestations?
- I started drafting some attributes that could work for a EAS Schema and ERC1155 properties here: Consider and Form Consensus on the Fields for an EAS Schema
- How easy or difficult would it be to modify the ERC1155 implementation?
- For example, if we decided to add another attribute/property, then could we do this easily?
Roles and Reputations
- Can this integrate smoothly and easily with Roles and Reputations?
Respect Visibility
- Will this allow us to add a picture for the Respect each week?
Personal Respect
- Can RESPECT1155 enable people to mint their own Respect?
- Can RESPECT1155 this be integrated with Zora smart contracts to use their creator tools and enable people to earn a portion of ?
OrNode and OrClient
Other componets currently being worked on:
- OrNode - nodejs component that stores OREC proposal metadata;
- OrClient - client to interact with smart contracts and OrNode;
- Can you provide more information about these?
- Who will run the Node and Client?
Front End
- Will it use the existing front-end or a new front-end?
- I don’t know what is Vipe. Is there some important differences between this and the current implementation?
- Does it make sense for Vlad and Lennar to help with any of this?
- There will be front-end place for disbursement of Respect
- Will there be front-end UI to manage contract proposals via OREC?
Next Steps
- What are the biggest priorities?
- Is there anything we should emphasize for other developers that needs to be done or should be considered?
Documentation
- Are you planning to write more documentation?
- Would it be helpful to publish or transcribe parts of this video to provide additional information?
How can we help?
- Is there anything you’d like from me, vlad, and/or rosmari?
Beta Testing
- A few weeks ago Zaal and Deeze volunteered to beta test the software, so I could ask them to test it out if it’d be helpful for any purposes
- Of course I’d also be happy to help with any testing as well
Eden Fractal Deployment
- Can we deploy this software on Base? When?
- Should/can we fully deploy it for Eden Fractal immediately when it’s available (while Optimism Fractal tests it for 6 weeks alongside the current app)?
- What are the risks or worst that can happen?
- It seems that the software will be much better than not using anything like we’re doing now and it could provide big opportunities for Eden Fractal, so I think it’s probably best to start using it immediately once it is ready
- Eventually we could port/migrate previous respect, but not a big deal for now
- Related notes:
Onchain Summer
Join the Base Onchain Summer Buildathon in June and compete for a share of 200 ETH in prizes across eight sponsored tracks. Backed by major sponsors like Stripe, Shopify, and Farcaster, this global online hackathon encourages builders to create innovative onchain solutions in payments, commerce, gaming, social, and more. Key dates include the kickoff on May 31st, application deadline on June 17th, and submission deadline on June 30th.
- You can find details here: Research and Consider Applying for Base Onchain Summer
- This could be a big opportunity to earn funding, attract community, and grow fractals
- It would be great to participate with the Fractal App in some way
- Is there any way that we’d like to apply as a team?
- If so, how?
- Alternatively we could also apply as individuals.
- Let me know if you think that’s better and would like any help or support
- Rosmari and I are considering to apply with Base Play. I’ll check the rules about participating on multiple teams