Notes
This commit is contained in:
parent
77ae33ce5a
commit
aba7cc6870
|
@ -0,0 +1,101 @@
|
||||||
|
# Revenue-generating work
|
||||||
|
|
||||||
|
## Expert stakes REP to register availability
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
graph
|
||||||
|
|
||||||
|
subgraph EOA
|
||||||
|
expert(Expert)
|
||||||
|
|
||||||
|
end
|
||||||
|
|
||||||
|
subgraph Contracts
|
||||||
|
availability(Availability)
|
||||||
|
end
|
||||||
|
|
||||||
|
expert -- 1. Stake ℝ --> availability
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
## Public submits work request with fee
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
graph
|
||||||
|
|
||||||
|
subgraph EOA
|
||||||
|
expert(Expert)
|
||||||
|
public(Public)
|
||||||
|
end
|
||||||
|
|
||||||
|
subgraph Contracts
|
||||||
|
business(Business)
|
||||||
|
availability(Availability)
|
||||||
|
end
|
||||||
|
|
||||||
|
public -- 1. Request<br />with fee $ --> business
|
||||||
|
business -- 2. Assign<br />work --> availability
|
||||||
|
availability -- 3. Transfer<br />staked ℝ --> business
|
||||||
|
availability -- 4. TODO Notify --> expert
|
||||||
|
```
|
||||||
|
|
||||||
|
## Expert submits work evidence
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
graph
|
||||||
|
|
||||||
|
subgraph EOA
|
||||||
|
expert(Expert)
|
||||||
|
end
|
||||||
|
|
||||||
|
subgraph Contracts
|
||||||
|
business(Business)
|
||||||
|
forum(Forum)
|
||||||
|
pool(Pool)
|
||||||
|
end
|
||||||
|
|
||||||
|
expert -- 1. Work<br />evidence --> business
|
||||||
|
business -- 2. Post --> forum
|
||||||
|
business -- 3. Stake ℝ --> pool
|
||||||
|
```
|
||||||
|
|
||||||
|
## Peers validate the work evidence
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
graph
|
||||||
|
|
||||||
|
subgraph EOA
|
||||||
|
peers(Peers)
|
||||||
|
end
|
||||||
|
|
||||||
|
subgraph Contracts
|
||||||
|
forum(Forum)
|
||||||
|
pool(Pool)
|
||||||
|
end
|
||||||
|
|
||||||
|
peers -- 8. Stake ℝ --> pool
|
||||||
|
pool -- 9. Validate post,<br />Transfer ℝ --> forum
|
||||||
|
```
|
||||||
|
|
||||||
|
## Rewards are distributed
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
graph
|
||||||
|
|
||||||
|
subgraph EOA
|
||||||
|
expert(Expert)
|
||||||
|
peers(Peers)
|
||||||
|
end
|
||||||
|
|
||||||
|
subgraph Contracts
|
||||||
|
pool(Pool)
|
||||||
|
business(Business)
|
||||||
|
forum(Forum)
|
||||||
|
end
|
||||||
|
|
||||||
|
pool -- Reward ℝ --> peers
|
||||||
|
forum -- Award ℝ --> expert
|
||||||
|
forum -- Award ℝ<br />via citation<br />WDAG --> peers
|
||||||
|
business -- Award % fee $<br />weighted by ℝ--> expert
|
||||||
|
business -- Award % fee $<br />weighted by ℝ--> peers
|
||||||
|
```
|
|
@ -0,0 +1,9 @@
|
||||||
|
## Client/UI
|
||||||
|
|
||||||
|
Voting consists of staking operations performed by software operated by owners of EOA.
|
||||||
|
|
||||||
|
This software may be referred to as "The UI". It may also be considered "a client".
|
||||||
|
|
||||||
|
It will need to be a network-connected application. It will need a certain minimum of RAM,
|
||||||
|
and for some features disk storage,
|
||||||
|
and for some features uptime .
|
|
@ -0,0 +1,5 @@
|
||||||
|
# Client Operations
|
||||||
|
|
||||||
|
Client must communicate with one or more servers.
|
||||||
|
|
||||||
|
Client must build a local view
|
|
@ -33,3 +33,114 @@ WHAT is our protocol for evaluating the perspectives offered by peers?
|
||||||
- If there is the HOPE of exact agreement, mistakes and attacks can be costly
|
- If there is the HOPE of exact agreement, mistakes and attacks can be costly
|
||||||
|
|
||||||
- If there is an EXPECTATION of exact agreement, there must be externalities supporting that agreement, i.e. a common protocol and governance of that protocol.
|
- If there is an EXPECTATION of exact agreement, there must be externalities supporting that agreement, i.e. a common protocol and governance of that protocol.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Internal operations
|
||||||
|
|
||||||
|
## Expert starts new DAO
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
graph
|
||||||
|
|
||||||
|
subgraph EOA
|
||||||
|
expert(Expert)
|
||||||
|
end
|
||||||
|
|
||||||
|
subgraph Contracts
|
||||||
|
forum(Forum)
|
||||||
|
pool(Pool)
|
||||||
|
end
|
||||||
|
|
||||||
|
expert -- Post --> forum
|
||||||
|
expert -- Fee $ --> pool
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
## Expert joins existing DAO
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
graph
|
||||||
|
|
||||||
|
subgraph EOA
|
||||||
|
expert(Expert)
|
||||||
|
peers(Peers)
|
||||||
|
end
|
||||||
|
|
||||||
|
subgraph Contracts
|
||||||
|
forum(Forum)
|
||||||
|
pool(Pool)
|
||||||
|
end
|
||||||
|
|
||||||
|
expert -- 1. Post --> forum
|
||||||
|
expert -- 2. Fee $ --> pool
|
||||||
|
peers -- 3. Stake ℝ<br />to approve --> pool
|
||||||
|
```
|
||||||
|
|
||||||
|
## Expert submits governance post
|
||||||
|
|
||||||
|
A governance post can be considered one that is respected in some way by the operations of the [Client/UI](./client-or-ui.md).
|
||||||
|
|
||||||
|
This is a broad class of posts.
|
||||||
|
|
||||||
|
Each type of governance post can be individually (or by category?) handled by the business contract for a given DAO.
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
graph
|
||||||
|
|
||||||
|
subgraph EOA
|
||||||
|
expert(Expert)
|
||||||
|
peers(Peers)
|
||||||
|
end
|
||||||
|
|
||||||
|
subgraph Contracts
|
||||||
|
forum(Forum)
|
||||||
|
pool(Pool)
|
||||||
|
business(Business)
|
||||||
|
end
|
||||||
|
|
||||||
|
expert -- 1. Stake ℝ on<br />governance post --> business
|
||||||
|
business -- 2. Post --> forum
|
||||||
|
business -- 2. Fee $ from<br />internal fund? --> pool
|
||||||
|
peers -- 3. Stake ℝ<br />to approve --> pool
|
||||||
|
pool -- 4. Validate --> forum
|
||||||
|
```
|
||||||
|
|
||||||
|
Forum usage is open-ended.
|
||||||
|
DAO protocol consists of core contracts + client behaviors.
|
||||||
|
Core contracts provide resilience to attacks, since reputation minting is financially backed by future income
|
||||||
|
|
||||||
|
Question: What does the DAO do with funds it receives?
|
||||||
|
Awswer: Distributes the funds to members immediately upon resolution of the reputation effects of a funded validation pool.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
Before we delve into example use cases, we need to talk about the [Client/UI](./client-or-ui.md), and make sure we have
|
||||||
|
a sound understanding of how client/ui behaviors interact with the core of the system.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
The forum, pool, business, and availability contracts all work together to express a single DAO.
|
||||||
|
|
||||||
|
Each post in the forum can be its own new DAO
|
||||||
|
|
||||||
|
What it would take for that to happen:
|
||||||
|
|
||||||
|
The seed of the new DAO becomes the tokens minted by that post DAO when it receives fees.
|
||||||
|
|
||||||
|
When will it receive fees? When submitted to its business contract interface.
|
||||||
|
|
||||||
|
What happens then? Work is assigned via availability stakes.
|
||||||
|
|
||||||
|
Meaning that someone has staked reputation.
|
||||||
|
|
||||||
|
Meaning that they had previously been awarded reputation.
|
||||||
|
|
||||||
|
The business contract, or the DAO, or the seed post, must be able to accept an initial fee
|
||||||
|
to mint the reputation of the first expert.
|
||||||
|
|
||||||
|
Then, that expert can stake their reputation on availability to perform the work expressed by the post and its associated business contract.
|
||||||
|
|
||||||
|
These operations can be consolidated.
|
||||||
|
|
||||||
|
When submitting a post to the forum, you may include an optional fee
|
||||||
|
|
|
@ -0,0 +1,30 @@
|
||||||
|
Matrix uses rooms to establish contexts.
|
||||||
|
|
||||||
|
We can have a forum context,
|
||||||
|
wherein a few things happen.
|
||||||
|
|
||||||
|
One is that the forum will have a root post; equivalently, any post can be the root of a forum.
|
||||||
|
|
||||||
|
The context of that post can be preserved.
|
||||||
|
|
||||||
|
The forum is thus a collection of posts. Each post MAY have its own internal structure.
|
||||||
|
A post MAY "replace" a prior post. This consists of on-chain and off-chain elements.
|
||||||
|
On-chain, a new post replaces a prior post.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
Reading Matrix spec, https://spec.matrix.org/latest/
|
||||||
|
|
||||||
|
> Events are signed by the originating server (the signature includes the parent relations, type, depth and payload hash) and are pushed over federation to the participating servers in a room, currently using full mesh topology. Servers may also request backfill of events over federation from the other servers participating in a room.
|
||||||
|
|
||||||
|
> In order to ensure that the mapping from 3PID to user ID is genuine, a globally federated cluster of trusted “identity servers” (IS) are used to verify the 3PID and persist and replicate the mappings.
|
||||||
|
>
|
||||||
|
> Usage of an IS is not required in order for a client application to be part of the Matrix ecosystem. However, without one clients will not be able to look up user IDs using 3PIDs.
|
||||||
|
|
||||||
|
> Users may publish arbitrary key/value data associated with their account
|
||||||
|
>
|
||||||
|
> - such as a human-readable display name, a profile photo URL, contact information (email address, phone numbers, website URLs etc).
|
||||||
|
|
||||||
|
> Users may also store arbitrary private key/value data in their account - such as client preferences, or server configuration settings which lack any other dedicated API. The API is symmetrical to managing Profile data.
|
||||||
|
|
||||||
|
> The client-server API allows clients to send messages, control rooms and synchronise conversation history. It is designed to support both lightweight clients which store no state and lazy-load data from the server as required - as well as heavyweight clients which maintain a full local persistent copy of server state.
|
|
@ -0,0 +1,4 @@
|
||||||
|
digraph {
|
||||||
|
layout=neato
|
||||||
|
|
||||||
|
}
|
|
@ -0,0 +1,56 @@
|
||||||
|
```mermaid
|
||||||
|
graph
|
||||||
|
classDef blue fill:#08f, color:#d8d8d8, stroke-width: 0
|
||||||
|
classDef yellow fill:#dd0, color:#a0c, stroke-width: 0
|
||||||
|
classDef green fill:#8c8, color:#333, stroke-width: 0
|
||||||
|
classDef purple stroke:#c38, stroke-width:2px, fill:#bbf, color:#c38
|
||||||
|
classDef orange fill:#d60, color:#dff, stroke-width: 0
|
||||||
|
classDef fuscia fill:#f6c, color:#00c
|
||||||
|
|
||||||
|
nodeSpec(Node spec<br />Matrix homeservers):::blue
|
||||||
|
storageSpec(Storage spec<br />Matrix homeservers):::orange
|
||||||
|
archiveSpec(Archive spec<br />Weavechain):::green
|
||||||
|
blockchainSpec(Blockchain spec):::purple
|
||||||
|
peerProtocolSpec(Peer protocol spec<br />Matrix messaging):::yellow
|
||||||
|
uiSpec(UI spec<br />Matrix client):::fuscia
|
||||||
|
|
||||||
|
|
||||||
|
nodeSpec --- uiSpec
|
||||||
|
linkStyle 0 stroke:#08f
|
||||||
|
nodeSpec --- storageSpec
|
||||||
|
linkStyle 1 stroke:#08f
|
||||||
|
nodeSpec --- peerProtocolSpec
|
||||||
|
linkStyle 2 stroke:#08f
|
||||||
|
nodeSpec --- archiveSpec
|
||||||
|
linkStyle 3 stroke:#08f
|
||||||
|
nodeSpec --- blockchainSpec
|
||||||
|
linkStyle 4 stroke:#08f
|
||||||
|
|
||||||
|
peerProtocolSpec --- storageSpec
|
||||||
|
linkStyle 5 stroke:#d60
|
||||||
|
|
||||||
|
storageSpec --- blockchainSpec
|
||||||
|
linkStyle 6 stroke:#c38
|
||||||
|
storageSpec --- archiveSpec
|
||||||
|
linkStyle 7 stroke:#8c8
|
||||||
|
|
||||||
|
archiveSpec --- blockchainSpec
|
||||||
|
linkStyle 8 stroke:#c38
|
||||||
|
|
||||||
|
uiSpec --- blockchainSpec
|
||||||
|
linkStyle 9 stroke:#c38
|
||||||
|
uiSpec --- archiveSpec
|
||||||
|
linkStyle 10 stroke:#8c8
|
||||||
|
uiSpec --- storageSpec
|
||||||
|
linkStyle 11 stroke:#d60
|
||||||
|
```
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
graph
|
||||||
|
|
||||||
|
forum --- pool
|
||||||
|
availability --- business
|
||||||
|
business --- forum
|
||||||
|
business --- pool
|
||||||
|
|
||||||
|
```
|
|
@ -4,6 +4,15 @@ export class Action {
|
||||||
this.scene = scene;
|
this.scene = scene;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
/**
|
||||||
|
*
|
||||||
|
* @param src
|
||||||
|
* @param dest
|
||||||
|
* @param msg
|
||||||
|
* @param obj
|
||||||
|
* @param symbol
|
||||||
|
* @returns {Promise<void>}
|
||||||
|
*/
|
||||||
async log(src, dest, msg, obj, symbol = '->>') {
|
async log(src, dest, msg, obj, symbol = '->>') {
|
||||||
await this.scene?.sequence?.log(
|
await this.scene?.sequence?.log(
|
||||||
`${src.name} ${symbol} ${dest.name} : ${this.name} ${msg ?? ''} ${
|
`${src.name} ${symbol} ${dest.name} : ${this.name} ${msg ?? ''} ${
|
||||||
|
|
|
@ -19,7 +19,14 @@ export class ReputationTokenContract extends ERC721 {
|
||||||
this.locks = new Set(); // {tokenId, amount, start, duration}
|
this.locks = new Set(); // {tokenId, amount, start, duration}
|
||||||
}
|
}
|
||||||
|
|
||||||
mint(to, value, context) {
|
/**
|
||||||
|
*
|
||||||
|
* @param to
|
||||||
|
* @param value
|
||||||
|
* @param context
|
||||||
|
* @returns {string}
|
||||||
|
*/
|
||||||
|
mint(to, value, context = {}) {
|
||||||
const tokenId = `token_${randomID()}`;
|
const tokenId = `token_${randomID()}`;
|
||||||
super.mint(to, tokenId);
|
super.mint(to, tokenId);
|
||||||
this.values.set(tokenId, value);
|
this.values.set(tokenId, value);
|
||||||
|
|
|
@ -10,10 +10,10 @@
|
||||||
<div id="flowchart-test"></div>
|
<div id="flowchart-test"></div>
|
||||||
</body>
|
</body>
|
||||||
<script type="module">
|
<script type="module">
|
||||||
import { Box } from '../classes/box.js';
|
import { Box } from '../classes/display/box.js';
|
||||||
import { Scene } from '../classes/scene.js';
|
import { Scene } from '../classes/display/scene.js';
|
||||||
import { Actor } from '../classes/actor.js';
|
import { Actor } from '../classes/display/actor.js';
|
||||||
import { Action } from '../classes/action.js';
|
import { Action } from '../classes/display/action.js';
|
||||||
import { delay } from '../util.js';
|
import { delay } from '../util.js';
|
||||||
|
|
||||||
const DEFAULT_DELAY_INTERVAL = 500;
|
const DEFAULT_DELAY_INTERVAL = 500;
|
||||||
|
|
|
@ -0,0 +1,14 @@
|
||||||
|
/**
|
||||||
|
* We want to be able to define tests essentially as sequences of actions by actors,
|
||||||
|
* with assertions about various values after each action.
|
||||||
|
*
|
||||||
|
* We also want the following features:
|
||||||
|
* - Advance tests automatically, for use as automated regression tests.
|
||||||
|
* - Advance tests manually, for use as a visual demo on a web page.
|
||||||
|
* - Nice to have: Manually add/remove/modify action steps.
|
||||||
|
* - Nice to have: Manually rewind actions to view prior states.
|
||||||
|
* - Nice to have: Export/import sequences of action steps.
|
||||||
|
*/
|
||||||
|
export class Test {
|
||||||
|
|
||||||
|
}
|
Loading…
Reference in New Issue