Portal:Complex Systems Digital Campus/SIRE

. C o s y p e d i a . the repository for Open Questions, Challenges and Ressources of the . Complex Systems Digital Campus

SIRE

Socially Intelligent Roadmap Ecosystem

Great Challenge & Dapp

Description

SIRE (Socially Intelligent Roadmap Ecosystem) was firstly designed for implementing a 'Socially Intelligent ICT ecosystem' (like Wikipedia) for the rapid development of the «living roadmap of complex systems». 'SIRE' recovers two of the four CS-DC commitments in its Cooperation Programme with UNESCO. The CS-DC Council, its sovereign assembly, was defining a 'SIRE':

• 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 a smart contract including its challenge and bylaws.
• as an autonomous 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 2nd internet revolution that brings a completely new way to manage humans affairs toward a decentralized society. That is the "Grand Challenge" of the 'SIRE Dapp' much beyond the CS-DC, e.g. the WWW DAO for the World Wide Wellbeing and the new 'science of mutual wellbeing'.

SIRE is deeply interacting with RAPSODY(fig.1): for each challenge, SIRE associate its Dapp; all users (in the center) are producing their own Dapp Data (DaD); RAPSODY is producing by social learning some advices for a new Dapp usage by an user; the advices are graded by the user and the user provides its own graded decision (can be outside the advices of RAPSODY)

fig.1 The coupling between SIRE and RAPSODY provides the most satisficing advices w.r.t. a challenge

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?

The SIRE Dapp contains not only the challenge and bylaws but also decentralized collaborative tools like NextCloud (for peer-to-peer immediate interactions), BigBlueButton (for organizing e-events).

Keywords

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), RAPSODY, trust in algorithms

Board

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

Bibliography

• Cornelius Castoriadis: autonomy and heteronomy
• the UniTwin Cooperation Programme signed by the UNESCO Director and the CS-DC

The ‘DAO’ as a ‘Socially intelligent Roadmap Ecosystem’ (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 satisficing way such ‘dynamic coordination game’.

But a 'dynamic coordination game' can have several solutions like 'driving left' or driving 'right'. For empowering the self-organized decentralized development of all DAOs, it is crucial to study which are the conditions for having a ‘adaptive, Ralwsian cooperative Nash-Pareto strategy’: the cooperative Nash-Pareto has a unique ESS (Evolutionary Stable Strategy); the Ralwsian strategy is organizing the convergence toward this ESS for those having the most difficulties; if the movement of the ESS on the Pareto front is not too quick comparing to the adaptive movement of individuals, the adaptive ESS is permanently inhabited by a very large majority of individuals.

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 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 at the end of this paragraph is saying that the Directed Graph of challenges can be always transformed into a Directed Acyclic Graph by assimilating a cycle of ‘equivalent’ challenges to a unique common challenge.

Principle 1 (Majority Judgment) : all decisions in the DAO are using the Maj Ranking Dapp, i.e. the most satisfying criteria for ranking different options of any choice, especially a basic consensus in a decentralized society. In case of very important decision, the ‘Qualified Grading 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 this one-to-one correspondence between a DAO ⇔ its ‘smart contract’ ⇔ its ‘challenge’ ⇔ its ‘member Dapp’ ⇔ each of its representative bodies with its function. 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 initial smart contract): Inside the ‘top DAO DAG’, the ‘initial smart contract’ of a new DAO of its supra-DAO is defining:

a. the DAO name

b. the DAO Dapp

c. the DAO bylaws for the attributions of internal actions and external transactions to its representative bodies. All the decisions of the representative bodies are using the MAJ Dapp as a ‘Proof of Authority’ (PoA). A new link requires the agreement of the two parties and can be removed by one party. The attributions can be delegated and are embodied in Dapps:

1. the ‘sovereign assembly Dapp’ for the change of the DAO smart contract and election of the direction,
2. the ‘board Dapp’ for the attachment on a supra-DAO and of sub-DAO written on the ‘top DAO blockchain’
3. the ‘direction Dapp’ with the chair and co-chairs for the attachment of new committees and members written on the ‘DAO blockchain’
4. the ‘chair Dapp’ for signing all the decisions in the name of the representative bodies

d. the mandatory DAO committees

e. the list of sub-DAOs is empty

f. the list of supra-DAOs is with the supra-DAO that creates the DAO

fig 2 is about the conservation of ‘autonomy’ in the sense of the definition 1 & 2.

Definition 2. (‘decentralized autonomy’): A DAO has ‘decentralized autonomy’ (fig. 2) if:

a. its sovereign assembly can modify its own smart contract

b. each sub-DAO has ‘decentralized autonomy’.

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. The ‘control’ is also decentralized, i.e. because all decisions are taken from inside each DAO DAG through bottom-up delegation that are voted.

If there is a strong need for a coordination principle for the challenge cascade and their delivery times, the DAO and its sub-DAOs have to satisfy a ‘SIRE initial contract’ (definition 3)

fig.3:

Definition 3 (the SIRE initial smart contract): a DAO smart contract is a ‘Socially Intelligent Roadmap Ecosystem’ (fig 2) if its bylaws are as follow:

a. Its DAO Dapp is about its challenge with its delivery time within the global roadmap of the ‘top DAO’. The two-levels living roadmap as a local coordination game must be ‘viable’, i.e. if the sub-challenge delivery times are fitting the challenge delivery time.

b. The constitutions of the representative bodies is as follow:

1. The DAO sovereign assembly is the same as the sovereign assembly of its DAO DAG, i.e. the set of all members of the DAO DAG,
2. The DAO 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.

fig.4: The ESS stochastic character comes from the permanent checking by the 'SIRE Dapp' of the viability of the local coordination game when any delivery 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
c. As a consequence, the Pareto Front is moving as well a the new ESS

Proposition 3 (adaptive Nash-Pareto Strategy of a SIRE): The DAO as a SIRE develops for its multilevel coordination game a ‘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.

Sketch of proof for the proposition 3 : Let us first remember that the DAO viability with delivery time T is T ≥ Max Ti where the Ti are the delivery sub-time of its sub-DAO. When the SIRE Dapp is propagating bottom-up any delivery time revision, it detects the upward cascade of the viability defaults until some DAO recovering all of them.

The coordination of whole resilience (= recovery of all the violated local viability) belongs to the chair of this DAO that has the trust of all its DAO DAG that elects it (definition 3b1). It is mixing two ways for the resilience with the DAO board that comprises all the chairs responsible for all the delivery sub-times (‘all’ because of definition 3b3):

1. solving a part of the delivery times that exceeds T by creating one or more sub-DAO(s) that bypasses the delivery sub-time Ti that exceeds T
2. asking for the resilience of the remaining part of delivery times that exceeds T by the corresponding responsible chairs of the board

As a result, the previous Nash-Pareto strategy with the previous roadmap becomes a new Nash-Pareto strategy with a revised roadmap that moves the Pareto front between the DAOs. The living roadmap is an adaptive Nash-Pareto strategy.

As seen in this sketch of proof, the bylaws constraints of the definition 3 are very valuable for the adaptive success of a DAO. They are thus constitutive of the SIRE definition and it is highly recommended to not modify them.

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.

Proposition 4 (cooperative Nash-Pareto Strategy): a DAO develops a cooperative adaptive Nash-Pareto strategy if the SIRE is a cooperative game.

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.

All the above is using 'DAGs'. The relation DAO -> sub-DAOs is a partial order, i.e. a Directed Graph (DG). The next proposition is saying that the DAG hypothesis is not restrictive.

fig.4: the DAG hypothesis is not restrictive

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’).

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.

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?

The SIRE language principles along the DAOs principles

fig.4 This is a methodological schema:the first implementation will be done with Haskell and Pyramid Scheme. But parallely, the most ambitious way to bring complete trust in algorithms is with Coq.

For the sharding problem, the 'chains of Nano S' are sufficient in SIRE: the contractual links between DAOs constitute the global 'blockchain'; the committees of a DAO with their contractual individual member constitute the local blockchain.
The principles of Nano S are also consistent with the great number of cohorts in RAPSODY

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.

Specification of the Generic Initial Smart Contract

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 for Mac finder. This Fancy Tree can be visualized quite equivalently as a vertical one on a mobile phone.

fig.5 The Fancy Tree interface is similar to Lisp but the 'symbols' are written as 'string'

fig.6 The non-fractal part has a reverse SGL identical to the SDL (idempotence)

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).

Let us now comment the SDL description of a generic smart contract. It is also obeying to a principle of Minimum Length description: each type contains all the tree of records that defined it in one unique entry. It means that a record of records is only one line. A main reason is that each instance of the type has exactly the representation in the DAO Fancy Tree.

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 10), “one choice” (line 14) and “multi choice” (line 19), “concrete type (lines 15)”. 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 “->”.

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 14) and a ‘societal member’ if not. Notice the role of ‘alias’ line 10: 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”. This very important default rule will be also used in the 'minimum length' part in order to have a kind of dependent product for types.

The Minimum Length Description

fig.7: the Minimum Length principle is used for diminishing the redundancy inside the description of types

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 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 main use of the Minimum Length principle in SIRE is because a DAO DAG is generally fractal, i.e. its 'DAO types' is a chain. Let us consider the SDL specification of the singleton type 'CS-DC UniTwin UNESCO' with the WWW DAO inside. Ligne 1-4 (above) are sufficient for its fractal specification. Line 1-11 below the 'reverse result' of the SGL

• line 02 & 05: the 'fractal operator' is 'DAO DAG' that is a DAG constructor of 'DAO type': the result is in the lines 1-3 & 10-14
• line 04: the 'fractal operator' is 'Dapp design' that is a DAG constructor for the interdependency between Dapps:the result is in the lines 4-7

The 'smart contract' of fig.6 above is written in an Idempotent Normal Form: the reinterpretation of its GDL is itself. The 'minimum length' example is compiled in an idempotent normal form (fig 7.) because the 'minimum length operator' are precisely designed for shorten the idempotent normal form. They are thus 'exten

The definition of the Idempotent Normal Form of the SDL is below.

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 and the compilation of the SDL into the GDL

fig.8: Table SDL -> SGL

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, Regular Mail

The table is giving the correspondence between the keywords in natural language that correspond in the host language (Coq, Haskell, OCaml or Scheme, see above the figure describing the compilation) to: - the one field constructors

- the type constructors

- the environment types

fig.9: The personalized studio visualizes all the personalized commitments in their order of importance

The personalized studio

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.

The personalized studio

- presents first the exploration opportunity of the 'top DAO'. For a new member, it is the only item of his/her personalized studio.

- provides all the DAOs where an individual member tooks some responsibility: chair or co-chair, board member or simple member. For each DAO, it gives directly the notifications and the list of available actions along the bylaws for this responsibility.

Members

• Paul Bourgine (chair)
• Zahira Souidi
• Masatoshi Funabashi
• Carlos J. Barrios Hernandez
• Zhangang Han
• Nataliia Harashchenko
• Maurice Tankou
• André Tindano
• Guiou Kobayashi
• Jeffrey Johnson
• Juan Simoes
• Mathieu Rodic

References

1. The Wikipedia articles for Coq, Haskell, OCaml, Scheme
2. Michael Burge for Pyramid Scheme, Description SLs for Ethereum Contracts, proof of program with Coq and Haskell.
3. IPFS, Filecoin, EOS.io, IeX.io, Nano S, BigChainDB for inspiration and/or collaboration.

SIRE collaborative tools (e-team)

description

The standard collaborative tools of the CS-DC are for each DAO:

• BBB for all kind of e-events including educational ones
• NextCloud for immediate interactions
• Forum for all kind of discussions

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 successively 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.

Immediate interactions are necessary in all social networks. The UNESCO UniTwin CS-DC and the WWW DAO needs an open tool for keeping at least minimal traces of this interactions (between board members, between individuals having the same wellbeing problem and searching solutions with their tutors, ..)

The forum has exactly the same utility as immediate interactions with the great advantage to keep automatically rich traces.

Members

• Julien Baudry (chair)
• Cyrille Bertelle (co-chair)

Data and/or tools to be shared

(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