Research Spike: best way to store registry data (members/proposals)

syvita / daoos

A group of tools for anyone to be able to create their own decentralised organisation on Bitcoin. 🟩

https://syvita.org/projects/daoos

MIT License

27 stars 10 forks source link

Research Spike: best way to store registry data (members/proposals) #82

Open falkonprods opened 3 years ago

falkonprods commented 3 years ago

Some thoughts:

Can create user in Gaia for the application, and store private key with the app
Can update this registry when a new user registers or new proposal is created

JMKJR commented 3 years ago

We want the frontend to provide a rich user experience with features like...

Show a list of members.
Show a list of proposals. etc.

The challenge here is you can't iterate through a map in a smart contract to return this data even if it's stored there. Additionally, Gaia stores user-specific data in a bucket for each user meaning the frontend app can't make a single call to a location to serve this data.

We need a solution for the best approach to serve these features while making sure the data in the frontend is in sync with the data on-chain.

JMKJR commented 3 years ago

Proposed solution 1:

Store all of this info in a centralized database solution. When the frontend presents this info to the user (like showing a proposal) - it will reference the smart contract in question in the frontend so a user can verify that what the frontend is presenting is true.

eg. a proposal in the frontend will have a tag/chip with the smart contract address it is referencing and users can make read-only calls to the contract to verify what the frontend is presenting is true. (The frontend could provide buttons/mechanisms from within the same page to provide a simple means for the user to call those contract functions it references and verify the data).

falkonprods commented 3 years ago

Proposed solution 2: store application data in a bucket for the app in Gaia - I asked in Stacks Discord and was told that this is something that a lot of apps do.

We could additionally use a client db solution that could sync to gaia, this will keep the data decentralized (and lower calls to smart contracts), but also allow for better performance.