Context
Respond to Spencer about Hats Protocol and Optimism Fractal Updates 
Amazing, thank you for sharing. I love the vision and reading the blog post helped me better understand the potential of Hats Protocol. The interoperable programmable graph sounds really cool and it’s exciting to think about how network effects accrue from each integration with Hats. I also enjoyed listening to the recent recording of the Hats Town Hall about this 🧢 🙌🏽
After reading the article I shared it with AI to draft some documents about benefits of integrating Hats Protocol in Optimism Fractal, potential roles for Optimism Fractal, and an overview of synergies between the Respect Game and Hats Protocol. The documents are early works in progress and I’ll write more soon, but it might be helpful for inspiration now and anyone is welcome to improve upon them. I’ve also been continuing to update other parts of the project to integrate Optimism Fractal with Hats Protocol and can share more details soon…
Welcome Zaal, thank you for joining!
Feel free to share any thoughts related to Hats Protocol, Optimism Fractal, and/or integrating the Respect Game with your communities :)
You’re welcome! Sounds good, I’m interested to hear your ideas and looking forward to our chat. Let me know when is good for you, I’m travelling now but can meet later in the week or next week if you’d like
Thanks so much for all the answers, that’s very helpful to know!
Here are some follow up questions:
- What happens if a community wants to change or update an agreement? For example, suppose a community wants to start with a very simple agreement that’s only a couple sentences long then add to it and release a new version(s) that participants would need to sign again in the future.
- Would this require deploying a new instance of the Hats Agreement Module again, giving out new Hats, and updating permissions to require the new Hats whenever the community wants to update the agreement?
- If so, how much time and resources would it take to do so? What would happen with the old hats?
- If not, is there some easier way to update an agreement that doesn’t require deploying a new instance of the module?
- I recently watched the video clip of the Hat-claim mini app with the All In For Sport’s claim page featured a Hats Town Hall and see that this Hat is mutable. Does this mean that the agreement is mutable without needing to change the Hat as well?
- Would it be possible to only give a membership Hat to people who sign the agreement AND who are invited into the community by another account (or x accounts) that have a Hat? For example, this could be used to create a qualification requirement whereby newcomers must sign an agreement and be invited onchain by 3 members who have earned x amount of Respect (perhaps in the past y weeks) in order to join the community.
- How much time and resources would it take to set up the agreement module? What would be the next steps?
- How much time and resources would it take to set up a Respect Eligibility Module? What would be the next steps?
- I’ve also been doing a lot of research into @jacob’s project for Roles and Reputations and am wondering if it uses it’s own eligibility module or if it could be integrated with a Respect Eligibility Module. If we implemented the Roles and Reputation project into Optimism Fractal, then would we also still be able to use a granular and flexible Respect Eligibility Module like you described in this message?
- We’ve been considering migrating Optimism Fractal// Respect to a ERC-1155 token standard and I recently learned about the ERC-404 token standard, which bears some similarities to the Respect token’s current implementation that displays in both ERC-721 and ERC-20 interfaces. I’ve curated research about potential migration to ERC-1155 here and ERC-404 here, but we haven’t yet decided on the best token standard to use going forward. Would you recommend that we decide if we’ll migrate to a different token standard before creating a Respect Eligibility Module (and do you have any thoughts on what token standard might be best)?
- Would there interdependencies between the agreement module and the respect eligibility module? Or would these be these entirely separate modules that are deployed independently of each other?
- How independent is Hats Protocol from the ProtoDAO and Haberdasher Labs?
- I see this section of the new blog post about Hats Protocol’s dedication to being a credibly neutral core infrastructure with immutable smart contracts that developers can depend upon, so I think I know the answers to these questions… but just want to make sure there aren’t some dependencies that I’m missing.
- Is the Hats Protocol code all entirely open source with an AGPL-3.0 license and located in this Github repository? For anyone who’s interested, I just asked ChatGPT about this license and the conversation can be seen here. As a high level overview, the AGPL-3.0 license is a type of open source license that requires anyone who uses the software and modifies it to make sure the original and modified code is available to others.
- How dependent is the Hats Protocol code on the ProtoDAO and Haberdasher Labs? Do either of these organizations have custody or ability to change the Hats Protocol code that we deploy in our apps and community?
- If we decide to use Hats Protocol for critical infrastructure like an agreement or automated council that changes based upon Respect, then would this create risks or vulnerabilities for us if there are changes from the ProtoDAO or Haberdasher Labs?
- Are there any other dependencies of Hats Protocol’s that someone building a business with the protocol should be aware of?
- Is there anything that builders using Hats Protocol should be aware of with regards to upcoming changes to the OP Stack or Ethereum protocol (such as EIP 3074 or 7702)? For example, do you expect that apps using Hats Protocol will have any interruptions in service or experience large upgrades in the near future? I know this is a rather general question with many potential answers so feel free to be brief of course, but I mainly want to confirm that we’ll be able to provide a seamless experience for clients and be aware if there are any expected reasons why issues may arise.
More details
- I think the first version of Joshua’s app may be better to deploy without hats if it takes much time
- The first version could just have his own contract for neothink and then they wouldn’t need Hats as much, but Hats would still be helpful to implement at first if it’s easy enough and there may be a lot of develop support to do this now
- I can scope out multiple buckets with different iterations over time
- V2 or V3
- WebRTC Integration
- Livepeer Integration
- Personal Respect?
- Provable Randomization
- Private Voting with Shutter
- Shared Consensus Algorithm Game Mode Option
- Roles and Reputations
- Mighty Network Spaces Integration
- Claiming can be claimed by admin, bot, or user
- We can call hats ‘badges’ or something else if joshua prefers
- Decentralized front-end via Psinq, ICP, etc
- Automated smart contract by Respect or Delegates
1. How to Create/Admin Community in Fractal App with Hats
I’m exploring a design for an app where participants register to join a fractal community by signing a brief agreement, then automatically receive a Hat that signifies that they are a member of the community. I’d like to design it so that participants are only eligible to play the Respect Game in this community if they have the member Hat for the community.
I’m wondering how this would technically work and at what point the Hat would permit access to the game. In this design, could the lack of a Hat prevent participants from interacting with the contract or joining the game lobby? Or would it technically work better to make it so that people can still join the game but can’t earn Respect unless they have a Hat?
Follow Up Questions
- How much time and resources would it take to set up agreement? what are the next steps?
- No access
- how much time and resources would it take to set up Respect Eligibility Module? what are the next steps?
- Does the agreement module require respect eligibility module or is this separate?
- I think i remember seeing an open-source front-end for the agreement module as well. Is this true? Is there any additional work required to set up front-end for agreement?
- Is the Hats Protocol entirely independent from the ProtoDAO and Haberdasher Labs?
- What are Hats Protocol’s dependencies?
- If we decide to use Hats Protocol for critical infrastructure like an agreement or automated council that changes based upon Respect, then would this create vulnerabilities for us if there are changes from the ProtoDAO or Haberdasher Labs?
- Is the Hats Protocol code all entirely open source?
- How dependent is the Hats Protocol code on the ProtoDAO or Haberdasher Labs? Do either of these organizations have custody or ability to change the code that we would deploy in our app and community?
- Can we make Account Abstraction work with Hats Protocol where only people with Hats can get gasless transactions sponsored by paymaster on this app / smart contract?
- Would this be easy to configure for our clients that may want to create their own smart contracts using our code?
- Can we make account abstraction work to give gas-less transactions to both metamask users and privy users can get free transactions?
- Is this a Hats specific question or more general?
- Is there anything we should be aware of with regards to Hats Protocol, our app development, and upcoming upgrades to Ethereum protocol changes or upgrades (such as EIP 3074?)
- See No access for more questions
