---
# System prepended metadata

title: Data Storage Experiments
tags: [v3]

---

---
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

