Portal:Complex Systems Digital Campus/SIRE

From Wikiversity
Jump to navigation Jump to search

the repository for Open Questions, Challenges and Ressources of the

Socially Intelligent Roadmap Ecosystem

Great Challenge & Dapp[edit]


SIRE (Socially Intelligent Roadmap Ecosystem) is devoted to the design and implementation of a Socially Intelligent ICT ecosystem (like Wikipedia) for the rapid development of the «living roadmap of complex systems». It has to be specified:

  • as an "Decentralized Autonomous Organisation (DAO) of DAOs" with as much levels as there is levels of challenges and sub-challenges in the living roadmap
  • as a fair organisation rewarding the scientific efforts of each individual member and each institutional member in order to disseminate trust amongst all these members through DAO smart contracts including the challenges and the statutes and bylaws
  • as a decentralized organisation with almost no administration not directly assumed by its members, where each DAO can modify its smart contract.

All these requirements are reachable through the main propositions of the 2nd internet revolution that brings a completely new way to manage humans affairs toward a decentralized society. That is the "Grand Challenge" of SIRE.

The SIRE Dapp is empowering a DAO with a great challenge as a ‘Socially Intelligent Roadmap Ecosystem’ (SIRE) for bringing the quickest and most satisficing answer to this great challenge. The path toward such great challenge is generally not direct. It needs a living cascade of sub-challenges, i.e. a living multilevel roadmap that has to evolve in case of difficulties. Such living roadmap is coordinating the efforts of the sub-DAO cascade toward the DAO great challenge. Thus the SIRE Dapp has to empower in the most satisfying way such ‘dynamic coordination game’ by solving the two following ‘DAO meta-challenges’:

  • (meta-challenge 1) What are the conditions for a standard smart contract that provides a ‘cooperative Nash-Pareto strategy’ to this cooperation game toward its ‘Evolutionary Stable State’?
  • (meta-challenge 2) What is an elegant and simple way to implement any living smart contract directly from its specification? How to guarantee that the implementation is ‘the same’ as its specification, thus satisfying the ‘trust in algorithm’ principle?


social autonomy, Socially Intelligent ICT ecosystem, living roadmap, 2nd internet revolution, blockchain, smart contract, Decentralized Autonomous Organisation (DAO), Decentralized application (Dapp) InterPlanetary File System (IPFS).


  • Cyrille Bertelle (chair | cyrille.bertelle@univ-lehavre.fr)
  • Paul Bourgine (chair | paul.bourgine@polytechnique.edu)
  • Julien Baudry, Juan Simoes, Clément Schreiner



The ‘DAO’ as a ‘Socially intelligent Roadmap Ecosystem’ (SIRE) (e-team)[edit]


The SIRE Dapp is empowering a DAO with a great challenge as a ‘Socially Intelligent Roadmap Ecosystem’ (SIRE) for bringing the quickest and most satisficing answer to this great challenge. The path toward such great challenge is generally not direct. It needs a living cascade of sub-challenges, i.e. a living multilevel roadmap that has to evolve in case of difficulties. Such living roadmap is 'coordinating the efforts of the sub-DAO cascade toward the DAO great challenge. Thus the SIRE Dapp has to empower in the most satisficing way such ‘dynamic coordination game’.

For empowering the self-organized decentralized development of any DAO, the SIRE Dapp has to solve some ‘DAO meta-challenges’ like: a. What are the conditions for a standard smart contract that provides a ‘cooperative Nash-Pareto strategy’ to this cooperation game toward its ‘Evolutionary Stable State’? (meta-challenge 1) b. What is an elegant and simple way to implement any living smart contract directly from its specification? How to guarantee that the implementation is ‘the same’ as its specification, thus satisfying the ‘trust in algorithm’ principle? (meta-challenge 2)

2.2.2. The ‘DAO’ as a ‘Socially intelligent Roadmap Ecosystem’ (SIRE) with its ‘cooperative Nash-Pareto strategy’

The concept of ‘living smart contract’ is extending ‘smart contract’ for the need of great integrative Dapp environment with interoperable basic Dapps. Such Dapps are facing a cascade of challenges organized as a ‘living roadmap’. The challenge cascade is a DG (Directed Graph) as well as the DAO cascade. The proposition 5 below is saying that the Directed Graph (DG) of challenges can be always transformed into a Directed Acyclic Graph (DAG) by assimilating a cycle of ‘equivalent’ challenges to a unique common challenge.

Principle 1 (Majority Judgment in a DAO DAG) : in a DAO DAG, each decision with only one option is expressing a consensus. Any decision with two options can use the majority vote. For more than 2 options, the DAO DAG is using the 'MAJ Dapp': the 'Maj Dapp' is indeed full of excellent properties in the voting process and, thus, the most satisfying way to aggregate the grades given by the voters and, then, to rank the options. In case of very important decision, the ‘Qualified Grading' (URL) in Majority Grading’ can be used for reinforcing the strength of the consensus.

This principle is essential for all DAOs as well as for the decentralized society (URL)

The definition 1 of the ‘living smart contract’ is establishing the one-to-one correspondence between a DAO ⇔ its ‘smart contract’ ⇔ its ‘challenge’ ⇔ its ‘member Dapp’ ⇔ each representative body with its Dapp. The properties of the living smart contract have to be studied before defining the ‘standard initial smart contract’ with its ‘minimal constraints’.

Definition 1 (‘DAO smart contract): The ‘smart contract’ of a DAO is defining: MAJ DAPP proof of authority a. its name b. its living challenge with its expected success time c. the attributions of internal actions and external transactions of its representative bodies, i.e. the following representative bodies Dapps 1. the ‘sovereign assembly Dapp’ for the DAO members, 2. the ‘board Dapp’ for the board members, 3. the ‘direction Dapp’ for the chair and co-chairs, 4. the ‘chair Dapp’ for the chair d. its different committees Dapps, each one being a sub-DAO with the same representative bodies Dapps e. the initial set of above Dapps for a new DAO.

Definition 2. (‘decentralized autonomy’): A DAO has ‘decentralized autonomy’ (fig. 2) if: a. its sovereign assembly can modify its own smart contract as well as the initial smart contract inside its DAO DAG b. each DAO decision is using the MAJ Dapp for ranking the options and, possibly, to use it as a Proof of Authority (PoA) c. each sub-DAO and each DAO committee has ‘decentralized autonomy’.

fig 2 is about the conservation of ‘autonomy’ in the sense of the definition 1.2. The definition applied recursively between the different organizational levels: from DAO to sub-DAO and committee and, then, individual members under the decentralized MAJ Dapp. All these levels share the same smart contract through a decentralized autonomy with a decentralized control through the MAJ Dapp.

The DAO DAG is including the DAO committees that are ‘its sub-DAO’ for milestones inside the DAO challenge horizon. The sub-DAOs themselves are for middle term (i.e. also milestones) or the same long-term horizon as the DAO. There is a crucial need for a coordination principle toward a cooperative Nash-Pareto principle: the DAO and its sub-DAOs have to satisfy a local ‘SIRE’ including the milestones:

Definition 3 (the DAO as a decentralized living SIRE): a DAO is a ‘Socially Intelligent Roadmap Ecosystem’ (abbreviated as SIRE – fig 2) if: a. Its two-levels living roadmap as a local coordination game is ‘viable’, i.e. if the sub-challenge success times are fitting the challenge success time b. The bylaws of the representative bodies are as follow: 1. the sovereign assembly of a DAO is the same as the sovereign assembly of its DAO DAG, i.e. the set of all members of the DAO DAG. 2. The direction, i.e. its chair and ‘n’ co-chairs are the first 1+n ranked by its sovereign assembly 3. The DAO board is composed with the DAO direction and the chairs of its sub-DAOs and committees. c. Each sub-DAO is a decentralized living SIRE

Proposition 3 (adaptive Nash-Pareto Strategy of a SIRE): The DAO as a SIRE develops for its multilevel coordination game an ‘adaptive Nash-Pareto strategy that converges toward a stochastic Evolutionary Stable State (ESS), i.e. the final state of its adaptive multilevel roadmap with the best probability of success. The ESS stochastic character comes from the permanent checking of the SIRE Dapp of the viability of the local game when any success time is revised; that can entail: a. A cascade of adaptive revisions within the DAO DAG sub-challenges as milestones and/or b. the adaptive creation of new sub-DAOs when stronger resilient strategy are necessary.

Sketch of proof for the proposition 2.1 • (from def. 3.b.3) The overlapping composition of the board is crucial for the stochastic viability of the local two-levels roadmap as a coordination game. The two-levels overlapping is creating de facto a global entanglement of the multilevel roadmap as a global coordination game (fig. 2). This entanglement is de facto a permanent ‘equivalence’ between the top challenge and the challenges at some level until the leaves challenges: it is a kind of conservation law of the challenge flow through the organisational levels. What remains to prove is the adaptive and efficient character of the entanglement. • (from def. 3.b.1&2) This adaptive and efficient character of the global entanglement comes from the composition of the DAO sovereign assembly and DAO chairs (the same as its whole DAO DAG) and the MAJ Dapp for the decentralized society (from 1.1.c). That applies at all level inside a top DAO (for electing the chairs and co-chairs which constitute the board or for taking any promising decision on each smart contract). That is crucial in a rapidly changing world for adaptive revision of sub-challenges as well as for the adaptive creation of new sub-DAOs for urgent resilient strategy. As a result, the multilevel roadmap is an adaptive one co-evolving with the world toward its (stochastic) successful final state. • Proposition 2.3.b. results from the definition of a cooperative SIRE (def. 3).

Thus, the bylaws constraints of the definition 2.1 are very valuable for the adaptive success of a DAO. They are thus constitutive of the SIRE definition and not modifiable.

Definition 4 (The SIRE as a cooperative game): The SIRE is a cooperative game if the added value (of any kind) is fairly distributed between the members during the coordination game and at the challenge completion. Remark: In the WWW DAO it can be always realized that the added value (scientific and/or financial) is fairly distributed between the members when the main DAO is successful: in the CS-DC UniTwin UNESCO, the scientific added value is fairly distributed. And in the WWW DAO, the creation of a WWW Dapp has a cost several orders of magnitude less than the social benefit. Proposition 4 (cooperative Nash-Pareto Strategy): a DAO develops a cooperative Nash-Pareto strategy if the SIRE is a cooperative game.

Definition 3 (the standard initial smart contract): The definition merging the definitions 1 & 3 of a smart contract is candidate to be the ‘standard initial smart contract’ for any new DAO or committee.

Principle 2 (approval of the standard initial smart contract): In a DAICO, the standard initial smart contract has to be approved by the whole DAO and by the Investor Committee.

The aim of the SIRE Dapp is to empower the evolution of local overlapping roadmaps (local SIRE) toward its local long term challenge and the evolution of the global entangled roadmap (global SIRE) toward its global long term challenge.

Proposition 5(a challenge cascade as a challenge DAG): The relation challenge -> sub-challenge as a Directed Graph (DG) can be always represented as a Directed Acyclic Graph (DAG). The same is true for the relation DAO -> sub-DAO. Proof: Adding the orange arrow is creating a cycle in the left DAO DG (fig 1.). The DAG property has to be recovered, e.g. with the right DAOs DAG by creating the new “sub-DAO” representing the cycle. The SIRE Dapp is checking the DAOs before recording the new orange link on the left graph. A cycle in the partial order DAO challenge => sub-DAO challenge means a challenge equivalence around a “common challenge”: the SIRE Dapp can recommend to the ‘sub-sub-DAO’ chair the organisation of an e-meeting with the other chairs for discussing several equivalent DAG solutions (e.g. the generic solution with the right DAG, creating the ‘sub-DAO’ recognizing a ‘equivalent common challenge’).

2.2 SIRE language: a language for specifying DAOs (along the DAOs principles)

The name of the language, ‘SIRE’, is expressing its function, i.e. launching any DAO in a DAO DAG as a ‘Socially Intelligent Roadmap Ecosystem’, locally and globally.

The role of the SIRE Language is to compile the description of the smart contract template written in the SIRE SDL (Specific Description Language) into the SIRE GDL (Generic Description Language). - a Specific DAO Language (SDL) allows to specify each new DAO, e.g. the WWW DAO: the specification comprises the DAG of the DAO types and the ‘Generic Initial DAO or smart contract’ (§2.2.3). - a Generic DAO Language (GDL) implementing the DAO types and the ‘initial smart contract’ and

The SIRE language has to obey to the following ethical principle as a natural continuation of the GDPR ethical principle:

Principle 4 (trust in the algorithms): algorithms have to do what they are believed to do.

In other words, the questions behind the Principle 4 are: is it possible that the algorithms are ‘democratic’, e.g. voted through an aggregation of individual preferences like ‘Majority Ranking’? and implemented exactly as voted? What kind of uniform interface is the most powerful, ergonomic and intuitive for almost all human in order each one by voting the specification is voting the algorithm?

2.3.1. The SIRE language principles along the DAOs principles

Principle 5 (SIRE language principles): For satisfying ‘trust in algorithm’, the following rules are required: a. (Minimum Length Description) SDL has to obey to Minimum Length Description Principle for readability and easy checking. b. (SDL in natural language) SIRE SDL is written in the natural language for being voted and is using ‘alias name’ for the type constructors of the host language. c. (idempotent compiler) SIRE GDL in the host language has to be reinterpreted in SIRE SDL for its signature by the chairs and the system administrators. The best way to check the reinterpretation is to provide an idempotent compiler: compiling twice gives the same result as compiling once. The rules for writing directly an idempotent SDL have to be simple. As a consequence, the ‘signed SDL’ has to be idempotent and it is always possible to obtain such idempotent SDL according to the idempotent property of the compiler. d. (GDL language neutrality) The GDL is neutral for translation between natural languages or change of a conventional n-word by another conventional n-word having the same semantic meaning. The GDL is translated in all the natural languages as wishes by users (like in Wikipedia). e. (soundness along all compilation certified steps):The GDL host language must have a certified compiler or a cascade of certified compiler if the first one is compiling into another computer language. f. (scalability & sharding problem) Scalability is necessary because the huge number of scientific and still much more societal members. The sharding will be obtained through the multilevel decentralised DAO DAG: for scientists the DAO DAG has scientific reason similar to the Knowledge Map; for societal members, the DAO DAG is just the multilevel territories that are concentrating the interactions (cf TIMES url). The decentralized DAO DAG approach is a very elegant way to solve the sharding problem for a very large social network.

Comments: 1. (trust in the algorithms) All these rules together allow each voter to say: the idempotent SDL specification (in my preferred language translation) IS the GDL specification and, by the certified compiler cascade, this GDL is exactly the algorithm that will be executed (trust in algorithm). Furthermore, the sovereign assembly can use the MAJ Dapp for modifying the specification according its graded preferences and some external recommendations or obligations. 2. (soundness along all compilation steps): The best host language for the SIRE GDL needs to be compiled in different languages having a certified compiler and already powerful libraries for the main tasks of the GDL: the tasks to be specified are not very complex programs but essentially streams of inputs, outputs and ‘simple conversion’ between input streams and output streams. It is expected that the following certified compiled languages list with their relevant existing libraries are sufficient: the chain {Haskell, OCaml, Scheme including Pyramid Scheme toward the Virtual Ethereum Machine (VRM)}=> final compiled code’ can be guaranteed and certified. The natural choice for the host language is thus Coq with its certified alternative compilations depending of the librairies: Coq =>{Haskell, OCaml, Scheme}. 3. (from SDL in natural language to GDL in the host language) The SDL with the horizontal Fancy Tree interface has a direct translation as a ‘Scheme object representation’. The ‘first program’ has to do the translation of a ‘Scheme object representation’ into the host language. As said just above, the preferred host language is Coq. The ‘first program’ can be written in Scheme, Haskell or OCaml. The first version is written in Haskell. 4. (scalability & sharding problem). Each DAO is concentrating the interactions and the internal PoAs (Proof of Authority) obtained through the MAJ Dapp. Each DAO has its own blockchain shared by their members. The DAOs main blockchain is just guaranteeing the links between the DAOs. The last problem is the societal DAO for mutual wellbeing with a potential huge number of participants. 5. (Social learning, identification and GDPR): user identification is necessary for a lot of Dapps in SIRE (e.g. Majority Ranking or social learning through Science). This identification can be anonymous (e.g. it is an axiom for the MAJ Dapp) or not (e.g. the Proof of Authority of a scientific jury). All the personal data has to be anonymous as required by the GDPR. Invitation or submission of new DAO is not public; but all the records of e-meetings have to be public.

2.3.2. Specification of the Generic Initial Smart Contract and its compilation

This first part of this section is devoted to the specification of the ‘Smart Contract’ (definition 1.1 above) in the SIRE SDL language, The second part is devoted to the Minimum Length Principle and is using the fractal character of a DAO DAG.

SIRE is using a uniform, intuitive interface in natural language: • for the SDL specification of DAO types and then • for describing the present state of the main blockchain (the DAO DAG) and the internal sub-blockchains of each DAO with its cascade of committees and members. This interface is a horizontal ‘Fancy Tree’ as done by Apple computer that can be visualized quite equivalently as a vertical Fancy Tree on a mobile phone.

This interface is also very powerful: the two ‘invisible operators’ (‘->’ and ‘,’) of a Fancy Tree provides an expressivity equivalent to a Lisp, e.g. Scheme. It is thus possible to define simple typed functions between input and output streams, i.e. abstract processes crucial for the interoperability between typed data and Dapps. It is also possible to simulate Pyramid Scheme for the interface with the Virtual Ethereum Machine. Such powerful, intuitive and uniform interface is needed for visualizing the SDL ⇔ GDL comparison until their idempotent equivalence. All cases of the Fancy Tree are either type constructors or types ‘named by a n-word’. It is claimed that such Fancy Tree can be written together by some heads of the DAO with the help of the ‘DAO administrator’. Its final version has to be voted by all the members (PoA).

The main function of the Website is to provide exploration of its contents through the Fancy Tree. Each visitor will have the opportunity to build in the first Fancy Tree column below the top DAO the list of its preferred sub DAO. For involved members, the list of their commitments is automatically listed with the priority order of their responsibilities. In both cases, visitor or member, need an identification.

An excellent representation of a Fancy Tree is its JSON. The JSON just below is translating the specification (def. 1.1) of the DAO type (line 1-9) with a complementary part specific to the WWW DAO (line 10-21).

Let us first remark that, in the Fancy Tree, the two ‘invisible operators’ (‘->’ and ‘,’) are visible in the JSON: ‘->’ means a shift of column and the ‘,’ means a shift of line. In the specification below, the constructors of types are “alias” (line 9), “one choice” (line 12, ..) and “multi choice” (line 19), “concrete type (lines 15)”, “such that” (lines16, 17). The most frequent constructor is “record”. It is the default constructor and thus the only one omitted along the Minimum Length Description principle (MLD): thus also record of records are just chained with “->”.

01 “DAO” -> {“supra DAO(s)”, “sub DAO(s)”, “smart contract” -> { 02 “name”, “challenge”, “representative bodies” -> { 03 “chairs”-> {“chair”, “co-chair(s)”, “new member(s)”, “chairs Dapp”}, 04 “board” -> {“board member(s)”, “supra DAO(s)”, “committees”, “board Dapp”}, 05 “sovereign assembly” -> {“member(s)”, “member Dapp”}, 06 “scientific committee*”, “societal committee*”, “committee(s)”}, 07 “committee” -> {“supra DAO(s)”, “sub committee(s)”, “smart contract”}, 08 “member” -> {“supra DAO(s)”, “scientific smart contract”, “studio Dapp”}, 09 “member” -> {“alias”, “chair”, “co-chair”}, 10 “societal committee” -> {“societal member(s)”, “WWW smart contract”, “sub committee(s)”}, 11 “societal member” -> {“supra DAO(s)”, “data sharing smart contract”, “WWW Dapp”}, 12 “WWW Dapp”-> {“one choice”, UN SDG(s)”-> {“UN Target(s)”}}, 13 “chairs Dapp” -> {“one choice”, “identification”, “new member invitation”, “new member submission”, “MAJ Dapp”, ”SIRE compiler”}, 14 “board Dapp” -> {“one choice”, “identification”, “invitation”, “submission”, “delegation”, “MAJ Dapp”, ”SIRE compiler”}, 15 “member Dapp” -> {“one choice”, “identification”, “invitation”, “submission”, “delegation”, “MAJ Dapp”, ”SIRE compiler”}, 16 “studio Dapp” -> {“one choice”, “identification”, “member submission”, “notification”, “delegation”, “MAJ Dapp”, ”SIRE compiler”}, % For the WWW DAOs, the following bylaws rules are contractual in the cooperation program between UNESCO and the CS-DC % 17 “institution” -> {“institution form”, “institution(s)”, “direction”, “UNESCO UniTwinable”, 18 “signatory institutional form” -> {"*17 SDG commitment letter", “*CS-DC representative”, “*e-team(s)”}}, 19 “UNESCO UniTwinable” -> {“one choice”, ”not UniTwinable”,“UniTwinable”->{"multiple choice", "High Education or Research 20 Institution", "NGO on High Education or Research", "Academic Association or Network", "Institution cooperating with 21 UNESCO"}

In the WWW DAOs part, an individual ‘member’ are either (line 11) a ‘scientific member’ if she/he belongs to at least one ‘UniTwinable Institution’ (line 19) and a ‘societal member’ if not. Notice the role of ‘alias’ line 9: it is creating a list of equality of types for different type names. There is a deep mechanism of default heritage when a name is a composed one: for example, it is not useful to write “scientific member”=”member” because the compiler is creating it by default. If the equality is not the case in the future release, it will be easy to create the right precise meaning of “scientific member”.

The definition of the Idempotent Normal Form (INF) of the GDL is above. The example above is written in such INF: the reinterpretation of its GDL is itself.

Definition (Idempotent Normal Form of the SDL) 1. all types are created and checked. An identifier is created for each type: it means that changing a type name is neutral for the GDL. Each type constructors expressed in natural language corresponds to a constructor of the host language. 2. the list of GDL types are those that are inserted in the list constructor; 3. a GDL type is exactly configured for creating a new type instance: all fields/records that are one-to-one associated with the new instance are listed in the JSON (i.e. the Fancy Tree); the tree of fields is stopping each time there is the list constructor because the one-to-one principle stops and the list is initially empty (see the example above); 4. the reinterpretation of this list in item 2 with their names instead of their identifiers or host type constructor gives the Idempotent Normal Form (INF) of the SDL

The hosting language is supposed to have the following type constructors: Cartesian product (∏), the Exponentiation (->), the Sum (∑), the Power set (2->X), a classifier (Boolean by default or, more generally, an Heyting algebra), the list monade X* for any X. It is supposed that the hosting language has basic types like the character chain, N, Z, Q, R and C with customizable precision. It is also supposed, but not necessary, to have types like Geolocation, Time, Date, Url, Hash, Email, RegularMail

SIRE SDL SIRE GDL Remarks One field constructor “DAO” Id_DAO GDL is reinterpretable in SDL “field(s)” Id_field* Id_ty*= the list constructor of Id_ty “*field” Mandatory id_field In DAO form; other fields are MayBe “DAO field” If not defined:Id_DAO_field = Id_field Heritage by default .. “member”->{“alias”, “chair”,”co-chair”} Id_chair =Id_co-chair = Id_member replaces ‘n’ lines of type equalities Type Constructors .. .. exist in the hosting language “DAO”-> {“field1”, “field2”,..} Id_DAO -> ∏ Id_field1 Id_field2 … CartesianProduct ∏ “ty” ->{“one choice”, “ty1”, “ty2”, …} Id_ty = ∑ Id_ty1 Id_ty2 … Type Sum ∑ “ty” ->{“multiple choice”, “ty1”,“ty2”} Id_ty = 2 ^{Id_ty1, …} 2^X is the Power set of X “ty” ->{“concrete type”, “s1”, “s2”…} Id_ty = Set Id_s1 Id_s2 … The ‘s’ are ‘singleton type’ Environment types “character(s)” , “N”, “Z”, “Q”, “R”, “C”, “time”, “date”, “email”, “hash”, “url”, “geolocation” character* , N, Z, Q, R, C, Time, Date, Email, Hash, Url, Geolocation Basic types or fields of the hosting language “EOS.io”, “Filecoin”, “IeX”, “Nano S”, “Dapps” Id_EOS, Id_Filecoin, Id_IeX, Id_NanoS, Id_Dapp Ethereum and CS-DC as hosting environment

01 “DAO” -> {“∏”, “name”, “sub DAO(s)”, “challenge”, “new member(s)”, “supra DAO(s)”, 03 “collegiums” -> {“∏”, “chairs”-> {“∏”, “chair”, “co-chair(s)”, “chairs constitution rule”, “chairs bylaws Dapps”}, 04 “board” -> {“∏”, “board constitution rule”, “board bylaws Dapps”}, 05 “sovereign assembly” -> {“∏”, “sovereign assembly constitution rule”, “sovereign assembly bylaws Dapps”}}, 06 “committees” -> {“∏”, “scientific committee”, “societal committee”, “committee(s)”}, 07 “Dapp(s)”}, 08 “committee” -> {“=”, “DAO”}, 09 “member” -> {“∏”, “DAO(s)”, “institution(s)”, “member form”, “personal studio”-> {“Dapp(s)”}}, 10 “chair” -> {“member”}, “co-chair” -> {“member”},

% For the WWW DAOs, the following bylaws rules are contractual in the cooperation programme between UNESCO and the CS-DC % 11 “member” -> {“∏”, “one choice”, “scientific member”, “societal member”}, 12 “institution” -> {“∏”, “institution form”, “institution(s)”, “direction”, “UNESCO UniTwinable”, 13 “signatory institutional form” -> {“∏”,"*17 SDG commitment letter", “*CS-DC representative”, “*e-team(s)”}}, 14 “UNESCO UniTwinable” -> {“∑”->{”not UniTwinable”,“UniTwinable”->{"2", "High Education or Research Institution", "NGO on High Education or Research", "Academic Association or Network", "Institution cooperating with UNESCO"}}} 15 “by-laws Dapps” -> {“Set”, “identification”, “invitation”, “submission”, “notification”, “delegation”, “Majority Ranking”, ”SIRE compiler”},

fig. 11: the SIRE SGL specification of the Generic Initial DAO

2.3.2. Specification of a DAOs type as a DAG, its compilation and its de-compilation

The Minimum Length Principle for any description is the littlest programme that reproduces this description. The length of this littlest program is called the Chaitin-Kolmogorov complexity. For example, the L-systems is a language that that describes the fractal development of the vegetal morphogenesis of each plant species: it allows to reconstruct the development of a plant species with a very short L-system program.

The Minimum Length principle is used in SIRE because a DAO DAG is fractal. Let us consider the example of the CS-DC and the WWW DAO:

01"CS-DC UniTwin UNESCO" -> {“DAO DAG”, 02 "CS-DC e-campus" ->{ "e-department(s)" -> {"e-laboratory(s)" -> {"e-team(s)" -> {"e-team(s)"}}}}, 03 "UniTwin UNESCO" ->{ 04 “UNESCO Cooperation Program” ->{“Dapp design”->{“MAJ”->{“SIRE”->{“RAPSODY”->{“iKM”->{“POEM”-> 05 {“WWW”->{“TIMES”}}}}}}}}, 06 “WWW DAO”-> {“ WWW DAG”, “territory leaves”}, 06 “TIMES”-> {“TIMES DAG”, “territories”}, 07 “WWW Dapp”->{“Dapp DAG”, “UN SDG(s)" -> {“UN Target(s)"}}, 08 “DAO” -> {“supra DAO(s)”, “sub DAO(s)”, “smart contract”} % recall % 09 “Dapp” -> {“Git or Github” -> “Function”, “input type”-> {“output type”}}, 10 “territories” -> “continent(s)", {“state union(s)" -> {"state(s)” ->{"region(s)” -> {“cities(s)”->{“house(s)”}}}}}, %Examples of Dapps% 07 “MAJ Dapp” -> {“Function”-> {”abbreviated matrix”}, “grade(s)”, “judge(s)”, “option(s)”}, 08 “SIRE Dapp” -> {“Function”->{“new DAO stream”}, "CS-DC UniTwin UNESCO"}

%Generating DAOs% 01 “e-department” -> {"CS-DC e-campus" , "e-laboratory(s)", “smart contract”}, 02 “e-laboratory” -> “e-department(s)”, "e-team(s)", “smart contract”}, 03 “e-team” -> {"e-laboratory(s)", “e-team”, “smart contract”}, %generating module% 04 “SIRE Dapp” -> {“import”, {“MAJ Dapp”}, “SIRE app”}, 05 “RAPSODY Dapp”-> {“import”, “SIRE Dapp”}, “RAPSODY app”}, …. 08 “WWW Dapp DAG” -> {“import”, “POEM Dapp”}, “WWW Dapp”}, 09 “TIMES Dapp DAG” -> {“import”, “WWW Dapp”}, “TIMES Dapp”}, %territories% 10 “WWW DAO”-> {DAO, {SE-MTIO} , “WWW Dapp”, “territories”} 11 “TIMES DAO”-> {DAO, {SEE-MTIO}, “TIMES Dapp”, “territories”},


  • Elias Showk (chair)
  • Paul Bourgine

CS-DC Finder (e-team)[edit]


The CS-DC Finder allows 1) an horizontal exploration of the whole CS-DC organisation in the same way and 2)the modifications of all the fields of the CS-DC e-structures as well as the specifications. These two features are exactly similar to the Mac Finder.


  • Salma Mesmoudi (chair)
  • Mathieu Rodic, Paul Bourgine

A CS-DC Database with the 2nd internet revolution (e-team)[edit]


The main idea is to use the 2nd internet revolution for 1)developing trust in the potential very large individual & institutional network as a DAO of DAOs for all having a contractual aspect (Smart Contract, BlockChain) and 2) allowing all members to share all data, informations and open source software as if they are in a single computer (InterPlanetary File System - IPFS). The 2nd internet revolution will also replace the huge diversity of WebApps by a much huger availability of BlockApps, that brings also the respect of privacy (like the General Data Protection Regulation, a EU regulation that will apply in May 2017).


  • Salma Mesmoudi (chair)
  • Mathieu Rodic, Paul Bourgine

CS-DC Cosypedia (e-team)[edit]


The only exception to the modifications of the fields of the different participants and research & education e-structures is the challenges with their sub-challenges. A Cosypedia (Complex Systems "pedia") will be designed for making the modifications of the challenges not only easier but also open to all propositions from anyone worldwide. This Cosypedia will be similar to the present Wikiversity and will also use Wikimedia.


  • Clément Schreiner (chair)

CS-DC e-events (e-team)[edit]


The main scientific as well as educational activities of the CS-DC and its members is to organize e-events for a level of interactions completely new. These interactions will diminish the diameter of the knowledge map by creating link at long distance in the map. It will diminish correlatively the diameter of individual knowledge maps and increase the capacity of everyone to increase his/her social imaginary when being succesively learner, tutor, teacher, researcher and again learner. The e-events are without fees and are open to anyone for any questions. They are recorded allowing new generation to revisit any talk at any time. The e-events are not mainly a way to attend individually the e-event at home or at his/her desk. Mini-events are created in any relevant place, especially in Universities, for increasing the interactions locally and at long geographical distance.


  • Julien Baudry
  • Cyrille Bertelle

Data and/or tools to be shared[edit]

(the ecosystem is not available yet: only its static version exists on http://cs-dc.org)

Return to the Wikiversity Portal of the Complex Systems Digital Campus

Return to the Complex Systems Digital Campus main website