This commit is contained in:
Ladd Hoffman 2023-03-02 07:45:01 -06:00
parent 77ae33ce5a
commit aba7cc6870
11 changed files with 351 additions and 5 deletions

View File

@ -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
```

View File

@ -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 .

View File

@ -0,0 +1,5 @@
# Client Operations
Client must communicate with one or more servers.
Client must build a local view

View File

@ -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

View File

@ -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.

View File

@ -0,0 +1,4 @@
digraph {
layout=neato
}

View File

@ -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
```

View File

@ -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 ?? ''} ${

View File

@ -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);

View File

@ -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;

View File

@ -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 {
}