Notes

forum-network/notes/business.md

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

forum-network/notes/client-or-ui.md

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

forum-network/notes/client.md

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

forum-network/notes/dao.md

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

forum-network/notes/rooms.md

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

forum-network/notes/system.gv

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

forum-network/notes/system.md

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

forum-network/src/classes/display/action.js

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

forum-network/src/classes/reputation/reputation-token.js

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

forum-network/src/tests/flowchart.test.html

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

forum-network/src/tests/scripts/test-framework.js

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