Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Idea/proof of concept: git-like controlled database/knowledge graph using multisig and WG static storage #4330

Open
mochet opened this issue Sep 29, 2022 · 1 comment

Comments

@mochet
Copy link

mochet commented Sep 29, 2022

Problem

By far the largest problem in the web3 and DAO space is documentation & tools and projects that utilize dozens of on-chain and off-chain tools. This problem persists across almost every single project I have come across and is compounded by the project's complexity. I have not really come across a project that manages this very well.
The key issues are:

A simple example of this problem:

  1. https://github.com/w3f/polkadot-wiki/blob/master/docs/build/build-open-source.md
  2. https://wiki.polkadot.network/docs/build-tools-index
  3. https://github.com/w3f/polkadot-wiki/blob/master/docs/build/build-wallets.md

These are 3 pages with partially overlapping sets of information that seem to be manually maintained. Information is spread across the place and it is generally difficult to find consistent, high quality indexes of information that are known to be up to date or maintained.

Examples / Use Cases

In order to maintain a high standard of documentation that is globally available to Joystream users of all levels, it makes sense that this is maintained on the DAO rather than using off-chain tools (like GitHub, Notion or others). It will also probably be likely that tracking task management, extended metadata of proposals (Joystream/community-repo#713 + Joystream/community-repo#710), budgets and any "goods" (such as scripts, tools or tutorials) that the DAO produces are conveniently stored for all use cases.

  • On one DAO the following was written on their governance forum, basically leaving the task of data management up to volunteerism:
    Please try and fill these tags in when you can; I can add them, but it’s easier if its done at the beginning.
  • On another, it was suggested that the marketplace should form to provide information
    image
  • Governance voter unable to find information due to lack of categorization (https://kusama.polkassembly.io/treasury/201)
    image

On top of this, there are very few DAOs which have task or project management features and instead extensively rely upon off-chain tools which are not only centralized but also not chained to on-chain identities.

Therefore for numerous reasons it would be highly desirable to have a git-like database / knowledge graph, which is extensively maintained of the Joystream DAO organization including areas such as:

  • Governance
  • Budgets
  • Tooling lists
  • Tutorial lists
  • WG processes and their internal management
  • many other areas

Solution 1

In the below example I am using OperationsGamma (HR).

  1. A multisig key is made up of the lead + worker keys
    image
  2. The extrinsic storage > sudoUploadDataObjects is used using the multisig
    image

Solution 2

In the below example I am using OperationsGamma (HR).

  1. operationsWorkingGroupGamma > workerRemark is used to commit a change
    image
  2. The lead can then merge the change using the same extrinsic.

For either of these a UI and tooling would have to be developed, but it seems like they could perhaps work.

@mochet mochet changed the title Idea/proof of concept: git-like controlled database using multisig and WG static storage Idea/proof of concept: git-like controlled database/knowledge graph using multisig and WG static storage Sep 30, 2022
@mochet
Copy link
Author

mochet commented Sep 30, 2022

Very relevant: https://kusama.polkassembly.io/post/1814

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant