Merge branch 'dev' into 'main'

Add link to artifacts generated for each different commit

See merge request dao-governance-framework/science-publishing-dao!1

.gitlab-ci.yml

@@ -1,7 +1,30 @@
+workflow:
+  rules:
+    - if: $CI_COMMIT_BRANCH
+
 pages:
+  stage: deploy
+  rules:
+    - if: $CI_COMMIT_BRANCH == "main"
   script:
     - mkdir public
     - cp -r forum-network/src/* public/
   artifacts:
     paths:
       - public
+
+artifacts:
+  stage: deploy
+  rules:
+    - if: '$CI_COMMIT_BRANCH != "main"'
+  script:
+    - mkdir public
+    - cp -r forum-network/src/* public/
+  artifacts:
+    paths:
+      - public
+  environment:
+    name: "$CI_COMMIT_BRANCH $CI_JOB_NAME"
+    url: "$CI_SERVER_PROTOCOL://$CI_PROJECT_ROOT_NAMESPACE.$CI_PAGES_DOMAIN/-/$CI_PROJECT_NAME/-/jobs/$CI_JOB_ID/artifacts/public/index.html"
+  variables:
+    PUBLIC_URL: "/-/$CI_PROJECT_NAME/-/jobs/$CI_JOB_ID/artifacts/public/index.html"

forum-network/notes/dao.md

@@ -1 +1,35 @@
-A DAO is a group of cooperating entities
+A DAO is a group of cooperating entities.
+
+If we're running our own network, it probably makes sense to consider nodes as the participants.
+
+If we're running as smart contracts, it probably makes sense to consider individual addresses as the participants.
+
+These schemes overlap, since both involve asymmetric keys.
+
+Each node must validate the work of the other nodes
+
+Our protocol will be a peer protocol, and will rely on signatures.
+
+Therefore we arrive at a requirement for nodes: they must be physically secured so that private keys are protected.
+
+We also arrive at a requirement for our network protocol: It must be possible to sign messages and verify message signatures against known public keys.
+
+The network protocol MAY support asking peers about other peers / telling other peers about peers.
+
+IF we support this IT SHALL BE linked with each node's reputation.
+
+CAN WE SAY that each node MUST maintain A VIEW of THE ENTIRE / (THE CURRENT) / (ALL / CURRENT) HASHES / MERKLE TREE / -- World state, History
+
+CAN WE GET AWAY WITH ONLY SAYING that each node maintains its own view.
+
+WHAT is our protocol for evaluating the perspectives offered by peers?
+
+- If one node perceives consensus among many others, that may sway their opinion.
+
+  - There may be opportunity during "informal voting" / non-binding validation pools (low tokenLossRatio) to gather this sort of information.
+
+- If there is exact agreement, we have a very efficient case.
+
+- If there is the HOPE of exact agreement, mistakes and attacks can be costly
+
+- If there is an EXPECTATION of exact agreement, there must be externalities supporting that agreement, i.e. a common protocol and governance of that protocol.

forum-network/notes/validation.md

@@ -0,0 +1,4 @@
+Possible statements
+
+- It is what I would have done
+- It is consistent with what I (would) have done