---
tags: protocol, rage report
---

[Immutable comment emmiter system](https://hackmd.io/@daohaus/HkEdZudYp). DH ecosystem universal data layer and messaging standard.

The goal here is to create a standard for products in our ecosystem to store and access onchain meta data. Having a ecosystem standard allows more interesting composiblity.

It builds on and leverages our current work with the Graphs services and reduces base line dependencies, requires no other hosted dependencies

It can evolve into more advanced structures like social graphs and knowledge graphs

## name
Emitter
DUCE
DAOHAUS universal comment emitter
Decentralized universal comment emitter
Decentralized Inteligencia agency

## tech
poster.sol
daohaus sdk - dao database \ indexer
https://docs.daohaus.club/subgraphs/dao-database

> note: indexer shouls have 2 entities, 1 for metadata and 1 for native content record (if applicable)

## MetaData
Publication / Base Node

id: uuid, // unique id / salt
storageProtocol: // native | arweave | ipfs
content: string, // hash
eventType: 0 - parent, 1 - edit, 2 - delete, 3 - group, 
table: // is this the schema? 
signature: encodedBytesData, // signed encoded node for verification
sender: address, // account
domain: // app code, referrer
version: "0.0.01", // version of the schema
queryType: list | latest | *latestList
createdAt
----
// maybe determined by content schema (optional)
daoId?:  // ??
context: string, // application specific context
scope?: // application specific scope in a context
origin: address, // smart contract
--- native content (optional)
...

## content schemas

duce base

id: // generic article id
author: // address of author
updated: // creation time
deleted: // should this cascade?

comment (big duce)

parentId: // id of the parent article, empty if root
content: string, // content (nested json, markdown fields, schema)
constentUri?: // maybe an ipfs (or other) cid
contentVersion: string, // content of the post (markdown)
refs: // array of refferenced ids
tags: // array of tags

reaction (lil duce)

type: // type of reaction

profile

tbd

link/grouped (duce pile)

tbd

posible usescases other schema contexts/scopes

- lil duce
- reactions
- trigger duce, something for offchain subscription
- link/group duce
- duce that could link and group multiple contexts

- big duce
- articles / blogs
- DIN
- article
- reaction
- comment / reply
- admin / proposal duce
- vote context
- proposal context
- comment duce
- proposal draft
- profile duce
- dao profile duce
- member profile duce
- signal sesh
- session duce
- choice duce
- cookiejar reason
- yeet deets

### notes
Poster.sol has 2 string fields content and tag. Content should contain a json string with meta data around a post 'node' and nested content in that. tag is used to set indexer level permissions / verification

> when poster is used from another contract ther is some extra information in that with the contract always being the sender

> align with rss?

> we may need a new validation type around shamans

> possible issue with order of operations with HOS. Shamans and HOS could want to make a record entry before the dao is summoned. that means the entery might not be indexed

> **Using shamans for indexing source is interesting, a 0 or > 7 permission shaman could act as a registry**
> proposed changes https://github.com/HausDAO/monorepo/compare/feat/shaman-poster-graph?expand=1

> other subgraph note: have noticed that shares/loot minted by HOS and shares/loot config happend by HOS before summon is not indexed. (this issue ended up having to do with needing to lowerCase)

> can filter be used on content
> ```const data = await listRecords({
networkId: chainId,
graphApiKeys: graphApiKeys,
filter: { dao: daoId, table: recordType, **more filters?** },
paging: { pageSize, offset },
});```

## verification / validation
- DAO membership
- shares only
- shares or loot
- delegation?
- base factory events
- proposal events
- future
- shamans
- based on other content (a id)
- based on other token holder?
- nodes can be signed with ethereum keys
- contracts could be allow listed

## Usecases - example thinking on potential usecases
Dao currated content
DIN
Emitter WTF

## Dao currated content
A lits of content currated by a DAO. Like a page of community content, anyone can create a submission to be added to it but only past authors of submissions would have final vote on if to include.
- Awesome list of Community projects
- List of community sponsors

## DIN usecase

> Problem: As an aspiring content creator, I'm hindered by traditional platforms that limit my ownership and control over my creations. Their retention of rights, distribution, and unfair compensation leave me frustrated and disempowered, unable to fully realize the value of my work.

POC and more details https://dekanbro.github.io/DAO-app-tutorial/

### THe DIN MVP build would include
- a summoner which would deploy and setup the initial publication DAO and NFT shaman.
- an explorer page that shows all DIN DAOs
- the publication app (similar to the POC with design and more fleshed out feature set)

### next steps
design sprint around MVP and tokenomics

## emitter wtf usecase (orig POC not leveraging dao-database)

### channels
a factory should deploy a standard wrapper around Poster.sol (channel emmiter). this way every channel is its own contract, it could have tag generation logic, also could be used for role/token gatting, fees, relayers or other nuonces. Channel can have different meta data: title/topic/etc. Channels could have a owner (DAO)

a channel would probably have a domain of a DAO or a more general app. could be scopped to more specific things

### post
A post can have a context of parent or child(anything string)
A root post is top level content.
A child (reaction/reply) and requires a parent

### indexing:
because of the channel emmiter contract indexing is scopped and in may case could be done client side. Could be a good usecase for a subgraph if multiple popular channels.

because this uses poster under the hood all data can be easily indexed, the contract wrapper allows further easy scoping

### post verification
a post needs to be able to be verified as coming from a signer and is unique

// TODO
  // add uuid and sender address to a signed hash
  // contract solution?
  // allows to verify that the content was created by the sender
  // uuid is a salt for a unique hash
  // this does not prevent a user from submitting the same salt again
  //  - maybe this is a feature for delete/edit, only using the most recent
  // const tag = `${TARGET.DOMAINID}:${uuid}:${address}

## Emiiter WTF UI

emiiter.wtf is a simple mico blog site
a post can be made by any address
a post can get a upddot or downdoot (increment totals, only one per account)
a post can have a reply

ipfs deploy - nobunny can take it down

### other potential actions
- bookmark // easy access in future
- go to external link // link out to external ref in post
- share // permalink to dedicated page
- go to replys // dedicated page for post and replys
- tip // sender address to send a tip to (alternate dao treasury)
- launch dao // launch a DAO and NFT for tips

### new channel summoner
### channel explorer

## DAOhaus emiiter react component
- should tak a contract, domain and scope
- install as npm package

## all on chain and no dependencies?
doesn't this require signatures and cost gas?
has no way to censor content or block spam?
**maybe thats the point**

## tips
any post can recieve a tip. tips could include stable or haus. there should be a splits to eco fund, product fund and OP. there could also be a burn of haus/duce for rev share.

## updoots / tipdoots
fee to OP, share to early adopters
fee to DAO treasury? OP choice on withdraw

## batch actions
keep a ui element on the bottom of page or something. allows users to periodically commit all changes with single signature (ups/comments/replys/etc)

## kick off notes