[META] WIP: r/boards"2"

[salmad3]

Context:

Warning

Criteria is a WIP and subject to change

"boards" serves as a demo and reference implementation for social media-like boards with posts and interactions. The goal is to fully realize the previous r/demo/boards initiative and use it as the foundation for a social interaction dApp on gno.land. For mainnet, "boards" will provide immediate functionality and connect users from day one to drive user enablement and acquisition. "boards" is also an opportunity to test Gno and gno.land as both a dogfooding exercise and a stress test to strengthen the chain's elements.

This META issue maps out the development plan for boards2, including creation, management, moderation, governance, and forking.

To-Do

• Forking criteria
• AdminDAO implementation with proposal system
• Alignment of AdminDAO with existing DAO implementations (e.g., GovDAO)
• ...

Important

Current conceptual model:

• Board creation and management are controlled by a flexible permissions system.
• A boards realm AdminDAO oversees realm-level operations like board creation, renaming, and freezing.
• The system supports multiple roles: admins, moderators, and members, each with distinct permission levels.
• A flagging system is implemented for content moderation with configurable thresholds.
• Forking is allowed at the board level, with clear guidelines for managing duplicate content.
• The implementation allows for future policy changes without significant code restructuring.
• Boards can have configurable default visibility settings for posts.
• Spam prevention measures are in place to maintain board quality.
• GovDAO has ultimate control over the boards realm AdminDAO.
• A mechanism exists for setting notification messages and freezing boards or the entire realm.
• An upgrade path is provided for future versions of the boards realm without forcing immediate migration.
• The system implements a multi-tiered governance structure:
  • GovDAO (top level)
  • Boards realm AdminDAO (realm level)
  • AdminDAO (board level)

System Relationships:

classDiagram
    class Board {
        <<realm>>
        +String name
        +Permissions permissions
        +UserDirectory userDirectory
        +Thread[] threads
    }

    class Thread {
        <<struct>>
        +String id
        +String title
        +Address author
        +Post[] posts
        +Flag[] flags
        +bool isLocked
    }

    class Post {
        <<struct>>
        +String id
        +String content
        +Address author
        +DateTime timestamp
        +Flag[] flags
    }

    class Flag {
        <<struct>>
        +Address user
        +String action
        +String reason
    }

    class Permissions {
        <<interface>>
        +WithPermission(user, action, args)
        +HasPermission(user, action, args)
        +GetRoles()
        +GetUsers(role)
    }

    class DefaultPermissions {
        +AdminDAO adminDAO
        +Map~Address, bool~ memberSet
    }

    class AdminDAO {
        <<package>>
        +Address[] admins
        +int threshold
        +ReviewProposal()
        +FreezeBoard()
        +SetNotificationMessage()
    }

    class BoardsRealmAdminDAO {
        <<realm>>
        +Address[] admins
        +int threshold
        +ReviewProposal()
        +FreezeRealm()
        +SetUpgradeNotification()
    }

    class UserDirectory {
        <<interface>>
        +Lookup(addr)
    }

    class UsersRealm {
        <<realm>>
        +LookupUser(name)
        +ValidateName(name)
    }

    class GovDAO {
        <<realm>>
        +ManageBoardsRealm()
    }

    Permissions <|.. DefaultPermissions : implements
    Board *-- Thread : contains
    Thread *-- Post : contains
    Post *-- Flag : has
    Thread *-- Flag : has
    Board *-- UserDirectory : has
    Board *-- Permissions : has
    DefaultPermissions --> AdminDAO : uses
    UserDirectory --> UsersRealm : interacts with
    BoardsRealmAdminDAO --> Board : manages
    GovDAO --> BoardsRealmAdminDAO : controls

Loading

Control Flow:

sequenceDiagram
    participant User
    participant Board
    participant Permissions
    participant AdminDAO
    participant UsersRealm
    participant BoardsRealmAdminDAO
    participant GovDAO

    User->>Board: Request Action (create/rename/fork)
    Board->>Permissions: WithPermission(user, action, args)
    alt Permission Denied
        Permissions-->>Board: Deny Action
        Board-->>User: Action Denied Message
    else Requires AdminDAO Approval
        Permissions->>Permissions: Check basic rules
        Permissions->>UsersRealm: Validate Name (if needed)
        UsersRealm-->>Permissions: Validation Result
        Permissions->>AdminDAO: Create Proposal
        Note over AdminDAO: Review Process
        AdminDAO-->>Permissions: Approve/Reject
        alt Approved
            Permissions-->>Board: Execute Action
            Board-->>User: Action Successful
        else Rejected
            Permissions-->>Board: Deny Action
            Board-->>User: Action Denied Message
        end
    end

    Note over BoardsRealmAdminDAO: Manages realm-level actions
    BoardsRealmAdminDAO->>Board: Freeze/Unfreeze Board
    BoardsRealmAdminDAO->>Board: Set Upgrade Notification

    GovDAO->>BoardsRealmAdminDAO: Control realm-level governance

Loading

Dependency Hierarchy:

graph TD
    A[GovDAO] -->|Controls| B[BoardsRealmAdminDAO]
    B -->|Manages| C[Board Creation]
    B -->|Manages| D[Board Forking]
    B -->|Manages| E[Board Renaming]
    B -->|Can| F[Freeze Realm]
    B -->|Can| G[Set Upgrade Notification]

    H[AdminDAO] -->|Manages| I[Individual Board]
    I -->|Has| J[Permissions]
    I -->|Contains| K[Posts]
    I -->|Contains| L[Threads]

    J -->|Enforces| M[Access Control]
    J -->|Manages| N[Role-based Permissions]

    O[DefaultPermissions] -->|Uses| H
    O -->|Implements| J

    P[UsersRealm] -->|Validates| Q[Board Names]
    P -->|Provides| R[User Directory]

    S[Permissions Interface] -->|Defines| T[WithPermission]
    S -->|Defines| U[HasPermission]
    S -->|Defines| V[GetRoles]
    S -->|Defines| W[GetUsers]

Loading

Acceptance Criteria:

Creation & Management:

Includes:

• A CreateBoard() function that uses the permissions system and AdminDAO interaction to control board creation.
• A board renaming process that requires owner or admin initiation, subject to permissions and AdminDAO approval.
• A FreezeBoard() function that allows the boards AdminDAO to freeze all activity on a board, except for Admin actions.
• Basic board operations (e.g., post creation, deletion) that utilize the permissions system.
• Functions to manage board settings, such as default visibility of posts and whether the board is open or invite-only.
• Name validation to prevent conflicts with existing usernames in the users realm.
• A SetNotificationMessage() function that allows the boards realm AdminDAO to set a notification message for all board renderings, useful for communicating upgrades or important information.
• An upgrade path mechanism that allows the boards realm AdminDAO to propose and implement new versions of the boards realm (e.g., boards2, boards3) without forcing immediate migration.
• A mechanism for GovDAO to control and potentially replace the boards realm AdminDAO, ensuring chain-level governance over the boards realm.

Permissions:

Includes:

• A flexible Permissions interface with methods like WithPermission(user, action, args) and HasPermission(user, action, args).
• A role-based access control system supporting admins, moderators, and members.
• Permissions associated with each role:
  • Admins: Can perform most actions except managing other admins; cannot delete the board.
  • Moderators: Can manage content and users, such as hiding or deleting posts.
  • Members: Can create posts and comments, subject to board settings.
• Ability for admins to remove themselves, with safeguards ensuring the presence of at least one admin.
• Automatic membership assignment to admins and moderators within the board they oversee.
• An interface supporting role management, including functions to get roles and users associated with roles.
• Integration with a UserDirectory interface to look up user information.
• Flexibility to implement different permission models, including those that require DAO proposals for certain actions and those that allow immediate execution.
• Support for configurable thresholds, such as the number of moderator flags required to hide a post.
• Ability to separate the implementation of permissions from the core board logic, allowing for customization without changing the board code.

Moderation:

Includes:

• A flagging system for content moderation to allow moderators and users to flag posts and comments.
• Functions for moderators to hide or delete posts based on board settings and flag thresholds.
• Configurable thresholds for actions, such as the number of flags required to automatically hide a post.
• Ability for admins and moderators to lock threads to prevent further comments.
• Spam prevention measures to maintain board quality, potentially including:
  • Rate limiting for new users or accounts with low karma
  • Automatic filtering of known spam patterns
  • Temporary muting of users who repeatedly post flagged content
• A system for users to appeal moderation decisions to admins or AdminDAO.
• Transparency logs for moderation actions, visible to admins and potentially to all users.
• Integration with the permissions system to ensure only authorized users can perform moderation actions.
• A mechanism for the BoardsRealmAdminDAO to intervene in cases of severe moderation failures or board-wide issues.
• Support for different levels of content visibility (e.g., visible, hidden, deleted) with appropriate access controls.

Forking:

Includes:

• A ForkBoard() function to create new boards based on existing ones.
• A system to track relationships between original boards and forks, possibly using data structures like linked lists.
• Visualization tools or data structure to represent fork relationships as interactive trees.
• Guidelines + mechanisms for managing duplicate content across forks.

Considerations:

• Optimize gas consumption for frequent operations while maintaining security for sensitive actions.
• Ensure clear error handling with appropriate feedback mechanisms when permissions are denied.
• Design the permissions system flexibly to accommodate future governance models without major code rewrites.
• Implement callback mechanisms for asynchronous operations related to proposals in AdminDAO.
• Address the challenges of upgrading realms and consider mechanisms for realm upgrades or migration.

Current State of Related Components:

Underlying Components	Enables	Already in Gno?	Implementation Required?	In Progress?	Related Issues
Copy-on-Write	Can enables efficient data management without data duplication for forking	No	Yes	Yes (#3126)	N/A
AVL Tree Structure	Will be used for handling of boards; can be used for ordered data like board names; quick lookups and uniqueness checks	Yes (/p/demo/avl)	No	N/A	N/A
Linked Lists	Can manages sequences with frequent insertions/deletions, such as comment threads	No	Yes (custom implementation)	No	N/A
Hash Maps (Maps)	Enables fast lookups for user roles, permissions, and other mappings	Yes	No	N/A	#1374 (Proposal for ordered tree-structured maps)
Validation Functions	Can ensure uniqueness and correctness of board names and usernames	To update	To update	To update	N/A
Binary Search Algorithms	Can provide fast retrieval of data in ordered collections	To update	To update	To update	N/A
Sorting Algorithms	Ordering posts, comments, or boards based on criteria	To update	To update	To update	N/A
Serialization Utilities	Can be used for data storage and transmission	To update	To update	N/A	N/A
Concurrency Primitives	Ensures data consistency during concurrent access	To update	To update	N/A	N/A

[salmad3]

[20-11-24]:

Criteria continues to evolve.

• Ownership and Roles:

  • The concept of ownership is evolving, with discussions around making boards potentially ownerless or having DAOs as owners. This impacts the current definition where owners have extensive control, including removing other owners as initially proposed.
  • An Owner can be seen as a special Admin member with additional privileges, such as removing other admins. However, if owners remove themselves, the board can become autonomous, relying on admins to manage it.
  • The Permissions interface should be adaptable to support both individual and DAO-based ownership models. This includes ensuring that permission checks can handle scenarios where a DAO might assume roles traditionally held by individual users.
  • We'll need to consider redefining roles to accommodate the possibility of a board being governed by a DAO or having no traditional owner.

• Governance:

  • The use of proposals for certain actions is being debated. For example, while renaming a board might not require a proposal if done by an Owner, it would for an Admin. The system should allow flexibility in whether actions require proposals based on user roles.
  • The integration with AdminDAO needs to be more explicitly defined, especially considering future governance decisions that might involve chain-level control or proposals for board management1
  • The role of AdminDAO in approving upgrades or changes should be clarified, as current discussions suggest that governance might shift from admins to a more chain-centric model.
  • The process for upgrading boards or implementing new versions needs a clear governance path, potentially involving proposals that could be approved by a DAO or chain-level decision-making body.

• Versioning:

  • Well, versioning applies broadly and is not limited to boards.
  • The process for upgrading boards may involve setting notification messages and potentially freezing activity on older versions to encourage migration to newer versions. This approach allows flexibility while maintaining user awareness of changes. In using a notification system, we can experiment with push notifications.
  • A proxy system was proposed to manage different versions of contracts.

• Moderation

  • The idea of having a global AdminDAO that can oversee boards was discussed. This entity could freeze boards or inject Moderators in cases of inappropriate content or governance issues.
  • Still, there are challenges and general concerns about managing inappropriate content on boards.
  • However, handling persistent data, especially when dealing with inappropriate content, poses challenges due to immutability. Discussions included potential solutions like using snapshots or having special privileges for data deletion managed by the associated DAO.