DGF
/
dao-governance-framework
6
0
Fork 0
Code Issues 7 Pull Requests Packages Projects Releases Wiki Activity

[SD-3] MVPR Architecture: Generic #3

New Issue
Open
opened 2022-07-26 18:07:53 -05:00 by laddhoffman · 40 comments
laddhoffman commented 2022-07-26 18:07:53 -05:00 (Migrated from gitlab.com)
Copy Link

Goals:

  • Produce sequence diagram that models the outline of an implementation of MVPR

Context:

This system has enough complexity that there are many possible starting points for an approach to implementation. We suggest that a high level architecture diagram can help navigate this decision landscape.

Diagram:

Sequence.org diagram

Figma

Documents:

DeSciPubDAOArchit22July19.pptx

Goals: - Produce sequence diagram that models the outline of an implementation of MVPR Context: This system has enough complexity that there are many possible starting points for an approach to implementation. We suggest that a high level architecture diagram can help navigate this decision landscape. Diagram: [Sequence.org diagram](https://sequencediagram.org/index.html#initialData=A4QwTgLglgxloDsIHMwHsCuwAEBiANlMgBYpggCe2AIgIIDyAUNnqJLPCEqpjrgO7EoEAKbZaAEwC2UBNgDCaJORgRmeFgCNMCCeCoAiLHtGLlIVQAoAlAewgAztmMhRAfRhKIKtS1xadPTBDGSQAJRFgDAhXKCUbO0dsUIg3MEj1f2wTEE1HMQMAMQxdRKc9NDcAMxKJTJFddTZoOEQyXjxCEghNfAwxADUQQhM4uQAFNDR8BS8fdT9mjjaeLGwAWREIYjQJBwWWbNdc-OwDcfAQKQcy7AA3NGgEZDc2K-2DgNr9M5h01xEA0eIgS9icfxEALcD1EB1wDTqh1Y4BanG46DW1GOcIRjAOS1aXHaawIRFIFBE+HwaH42CBolm5lUn2R7EJ6I6m22u32SKR2m+wTOMJBtjB92BLPhjT5rNRKwxOCxMRZLByeQcBXpIhu4pFvL50sRh1xLFxTRRyyJqz4wFkAGtsIU0GAMFJGd4LL5DrgCWjiTguTs9iz1adzpdrrcqi63a9Ix9ZQLdD8DMA0A4IKCkunMziZT6-QqOsqQPm6vjLeyA3gXVxkGJJpmPfNZWHNWczKIkLdcxADfzAqnXKJM9mnCOdd7B4LDCKIg4MPgs2KkjHXVJocC0jql9PDsmgoZPFIpA0V7cT2ekCzD6n0ncoCJ+OPsA+n-wDqbsAjsHjFlW-rYAAQhgDiyDqTgAMryJkRZEuIdwgFA+C5ChwhUDBeLmow8EciSXSkKgIgNNg9DbCIYAtl6Bp4RAZwRI+z6Ubc77MWACz+HRNrYBEUQxNASjYAAcoUAAqA5cYBbRnAA4mgdyUQgXAwCItzEcAnHYHRZxNhAtzgBk5q+tJ1qKp0ZIQDAFBcGRVRVAAtPIxDIQgAA6CBQRQmYiNcjC4O2BTOhuHkAOp0LJtz8HoyD+eaXpQEhDIwrILxvH5CVJWI65xulHw8bQ0Q7FRIDaRmagIMC2AKZRZXNgAXHVK4eQ52CLpoMgOOBQnrm+IhMfwLV9QNQ1XueQ3pdgMAuc8YjAOgubDKNcxes4wCoCAEhzQtGbDOomUAk1TTldgDkAHzYDlm55fVESbdpCbHc251NU4jXyP8DJ9tgsiZipIgANweQAkggwhQMMUAAF5iPwwjEFNGBgOkSAeZNSF9Dq+2qIlh19rR5UOOd+O3SIVSUQ0qkeY8xC1STHnBdc9hhRFjDmgVECjgJYyMAAkAdDJsfwlEHLhhPnULlGk-dXASM4uiUX9jT88uLLpFU1WKVRktgAANE12D1YV3IlU1y2nueX7Kzr52Tpm9V2yufMC2IjsHI7p0XR7jW0JzU6xEoHnbOkDg7PgEgef800iMaLCO+dEJQiK9WJ6I2o2ENlUIJosgSKlzs41lU2fSIW6wkiW0u-Yft5r+eI8aD65SMMdKPPnSIHOrmu1anpcivr+qGwoJcSgyliyE3wzWENAAyUyavgVA57oqWz0oyDZEjAcIAcleF4dvdlyIotIlX+oHNSaCabKwz0aqfUazV2v9R+lH699PtFS69hmwgrVCyySkHZ75dyfsNV+esDafxNj-Ps5trz7jNAWJBsdsCX2vnyUBWtR4iH1jrIe8hHD0VKiKK2qCz6Sg7qfZc2BG4umbjMEUD0upY0PiKAAPA5ZOvd07Tz-tgZeednidzJt3Ki+p9ZsKqu9EeTDLCT3wHw1qYlLKLwEbnVe-CoLFXohILegkd4V0hPvZKwIBw-mQdkYx0Ai6kPUHXKh2AeIfUhKY8u2BKoMjAVIhkjUeHAgzvwueGYRAAHoVHdHUSvZ4Q1tEuggKEuezxN7kAMf+ewJixA+OPiwbJ50UrPHjOQa40s5Z5XUNkz2OCHAyNcWIJhv0YgIFUkDBAoNwaQxhs4cCySYBIxRhANGkZ7jDH6AaCho51B7xsQfEuR91CDxevjIeERyYo1UrA8q9jGiMGcUQn+pCWCeLEGAph9URSBP-pEaI29sAQDQG1GI9oRAeWxjMtxOSMnvLEDrBZVUXr6lKdpMAcRxFmMYCKYmhN6piXIFrDs4VaCyTuQ8raILFI4Ofvxbe+xIVnUBQAVWACYF5CARSRxEJ4MAxo8XJwAKIYwwIdclSBKKhG3h5TwK8DEfFvq3J4G9RBgHZaOfWFgqVCMFQ88pccaH0lSg9YpU0ZoNj+aIKFmYal3TKSdLl3Z+wQuBPktuhSbpEpJUM4p+xcB4vSMAeq6xZD0TtTcgxl1v5MLhggBAittl1DxVdI+O5FzLnOcCBce4bBvNxgyQNIpg17kYMcsR7qNxBpDnuMNogI3LkuaPVKFwrVDQzcuA0cbtwlvokswmKzIQ6ubHq88ZbYybnjZWqpgabrasVe8faNDgpuh7e6aa9ZPksHLe4dtL1O0JiHuagElre0oLFpqzhE7S6VphXCxWrtdBrRJdgRFskPKyAyRK-62A4bbBwX1EN3pcA8T4q6sY2AvI+SkJkddCblycLtUCkAX8wBOBddzJQBpcBfsrRLSIDqnV9WxW63q31Qn2EA04FD6sKbNJ1B5agkQEROB6i2odWxFb2D3QUje6VSNAfqAWaZMbsotvTbuVWvpyrQftY6pA8Hn1CXuZe2QPraO4gY7YyUYnDq-IREAA) [Figma](https://www.figma.com/file/jhYVGgStSgaHcxfnANOgMe/DAO-Governance-Framework?node-id=0%3A1) Documents: [DeSciPubDAOArchit22July19.pptx](/uploads/918dfbdd9e6d36bcccf49479a9ca67b9/DeSciPubDAOArchit22July19.pptx)
laddhoffman commented 2022-07-26 19:39:30 -05:00 (Migrated from gitlab.com)
Copy Link

MVPR Parameters

How can we maintain the Spirit of the Law vs. Letter of the Law using these hyperparameters?

Main Contract

  • Start
    • c1 Minting Ratio
    • c2 Fraction of tokens staked for and against a post
    • c3 Fraction of tokens staked in poster’s name
  • Conditions of winning
    • c4 Ratio of upvotes to downvotes
    • c5 Ratio of upvotes to experts
    • c6 Duration of voting window
  • Voting Typologies: Timing and Binding Parameters
    • c7 Validation pool termination period
    • c8 Token loss ratio
    • c9, c10 ​Contentious debate period
    • c11 Locking time

Forum Contract

  • Start
    • q1 Initial value of post
  • WDAG
    • Reputation Value Operations:
      • q2 Limit to revaluation
      • q3 Limit to the length of reference chain effect
      • q4 Leaching value
      • q7 Limit of potency
    • Node Limits for Incoming and Outgoing Edges
      • q5 Limit of references
      • q6 Limit of referrers

Mindmap of Parameters:
calcaterra2018-On-chain-Governance-of-Decentralized-Autonomous-Organizations_withMarginNotes.pdf

## MVPR Parameters > **How can we maintain the Spirit of the Law vs. Letter of the Law using these hyperparameters?** ### Main Contract - Start - c1 Minting Ratio - c2 Fraction of tokens staked for and against a post - c3 Fraction of tokens staked in poster’s name - Conditions of winning - c4 Ratio of upvotes to downvotes - c5 Ratio of upvotes to experts - c6 Duration of voting window - **Voting Typologies: Timing and Binding Parameters** - c7 Validation pool termination period - c8 Token loss ratio - c9, c10 ​Contentious debate period - c11 Locking time ### Forum Contract - Start - q1 Initial value of post - **WDAG** - Reputation Value Operations: - q2 Limit to revaluation - q3 Limit to the length of reference chain effect - q4 Leaching value - q7 Limit of potency - Node Limits for Incoming and Outgoing Edges - q5 Limit of references - q6 Limit of referrers Mindmap of Parameters: [calcaterra2018-On-chain-Governance-of-Decentralized-Autonomous-Organizations_withMarginNotes.pdf](/uploads/5520c63dbea629f1a116cfafe3772063/calcaterra2018-On-chain-Governance-of-Decentralized-Autonomous-Organizations_withMarginNotes.pdf)
laddhoffman commented 2022-07-26 19:40:06 -05:00 (Migrated from gitlab.com)
Copy Link

Layers of smart contracts

  • Main DAO SC (Validation pool)
  • Business SC (Review)
    • Connects customers, funds, operations
  • Availability SC
    • Getting material in front of the right people
    • Optin in, participating
  • Forum SC
    • Governance
Layers of smart contracts - Main DAO SC (Validation pool) - Business SC (Review) - Connects customers, funds, operations - Availability SC - Getting material in front of the right people - Optin in, participating - Forum SC - Governance
laddhoffman commented 2022-07-26 21:02:54 -05:00 (Migrated from gitlab.com)
Copy Link

changed title from MVPR Architecture to {+[SD-2] +}MVPR Architecture

changed title from **MVPR Architecture** to **{+[SD-2] +}MVPR Architecture**
laddhoffman commented 2022-07-26 21:03:01 -05:00 (Migrated from gitlab.com)
Copy Link

changed title from [SD-{-2-}] MVPR Architecture to [SD-{+3+}] MVPR Architecture

changed title from **[SD-{-2-}] MVPR Architecture** to **[SD-{+3+}] MVPR Architecture**
laddhoffman commented 2022-07-26 21:05:24 -05:00 (Migrated from gitlab.com)
Copy Link

changed the description

changed the description
laddhoffman commented 2022-07-27 17:02:59 -05:00 (Migrated from gitlab.com)
Copy Link

Aaron: Question, do reviews get a score like articles do?

Jonathan: No, because we want them to be double-blind

Aaron: Question, do reviews get a score like articles do? Jonathan: No, because we want them to be double-blind
laddhoffman commented 2022-07-27 17:15:44 -05:00 (Migrated from gitlab.com)
Copy Link

Article data structure:

  • Title/Address

  • Contributors, weighted by contributions

  • AREP - Derived from citations and reviews

  • Citations away - Weighted list

  • Article data - Artifact - Content and/or Hash and/or External Reference

Article data structure: - Title/Address - Contributors, weighted by contributions - AREP - Derived from citations and reviews - Citations away - Weighted list - Article data - Artifact - Content and/or Hash and/or External Reference
laddhoffman commented 2022-07-27 17:22:09 -05:00 (Migrated from gitlab.com)
Copy Link

In this context, we agree to assume all operational data will be on-chain. Off-chain, non-operational shall include things like article content.

Question, will some posts live on-chain and some not?

In this context, we agree to assume all operational data will be on-chain. Off-chain, non-operational shall include things like article content. Question, will some posts live on-chain and some not?
laddhoffman commented 2022-07-27 18:40:58 -05:00 (Migrated from gitlab.com)
Copy Link

To what extent do we want or need to encode our own data history vs relying on records provided by the underlying blockchain storage?

To what extent do we want or need to encode our own data history vs relying on records provided by the underlying blockchain storage?
daedelan commented 2022-07-28 13:55:54 -05:00 (Migrated from gitlab.com)
Copy Link

In regards to science publishing, I limit the referrers and references (q5,6) by requiring annotated bibliographies that will be actively reviewed and weighted more heavily than context citations. I also putting a cap on the amount of reputation allocated to work cited so that citation mills will have diminishing returns. Hard coding the parameters works, but improving practices within the system is preferable.

In regards to science publishing, I limit the referrers and references (q5,6) by requiring annotated bibliographies that will be actively reviewed and weighted more heavily than context citations. I also putting a cap on the amount of reputation allocated to work cited so that citation mills will have diminishing returns. Hard coding the parameters works, but improving practices within the system is preferable.
laddhoffman commented 2022-07-28 15:31:02 -05:00 (Migrated from gitlab.com)
Copy Link

changed title from [SD-3] MVPR Architecture to [SD-3] MVPR Architecture{+: Generic+}

changed title from **[SD-3] MVPR Architecture** to **[SD-3] MVPR Architecture{+: Generic+}**
laddhoffman commented 2022-07-28 15:34:12 -05:00 (Migrated from gitlab.com)
Copy Link

mentioned in issue #4

mentioned in issue #4
laddhoffman commented 2022-07-28 17:21:32 -05:00 (Migrated from gitlab.com)
Copy Link

Technology Stack Overview

graph BT

%% Actors

user
UI
api[API]
sc[Smart Contract]
chain[Block Chain Data]
data[Off-Chain Data]
user[User] -- input --> UI

%% Actions

UI -- output --> user
UI -- Request --> api
api -- Response --> UI
api -- Set --> data
data -- Get --> api
api -- Call --> sc
sc -- Operate --> chain
chain -- Read --> api
api -- Notify --> UI
sc -- Watch? --> api
chain -- Watch? --> api

How will Watch be implemented? Maybe something along the lines of https://github.com/Neufund/smart-contract-watch

We would just need a node to spin up, read current blockchain state, and then standby to monitor for changes and issue notifications.

Technology Stack Overview ```mermaid graph BT %% Actors user UI api[API] sc[Smart Contract] chain[Block Chain Data] data[Off-Chain Data] user[User] -- input --> UI %% Actions UI -- output --> user UI -- Request --> api api -- Response --> UI api -- Set --> data data -- Get --> api api -- Call --> sc sc -- Operate --> chain chain -- Read --> api api -- Notify --> UI sc -- Watch? --> api chain -- Watch? --> api ``` How will `Watch` be implemented? Maybe something along the lines of https://github.com/Neufund/smart-contract-watch We would just need a node to spin up, read current blockchain state, and then standby to monitor for changes and issue notifications.
laddhoffman commented 2022-07-28 17:44:02 -05:00 (Migrated from gitlab.com)
Copy Link

Ok so the base protocol should probably support implementations adding custom parameters that map to the base parameters c1..., q1...

Ok so the base protocol should probably support implementations adding custom parameters that map to the base parameters `c1...`, `q1...`
laddhoffman commented 2022-07-28 18:39:36 -05:00 (Migrated from gitlab.com)
Copy Link

What is the process by which implementers will enumerate their domain-specific considerations?

What is the process by which implementers will enumerate their domain-specific considerations?
laddhoffman commented 2022-07-28 18:51:57 -05:00 (Migrated from gitlab.com)
Copy Link

Different groups have different norms, expectations, aesthetics around how to express notions of truth. E.g. composability. How can ideas be connected with one another; how precisely can the relationships be expressed? In what way are claims context-dependent, and in what ways can they be abstracted across contexts?

Enable each DAO to mint reputation corresponding to each category of reputation that its members are able to identify.

This means any given post should be able to stake a claim for 0 or more denominations of reputation. Other members of the DAO should then have an opportunity to affirm or refute these claims. The resulting graph can be evaluated with weights given to each reviewer's own reputation.

Weight of claims can change over time. We should identify the process/mechanism for each way they can change. For example a comment gaining reputation because other members find it valuable.

Different groups have different norms, expectations, aesthetics around how to express notions of truth. E.g. composability. How can ideas be connected with one another; how precisely can the relationships be expressed? In what way are claims context-dependent, and in what ways can they be abstracted across contexts? Enable each DAO to mint reputation corresponding to each category of reputation that its members are able to identify. This means any given post should be able to stake a claim for 0 or more denominations of reputation. Other members of the DAO should then have an opportunity to affirm or refute these claims. The resulting graph can be evaluated with weights given to each reviewer's own reputation. Weight of claims can change over time. We should identify the process/mechanism for each way they can change. For example a comment gaining reputation because other members find it valuable.
laddhoffman commented 2022-07-30 18:44:41 -05:00 (Migrated from gitlab.com)
Copy Link

Diagram distinguishing Proposal and ProposalReview. Reusing Edit and Comment as generic elements.

classDiagram

direction LR

class Member {
    AREP
    RREP
    CREP
    GREP

    getPosts()
    getReputationHistory()
}

class Post {
    Id id
    [] authors
    blob content
    [] referencesAway

    getReferencesToward()
    getHistory()
    getStakes()
    getScore(kind)
    stake(kind, amount)
}

class Edit {
    Id postId
    contentOrDelta
}

Member --> Post

Post <|-- Proposal
Post <|-- WorkProduct
Post <|-- Edit
Post <|-- Comment
Post <|-- WorkProductReview
Post <|-- ProposalReview

class WorkProduct {
    stakeAREP()
}

class Comment {
    Id[] commentOn

    stakeCREP()
}

class WorkProductReview {
    Id reviewOf

    stakeRREP()
}

class ScienceArtifact {
    string title
    experimentalData
    dataScripts
    formulas
    figures
    figureScripts
    interpretations
    citations
    annotatedCitations

    getScore(kind)
    getScoreHistory()
}

class Proposal {
    paramChange
    description

    stake()
}

class ProposalReview {
    Id reviewOf

    stake()
}

WorkProduct <|-- ScienceArtifact

WorkProductReview --> WorkProduct
Comment --> WorkProduct
Comment --> WorkProductReview
Comment --> Edit
Edit --> Comment
Edit --> WorkProductReview

ProposalReview --> Proposal
Comment --> Proposal
Comment --> ProposalReview
Edit --> Proposal
Edit --> ProposalReview
Diagram distinguishing `Proposal` and `ProposalReview`. Reusing `Edit` and `Comment` as generic elements. ```mermaid classDiagram direction LR class Member { AREP RREP CREP GREP getPosts() getReputationHistory() } class Post { Id id [] authors blob content [] referencesAway getReferencesToward() getHistory() getStakes() getScore(kind) stake(kind, amount) } class Edit { Id postId contentOrDelta } Member --> Post Post <|-- Proposal Post <|-- WorkProduct Post <|-- Edit Post <|-- Comment Post <|-- WorkProductReview Post <|-- ProposalReview class WorkProduct { stakeAREP() } class Comment { Id[] commentOn stakeCREP() } class WorkProductReview { Id reviewOf stakeRREP() } class ScienceArtifact { string title experimentalData dataScripts formulas figures figureScripts interpretations citations annotatedCitations getScore(kind) getScoreHistory() } class Proposal { paramChange description stake() } class ProposalReview { Id reviewOf stake() } WorkProduct <|-- ScienceArtifact WorkProductReview --> WorkProduct Comment --> WorkProduct Comment --> WorkProductReview Comment --> Edit Edit --> Comment Edit --> WorkProductReview ProposalReview --> Proposal Comment --> Proposal Comment --> ProposalReview Edit --> Proposal Edit --> ProposalReview ```
laddhoffman commented 2022-07-30 19:21:00 -05:00 (Migrated from gitlab.com)
Copy Link

Diagram focusing on AREP and RREP

classDiagram

direction LR

class Author {
    identity
    AREP
    RREP
    CREP

    getPosts()
    getReputationHistory()
}

class Member {
    post()
}

class Post {
    Id id
    Author[] authors
    blob content
    [] referencesAway

    getReferencesToward()
    getHistory()
    getStakes()
    getScore(kind)
    stake(kind, amount)
}

class WorkProduct {
    AREP
}

class WorkProductReview {
    Id reviewOf

    stakeRREP()
}

class Patent {
    license()
}

Author <|-- Member

Member --> Post

Post <|-- WorkProduct : instance
Post <|-- WorkProductReview : instance

WorkProduct <|-- Patent : instance

WorkProductReview --> WorkProductReview : RREP
WorkProductReview --> WorkProduct : RREP
WorkProduct --> WorkProduct : AREP
WorkProduct --> Author : AREP

Patent --> Member : Profit weighted by AREP
WorkProductReview --> Member : Fees / RREP bounty
Diagram focusing on AREP and RREP ```mermaid classDiagram direction LR class Author { identity AREP RREP CREP getPosts() getReputationHistory() } class Member { post() } class Post { Id id Author[] authors blob content [] referencesAway getReferencesToward() getHistory() getStakes() getScore(kind) stake(kind, amount) } class WorkProduct { AREP } class WorkProductReview { Id reviewOf stakeRREP() } class Patent { license() } Author <|-- Member Member --> Post Post <|-- WorkProduct : instance Post <|-- WorkProductReview : instance WorkProduct <|-- Patent : instance WorkProductReview --> WorkProductReview : RREP WorkProductReview --> WorkProduct : RREP WorkProduct --> WorkProduct : AREP WorkProduct --> Author : AREP Patent --> Member : Profit weighted by AREP WorkProductReview --> Member : Fees / RREP bounty ```
laddhoffman commented 2022-07-30 19:59:18 -05:00 (Migrated from gitlab.com)
Copy Link

Diagram focused on GREP

classDiagram

direction LR

class Author {
    identity
    AREP
    RREP
    CREP

    getPosts()
    getReputationHistory()
}

class Member {
    Id id
    post()
}

class Post {
    Id id
    [] authors
    blob content
    [] referencesAway

    getReferencesToward()
    getHistory()
    getStakes()
    getScore(kind)
    stake(kind, amount, coupling)
}

class Proposal {
    paramChange
    description
    [] attestation
    stakedGREP
    [] pollResults
    [] voteResults

    stakeGREP()
    attest()
    voteNonbinding()
    voteBinding()
}

class ProposalReview {
    Id reviewOf

    stake()
}

Member --> Post
Author <|-- Member

Post <|-- Proposal : Instance
Post <|-- ProposalReview : Instance

ProposalReview --> Proposal : GREP
Proposal --> Member : GREP\nto winners

Member --> Proposal : Attest
Member --> Proposal : Vote (Nonbinding)
Member --> Proposal : Vote (Binding)
Diagram focused on GREP ```mermaid classDiagram direction LR class Author { identity AREP RREP CREP getPosts() getReputationHistory() } class Member { Id id post() } class Post { Id id [] authors blob content [] referencesAway getReferencesToward() getHistory() getStakes() getScore(kind) stake(kind, amount, coupling) } class Proposal { paramChange description [] attestation stakedGREP [] pollResults [] voteResults stakeGREP() attest() voteNonbinding() voteBinding() } class ProposalReview { Id reviewOf stake() } Member --> Post Author <|-- Member Post <|-- Proposal : Instance Post <|-- ProposalReview : Instance ProposalReview --> Proposal : GREP Proposal --> Member : GREP\nto winners Member --> Proposal : Attest Member --> Proposal : Vote (Nonbinding) Member --> Proposal : Vote (Binding) ```
daedelan commented 2022-08-01 06:52:15 -05:00 (Migrated from gitlab.com)
Copy Link

I might have misheard the problem. Reviews will also get scores. In fact Reviews are the heart of MVPR. Anyone can make a post, however its real value should be based on how well those posts survive validation processes. Also I think we also talked about identity regarding the topic.

Regarding double-blind reviews, this is where we also need to rope in different identities to prevent collusion etc. Having ones reputation at stake on the paper being reviewed is another form of accountability that would deter collusion.

In the whitepaper I wrote, I suggested seasonal governance where the scoring of reviews and articles will oscillate like a predator prey model. Sometimes the ecosystem needs to be more innovative, sometimes it needs to focus on validation depending on the "health" of the ecosystem - ie. if the ratio of negative citations, peer review, and replication studies raises above a threshold, the parameters will shift (tbd by group) to value replication papers more.

I might have misheard the problem. **Reviews will also get scores. In fact Reviews are the heart of MVPR.** Anyone can make a post, however its real value should be based on how well those posts survive validation processes. Also I think we also talked about identity regarding the topic. **Regarding double-blind reviews, this is where we also need to rope in different identities to prevent collusion etc.** Having ones reputation at stake on the paper being reviewed is another form of accountability that would deter collusion. **In the whitepaper I wrote, I suggested seasonal governance where the scoring of reviews and articles will oscillate like a predator prey model.** Sometimes the ecosystem needs to be more innovative, sometimes it needs to focus on validation depending on the "health" of the ecosystem - ie. if the ratio of negative citations, peer review, and replication studies raises above a threshold, the parameters will shift (tbd by group) to value replication papers more.
laddhoffman commented 2022-08-01 18:11:37 -05:00 (Migrated from gitlab.com)
Copy Link

Sequence diagram for interactions among smart contracts and internal/external user interfaces

Sequencediagram.org diagram

Sequence diagram for interactions among smart contracts and internal/external user interfaces [Sequencediagram.org diagram](https://sequencediagram.org/index.html#initialData=C4S2BsFMAIFkDUAKAlaBhA9gO2AJwIYDGwAztPlgCbQCSOkuAZkZCQFCQ64CeJADkRBYA5tAAMAOgBsbAblCEQAnMNwYArn2gBlALb556bHiKk20aHIVKKwVRq2x8Q6ABEAggHkdaADpYACnh8cBBKfFBsaEQMDHAASnNoAGIAWmgACQ0SVjgkVDl8XUhgBnYLCysQRWVgaAAiRAMikn9CAEYJCQ72+vIyQt0SAH1CJM5KJKSqmtt7TWgAIXUSIVYybT9A5EgANxBIAHcSRIs0oywsSGIyQhXgDGLcEgAaaEZ1KlfoDD4GCJA2HKFRmNhwDQA6hhcABrfw7ACO6lYwD6+AGako6mI4yoU0qBmstXmWncu2c4HwACMQKFgNwfElzgBxEqgETQfSlXAgELQFyMNTgjCMaDAAAWMB5wnFdT+vygTOg6U8fHZ-Kwb1BAnZwiSBPk1TBdXqmF0ujAqX8xRwJDRZBIwHwMNYuOo+MshKNxLUCwAYtD1LpGRVPYbZuDGs0hv4EZ0JAiAOz2sMtYYI-VholzX1aGKO4Gh7W2BpNAjFbn+RBqPgYEghO39Sx1syhg3ZyM7fZHFO4PYHQ6Z9vekumx420gpwjjzjATMTN0cPGyL0Ruy56AAVRo01XxoaXYHZX825T6hAwyEc+Ha9L6ipoUIJ5oZ4vkAAHnOJtA2Cvw8aSTYABIUxoQPfsjgYXsIMOBhM1A3AGncdQJWhFN8BQ8VoSXSY2BJJYVjWEgyFVf5IiwYFTBAclSlTIZRiSKiaJgQYRgzCwmIiGBz0vHBGOIaiuOgHiP2vH8sAwWiMF2BhhIvK83hEz9oAALjgfAGT7JEQD7aAsMdSBqByXB9kIV1dwIcAoHAH4sCSPtu1gxDUgAPjk3jgDUuhKGqIT8HJWlqVpMBuCSHir2VVzoEdZ1chUiyQmsn5GEYX8OIE5joqdF1KIyoSHKPXA0ugfDEWRR1oEPI54MwsCoqUuo1MWNRjkgeC8tojDUKK0MGsityuqwxC1OraSwhgK5DMMjVGAwYqJKkmTEIat5BrAtSIXFCI6JKY8sAMCbICm6hJT7AB+TNCisyAbOwGruuVNy+rUsqUWgArqt6t9lKivhMWxRqdHvC06kYI6yAoahVygd4wI+wci2aa7bpS4r0tATK-owLEcQsb8fwsJJ8MQBhZtwYMqoRkF-uIR6stisg1L9IRqHhuDQwWmBpNkrGceAN4Ypy1TaDICUQAhrcaB+XB-D4dQ+3ABlNh+P4CHIi7Q0F3JUl+mnGrR1Nkdsy69bp8LwTU9xiJAYQsHIKhoAWkBGE0mD2Yqc26h1ty2eGy6kaSkVUvajH8rdor-cswO7NDX2zfki2gapEHoGnc1Z0zT3+tTmcLcjxKbuS4PQ042i04nA2rujzOE69p7vsBgA5STnYZNaeo9hvs-b1T86NoPfyAqvC7uoCs-qru1Ob0AXfe8PC3c0Ts99xm+8D1G15HmOKh7ifhiXtTtGBsAc-Tvivv3n6ovL2de8RqOR43++C9u7eLD6veIqnlvZ5XmuPOXuHO+IIA6P2LiAh+r9Mxx0-onI+ycT7w38AEbQ2UYDIGQAAUUQKcTuADvZz0csAg0L8i4G1LlKGCmZKCQAoYQwqldQFQNjjBeOADv4z1djJEATkF7jyinHeKz9+5Px3h1Shjk4KZnwvAFuIghyG2rm2ehkFnL13YbQLAYBeS0V2JJGAKC0GVSwYgaAAB6aAfpwa4IvhFAhrFRjEIgaQgeyiFEhDEsohxhA6a1gLMLHYYM+xYDMgokh9EfECNYS9SAQTOChOUeEkYkS3I30ToEhg8S2rKIXG4rxTDjbKJgeor+0BZG0UMbFYx2DzGWOsQo-hblvFOJISI4OQEOLgE8W2Zpv0WyM2qYgMJdFkl03hgE2JmSQnZMSb0n2QCXomOGXM8gtVhrQHcEsnJeJQwLmobQ8RKinKV1NlEyR6yrG5FgjbWU00qQMgwdgxc35fz4WZNzXA+1pkJX7tvYp7lSmjT8SxaMqctoiEgMg1BVTmQmNwY05s-ihGKLAcVOhfizA-KUYi0gbDSnT1bkcsoYVa6APOcA4eKNwGUsKUStRALE5mgru-UlBC0n61aevalBS7oWH+VnNS5SZkIuacimlriRmOPsf04WsKnkJQiWSwqsqtk4rIL9aMbFhawGxoS1i0wZUavLKMtSOqfKz31QuIAA)
laddhoffman commented 2022-08-01 21:24:52 -05:00 (Migrated from gitlab.com)
Copy Link

Current expectation is that Proposals and ProposalReviews will both utilize GREP. This is a distinction between the Work Product process and the Proposal process; in the Work Product process, AREP and RREP are separate.

Current expectation is that Proposals and ProposalReviews will both utilize GREP. This is a distinction between the Work Product process and the Proposal process; in the Work Product process, AREP and RREP are separate.
daedelan commented 2022-08-03 17:08:33 -05:00 (Migrated from gitlab.com)
Copy Link

Science Peer-Review Typology as a real-world example to help with review abstractions as it relates to different identities.

[Science Peer-Review Typology](https://gitlab.com/dao-governance-framework/science-publishing-dao/-/issues/4#note_1050110823) as a real-world example to help with review abstractions as it relates to different identities.
laddhoffman commented 2022-08-08 17:19:26 -05:00 (Migrated from gitlab.com)
Copy Link

Sequence diagram for interactions among smart contracts only; specifically voting and forum.

Sequencediagram.org diagram

Updated sequencediagram.org diagram

Sequence diagram for interactions among smart contracts only; specifically voting and forum. [Sequencediagram.org diagram](https://sequencediagram.org/index.html#initialData=A4QwTgLglgxloDsIHMwHsCuwAEBiANlMgBYQBG+GAptgGprQLLYDCaSYIMEAUNtqEix4IJKkw4AslQjE0AEwDOfftjKYE88AE9sAIhhgqICFXqmAFAEo92EIuyHjpgPoA3BlRX91GTTv0PUwAlKkUMfAhFa1t7bCCoJndPFyNwyJUqTWwVQWg4RBR0LGwAERMQb2wtCBAyexo9AAVwEABbRViHBKTBduV+LPkeIZ4ePOFC8RKCIlJtKnx8NAB3Ok9WdghOblzwfJExYqkZOSUq338wXT0gqhi7bs9MzT2hAtEiiTKKqpq6hr6cxhLrxTwDbCjUb8cb7SafaY4XDARIAa2wADE0GAMG1NhwuLx+BMPkdvtJZAoIT4NFprvpgGhFBAHnFGcyLrSArdPKF0iybI9sAAzbG45KuNIRImQ17EuGkr4lcq1P4VeqKRotTgdUGinFtFx9DovYajWHvQ5KpHY0TIGhNJkQAA6CDYBN28stU2OP1Vqmq6sBzSdnSF7KippGrwtBx931mJCKVCy2AA8sAqJxGMwAIIwGAaSNeuOffShYAYWrQdiugByGIAKqCjMA3qWkOWqG4oFQVlmW93e-2wO34Z3mhgKLBQZXpzBo-IcjxCVA3CYaD1kEbWibV+vTCKxYbjcp9xvsK2xojsLmq3IwHYBE7clPCDBsABaAB8z+Z2AALj-AUVHPQ853fUDuDXC8I3GJ0AB5P31cVTwA0IQCXY14hASgwlyJ0v1-CMHCAlgjFgwjEmZUQYCoABuV0AEkECgaBcKgAAvGgVjY4hHAwMAjCQV1sPXPCITAmgSPg5lFB-Ej0KoYUsyyOjXQYYgs2AiF5GMaCD2kl9+D0qSBDfWBF2XG8WLYqALxAMFTBUIwez7bSf0cCjXDuQCvOcMxPGsKDoEMy8h3c0d+DMpwNwlLx+FinzPCQrcdx1RQlMwgRdwhJKqHioinLCPzyIC4rsGo2oEDoxiEFs9jCG47BeNkAShKyF0EDE3DqEkgyLzuCEhqKki-NCFThLop84JM-TQovfL4pUUyBsPVzhyzRdr19Fh7AgJ87hciKRx-O4ALuYLorWzdnmuhb1pOrb+DuVLwSyrCwCgbFiohVszs8D7isfVsqxMb6EGGzwAdMACAFFxIwDdXVMMA2kScGmFdQtNDs9hlHNXCDvMRJmFR9GEA3RQABo7ALbF5FJ7AIDQHKMtAyJ1hzNn2kcYg7QSnSYaoIGI0cLZOqh0wYdJ+LUjCaULt5BXIiu1Q0rueX+SItLTz8gBVYAaioUTcqjF7wR-FDDU1qVIiVkIVZA+6YMPa25btmUxqt48Pad8bjCwwicdMJAIXd22naQ920IwrCzeizmsQNHm8RgfmmEF-gI5ST2ipj3KDaN5HuoT2Vhmz33I-5JDWyBkB72xBxQerCHw6r3OnZ-OvJESA6W-B9gj0fMWAHo7EbsAHHHoxJrU-C5rMnPJSdkLXZoK8LdMeTvx7vvwsrVuh-1CreIQBAs36h6N6oNtRjuYXMsN43XTuV0jELMBhlW6-ip4H-17hTciOIAA) [Updated sequencediagram.org diagram](https://sequencediagram.org/index.html#initialData=A4QwTgLglgxloDsIHMwHsCuwAEBiANlMgBYpggCe2AIgIIDyAUNnqJLPCEqpjrgO7EoEAKbZaAEwC2UBNgDCaJORgRmeFgCNMCCeCoAiLHtGLlIVQAoAlAewgAztmMhRAfRhKIKtS1xadPTBDGSQAJRFgDAhXKCUbO0dsUIg3MEj1f2wTEE1HMQMAMQxdRKc9NDcAMxKJTJFddTZoOEQyXjxCEghNfAwxADUQQhM4uQAFNDR8BS8fdT9mjjaeLGwAWREIYjQJBwWWbNdc-OwDcfAQKQcy7AA3NGgEZDc2K-2DgNr9M5h01xEA0eIgS9icfxEALcD1EB1wDTqh1Y4BanG46DW1GOcIRjAOS1aXHaawIRFIFBE+HwaH42CBolm5lUn2R7EJ6I6m22u32SKR2m+wTOMJBtjB92BLPhjT5rNRKwxOCxMRZLByeQcBXpIhu4pFvL50sRh1xLFxTRRyyJqz4wFkAGtsIU0GAMFJGd4LL5DrgCWjiTguTs9iz1adzpdrrcqi63a9Ix9ZQLdD8DMA0A4IKCkunMziZT6-QqOsqQPm6vjLeyA3gXVxkGJJpmPfNZWHNWczKIkLdcxADfzAqnXKJM9mnCOdd7B4LDCKIg4MPgs2KkjHXVJocC0jql9PDsmgoZPFIpA0V7cT2ekCzD6n0ncoCJ+OPsA+n-wDqbsAjsHjFlW-rYAAQhgDiyDqTgAMryJkRZEuIdwgFA+C5ChwhUDBeLmow8EciSXSkKgIgNNg9DbCIYAtl6Bp4RAZwRI+z6Ubc77MWACz+HRNrYBEUQxNASjYAAcoUAAqA5cYBbRnAA4mgdyUQgXAwCItzEcAnHYHRZxNhAtzgBk5q+tJ1qKp0ZIQDAFBcGRVRVAAtPIxDIQgAA6CBQRQmYiNcjC4O2BTOhuHkAOp0LJtz8HoyD+eaXpQEhDIwrILxvH5CVJWI65xulHw8bQ0Q7FRIDaRmagIMC2AKZRZXNgAXHVK4eQ52CLpoMgOOBQnrm+IhMfwLV9QNQ1XueQ3pdgMAuc8YjAOgubDKNcxes4wCoCAEhzQtGbDOomUAk1TTlQAPA5OWbnl9URJt2mRvcwz9LR5XYA5AB8TVOI18j-AyfbYLImYqSIADcHkAJIIMIUDDFAABeYj8MIxBTRgYDpEgHmTUhfQ6vtqiJYdfbPZmDjvcT10iFUlENKpHmPMQtUUx5wXXPYYURYw5oFRAo4CWMjAAJAHQybH8JRQti5R72Tpm9WyyuQsi2ICsHArr0ferjW0LzU6xEoHnbOkDg7PgEgef800iMaLAK+9EJQiK9UO6I2o2ENlUIJosgSKlSsE1lU2-SIW6wkiW3K-Yut5r+eI8ZD65SMMdKPH7SIHOkVTVYpVEuyHIoADQSqO2DfcHxdiJYsiJ8M1hDQAMlMmr4FQ3u6KlDdKMg2Ro-rCAHBHAeHXnociAcatD8lwIDtg1JoJpsrDPRqp9VnNVUVLYBF-92tFS69hNUNYsspSHYr5n2e1Zv28vbv3IlYfCCtWNN6yt+ZoFiwc8L3yF-rxXRdN6lwUI4eipURRfk-vYSeYgIHpyREvbACcXRJxmCKO6XU8YjxFGdJ2ec3Z1yftgNuvtngZyppfKi+oi7YKqmXSEU8GSWBrvgQhrUxKWRbsQn2HciFQWKvRCQvdBL93DpCGBFcZ7v2yOI6AgcIHqFjvA7APEfoMNgZKFglUGT-1oQyRq+DgTuyIY3DMIgAD0HDujcPbs8Ia-CXQQHMY3Z4PdyAiP-NAuRw9g6j3UHokQuDU7PHjOQa4lNbp5X8b49B71JH0MOugwGMQECqTBggSG0NYYI2cOBVxMA0YYwgFje6OMnr428YwvGapZGEwZAE9Q+oNafWAREamGNVIHz7IoxojBVGgIPnA7A2ixD-3QfVEUxjWrpH4n3bAEA0BtRiPaEQHkKl1I0WHLxGzhofgliwHBDl9QRIkNpMAcQqHT0acCd6TsACiZTEnAkNpRUIfcPKeHbiIj4xNbnAnqmJcgOcOzhVoLJeZiytrnMUhXDekRoh932Ig+kqV5mvNkACBwRcLCeDAKQ7uCy7phINMi4J3dJrTXrGPFgvy3pOxuqc-6nzuz9kYCKP5Tw0oJnqgAVWACYVZCAom4HZW9GZ9V1iyHojMhFIjsC9XQUjBACBKIGlxKKi6o8dyLmXBM4EC49xTOLqlC4xKj67mXA4NZtsJGapFNqvcx1SYaztduY2e5WmQkZS9Zl54DSuvcO65cZ1NVXQZUS94+1lxOljO6ClM0GwHADSHIN9E4mhoTMAvlAqSnEp6XUYmIbY1atTQCoFqqVa6DWgK7AoLZIeVkNA3FehUmI2RhXPqOrvS4B4nxWVYxsBeR8lITIyaHXBocuK8NIA95gCcDK-mSgDS4DHam964rJVID6rMuVvV-rmPsLOpwB7M401bVahA1BIgIicD1WNEazyiDnfYKtKVXHpS2Kq+oBZB6VOysW+1qb-J9nXZECVUrt39qEoSpVKq51c0aKK452aAQeRFBbEQzbGC-p2RAnDgdN4IYkEAA)
laddhoffman commented 2022-08-10 14:22:02 -05:00 (Migrated from gitlab.com)
Copy Link

Updated diagram for possible validation pool and forum interactions

Sequence diagram

Updated diagram for possible validation pool and forum interactions [Sequence diagram](https://sequencediagram.org/index.html#initialData=A4QwTgLglgxloDsIHMwHsCuwAEBiANlMgBYpggCe2AIgIIDyAUNnqJLPCEqpjrgO7EoEAKbZaAEwC2UBNgDCaJORgRmeFgCNMCCeCoAiLHtGLlIVQAoAlAewgAztmMhRAfRhKIKtS1xadPTBDGSQAJRFgDAhXKCUbO0dsUIg3MEj1f2wTEE1HMQMAMQxdRKc9NDcAMxKJTJFddTZoOEQyXjxCEghNfAwxADUQQhM4uQAFNDR8BS8fdT9mjjaeLGwAWREIYjQJBwWWbNdc-OwDcfAQKQcy7AA3NGgEZDc2K-2DgNr9M5h01xEA0eIgS9icfxEALcD1EB1wDTqh1Y4BanG46DW1GOcIRjAOS1aXHaawIRFIFBE+HwaH42CBolm5lUn2R7EJ6I6m22u32SKR2m+wTOMJBtjB92BLPhjT5rNRKwxOCxMRZLByeQcBXpIhu4pFvL50sRh1xLFxTRRyyJqz4wFkAGtsIU0GAMFJGd4LL5DrgCWjiTguTs9iz1adzpdrrcqi63a9Ix9ZQLdD8DMA0A4IKCkunMziZT6-QqOsqQPm6vjLeyA3gXVxkGJJpmPfNZWHNWczKIkLdcxADfzAqnXKJM9mnCOdd7B4LDCKIg4MPgs2KkjHXVJocC0jql9PDsmgoZPFIpA0V7cT2ekCzD6n0ncoCJ+OPsA+n-wDqbsAjsHjFlW-rYAAQhgDiyDqTgAMryJkRZEuIdwgFA+C5ChwhUDBeLmow8EciSXSkKgIgNNg9DbCIYAtl6Bp4RAZwRI+z6Ubc77MWACz+HRNrYBEUQxNASjYAAcoUAAqA5cYBbRnAA4mgdyUQgXAwCItzEcAnHYHRZxNhAtzgBk5q+tJ1qKp0ZIQDAFBcGRVRVAAtPIxDIQgAA6CBQRQmYiNcjC4O2BTOhuHkAOp0LJtz8HoyD+eaXpQEhDIwrILxvH5CVJWI65xulHw8bQ0Q7FRIDaRmagIMC2AKZRZXNgAXH2NgeQ5b4iAAjv0zbrm1TH8C1bWdVO2A9Ve54APwDWx-UIK1Y1IAN6XYDALnPGIwDoLmwwDZ4TL0VgqAgBI62bRm22zfYEgSOkDhOIIwiUlAmapdpp0OMM43qJlAJ1d6fbYA5AB8I2xpueX1RER3aQmTTlQDwN9k49UKP8DL-bImYqSIADcHkAJIIMIUDDFAABeYj8MIxDLRgYDpAtCBLUhfQ6l9qiJT9iOw5mDhA4jEMiFUlENKpHmPMQtX8x5wXXPYYURYw5oFRAo4CWMjAAJDfQy02UQcuHlbzgO62AAtQ1wEjOLolGY40WvLiy6RVNVilUSbAA0v3YPVhXciVv07Wgp7nl+dsm0Dk6ZvVkcrpr2tiDHBwx-D9gq8NyO0GnmOCe5SDEDdOz4BIHn-CtIjGiwMdAxCUIivVNeiNqzUXZVCCaLIEipXH7NZctqMiFusJIsd8ep6riu6H+jA8QT65SMMdKPF3SIHE7Lu1Q3A8ip7+reyjkLJVVliyHPwzWANAAyUyavgVDt7oqWX0oyDZLTsRKAcI89z9m+DyI+tIlHvqA41I0CaVlMMeiqo2rOxqm7EQfVKKe3+hnIqLp7ABwutNFklIOzQLXnA3qH4kFe1QX7DBfZA7BxvLKb8ZoCwsFAeAvkBDXYSlEJ7E2e95COHoqVEUocK72G-ofIehwk7LmwLPF088ZgimhrdVmv8RQAB4HJ103k3c+F176d2eKvQW68qL6k9soqqyN5D93YWISwp98DaNamJSyt9sC6MfhdKCxV6ISDfjnT+kIRFiGAUiOh2QAnQF7gI9Qv4AHYB4pYg+QTJQsEqgyQhZiGTI00cCZurUr4ZhEAAeicd0VxHd3GtU8S6CAhSr7PFfuQPxbMIk-37n-dQGSRBAxSs8eM5Brhm0tnlDpbT5FA2sQ4CxVj5EYxiAgVSuMEAEyJiTcmzhwL1JgLTemEAPJM2GF1ZpHNRGszVOE45YhOnqF3uMxGe8IhC3pqpCh5VomNGnuZHhzZ+HJOwKksQhD5H1RFLktq-F35yAgGgbAmN7QiA8kcyJvzR4m2uVVcZ+pBmvTiMY4E+wRR80NvVMS5BXYdnCrQWS2AoVhLAIlJJoh4Hgpzvi4E3S8X1QAKrABMPChAIoS4iE8GAY0BLAZ1wAKLMwwD9AVSBKKhAhR5XancWV4kgYvJ4L9GWKtHJ7Cwwq9HauhcMyukj6QvSWites-8WBiv5pDIZcNdrdn7IwMVPS0oJi5TygEeyYa4DFekYA9V1iyHosG6IEKQa4oZJTBACAbZvLqGKnKm4RQ7kXMuYFwIFx7hsIin6aa-6Zr3Iwf5RiY1xgzTdPcObRB5uXKCz1Fx+kOCmruZcBpi01s7fRW5ht7mQidc2F155u2gxLbWyR4zi3g0ddDNtX1JHBTdIuq4y1VoNgOD27c07+3AznQmPe3LeX+qXfQuoiM1G7vcPu4lpKbYJ0ni4BkFLZIeVkMIw1WNsCU22NYtqWbvS4B4nxKNOdsBeR8lITIt6B77rUcGrFIA0FgCcJGtWSgDS4Hg6W5cQNkNhqQGCiDYwY1e0KfYNDTgqNO2FvMnUHlqCRARE4ISab11nkZROSenquNbCTX4b8X8WkMjw-u-yfZCORFDeG0jWHIXQvjYm9DE86iiYudYxgmne6ooREAA)
laddhoffman commented 2022-08-10 17:29:59 -05:00 (Migrated from gitlab.com)
Copy Link

changed the description

changed the description
daedelan commented 2022-08-10 17:41:39 -05:00 (Migrated from gitlab.com)
Copy Link

changed the description

changed the description
daedelan commented 2022-08-10 17:42:05 -05:00 (Migrated from gitlab.com)
Copy Link

changed the description

changed the description
daedelan commented 2022-08-10 23:00:54 -05:00 (Migrated from gitlab.com)
Copy Link

changed the description

changed the description
daedelan commented 2022-08-10 23:01:21 -05:00 (Migrated from gitlab.com)
Copy Link

changed the description

changed the description
daedelan commented 2022-08-10 23:01:38 -05:00 (Migrated from gitlab.com)
Copy Link

changed the description

changed the description
daedelan commented 2022-08-17 15:58:59 -05:00 (Migrated from gitlab.com)
Copy Link

changed the description

changed the description
daedelan commented 2022-09-09 11:46:23 -05:00 (Migrated from gitlab.com)
Copy Link

Craig had mentioned problems with the long-term sustainability of the MVPR/Semada system if "old" reputational value doesn't decay with time. The q7 hyperparameter can address this problem, but new ideas are welcome.

Our current solution is to still maintain a history of reputation but to differentiate between active and passive reputation. Active reputation relates to reputation salary but its value will decay or have a strong cutoff over time converting to passive reputation. This means people can still see a person's history yet continue to be engaged in earning a reputation salary.

Example: A newcomer to a DAO brings in $100 to a mature MVPR/Semada-based DAO. Without the reputation decay factor, the $100 that low-reputation newcomer brings into the system would be largely distributed to the senior members of the DAO. By including a decay/cutoff transition from active to passive reputation, the total accumulated reputation can still elicit outside funding based on total reputation accumulated while providing a power distribution mechanism that is amenable to short-mid-long term engagement.

Craig had mentioned problems with the long-term sustainability of the MVPR/Semada system if "old" reputational value doesn't decay with time. The q7 hyperparameter can address this problem, but **new ideas are welcome**. **Our current solution is to still maintain a history of reputation but to differentiate between active and passive reputation.** Active reputation relates to reputation salary but its value will decay or have a strong cutoff over time converting to passive reputation. This means people can still see a person's history yet continue to be engaged in earning a reputation salary. **Example:** A newcomer to a DAO brings in $100 to a mature MVPR/Semada-based DAO. Without the reputation decay factor, the $100 that low-reputation newcomer brings into the system would be largely distributed to the senior members of the DAO. By including a decay/cutoff transition from active to passive reputation, the total accumulated reputation can still elicit outside funding based on total reputation accumulated while providing a power distribution mechanism that is amenable to short-mid-long term engagement.
daedelan commented 2022-09-09 15:27:25 -05:00 (Migrated from gitlab.com)
Copy Link

https://sciencepublishingdao.slack.com/archives/C03PF04MHL2/p1662744242137759

https://sciencepublishingdao.slack.com/archives/C03PF04MHL2/p1662744242137759
laddhoffman commented 2022-09-18 23:17:52 -05:00 (Migrated from gitlab.com)
Copy Link

mentioned in issue #5

mentioned in issue #5
laddhoffman commented 2022-10-02 16:51:23 -05:00 (Migrated from gitlab.com)
Copy Link

Preparation for DxD Admin grant proposal

Summary

The outcome of this work shall be a prototype of an MVPR DAO.

Under this model, an MVPR DAO is comprised of a group of experts in a given discipline. The DAO will enable these experts to do the following:

  • Receive work requests and associated fees
  • Submit a forum post
    • Work products for review by fellow experts
    • Governance proposals, including hard and soft protocols
    • Commentary and discussion
    • Posts can stake reputation for/against other posts, forming a weighted graph
  • Vote for/against a forum post
  • Earn reputation by winning votes

Architecture

This MVPR DAO prototype will consist of the following elements:

  • A collection of smart contracts
  • A freestanding application to be run on a server
  • A web client application

The smart contracts constitute the hard protocols of the DAO.

The off-chain server, client software, and user behavior constitute the soft protocols of the DAO.

Smart contracts

  • Reputation
  • Voting
  • Business
  • Forum

Off-chain server software

  • Serve the web client application to the user
  • Coordinate access to off-chain data storage

Web client

  • Browse the forum
  • Post to the forum
  • Participate in voting
Preparation for DxD Admin grant proposal --- # Summary The outcome of this work shall be a prototype of an MVPR DAO. Under this model, an MVPR DAO is comprised of a group of experts in a given discipline. The DAO will enable these experts to do the following: - Receive work requests and associated fees - Submit a forum post - Work products for review by fellow experts - Governance proposals, including hard and soft protocols - Commentary and discussion - Posts can stake reputation for/against other posts, forming a weighted graph - Vote for/against a forum post - Earn reputation by winning votes # Architecture This MVPR DAO prototype will consist of the following elements: - A collection of smart contracts - A freestanding application to be run on a server - A web client application The smart contracts constitute the hard protocols of the DAO. The off-chain server, client software, and user behavior constitute the soft protocols of the DAO. ## Smart contracts - Reputation - Voting - Business - Forum ## Off-chain server software - Serve the web client application to the user - Coordinate access to off-chain data storage ## Web client - Browse the forum - Post to the forum - Participate in voting
laddhoffman commented 2022-10-05 16:24:17 -05:00 (Migrated from gitlab.com)
Copy Link

Technical Architecture

Authentication pathways

  • User must have a private key that corresponds to a wallet contract address
  • Browser extension enables web client to sign messages with the user's key
  • Server must have a private key
  • Web client may challenge server to verify its reputation
  • Server may challenge client to verify its reputation
sequenceDiagram
participant user as User
participant web_client as Web Client
participant server as Server
participant blockchain as Blockchain
participant archive as Archive

user ->> blockchain : Authenticate
user ->> web_client : Authenticate
web_client ->> blockchain : Authenticate
web_client ->> server : Authenticate
server -->> web_client : Authenticate
server ->> blockchain : Authenticate

Application code delivery

  • User may deploy server
  • User may query blockchain to find a hash of, and link to, the canonical server application code
  • User should verify the hash before installing
  • Server may query blockchain to find a hash of, and link to, the canonical client application code
  • Server should verify the hash before serving to clients
  • User will navigate their browser to connect to the server
  • Server will send the client application to the browser
  • User may verify the client application hash
sequenceDiagram
participant user as User
participant web_client as Web Client
participant server as Server
participant blockchain as Blockchain
participant archive as Archive

user ->> blockchain : Query
blockchain ->> user : Server code hash
user ->> archive : Query
archive ->> user : Server code
user ->> server : Deploy
server ->> blockchain : Query
blockchain ->> server : Client code hash
server ->> archive : Query
archive ->> server : Client code

user ->> web_client: Navigate
web_client ->> server : Connect
server ->> web_client : Client code

Read

  • Web client will query the Server
  • Server will build and maintain views of the system data
  • Server will read from a data archive as needed
sequenceDiagram
participant user as User
participant web_client as Web Client
participant server as Server
participant blockchain as Blockchain
participant archive as Archive

user ->> web_client : Browse

web_client ->> server : Query
web_client ->> server : Subscribe

server ->> server : Query
server ->> server : Subscribe

server ->> blockchain : Query
server ->> blockchain : Subscribe
blockchain ->> server : Data

server ->> archive : Query
archive ->> server : Data

server ->> server : Compute
server ->> server : Store
server ->> web_client : Data

web_client ->> user : Display

Write

  • Web client will submit actions to the server
  • Server will update its operational data store
  • Server will call smart contracts as needed to write data
  • Server will upload archive data as needed
sequenceDiagram
participant user as User
participant web_client as Web Client
participant server as Server
participant blockchain as Blockchain
participant archive as Archive

user ->> web_client : Input
web_client ->> server : Data
server ->> server : Store
server ->> server : Message

server ->> web_client : Data
web_client ->> user : Display

server ->> archive : Data
server ->> blockchain : Data

Verify

  • Web client may read content hashes from the blockchain
  • Web client may vote against a server that provides bad data
  • Server may read content hashes from the blockchain
  • Server should use content hashes to verify integrity of stored data
sequenceDiagram
participant user as User
participant web_client as Web Client
participant server as Server
participant blockchain as Blockchain
participant archive as Archive

web_client ->> blockchain : Query
blockchain ->> web_client : Content hash
web_client ->> web_client : Verify content
web_client ->> blockchain : Vote

server ->> blockchain : Query
blockchain ->> server : Content hash
server ->> server : Verify content
server ->> blockchain : Vote
# Technical Architecture ## Authentication pathways * User must have a private key that corresponds to a wallet contract address * Browser extension enables web client to sign messages with the user's key * Server must have a private key * Web client may challenge server to verify its reputation * Server may challenge client to verify its reputation ```mermaid sequenceDiagram participant user as User participant web_client as Web Client participant server as Server participant blockchain as Blockchain participant archive as Archive user ->> blockchain : Authenticate user ->> web_client : Authenticate web_client ->> blockchain : Authenticate web_client ->> server : Authenticate server -->> web_client : Authenticate server ->> blockchain : Authenticate ``` ## Application code delivery * User may deploy server * User may query blockchain to find a hash of, and link to, the canonical server application code * User should verify the hash before installing * Server may query blockchain to find a hash of, and link to, the canonical client application code * Server should verify the hash before serving to clients * User will navigate their browser to connect to the server * Server will send the client application to the browser * User may verify the client application hash ```mermaid sequenceDiagram participant user as User participant web_client as Web Client participant server as Server participant blockchain as Blockchain participant archive as Archive user ->> blockchain : Query blockchain ->> user : Server code hash user ->> archive : Query archive ->> user : Server code user ->> server : Deploy server ->> blockchain : Query blockchain ->> server : Client code hash server ->> archive : Query archive ->> server : Client code user ->> web_client: Navigate web_client ->> server : Connect server ->> web_client : Client code ``` ## Read * Web client will query the Server * Server will build and maintain views of the system data * Server will read from a data archive as needed ```mermaid sequenceDiagram participant user as User participant web_client as Web Client participant server as Server participant blockchain as Blockchain participant archive as Archive user ->> web_client : Browse web_client ->> server : Query web_client ->> server : Subscribe server ->> server : Query server ->> server : Subscribe server ->> blockchain : Query server ->> blockchain : Subscribe blockchain ->> server : Data server ->> archive : Query archive ->> server : Data server ->> server : Compute server ->> server : Store server ->> web_client : Data web_client ->> user : Display ``` ## Write * Web client will submit actions to the server * Server will update its operational data store * Server will call smart contracts as needed to write data * Server will upload archive data as needed ```mermaid sequenceDiagram participant user as User participant web_client as Web Client participant server as Server participant blockchain as Blockchain participant archive as Archive user ->> web_client : Input web_client ->> server : Data server ->> server : Store server ->> server : Message server ->> web_client : Data web_client ->> user : Display server ->> archive : Data server ->> blockchain : Data ``` ## Verify * Web client may read content hashes from the blockchain * Web client may vote against a server that provides bad data * Server may read content hashes from the blockchain * Server should use content hashes to verify integrity of stored data ```mermaid sequenceDiagram participant user as User participant web_client as Web Client participant server as Server participant blockchain as Blockchain participant archive as Archive web_client ->> blockchain : Query blockchain ->> web_client : Content hash web_client ->> web_client : Verify content web_client ->> blockchain : Vote server ->> blockchain : Query blockchain ->> server : Content hash server ->> server : Verify content server ->> blockchain : Vote ```
laddhoffman commented 2022-10-18 00:05:40 -05:00 (Migrated from gitlab.com)
Copy Link
flowchart

computation --> abstraction
ooda --> abstraction
abstraction --> system

subgraph Background
    computation
    ooda
end

subgraph computation[Computation]
    network[Network] -->|receive| compute
    compute[Compute] -->|send| network

    compute -->|store| storage
    storage[Storage] -->|retrieve| compute
    
    compute -->|output| interface
    interface[Other<br>interface] -->|input| compute
end

subgraph ooda[OODA Loop]
    observe[Observe] --> orient
    orient[Orient] --> decide
    decide[Decide] --> act1
    act1[Act] --> observe
end

subgraph abstraction[Abstraction]
    event[Event] -->|info| consider
    consider[Consider] -->|decide| act[Act]

    subgraph Consideration
        consider -->|update| provisionalSubgraph
        provisionalSubgraph -->|update| beliefs
        beliefs[Beliefs] -->|view| consider
        subgraph Beliefs
            subgraph provisionalSubgraph[Provisional beliefs]
                possibility[Possibility]
                probability[Probability]
            end
        end
    end
end

subgraph system[Systems]
    ui[UI] --- node[Node]
    node --- archive[Archive]
    ui --- archive
    subgraph Node
        node --- local_storage[Storage]
        node ---|peers| node
    end
    node --- blockchain[Blockchain]
    ui --- blockchain
end

system --> specs1

subgraph specs1[Specs by system]
    nodeSpec[Node spec]
    storageSpec[Storage spec]
    archiveSpec[Archive spec]
    blockchainSpec[Blockchain spec]
    peerProtocolSpec[Peer protocol spec]
    uiSpec[UI spec]

    nodeSpec --- uiSpec
    nodeSpec --- storageSpec
    nodeSpec --- peerProtocolSpec
    nodeSpec --- archiveSpec
    peerProtocolSpec --- storageSpec
    storageSpec --- blockchainSpec
    archiveSpec --- blockchainSpec
    storageSpec --- archiveSpec
    uiSpec --- blockchainSpec
    uiSpec --- archiveSpec
    uiSpec --- storageSpec
    nodeSpec --- blockchainSpec
end
```mermaid flowchart computation --> abstraction ooda --> abstraction abstraction --> system subgraph Background computation ooda end subgraph computation[Computation] network[Network] -->|receive| compute compute[Compute] -->|send| network compute -->|store| storage storage[Storage] -->|retrieve| compute compute -->|output| interface interface[Other<br>interface] -->|input| compute end subgraph ooda[OODA Loop] observe[Observe] --> orient orient[Orient] --> decide decide[Decide] --> act1 act1[Act] --> observe end subgraph abstraction[Abstraction] event[Event] -->|info| consider consider[Consider] -->|decide| act[Act] subgraph Consideration consider -->|update| provisionalSubgraph provisionalSubgraph -->|update| beliefs beliefs[Beliefs] -->|view| consider subgraph Beliefs subgraph provisionalSubgraph[Provisional beliefs] possibility[Possibility] probability[Probability] end end end end subgraph system[Systems] ui[UI] --- node[Node] node --- archive[Archive] ui --- archive subgraph Node node --- local_storage[Storage] node ---|peers| node end node --- blockchain[Blockchain] ui --- blockchain end system --> specs1 subgraph specs1[Specs by system] nodeSpec[Node spec] storageSpec[Storage spec] archiveSpec[Archive spec] blockchainSpec[Blockchain spec] peerProtocolSpec[Peer protocol spec] uiSpec[UI spec] nodeSpec --- uiSpec nodeSpec --- storageSpec nodeSpec --- peerProtocolSpec nodeSpec --- archiveSpec peerProtocolSpec --- storageSpec storageSpec --- blockchainSpec archiveSpec --- blockchainSpec storageSpec --- archiveSpec uiSpec --- blockchainSpec uiSpec --- archiveSpec uiSpec --- storageSpec nodeSpec --- blockchainSpec end ```
laddhoffman commented 2023-02-16 16:13:49 -06:00 (Migrated from gitlab.com)
Copy Link

Task-based, revenue-generating work

Expert stakes REP to register availability

graph

subgraph EOA
  expert(Expert)

end

subgraph Contracts
  availability(Availability)
end

expert -- 1. Stake ℝ --> availability

Public submits work request with fee

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

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

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

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

Internal operations

Expert starts new DAO

graph

subgraph EOA
  expert(Expert)
end

subgraph Contracts
  forum(Forum)
  pool(Pool)
end

expert -- Post --> forum
expert -- Fee $ --> pool

Expert joins existing DAO

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.

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.

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
# Task-based, 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 ``` # 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 ```
laddhoffman commented 2023-04-10 09:43:51 -05:00 (Migrated from gitlab.com)
Copy Link
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 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 ```
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
main
semantic-scholar-import
dev
forum-test-6
forum-network
Labels
Clear labels   
discussion

   
draft
No Label
discussion
draft
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: DGF/dao-governance-framework#3
No description provided.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?