86 lines
2.8 KiB
Markdown
86 lines
2.8 KiB
Markdown
# 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
|
||
|
||
---
|