---
tags: v3
---

# Data Storage Experiments

## 1. Poster

##### Solution:
Replace airtable - read and write dao metadata.
On chain and simple implementation. Downside is it requires a transaction.
Metadata updates emited in contract events + stored in subgraph

##### Success Criteria
1. Sufficient Decentralizaton
2. Can enforce member only updates
3. Is easy/fast to query
4. Will plug into the current front end implementation with minimal changes
5. Can be utilized in lambda functions similar to current solution

##### Detail

- 1 contract deployed per network
- Each metadata update is a transaction a member makes with the json metadat schema as an arg

    function post(string calldata content, string calldata tag) public {
        emit NewPost(msg.sender, content, tag);
    }

- Subgraph to catch each event
- parse json, validate content and create metadata entity
- Subgraph can be queried by molochAddress
- get latest metadata record

- Some considerations
- mainnet transaction cost
- could explore a single contract on xdai and require network switch
- makes member check in subgraph impossible
- worse ux
- could have this as a boost/optin
- tier 1 = centralized data (do we want to support this at all?)
- tier 2 = member only
- tier 3 = requires minion proposal
- alternate idea:
- 'What if on the new app we started decentralized, then offered centralized caching boosts to speed things up?'

- Challenges
- json parsing in subgraph mappings - solved

- TODO
- define data schema
- how do we change this - will be easy to add fields
- will this work for our deeply nested elements - boosts/playlists
- will need to store a lot as just json and have subgraph fields for essential items like 'name' used in search/filters
- define schema for making updates
- send an array of fields we are updating + new data
- can look up and update only those fields in subgraph
- define summon flow
- define upgrade flow
- how to we get current metadata blobs into this solution

#### Progress/implementation notes
Rinkeby contract:
https://rinkeby.etherscan.io/address/0x917d84787a266f9d649d519a7ec8445ea43514d8#code
Subgraph test:
https://thegraph.com/hosted-service/subgraph/odyssy-automaton/daohaus-poster-rinkeby?selected=playground

#### Results

1. Sufficient Decentralizaton
- editing data is on anchain function call
- data lives in on chain event logs + subgraphs

3. Can enforce member only updates
- subgraph will be able to check and enforce this

5. Is easy/fast to query
- integrated into our supergraph and current data pipeline

7. Will plug into the current front end implementation with minimal changes
- metadata updates will require a new transaction
- might be some additonal data management similar to how we handle playlists now
- summon flow might be the biggest effort
- first time metadata creation
- opportunity to impove what we have now

9. Can be utilized in lambda functions similar to current solution
- lambda will easily be able to use this and it likely eliminates the need for some
- add/update dao/boost metadata

##### pros
- tech is ready, can start tomorrow
- no new solution to learn
- simplest permission management
- can work for proposal based or member based

##### cons
- mainnet tx fee
- some work to integrate, but likely less than other solutions

----

## 2. Ceramic
Replace airtable - read and write dao metadata.

current feeling from sam is we need a moloch:did
- need to be able to fetch did with a moloch address without backend cache

----

## 3. Textile
Replace s3 - store hydrated, app-ready data

----

## 3. Storj
Replace s3 - store hydrated, app-ready data

----

## 4. Skynet
Replace s3 - store hydrated, app-ready data