[Communities] Ability to discover, create, and edit community

[ori-near]

Problem Currently, only DevDAO developers have the ability to create a new community space using custom hand code, leaving users without the power to discover or create the communities they care about. This creates limitation and hinders the growth of our platform. This ticket introduces a dedicated "All Communities" page that will serve as the main hub for all communities. It will also offer the ability for users to create and edit new communities.

User Stories

• As a general user user, I want to discover all the relevant communities that I can participate in and to create my own community so that I can connect with others who share a similar interest and create a space to centralize discussions and share information.
• As a DevHub moderator, I need to have a way to edit any community so that I can support our communities with any issues that arise.
• As a user with community moderator permissions, I need to have a way to edit the relevant items for my community so that I can make the necessary changes without relying on DevDAO developers.

Acceptance Criteria

• Discovery: There is a dedicated page for All communities that lists all of the communities in the same card format as the homepage
  • Users can access the page using the /communities/ URL and stay on that page when they click refresh
  • Users can discover the page using a "View All" button from the homepage
• Creation: There is a "Create new community" button in the All Communities page. When a user clicks create, they can add all the required details:
  • Short community URL slug (e.g. /communities/slug – only allow dashes, letters, and numbers)
  • Community name (limit to 30 characters or which ever number will not break the one line on the homepage card)
  • Short description (limit to 60 characters or whichever number will not break the two lines on the homepage card)
  • Feature image (610px by 330px)
  • Thumbnail (100px by 100px)
  • Overview Tab content (editable using markdown large text field)
  • Events Tab content (editable using markdown large text filed)
  • Telegram channel(s) to pull content from
  • Admin users – user can designate all the users who will have admin permissions to edit this community. By default the user who creates the page gets listed as an admin.
  • User can designate multiple labels for their community. One primary label is required.
• Editing: Users with permission to edit communities will see an "admin" tab for the appropriate community.
  • Permissions:
    • DevHub moderators will see the admin tab for all communities
    • Community Moderators can only see the admin tab on communities they have permissions to manage
    • Regular users will not see the admin tab
  • Once in admin mode, users with permissions can can see and edit all of the relevant community fields from the creation step

Attachments See Figma design

[ori-near]

@nearmax @frol @ailisp – Please see this proposed ticket for creating a new community and provide any feedback or concerns.

Some considerations:

1. Should we provide anyone with the ability to create a new community page?
2. Should there be some kind of "moderation" step to review and approve new communities before they're published? I think we're better off allowing anyone to create one, and just adding the ability to delete/hide pages that violate any terms.
3. How should we show "communities" that DevDAO plans to "officially support." Perhaps that's something we list on our DevGov page. Or we could add an official indication in the community (e.g. a badge that says DevDAO sponsored community).

[jefedeoro]

I think it could be a good idea to allow anyone to add a community but have 2 sections of community links.

(First / at the top) the official Dev Hub communities (followed by) a section for the greater community (with flagging/removal if breaks terms)

and then the ability to promote a community page to the official Dev Hub list.

[ailisp]

Short community URL slug (e.g. /communities/slug – only allow dashes, letters, and numbers)

This is not possible because near social's router cannot be configured - each widget is strictly mapped to the source code file in the repo. E.g. /communities/zk - must be a file in neardevhub-widgets: src/communities/zk.jsx

[ori-near]

@near-akaia-root As we discussed, I incorporated the old Discover "All Communities" page (#79) ticket into the first AC of this ticket. Will repurpose 79 for a different task.

CC: @ailisp

[carina-akaia]

UPD: In progress

[gagdiez]

Hi team, amazing job on moving this forward. Could we get some insight into how the community is planned to be stored? Is this a data blob in social.near? In such case, what are the data fields, and under which key/action is it stored? Is there an indexer call happening on creation? Using which fields?

A great idea would be to coordinate so we propose a standard: https://github.com/NearSocial/standards/tree/main

If you already have an initial idea, would love to hear it and help in standardising it.

[carina-akaia]

Hi team, amazing job on moving this forward. Could we get some insight into how the community is planned to be stored? Is this a data blob in social.near? In such case, what are the data fields, and under which key/action is it stored? Is there an indexer call happening on creation? Using which fields?

A great idea would be to coordinate so we propose a standard: https://github.com/NearSocial/standards/tree/main

If you already have an initial idea, would love to hear it and help in standardising it.

Hi, recently we decided to store and process data on DevHub's own contract, as it is the fastest way to implement MVP at this moment

SocialDB will be considered a target for migration in later updates

[frol]

@gagdiez As @near-akaia-root has already mentioned, after some brainstorming, we decided to postpone the usage of SocialDB for communities due to permission system limitations (you cannot revoke access after you granted it).

Just for future context, our exploration led us into considering creating new accounts (zk-community.near) or subaccounts (like, zk.dev-hub.near) and using its profile key to reflect that it is a community account. Users willing to post to the community would post it to their own feed with a special index key, and a relevant community account then would re-share those posts to their feed (it could even be a DAO-enabled process to ensure pre-moderation). This way the posts would still belong to the author while the community account would help to organize them, and it won't introduce major changes to the feed implementation and communities discovery will just leverage the existing accounts search capabilities.

There are a ton of small details when it comes to the implementation, so we decided to get back to it later once we will know more about the needs of the communities on NEAR. Learn more about SocialDB limitations and various quirks we can implement in #137.