5.0 KiB
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.