dao-governance-framework/forum-network/notes/notes.md

# Challenges

- Receiving payments
- Distributing payments to participants
- Computing updates to forum graph

---

# Receiving payments

Business SC will need to implement a financial model.

---

# Excerpts from DeSciPubDAOArchit22July19PrintCut.pdf

> With today’s prices, however, we will begin by programming this all off-chain and simplify the reputation tokens to be less dynamic in their evaluation. Next iteration improves the decentralization commensurate with practical realities.

---

# Validation pool termination

How do we want to handle this?
The validation pool specifies a duration.
We don't want to compute results until the end of this duration.
We're currently supporting anonymous voting.
With anonymous voting, we need to wait until the end of the vote duration,
and then have a separate interval in which voters reveal their identities.
For now, we can let anonymous voters reveal their identities at any time

---

Bench.totalReputation is a very important quantity, isn't it? Basically determines inflation for reputation.

---

Should availability registration encumber reputation?

---

- Is a particular availability stake amount required?

Currently we support updating the staked amount.
Seems like a soft protocol thing.
A given DAO can have a formula for deciding appropriate amounts.

---

The following was a code comment on `Business.submitRequest(fee, ...)`:

> Fee should be held in escrow.
> That means there should be specific conditions under which the fee will be refunded.
> That means the submission should include some time value to indicate when it expires.
> There could be separate thresholds to indicate the earliest that the job may be cancelled,
> and the time at which the job will be automatically cancelled.

# Implementing forum

Does the following make sense?
We will link the forum to the bench
An author of a forum post /_ ? is always? can be? _/ a reputation holder.
This is what we call a expert. Let's update that terminology to be `reputationHolder`.
That's too long, though. Let's rename it to `expert`.
So we want to aim for the situation where the author of a forum post is an expert.
For now let's try thinking of them as experts no matter what;
The strength of their expertise is meant to be represented by reputation tokens.
So each reputation token must be a contract.
Minting a reputation token means to construct an instance of such a contract.
The reputation contract then has its own lifecycle.
We can support dynamic reevaluation if the reputation contract

- has an interface that allows (securely) updating
- Define secure :: passes validation pool
- How shall it know the operation is occurring as part of an "official" validation pool?
  It can verify a signature...

---

Tokens staked for and against a post.

---

Token loss ratio

---

parameter q_4 -- what is c_n?

---

what is reputation?
valuable evidence that you're going to do what you say you'll do in the future

---

for now, combine c2 and c3

validation pool should compute rewards for author,
then send that to the forum to distribute.