Compare commits

..

137 Commits

Author SHA1 Message Date
Ladd Hoffman 24c183912a remove old stuff 2024-04-04 12:10:00 -05:00
Ladd Hoffman ad382b5caf Merge branch 'semantic-scholar-import' 2024-04-04 12:02:42 -05:00
Ladd Hoffman 846eb73cea Add link to new repo 2023-07-28 18:23:23 +00:00
Ladd Hoffman 1f3d8a7d1e Merge branch 'dev' into 'main'
Moved forum prototype code to https://gitlab.com/dao-governance-framework/forum-logic

See merge request dao-governance-framework/dao-governance-framework!11
2023-07-10 18:36:26 +00:00
Ladd Hoffman 6679b9dedb remove gitlab CI 2023-07-10 13:36:07 -05:00
Ladd Hoffman 7a8bb0a95e Moved forum prototype code to https://gitlab.com/dao-governance-framework/forum-logic 2023-07-10 13:34:50 -05:00
Ladd Hoffman 4d53f5c70e Merge branch 'dev' into 'main'
Improved graph editing

See merge request dao-governance-framework/science-publishing-dao!10
2023-07-10 15:08:35 +00:00
Ladd Hoffman 907b99bb65 Remove extraneous info 2023-07-10 02:41:44 -05:00
Ladd Hoffman 5230f8664b Show vertex ids in graph 2023-07-10 02:33:29 -05:00
Ladd Hoffman 9eff884636 Display vertex type in graph 2023-07-10 01:46:52 -05:00
Ladd Hoffman 8d0daf2062 Minor cleanup 2023-07-10 01:20:51 -05:00
Ladd Hoffman 72c3bd1663 Able to delete vertices 2023-07-09 23:48:45 -05:00
Ladd Hoffman ea6e2d4494 Able to add new vertices and edges 2023-07-09 23:38:59 -05:00
Ladd Hoffman a743a81218 Able to add new vertices 2023-07-09 23:00:57 -05:00
Ladd Hoffman 07370be4fa Misc. fixes/improvements
Standardize vertex as label + list of properties, for rendering and editing
2023-07-09 21:48:00 -05:00
Ladd Hoffman 56132b2fec Add cancel buttons 2023-07-09 16:33:11 -05:00
Ladd Hoffman f978c20104 Fixup, use string for INCINERATOR_ADDRESS 2023-07-09 14:25:34 -05:00
Ladd Hoffman ae5ab09e16 Merge branch 'dev' into 'main'
Basic graph editing

See merge request dao-governance-framework/science-publishing-dao!9
2023-07-04 00:33:47 +00:00
Ladd Hoffman dd582c4d20 Refinements to basic graph editing 2023-07-03 19:30:04 -05:00
Ladd Hoffman 77d6698899 Basic graph editing
Also renamed WDAG -> WDG
2023-07-03 17:03:29 -05:00
Ladd Hoffman 498b5c106f Add basic button input 2023-07-02 04:16:48 -05:00
Ladd Hoffman 9eb3451451 Separate files for Document and Input classes 2023-07-02 02:12:44 -05:00
Ladd Hoffman 82e026f327 Merge branch 'dev' into 'main'
Add some basic introductory text to the home page

See merge request dao-governance-framework/science-publishing-dao!8
2023-06-30 22:03:04 +00:00
Ladd Hoffman 1f1f1f0c1d Add some basic introductory text to the home page 2023-06-30 16:59:38 -05:00
Ladd Hoffman 8bb188ff13 Merge branch 'dev' into 'main'
Dev

See merge request dao-governance-framework/science-publishing-dao!7
2023-06-28 21:14:40 +00:00
Ladd Hoffman 9974712aa9 slight refactor 2023-06-28 09:22:12 -05:00
Ladd Hoffman a8544dfd39 Preliminary support for user input 2023-06-28 08:40:19 -05:00
Ladd Hoffman 36acc56fa2 Remove forum-network stub code 2023-04-23 11:57:37 -05:00
Ladd Hoffman 7e74773242 Refactor to clarify input parameters for validation pool 2023-04-23 11:55:03 -05:00
Ladd Hoffman e602466800 Fixup, add trailing commas 2023-04-23 08:16:30 -05:00
Ladd Hoffman 7eddd66385 Support case where post sender is the only author 2023-04-23 08:12:00 -05:00
Ladd Hoffman 21a0ef6bda Enforce total author weight == 1 2023-04-23 08:06:13 -05:00
Ladd Hoffman ce4f78aa97 Merge branch 'dev' into 'main'
Move params to validation pool

See merge request dao-governance-framework/science-publishing-dao!6
2023-04-23 01:25:39 +00:00
Ladd Hoffman 81823cd009 Move param definitions to validation pool 2023-04-22 20:22:42 -05:00
Ladd Hoffman b02efb66ad Move all params to validation-pool.js 2023-04-22 20:22:35 -05:00
Ladd Hoffman 36c827a40f Notes 2023-04-22 20:22:27 -05:00
Ladd Hoffman 92bbab2a5b Merge branch 'dev' into 'main'
Add support for posts with multiple authors

See merge request dao-governance-framework/science-publishing-dao!5
2023-04-17 01:41:13 +00:00
Ladd Hoffman d4bdb1c435 Add support for posts with multiple authors 2023-04-17 01:41:12 +00:00
Ladd Hoffman f3037a766d Add seq diagram line for rejected citation of incinerator 2023-03-14 21:33:10 -05:00
Ladd Hoffman 5ca884686b Merge branch 'dev' into 'main'
Add special case: Incineration

See merge request dao-governance-framework/science-publishing-dao!4
2023-03-15 02:19:44 +00:00
Ladd Hoffman 2ed07b7f5e Add test verifying reputation cannot be sourced from incinerator 2023-03-14 21:18:12 -05:00
Ladd Hoffman 353190fdcd Update simple power redistribution example
Making the receiving post start with zero value,
for a simpler comparison with example 9
2023-03-14 21:05:30 -05:00
Ladd Hoffman 0a8b170115 Example: use incineration to achieve more balanced reweighting 2023-03-14 20:53:19 -05:00
Ladd Hoffman 5988950857 Add special case: Incineration 2023-03-13 22:40:44 -05:00
Ladd Hoffman 63b43a0f4d Add example of negatively citing a zero-value post
Also adds misc. notes
2023-03-13 21:44:44 -05:00
Ladd Hoffman e6a0c22d3f Add second work evidence post to example 6 2023-03-13 21:12:07 -05:00
Ladd Hoffman dddee70365 Merge branch 'dev' into 'main'
Add example of work SC prototype reputation graph

See merge request dao-governance-framework/science-publishing-dao!3
2023-03-13 21:08:56 -05:00
Ladd Hoffman b943daf28c Merge branch 'dev' into 'main'
Add example of work SC prototype reputation graph

See merge request dao-governance-framework/science-publishing-dao!3
2023-03-13 20:25:34 +00:00
Ladd Hoffman fa7f0620b6 Add example of work SC prototype reputation graph 2023-03-13 20:25:34 +00:00
Ladd Hoffman c4a528283c Merge branch 'dev' into 'main'
Add support for manually stepping through tests

See merge request dao-governance-framework/science-publishing-dao!2
2023-03-03 17:22:21 +00:00
Ladd Hoffman 3072dbae28 Add support for manually stepping through tests 2023-03-02 10:28:28 -06:00
Ladd Hoffman aba7cc6870 Notes 2023-03-02 07:45:01 -06:00
Ladd Hoffman 77ae33ce5a more reorganizing 2023-02-13 10:24:24 -06:00
Ladd Hoffman 602ce75871 Merge branch 'dev' into 'main'
Add link to artifacts generated for each different commit

See merge request dao-governance-framework/science-publishing-dao!1
2023-02-09 21:37:04 +00:00
Ladd Hoffman a2a1035da8 Attempt to fix url 2023-02-09 14:49:50 -06:00
Ladd Hoffman 9e5b6a4064 fixup yaml 2023-02-09 14:18:35 -06:00
Ladd Hoffman 6012cb2d1a Testing CI 2023-02-09 14:15:16 -06:00
Ladd Hoffman 7d89df7a61 Fixup yaml 2023-02-09 13:54:42 -06:00
Ladd Hoffman 87f04bd7d3 Testing publishing dev branch to separate URL 2023-02-09 13:53:09 -06:00
Ladd Hoffman 90eded96e5 Stub files 2023-02-09 13:10:39 -06:00
Ladd Hoffman 1181aca9d7 Notes 2023-02-07 11:56:34 -06:00
Ladd Hoffman 92cfdaaa63 Fixup missing flowcharts 2023-02-06 08:35:48 -06:00
Ladd Hoffman fc27cda81d Reorganization 2023-02-04 22:32:47 -06:00
Ladd Hoffman 4eced65dbf Add basic virtual machine concept 2023-02-02 21:54:37 -06:00
Ladd Hoffman 50df9efabc Update index style and add a comprehensive test page 2023-02-02 21:54:13 -06:00
Ladd Hoffman 30ebe04db7 Add erc20 implementation 2023-02-02 21:53:21 -06:00
Ladd Hoffman d136e6ff45 Add links back to home page 2023-02-02 21:51:54 -06:00
Ladd Hoffman e63d4b9b21 Notes 2023-02-02 21:49:39 -06:00
Ladd Hoffman f57c38e322 Simplify sequence diagram 2023-02-01 23:03:40 -06:00
Ladd Hoffman be71d4f3cd Add additional forum test case 2023-02-01 22:13:25 -06:00
Ladd Hoffman 3541802d93 Refactor to simplify
- Add DAO class to contain the various contracts and data
- Use window?.scene? instead of passing as arg to every constructor
2023-02-01 21:43:47 -06:00
Ladd Hoffman c8ce74cf13 Brainstorming 2023-01-31 22:16:10 -06:00
Ladd Hoffman a48d14905c When propagating value, apply leaching before donations 2023-01-31 09:28:06 -06:00
Ladd Hoffman 5fc5bbe0b5 Refactor part of forum-node into network-node 2023-01-30 20:59:16 -06:00
Ladd Hoffman ab63ad1868 Cleanup related to forum network test
Also misc minor stub additions
2023-01-30 20:30:05 -06:00
Ladd Hoffman c24952497d Move forum tests to new subdir 2023-01-30 20:29:14 -06:00
Ladd Hoffman e7ff4254a3 Fixes to forum value propagation logic 2023-01-30 12:25:08 -06:00
Ladd Hoffman 3cf24c6fa1 Render multiple edge labels
WIP: Forum propagation
2023-01-29 23:43:30 -06:00
Ladd Hoffman 721718ac13 Add failing test for power redistribution via subsequent support 2023-01-29 18:51:24 -06:00
Ladd Hoffman 329af5c640 Add test case for redistributing power in the forum, and fix logic to make it pass 2023-01-29 18:41:07 -06:00
Ladd Hoffman 7cda474d20 Fix forum logic for negative citations 2023-01-29 18:28:27 -06:00
Ladd Hoffman 0c98ae2505 Add mocha tests for validation pool 2023-01-29 17:13:21 -06:00
Ladd Hoffman 23070ae381 Added test of a currently failing scenario 2023-01-29 12:41:03 -06:00
Ladd Hoffman e26afa1eb4 Add mocha tests and fix forum logic 2023-01-29 12:29:51 -06:00
Ladd Hoffman f475742cbf Minor refactoring 2023-01-29 04:38:28 -06:00
Ladd Hoffman e20a864738 Move forum test to its own js file 2023-01-28 14:17:50 -06:00
Ladd Hoffman 1668ceeda3 Adjust values in forum example
- Also add helper function to simplify scenario definition
2023-01-28 10:55:33 -06:00
Ladd Hoffman b7280d9946 Add timestamps to table view 2023-01-28 10:23:07 -06:00
Ladd Hoffman 5834f89882 Improve forum graph rendering 2023-01-28 10:19:26 -06:00
Ladd Hoffman d1570e7672 Fixup negative citation propagations to handle all cases 2023-01-28 09:37:46 -06:00
Ladd Hoffman 667a051c13 Fixup reference chain limit enforcement 2023-01-28 08:24:39 -06:00
Ladd Hoffman 94200b59d4 Fix negative citation propagation 2023-01-28 08:22:52 -06:00
Ladd Hoffman d04b280645 Limit reference chain depth to 1 for negative citations 2023-01-27 21:27:32 -06:00
Ladd Hoffman 4c9cee9963 Added table view 2023-01-27 21:20:13 -06:00
Ladd Hoffman acda73fff4 Clarify sequence for value propagation 2023-01-27 18:07:45 -06:00
Ladd Hoffman db8a8ca346 Fixup old tests 2023-01-26 11:36:39 -06:00
Ladd Hoffman 4789ed7499 Fixup link paths to test files 2023-01-26 11:20:36 -06:00
Ladd Hoffman 0671ad7b64 Fixup css path for index.html 2023-01-26 11:18:06 -06:00
Ladd Hoffman a0d5611ca4 Use relative paths for gitlab pages 2023-01-26 11:15:25 -06:00
Ladd Hoffman 2d48825dae Publish to gitlab pages 2023-01-26 11:07:25 -06:00
Ladd Hoffman 9deaf4db07 Update business and availability contracts to use rep tokens 2023-01-26 10:44:57 -06:00
Ladd Hoffman 8982ac610f Reputation tokens 2023-01-18 01:07:10 -06:00
Ladd Hoffman cd5fce820c eslint 2023-01-17 18:00:41 -06:00
Ladd Hoffman 7a23e94e9d Remove extraneous comments 2023-01-13 08:26:47 -06:00
Ladd Hoffman ea087451ff Refactor 2023-01-12 16:42:35 -06:00
Ladd Hoffman 92da97fede Initial work on reputation nft 2023-01-12 09:04:40 -06:00
Ladd Hoffman 75bb48a0e5 Cannot -> can not 2023-01-12 09:04:17 -06:00
Ladd Hoffman ff5edc64ac Fix revaluation limit enforcement 2023-01-12 09:03:54 -06:00
Ladd Hoffman 83f9007401 Prevent reputation from decreasing below zero 2023-01-11 23:04:12 -06:00
Ladd Hoffman e777a0ee85 Fixup, distribute rewards to voters 2023-01-08 20:28:54 -06:00
Ladd Hoffman 6cc1c25b37 Fixup forum logic 2023-01-08 20:19:33 -06:00
Ladd Hoffman 7c7d01aa91 Use adjusted increment value for author reputation awards 2023-01-08 13:34:26 -06:00
Ladd Hoffman 675fd17734 Implement leaching value 2023-01-08 12:27:53 -06:00
Ladd Hoffman e4566d1a45 Show flowchart at top of page 2023-01-05 14:30:21 -06:00
Ladd Hoffman 1066372371 Add support for flowchart diagrams alongside sequence 2023-01-05 14:21:45 -06:00
Ladd Hoffman b644d6c119 Progress in forum implementation 2023-01-05 01:19:14 -06:00
Ladd Hoffman cfa445471f Post value propagation 2023-01-04 16:28:36 -06:00
Ladd Hoffman 8980885881 Additional cleanup in preparation for forum test 2023-01-04 15:18:29 -06:00
Ladd Hoffman 07b992e572 Rename directory 2023-01-04 14:32:01 -06:00
Ladd Hoffman e34534675f Color theme, notes 2023-01-04 14:30:15 -06:00
Ladd Hoffman f944d19728 Rename `member` to `expert` 2023-01-03 12:00:12 -06:00
Ladd Hoffman f93aaf7373 Diagram theme 2023-01-03 11:59:44 -06:00
Ladd Hoffman 4c53d2a0f7 Prepare forum implementation for further development
Includes minor refactoring of existing code / tests
2023-01-03 01:26:55 -06:00
Ladd Hoffman 03af7d4b10 Move tests to subdir and consolidate html+js 2023-01-02 13:52:05 -06:00
Ladd Hoffman fc3138adab Improve Availability test 2023-01-02 13:14:32 -06:00
Ladd Hoffman 6ad293b5b8 Added business and availability SC 2023-01-01 21:09:02 -06:00
Ladd Hoffman 59c10f1ac2 eslint fixes 2022-12-31 16:08:42 -06:00
Ladd Hoffman d63a93562f eslint 2022-11-30 09:13:52 -06:00
Ladd Hoffman d6a76441ae Add more details to graph 2022-11-17 09:07:11 -06:00
Ladd Hoffman 64a2feeaa8 simplify output 2022-11-17 08:44:57 -06:00
Ladd Hoffman e7120f87b1 Fixes to validation pool 2022-11-17 08:30:06 -06:00
Ladd Hoffman a481710cde Automatic seq graph rendering, with debounce 2022-11-14 10:17:43 -06:00
Ladd Hoffman 41506fdcd5 Improved seq diag logging 2022-11-13 12:25:01 -06:00
Ladd Hoffman c89ba51dab Clarify terminology: Bench, Validation Pool, Vote 2022-11-13 10:54:07 -06:00
Ladd Hoffman c44c70cf03 Basic validation pool is working 2022-11-12 18:06:09 -06:00
Ladd Hoffman beb1a069d7 Validation pool initial implementation 2022-11-11 16:52:57 -06:00
Ladd Hoffman 715943ec77 Work in progress: prototyping forum network 2022-11-07 17:48:49 -06:00
5 changed files with 1 additions and 425 deletions

View File

@ -1,4 +1,4 @@
# Science Publishing DAO # DAO Governance Framework
## Subprojects ## Subprojects

View File

@ -1,101 +0,0 @@
participantgroup #lightblue Voting Contract
participantgroup Methods
boundary "createVote()" as create_vote
boundary "voteResults()" as voting_vote_result
end
participantgroup Data
database "Params" as voting_params
end
end
participantgroup #lightyellow Vote Contract
participantgroup Methods
boundary "vote()" as vote
end
participantgroup Data
database "Votes" as votes
end
end
participantgroup #pink Forum Contract
participantgroup Methods
boundary "post()" as post
boundary "voteResult()" as forum_vote_result
end
participantgroup Data
database "Params" as forum_params
end
end
participantgroup #orange Post\nContract
participantgroup Data
database "Posts" as posts
end
end
participantgroup #lightgreen Operating Accounts
participant "Reputation\nNFT" as rep
participant "Reviewer" as reviewer
participant "Public" as public
end
activate voting_params
activate forum_params
activate rep
group Author a post
public -> post : post()
activate public
activate post
post<-forum_params:Read param values
post -> posts : Create post instance;\nInitialize with current\nparam values
activate posts
posts->posts:Reference\nother posts
deactivate post
deactivate public
end
group Initiate a vote
reviewer -> create_vote : createVote()
activate reviewer
activate create_vote
create_vote<-voting_params:Read params
create_vote -> votes : Create vote instance;\nInitialize with current\nparam values
activate votes
votes -> posts : Reference a post
deactivate create_vote
deactivate reviewer
end
group Cast a vote
reviewer->vote:vote()
activate vote
activate reviewer
vote<-votes:Read prior votes
rep->vote:Read voter reputations
vote->vote:Evaluate\nterminating\nconditions
end
alt Voting terminates, according to params
alt Voting param change
posts->vote:Read post contents
vote->voting_vote_result:voteResult()
voting_vote_result ->voting_params : Update\nparams
end
votes->forum_vote_result:voteResult()
activate forum_vote_result
posts ->forum_vote_result : Read post contents
forum_vote_result<-forum_params:Read params
alt Forum param change
forum_vote_result -> forum_params : Update\nparams
end
forum_vote_result<-rep:Read authors reputations
forum_vote_result->rep:Mint reputation for post / authors / references
deactivate forum_vote_result
activate rep
votes->rep:Mint reputation for vote winners
activate rep
end
vote->votes:Update\nvote\nrecord
deactivate vote
deactivate reviewer

View File

@ -1,84 +0,0 @@
Forum Network Node
---
The forum is a collection of posts.
Each post may reference other posts, attributing some reputation to those posts.
A validation pool may vote to validate forum posts.
When such a vote passes, the reputation minted at the creation of the post, gets awarded
- to the post author
- to the voters
- recursively to cited posts
A post's author should be able to choose how much reputation to stake on it.
- Work evidence post. expect unanimity, decent sized stake, punish losers.
- Upvote on a comment. Low stakes. Constitutes validation of the comment as
- carrying an appropriate stake
- containing appropriate content
- Downvote a comment. Moderate stakes.
- Upvote on a post. Moderate stakes. Constitutes validation of the post as being valuable to the DAO.
- Downvote on a post. Moderate stakes.
what if we don't support generic upvotes?
instead we would just have posts with weighted citations, and standard validation pool votes on each post.
It will be important for forum voting to be cheap too, in addition to posting to the forum.
So we probably need off-chain voting as well.
We probably want each client UI to be validating as many posts as possible.
We can try to do something clever such as monitor the time the user spends with a given post visible on their screen, and if they don't downvote it within a certain time, we can cast an implicit upvote. This would save a lot of manual activity.
The DAO can choose to implement additional automated filtering of what to show the user, and could automatically downvote unwanted content in order to earn validation pool rewards, punish bad actors, and decrease visibility of the unwanted content.
The UI can be configured to highlight incoming, unvalidate posts for the user to review and validate.
A user might choose to disable this option, setting the threshold higher, so that they only see validated posts.
This is something a user might turn on and off at different times, depending on their present mode of engagement with the forum.
I.e., browsing or actively engaged.
Approving these posts should be a quick operation on the client side.
The results of such operations should be propagated among network nodes and to other clients as needed, so that the off-chain system maintains an up-to-date view of the status of each post. Periodically, the resulting changes to reputation balances should be written to the blockchain.
We should identify all viable opportunities to collect payments from users. These payments will be necessary to fund the on-chain operations of this system.
Fundamentally we expect payments will be associated with incoming work requests from outside.
So a post is made requesting work?
Then the worker makes a post presenting the work output for validation.
Discussion may occur in the forum regarding the work output.
This means associates will make new comment posts descending from the work output.
These comments form a body of discussion.
Comments may declare their agreement or disagreement with other comments.
The validation pool will need to validate the comments.
The comments should not mint new reputation if there is no incoming fee.
Instead, the commenter must stake some of their own reputation.
If the comment is successfully validated, it gains comment reeputation.
Then once the parent post is validated, the comment author will get a portion of the reputation minted from the parent post creation.
If the comment is not successfully validated one way or the other, the author's stakes will be returned to them.
If the comment is invalidated, the author will lose their stakes.
The validation pool eventually votes on the work output.
If the vote passes, awards are distributed among
- authors
- cited posts, weighted
- validated comments, weighted by the comment reputation balances
A governance post, such as a parameter change or a client software upgrade, will function similarly.
The expected fee will be smaller.
The reputation awards should be pretty decent.
The discussion around these governance posts will be particularly important.
Posts, including comments and governance posts, can reference prior posts.
Suppose a comment references a prior comment from a different thread (different work product parent post).
Then if reputation is awarded to the new comment, some of it should be transitively awarded to the referenced comment.
In this way, a comment can gain reputation over time, which in turn awards reputation to its authors and cited posts.
Thus, the forum is like a living system, where connections with new posts can influence existing posts.
---
We want the Network Node to accept reputation-staking actions from the web client (to make it more general, let's call it the user agent).
This means the user agent must have a way to prove that the user owns a given reputation token.
Ideally this should be done via a zero-knowledge proof, where
- the server sends the client something,
- the client does something with it and sends a response, and
- the server is able to verify based on the client's response that they own the given reputation token.

View File

@ -1,235 +0,0 @@
# Goals
- Enable each individual to express their values by taking actions in the system.
- Enable a group to arrive at a decision through a process of deliberation.
- Reward participants in the deliberation process.
- Enable participants to post contributions for review.
- Also enable discussion during this review process, a.k.a.
Enable participants to post comments on the review and on other comments
- Enable participants to submit arbitrary posts that stand alone or that reference other posts
- This correctly implies recursion.
- Since we don't want loops, we want a DAG (directed acyclic graph).
# Requirements
## Use Cases
- Outsiders can submit work requests via the Business contract
- Includes fees
- Incoming request can be reviewed and approved by validators
- Adds a post to the forum
- Assigns the work request to an associate, via Availability contract
- Associate can submit their work results via the Business contract
- Adds a post to the forum
- Associates can carry out discussions on the forum by adding new posts.
- Each post can attribute reputation for or against other posts
- Each post should be validated by associates.
- Eventually a formal vote should occur, in the context of the Business contract.
If the votes passes, reputation should be awarded to the following:
- associate who submitted the work
- associates who voted in favor of the post
- associates whose comments in the discussion earned reputation
- Associates can submit new posts to the forum, outside of any existing post or work request
- Each post should be validated by associates
- These can be referenced by future posts, thereby gaining or losing reputation
- Reputation awards are only distributed when posts are later referenced in a fee-generating discussion
## Storage Requirements
- Run-time operational data
- Active sessions
- Possible cache of on-chain data to expedite look-ups
- Subscribe to updates?
- Archival data
- Forum posts and their contents
- This is needed in order to display forum contents to clients,
as well as to compute reputation awards when submitting a batch
of forum results to the forum validator contract.
## Messaging Requirements
# Contracts
## Validator Contract
How generic do we want our validator contract to be?
So far, what I've thought of:
- Points to a forum post.
- Off-chain computation provides reputation effects arising from the forum attribution DAG.
- Network nodes function as voters here, to vote on the result they believe is correct.
This decision is expected to be determined by the forum client software.
The forum contract must include provision for tracking the forum client post with the highest reputation.
A new forum client post would include reputation stake against the previous version, and if
Like all governance decisions and perhaps many other kinds of decisions, there should be a period of deliberation where participants may express their opinions.
At some point it will transition to a formal vote. This will occur when the off-chain network nodes decide to cast formal votes.
## Network Node Contract
- Should require staking reputation to add a new network node
- Should require vote by validation pool to add the new network node
- Should allow vote by validation pool to remove a network node
# Options for architecture of off-chain forum components.
## 1
Use the following components:
- Existing storage network
- Existing messaging network
- New forum network nodes
Effects of this arrangement:
- Pro: Minimize storage and network requirements for the individual network nodes,
since they won't need to talk to each other directly.
- Pro: Gains benefits of whatever features the chosen storage or messaging systems provide.
- Con: Adds infrastructure costs that must be managed.
- Con: Adds requirement to implement integration with chosen storage and messaging systems.
## 2
Use the following components:
- Existing storage network
- New messaging network
- Network nodes talk to each other directly
Effects of this arrangement:
- Pro: Reduce messaging infrastructure costs by implementing this functionality within our own application.
- Nodes can discover each other by reading from the blockchain.
- Nodes can vote for/against each other with regard to their stakes as network nodes.
Nodes can gossip amongst each other.
Nodes MUST be able to verify peer nodes ownership of reputation tokens.
Nodes SHOULD periodically re-verify their local view of the network, with the view that may be accessed on-chain.
Notes:
- Since we need our application to be publicly networked anyway, to interact with user agents,
it's not asking a huge amount for them to communicate amongst one another.
## 3
Use the following components:
- New messaging network
- New storage network
Effects of this arrangement:
- Pro: Integrity of storage can be policed by reputation staking
Notes:
- We would have to choose a consensus algorithm for our data storage, or adopt an existing self-managed solution
---
# Questions
## How much on-chain?
Just hashes? Any full content?
## What forum storage?
IPFS?
Filecoin?
Arweave?
CouchDB?
Custom?
If we use existing/separate networks for storage and/or messaging, how do we police them?
If they mess up our data, whose reputation is staked?
Perhaps this is implicitly covered by the Validator voting, where off-chain results are compared.
We may want to support multiple storage options.
No matter where archival storage occurs, stored data can and should be verified using hashes stored on-chain.
Nodes should only write to the archive AFTER voting on results.
In the worst case, if archived data loses integrity, it will prevent the forum from processing new transactions.
If enough network nodes could agree on a strategy to remediate the data, it might be possible to recover somewhat gracefully. This would depend on the nature and extent of the damage.
The last resort would be to initialize a new forum and abandon the old one.
While this would be disruptive to continuity of operations for the DAO, it would not alter on-chain reputation holdings.
## What forum messaging?
ZeroMQ?
RabbitMQ?
CouchDB?
Custom?
## What UI?
The forum contract should serve the forum network node source code.
If we only store a hash, we need a secure mechanism for storing and serving the actual code.
If we store the full code on-chain, we would also need to document a process for network node operators to obtain the code.
For example, by using existing command-line utilities to interface with the blockchain and download the data.
If we store the full code off-chain, we would still need to document the process for network node operators to obtain the code.
We would also need to make sure that one network nodes are up and running, they help pin the content to IPFS.
The forum network node should then serve the UI to users. This can be served as a web application.
Network node will send HTML, CSS, and Javascript to a browser client.
The browser client must have an extension that allows it to function as a wallet, and it must be able to
provide proof to the forum node, of the user's ownership of reputation tokens.
This can be accomplished as follows:
1. Web client prepares a message (probably using Casper Signer browser extension). Message includes:
- Public key
- Nonce
- Signature
2. Forum node verifies the signed message.
3. Forum node checks on-chain reputation for the given public key.
4. Forum node authenticates the client's HTTPS session.
From there, the forum node should be able to take actions on behalf of the client.
Most of these actions will occur initially within the off-chain context.
Eventually however, the results of the actions should be encoded in an on-chain validation vote.
The above step 3, check on-chain reputation for given key, may be prohibitively expensive.
Here's a way we might deal with that.
When the forum node receives the signature from the client, we can store it along with the data representing other forum activities; we can provisionally accept the offered public key from the client, and use it for the purposes of computing
reputation effects from forum activities. It could be verified asynchronously. If it turns out to have an issue, however,
then we would have to remediate our results before finalizing.
Here's another approach.
Each client will need to pay a small fee to register with the forum.
This would cover the cost of the on-chain transaction which is needed in order for the forum node to verify the client's reputation.
Once verified, the forum will store the client's public key. The client will then be able to authenticate with the off-chain forum network.
Certain actions in the forum will involve an associate staking reputation.
The plan is for the off-chain network to keep track of these actions,
and periodically vote on-chain to enact their results.
In order for these reputation stakes to be realized on-chain,
the Forum Validator Contract must empowered to apply the resulting reputation effects.
Otherwise, the user agent would need to engage directly with the blockchain.
How shall we fund the forum nodes to deploy the necessary calls to smart contracts?
Maybe it should be possible to submit a fee in order to fund a given forum node, and
thereby to gain some reputation, and thus receive a share of the fees that the DAO earns.
This would also suggest the need for a votable parameter to tune the proportion of these rewards.
## Should network node contract voters consist of network nodes, or voting associates?
Network nodes should be resistant to DOS attacks by restricting white-listed peers to the list obtained from the network node contract on-chain.
But what if a whitelisted node starts misbehaving?
A network node that notices a problem with another network node can:
- Locally graylist or blacklist the offending peer.
- Attempt to notify its human operator, who may then cast an on-chain vote against the offender.
- Attempt to notify its network peers, who may then graylist or blacklist the offending peer.
- Automatically cast an on-chain vote aginst the offender.
Let's consider the possibility of nodes notifying each other of problematic behavior of other nodes.
What if a bad node sends messages to its peers attempting to gray/blacklist a good node?
This suggests that each node should listen for such messages from peers, but should require
some number of them before taking action.
Perhaps the degree of graylisting can build up with additional reports from other peers.
It should be expected that people will attempt to attack the network nodes.
If we enforce whitelisting by reputation stakes via on-chain network node contract,
we raise the bar considerably for a successful attack.
Remaining threat models:
- A reputation holder may attempt to act against the interests of the DAO.
- A supply chain attack may occur against the network node or user agent
- A man-in-the-middle attack may occur between network nodes, or between user agents and network nodes
- A network node may be compromised.
- A user agent may be compromised.
Among these threats, the supply chain attack against the network node is the most severe.
The other threats are limited because individual nodes, clients, or accounts must be compromised one by one.
But a supply chain attack may compromise many nodes, clients, or accounts.
Therefore, securing the supply chain is a top priority for this system.
## What's the desired timing of the process to initiate a new network node?
If the initiator already has reputation available to stake, maybe the process shouldn't take very long.
However, it's an action with serious repercussions. If network nodes can be added quickly,
then anyone in control of a disproportionately large amount of reputation for whatever reason,
could potentially quickly add a fleet of new network nodes and execute a 51% attack on the forum.
So, on the order of hours to days seems reasonable to me. Also the answer may depend on the current number of network nodes.
When there are more, it will make sense to add them in batches, and it might be nice to expedite that process to an appropriate degree.
On the other hand, there may not be a legitimate value in adding many new network nodes in the same physical location.
If they're going to be spreat out in space, their activation might as well be spread out in time.

View File

@ -1,4 +0,0 @@
```mermaid
```