---
tags: product, din
---

# DIN subgraph spec sesh and sepolia deploy

estimated time:
- 1.5 hr spec x2
- .5 hr documentation
- .5 hr deploy x2

.15 eth

The purpose of this session was to spec and document any changes that might be needed for the current DAOhaus subgraphs. We are trying to get the minimal viable changes without introducing any breaking changes. THe changes should allow a few things
- a proposal to link to and "ratify" some content record
- a record should be able to be linked to from multiple proposals
- a record should have an idea of parentId which could allow hiarchiacal linking of records
- a shaman should be able to submit records without being a "member" itsself

We should touch on the differences of using the DAOhaus subgraph vs a new one.

We should touch on the RG Reseach data DAO usecase and a users critcal path

## Does it need to be in DAOhaus subgraph "database"?
It feels like the DAOhaus database should be directly linked to DAOs and try to keep in that scope. Things like validations around shares/loot, shaman, from summoner or from a proposal.

## compared to using a different subgraph
- TheGraph is closest to being decentralized, which seems important
- it's nice to have a single source of data, it reduces deployment complexity and leatning and depending on some other centralized tech
- some current infra for queries and deployment exists
- the con is it is relativly expensive and the studio deployment is more complex.

## Critical Path

1) User creates local draft (offchain)
2) User publishes draft to local "personal hub" as a onchain content record
3) User creates proposal on a "topic hub" to ratify and curate content

> useing a "personal hub" as a kind of staging area where content can be ratified from many "topic hubs" daoifies all the things.

## Code review

The current record entity
https://github.com/HausDAO/monorepo/blob/4bf0f40175a66030c52f2c7e790a264d5c21e976/apps/moloch-v3-subgraph/schema.graphql#L223

Validation on posts to become records happen here, using tags on the post (member, shaman, dao safe checks)
https://github.com/HausDAO/monorepo/blob/4bf0f40175a66030c52f2c7e790a264d5c21e976/apps/moloch-v3-subgraph/src/poster-mapping.ts#L21

valid json content is accessed here and can allow further "hard" relationships in queries
https://github.com/HausDAO/monorepo/blob/4bf0f40175a66030c52f2c7e790a264d5c21e976/apps/moloch-v3-subgraph/src/poster-mapping.ts#L45

**record ids**
a new record is issued an id in the format of
`daoid-record-blocktimestamp-eventlogindex`

this should be enough to get a uid and target specific records

**Proposal mapping**
Proposal have mappings that happen with the json details
https://github.com/HausDAO/monorepo/blob/4bf0f40175a66030c52f2c7e790a264d5c21e976/apps/moloch-v3-subgraph/src/baal-mapping.ts#L228

At this point what we want to do is
- determin if a proposal is to be linked to a record
- this should happen when a proposal is submitted (not only when executed)
- a proposal should be able to link to a single record, and a record should be able to link to multple proposals (DAOs)

here is a branch with proposed changes
branch with changes
https://github.com/HausDAO/monorepo/tree/sk/duce-subgraph

**Record/Proposal Relationship**
- Record (optional) property is added to the Proposal entity
- Proposals property is added to the Record entity
- parentId (string for flexibilty) property is added to the Record entity
- when handling submit proposal event a relatedRecordId is checked to create the Record/Proposal relationship

> Question: is this still needed?
https://github.com/HausDAO/monorepo/blob/8a9186e05d62f099976acc5c10eef64af55ce205/libs/moloch-v3-legos/src/tx.ts#L270

**parent id**
- a new record checks for a parentId to index

**Is Shaman Validation**
- in poster validation a check that sender is a valid shaman
- permissions for shaman should be > 0

Changes and Subgraph is deployed to sepolia for testing
https://thegraph.com/hosted-service/subgraph/hausdao/daohaus-v3-sepolia