Get Chains out of the Community Model and relegated to Group Memberships + Onchain Integrations!
tl;dr: Communities no longer require a chain, but default membership take on the onchain requirements
Overview: Allowing communities to operate independently of a specific blockchain ("Chains b Gone") and accept any address type by default. This feature empowers communities to embrace diverse user bases, reducing barriers to entry to a basic community. By providing the ability to set custom address standards and requirements, communities can fine-tune their membership criteria to align with their goals and the needs of their members. Moreover, by removing chain-specific steps in the community creation flow, we can further simplify the process.
Goals:
Introduce the "default" membership group in the App, allowing admins to gate their Community Top-Of-Funnel by Address type or any other requirement.
Admins can restrict membership to specific address standards if desired (e.g., only 0x addresses, Cosmos addresses, etc.).
Remove Chain-Specificity from our model of Community
Remove Chain selection from Community Creation flow
Refocus "chain" as a part on address type and other onchain membership requirements for groups.
As a community admin, I want to allow both Cosmos and Ethereum addresses to join my community.
As a Community Admin, I want to be able to set the requirements for my community's default member group, just all my other groups!
As a community admin, I want to set the address standard for our community's default membership, allowing only Ethereum or Cosmos addresses to be used.
As a community creator, I do not want to "select a chain" for my community in the community creation process. It should only come up in the group + membership configuration step.
As a user, I should managed memberships for a single address, not many addresses as memberships in my communities.
Design Links
No response
Design Screenshots
No response
Additional Context
Benefits
Inclusivity: By accepting any address type, communities can attract a diverse range of members, reducing barriers to entry.
Flexibility: Admins can set preferred address standards as a requirement for their default membership group.
Broader Participation: Accepting multiple address types and ecosystems encourages cross-chain collaboration and engagement, expanding a community's potential reach within Common.
ForestMars
commented
3 months ago
Description
Get Chains out of the Community Model and relegated to Group Memberships + Onchain Integrations!
tl;dr: Communities no longer require a chain, but default membership take on the onchain requirements
Overview: Allowing communities to operate independently of a specific blockchain ("Chains b Gone") and accept any address type by default. This feature empowers communities to embrace diverse user bases, reducing barriers to entry to a basic community. By providing the ability to set custom address standards and requirements, communities can fine-tune their membership criteria to align with their goals and the needs of their members. Moreover, by removing chain-specific steps in the community creation flow, we can further simplify the process.
Goals:
Project Owner
@zakhap
PRD
https://www.notion.so/buildcommon/Chains-b-Gone-Bucket-29b114c6e83b4de8923b8509c6a1908f
Tasks
Design Links
No response
Design Screenshots
No response
Additional Context
Benefits