[r/boards] initialize AdminDAO

[salmad3]

Context:

⚠️ WIP (Simplifying much of the logic for MVP)

The AdminDAO is a crucial component of boards, responsible for managing high-level configurations and permissions. It serves as the primary administrative entity for the entire boards realm, separate from individual board management. The AdminDAO needs to be initialized with appropriate permissions and functionalities to oversee the boards realm effectively.

Eventually, AdminDAO will turn into a general DAO that is leveraged or consumed by other (d)Apps, dubbed "CommonDAO".

Acceptance Criteria:

• Implements an AdminDAO struct with necessary fields:

  Example

  type AdminDAO struct {
      Members []Address
      Config BoardsRealmConfig
  }

• An InitializeAdminDAO function sets up the initial state:

  Example

  func InitializeAdminDAO(initialMembers []Address) *AdminDAO {
      return &AdminDAO{
          Members: initialMembers,
          Config: BoardsRealmConfig{
              MinBoardNameLength: 3,
              DefaultBoardCreationCost: 1000000, // 1 GNOT
              BoardNameValidationCallback: defaultBoardNameValidation,
          },
      }
  }
  
  func defaultBoardNameValidation(name string) (bool, uint64) {
      if len(name) < 3 {
          return false, 0
      }
      if len(name) <= 6 {
          return true, 10000000 // 10 GNOT for short names
      }
      return true, 1000000 // 1 GNOT for regular names
  }

• Functions for the AdminDAO to manage global boards realm settings:

  • Set minimum board name length
  • Set default board creation cost
  • Set board name validation callback

• Ensures the AdminDAO can set and update the callback function for board name validation:

  Example

  func (dao *AdminDAO) SetBoardNameValidationCallback(callback func(string) (bool, uint64)) {
      dao.Config.BoardNameValidationCallback = callback
  }
  

• Includes a function for the AdminDAO to freeze a board in case of policy violations:

  Example

  func (dao *AdminDAO) FreezeBoard(boardName string) error {
      // Implementation
  }
  

• Includes a function for the AdminDAO to set realm-wide notifications:

  Example

  func (dao *AdminDAO) SetRealmNotification(message string) {
      dao.Config.RealmNotification = message
  }
  

• Ensures the AdminDAO can manage the upgrade process for the boards realm:

  • Set upgrade path
  • Approve upgrades
  • Manage transition to new versions

• Implements a mechanism to handle name change lookups:

  Example

  type NameChangeRecord struct {
      OldName string
      NewName string
      Timestamp time.Time
  }
  
  func (dao *AdminDAO) RecordNameChange(oldName, newName string) {
      // Implementation
  }
  
  func (dao *AdminDAO) LookupCurrentName(name string) string {
      // Implementation
  }
  

• Unit tests to verify the functionality of the AdminDAO

  • Member management
  • Configuration updates.

Notes:

• The AdminDAO should reside within the boards realm, not as a separate realm.
• The AdminDAO should not have direct control over individual boards but should be able to intervene in extreme cases (e.g., freezing a board).
• The initial implementation should be simple, with the expectation that more complex governance mechanisms may be added in future versions.
• The AdminDAO should be designed with the possibility of future integration with a chain-level governance system (GovDAO) in mind.
• For the MVP, the AdminDAO will have no owner, only admins. The chain-level governance (GovDAO) will have the ability to replace admins in the future.
• The board name validation should initially enforce the same rules as the users realm (e.g., ending with three digits for free names).

[salmad3]

Initial work includes the following:

• An AdminDAO struct has been implemented, which includes members, proposals, and configuration fields.
• Functions for adding and removing members from the AdminDAO have been created.
• The AdminDAO has been integrated with the board creation process.
• Functions for inviting members and assigning roles have been implemented.
• A basic proposal system structure has been added to the AdminDAO (though it's noted that it needs further implementation).

[jeronimoalbi]

We are switching efforts to have an MVP by focusing in a default permissions implementation that doesn't use proposals for its functionality. Once the MVP is finished and once the voting mechanics are defined we will resume the work started in feat/admindao-proposals branch.

[salmad3]

[08-01-2025]:

• A top-level DAO governs the entire boards realm, holding ultimate authority (e.g., creating boards, managing upgrades).
• We'll launch with a simple owner/super role; additional roles and permissions can evolve in future versions.
• The "super" DAO logic will be separate from boards logic, based migration and maintainability benefits.
• The "super" DAO has discretion on memberships and flagging across all boards.
• The current approach lays groundwork for potential integration with other DAOs or new features (e.g., voting mechanisms) without major rewrites.

[moul]

It should not be prefixed as "boards." Commondao is not a subset of boards; rather, it is a dependency shared with other elements.

cc @Kouteki

[salmad3]

@moul I suggest we keep this issue focused on the original AdminDAO criteria for MVP, then extract it into its own realm under the “CommonDAO” model. There is already some AdminDAO logic in the boards realm; currently, it doesn’t contain any board-specific code—it only manages members, permissions, and minimal proposals/voting. Since we plan to refactor the boards realm anyway, we can see the implementation through and begin testing boards. Meanwhile, we’ll work on a complete definition of the CommonDAO.

[salmad3]

If this works, we'll open a separate issue for the CommonDAO initiative (not prefixed as "[r/boards]").