---
# System prepended metadata

title: 'Rage Report: DAO Content through Poster, Contract Events, and The Graph.'
tags: [' v3', rage-report]

---

---
tags: rage-report, v3 
---

# Rage Report: DAO Content through Poster, Contract Events, and The Graph. 

**Background:**

User generated content that lives on the DAOhaus interface is increasingly important as communities desire to shape their culture and identities. While we've paid much lip-service to generating community and DAO content, we've been stuck at a technical impasse. Storing content on chain is costly and somewhat complicated. Using other IPFS integrated services seems to be the path forward, but it relies on a complicated Jenga-tower of semi-centralized services that are neither reliable or easy to use, though this may change in the future. 

This experiment aims to test the use of Poster as a means to storing DAO data on chain, while cutting on the costs of state bloat and gas by emitting content as events. In doing so, we may be able to compose these events into DAO messages that are legitimized by governance. Then we can use The Graph to easily index and query these events. The app can consume this data and display it easily, quickly, and reliably. 

Finally, probably the biggest potential 'killer features' of Poster is its simplicity and legitimacy. On chain data can reliably prove that a DAO agrees on this content, thus giving a undeniable voice to the community. Its simplicity not only makes it easy for developers to bundle into other services, but it makes it easier for community members to understand the process. 

**Experiment 1**

Building a boost with Poster will be pretty easy and lightweight. (Would only require a short Rage session to make a viable content form, and a place to view that content)

Poster will be composable. It's not just for metadata, it's for ratifying documents, discussions, D2D interaction, and storing code on-chain. 

**Experiment 2**

IPFS based services are still going to play a big part in DAOhaus. Poster will also be able to compose other services like Ceramic to handle long term-sustainability. 

Because Poster can be an interface for composing other storage options (Ceramic, Pinata) it will make more sense to use it as a DA0 content primitive than an optional boost. 


### Experiment 1: Content Governance

- Build a safeMinion proposal form
- Display the content so that people can decide what they're voting on 
- Display the markdown in the form so that we can edit in DAOhaus or on another platform (like HackMD), and see the results before calling TX.
- Once the SafeMinion proposal is executed, it calls the poster contract and Posts the markdown, title, location, and moloch address
- Subgraph indexes that data
- App queries subgraph data and displays
    - A page with all of the DAO's ratified docs
    - A page that displays a single doc's markdown
    - An spot on the overview page that will display Markdown if a DAO publishes a doc to that location 
- in order to test ease-of-dev, this form, docs pages, and overview panel must be built within a few days. 


### Expectations: 
- Easy/quick to build
- Flexible or composable functionality
- Lightweight state

### Results/Findings: 
- The most difficult part of building was searching for MD libraries. One potential challenge will be preventing XSS attacks and sanitizing inputs. Another might be customizing the editor and MD output to fit the app. 
- More composable and flexible than I thought it would be.
- Definitely too flexible at the moment. We need to scope and permission Poster contracts to their DAO in order to tie content to governance and get a sense of 'who is talking'. 
- Perhaps Poster's biggest use-case will be as an interface to other decentralized storage options. 
- Does not solve for state bloat. At least with V2's. 
    - Proposal Action state still persists in the minion contract after execution
    - Essentially, we're creating the same content twice
- Tags are good at telling us what the content type is, but not security
- DAOs may have to deploy their own modified contract in order to prove support for the content. 

### Proposed Next Steps: 
- Add a `to` field to data model. Allows DAOs to send messages to other DAOs. 
- Create a field that denotes whether this post has governance attatched to it (something that is ratified)
- Create different tags for content types. 
- Figure out a way to prove a message is coming from a DAO (minion proposal governance), and whether it's coming from a member (no gov, just permissions). 
- Start planning out how we decentralize the metadata. 
- Start thinking of how we'd like our community to start generating content.
    What we have so far
    - Manifesto style front page content. 
    - A store of docs. 


Ideas: 
- Proof of Agreement. A DAO could ratify a verbal agreement from another DAO. 
- DAOpub. A DAO of editors who source content from the DAOhaus ecosystem. Content can be written by members who represent a certain DAO, or written by DAOs as group drafts The DAO's content could become a CMS for a separate bolt-on. 
 
- DAOfeed. A feature where users can subscribe to DAO content in the hub section. 
- Proposal discussion and comments (I've mentioned this one before)
- DAOpub, but for gating and whitelisting code (ex. Legos for boost foundry)
- DAOdvertising. Carving out some real esate in our apps and bolt-ons so that DAOs can information in front of people. 
    - Classifieds, jobs, hiring. 
