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 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;
|
||||
}
|
||||
|
||||
/**
|
||||
*
|
||||
* @param src
|
||||
* @param dest
|
||||
* @param msg
|
||||
* @param obj
|
||||
* @param symbol
|
||||
* @returns {Promise<void>}
|
||||
*/
|
||||
async log(src, dest, msg, obj, symbol = '->>') {
|
||||
await this.scene?.sequence?.log(
|
||||
`${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}
|
||||
}
|
||||
|
||||
mint(to, value, context) {
|
||||
/**
|
||||
*
|
||||
* @param to
|
||||
* @param value
|
||||
* @param context
|
||||
* @returns {string}
|
||||
*/
|
||||
mint(to, value, context = {}) {
|
||||
const tokenId = `token_${randomID()}`;
|
||||
super.mint(to, tokenId);
|
||||
this.values.set(tokenId, value);
|
||||
|
|
|
@ -10,10 +10,10 @@
|
|||
<div id="flowchart-test"></div>
|
||||
</body>
|
||||
<script type="module">
|
||||
import { Box } from '../classes/box.js';
|
||||
import { Scene } from '../classes/scene.js';
|
||||
import { Actor } from '../classes/actor.js';
|
||||
import { Action } from '../classes/action.js';
|
||||
import { Box } from '../classes/display/box.js';
|
||||
import { Scene } from '../classes/display/scene.js';
|
||||
import { Actor } from '../classes/display/actor.js';
|
||||
import { Action } from '../classes/display/action.js';
|
||||
import { delay } from '../util.js';
|
||||
|
||||
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