# Keynote: Large-scale trustworthy distributed collaborative systems - challenges and prospective solutions

Claudia-Lavinia Ignat

<figure><img src="image_1.png" /></figure>

## To cite this version:

Claudia-Lavinia Ignat. Keynote: Large-scale trustworthy distributed collaborative systems - challenges and prospective solutions. INFORSID (INFormatique des ORganisations et Systèmes d'Information et de Décision) 2024, May 2024, Nancy, France. hal-04595294

HAL Id: hal-04595294

https://inria.hal.science/hal-04595294

Submitted on 31 May 2024

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Keynote: Large-scale trustworthy distributed collaborative systems - challenges and prospective solutions

Claudia-Lavinia Ignat

► To cite this version:

Claudia-Lavinia Ignat. Keynote: Large-scale trustworthy distributed collaborative systems - challenges and prospective solutions. INFORSID 2024 - INformatique des ORganisations et Systèmes d'Information et de Décision, May 2024, Nancy, France. hal-04595294v2

HAL Id: hal-04595294

https://inria.hal.science/hal-04595294v2

Submitted on 18 Jul 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
<figure><img src="image_3.png" /></figure>

Loria

<figure><img src="image_4.png" /></figure>

UNIVERSITÉ
DE LORRAINE

<figure><img src="image_5.png" /></figure>

informatics mathematics
Inria

Large-scale trustworthy
distributed collaborative systems:
challenges and prospective solutions

Claudia-Lavinia Ignat

COAST - Centre Inria de l'Université de Lorraine

Inforsid 2024

May 30, 2024

claudia.ignat@inria.fr
anr

<figure><img src="image_2.png" /></figure>

<figure><img src="image_3.png" /></figure>

PROGRAMME
DE RECHERCHE

NUMÉRIQUE
COLLABORATIF

<figure><img src="image_4.png" /></figure>

Loria

<figure><img src="image_5.png" /></figure>

UNIVERSITÉ
DE LORRAINE

<figure><img src="image_6.png" /></figure>

<figure><img src="image_7.png" /></figure>

informatics mathematics

Large-scale trustworthy
distributed collaborative systems:
challenges and prospective solutions

Claudia-Lavinia Ignat

COAST - Centre Inria de l'Université de Lorraine

Inforsid 2024

May 30, 2024

claudia.ignat@inria.fr
# Douglas Engelbart: Augmenting Human Intellect

<figure><img src="image_6.png" /></figure>

The Mother of all Demos, December 9, 1968

<figure><img src="image_7.png" /></figure>

NLS: Online System

https://archive.org/details/dougengelbartarchives
Douglas Engelbart: Augmenting Human Intellect

<figure><img src="image_8.png" /></figure>

The Mother of all Demos, December 9, 1968

<figure><img src="image_9.png" /></figure>

NLS: Online System
https://archive.org/details/dougengelbartarchives
Groupware, early 1990s

« Computer-based systems that support groups of people engaged in a common task (or goal) and that provide an interface to a shared environment. » [EGR91]

* Lotus Notes (HCL Notes today), one of the first commercial groupware allowing remote group collaboration
Groupware, early 1990s

« Computer-based systems that support groups of people engaged in a common task (or goal) and that provide an interface to a shared environment. » [EGR91]

* Lotus Notes (HCL Notes today), one of the first commercial groupware allowing remote group collaboration
# Groupware Time Space Matrix [J88]

same place
co-located

different place
remote

same time
synchronous

different time
asynchronous

**Face to face interactions**
decision rooms, single display groupware, **shared table**, wall displays, roomware, ...

**Continuous task**
**large public display**, team rooms, shift work groupware, project management, ...

**Remote interactions**
video conferencing, instance messaging, **chats**/MUDs/virtual worlds, shared screens, **multi-user editors**, ...

**Communication + coordination**
email, bulletin boards, blogs, asynchronous conferencing, group calendars, workflow, **version control**, **wikis**, ...

Time/Space
Groupware
Matrix
# Groupware Time Space Matrix [J88]

<figure><img src="image_10.png" /></figure>
## Collaborative Systems: from users to community of users

<figure><img src="image_8.png" /></figure>

<figure><img src="image_9.png" /><figcaption>GROVE, 1989</figcaption></figure>

*“Isn't it chaotic to all edit in the same document, even the same paragraph, at the same time?”*

*“Why would a group ever want to edit in the same line of text at the same time?”* [EGR91]
## Collaborative Systems: from users to community of users

<figure><img src="image_11.png" /></figure>

"Isn't it chaotic to all edit in the same document, even the same paragraph, at the same time?"

"Why would a group ever want to edit in the same line of text at the same time?" [EGR91]

GROVE, 1989
# From users to community of users: new practices

<figure><img src="image_10.png" /></figure>

WIKIPEDIA
The Free Encyclopedia

Main page

Contents

Current events

Random article

About Wikipedia

Contact us

Donate

Contribute

Help

Learn to edit

Community portal

Recent changes

Upload file

Tools

What links here

Related changes

<figure><img src="image_11.png" /></figure>

Special pages

Page information

Wikidata item

Languages

<figure><img src="image_12.png" /></figure>

<figure><img src="image_13.png" /></figure>

Not logged in Talk Contributions Create account Log in

Article

Talk

Read

Edit

View history

Search Wikipedia

<figure><img src="image_14.png" /></figure>

## United States Capitol: Revision history

<figure><img src="image_15.png" /></figure>

Help

View logs for this page (view filter log)

### Filter revisions

External tools: Find addition/removal (Alternate) · Find edits by user · Page statistics · Pageviews · Fix dead links

For any version listed below, click on its date to view it. For more help, see Help:Page history and Help:Edit summary. (cur) = difference from current version, (prev) = difference from preceding version, m = minor edit, → = section edit, ← = automatic edit summary

(newest | oldest) View (newer 20 | older 20) (20 | 50 | 100 | 250 | 500)

### Compare selected revisions

* (cur | prev) 22:56, 6 January 2021 Sleyece (talk | contribs) .. (83,551 bytes) (+96) .. (Be Concise) (undo)

* (cur | prev) 22:53, 6 January 2021 Thanoscar21 (talk | contribs) m .. (83,455 bytes) (-39) .. (Rollback edit(s) by 49.195.0.222 (talk): per WP:NPOV (RW 16)) (undo) (Tag: Rollback)

* (cur | prev) 22:52, 6 January 2021 49.195.0.222 (talk) .. (83,494 bytes) (+39) .. (undo) (Tag: Reverted)

* (cur | prev) 22:52, 6 January 2021 Sleyece (talk | contribs) m .. (83,455 bytes) (-3) .. (Grammar) (undo)

* (cur | prev) 22:52, 6 January 2021 2605:a601:ada1:2a00:ad83:9ec8:20bc:44c5 (talk) .. (83,458 bytes) (+4) .. (→Major events: Fixed punctuation) (undo) (Tags: Mobile edit, Mobile web edit)

* (cur | prev) 22:51, 6 January 2021 Sleyece (talk | contribs) .. (83,454 bytes) (+423) .. (Bot Reverted too Much) (undo)

* (cur | prev) 22:49, 6 January 2021 2605:a601:ada1:2a00:ad83:9ec8:20bc:44c5 (talk) .. (83,031 bytes) (+15) .. (→Major events: Cleaned up wording on Trump recorded message) (undo) (Tags: Mobile edit, Mobile web edit)

* (cur | prev) 22:47, 6 January 2021 2605:a601:ada1:2a00:ad83:9ec8:20bc:44c5 (talk) .. (83,016 bytes) (-1) .. (→Major events: Replaced one other instance of "rioters" with "people") (undo) (Tags: Mobile edit, Mobile web edit)

* (cur | prev) 22:45, 6 January 2021 2605:a601:ada1:2a00:ad83:9ec8:20bc:44c5 (talk) .. (83,017 bytes) (-8) .. (→Major events: Typo) (undo) (Tags: Mobile edit, Mobile web edit)

* (cur | prev) 22:45, 6 January 2021 2600:1700:2b9c:5010:a145:6992:7d5a:8714 (talk) .. (83,025 bytes) (+81) .. (→Major events) (undo)

* (cur | prev) 22:44, 6 January 2021 2605:a601:ada1:2a00:ad83:9ec8:20bc:44c5 (talk) .. (82,944 bytes) (+52) .. (→Major events: Rephrased "rioters") (undo) (Tags: Mobile edit, Mobile web edit)

* (cur | prev) 22:39, 6 January 2021 Jleswinj (talk | contribs) .. (82,892 bytes) (-351) .. (undo) (Tag: Visual edit)

* (cur | prev) 22:39, 6 January 2021 ClueBot NG (talk | contribs) m .. (83,243 bytes) (-47) .. (Reverting possible vandalism by 2603:9001:4903:D811:9052:EFE:155C:2134 to version by 81.167.188.42. Report False Positive? Thanks, ClueBot NG. (3860441) (Bot)) (undo) (Tag: Rollback)

* (cur | prev) 22:39, 6 January 2021 2603:9001:4903:d811:9052:efe:155c:2134 (talk) .. (83,290 bytes) (+47) .. (undo) (Tags: Mobile edit, Mobile web edit, Reverted)

* (cur | prev) 22:35, 6 January 2021 81.167.188.42 (talk) .. (83,243 bytes) (+40) .. (undo)

* (cur | prev) 22:34, 6 January 2021 72.217.56.18 (talk) .. (83,203 bytes) (-58) .. (person shot has not been reported dead as of yet!) (undo)

* (cur | prev) 22:33, 6 January 2021 2600:1700:1c60:41d0:e5a9:3248:c03e:eb02 (talk) .. (83,261 bytes) (+73) .. (Adding the President's reaction to the event.) (undo) (Tag: extraneous markup)

* (cur | prev) 22:31, 6 January 2021 2603:8000:8e42:cb00:55ec:35dc:94e4:c9be (talk) .. (83,188 bytes) (+1) .. (undo) (Tag: Possible vandalism)

* (cur | prev) 22:29, 6 January 2021 92.21.72.53 (talk) .. (83,187 bytes) (+40) .. (Adding info) (undo) (Tags: Mobile edit, Mobile web edit, Visual edit, Possible vandalism)

* (cur | prev) 22:28, 6 January 2021 176.23.9.200 (talk) .. (83,147 bytes) (+10) .. (undo)

### Compare selected revisions

(newest | oldest) View (newer 20 | older 20) (20 | 50 | 100 | 250 | 500)
# From users to community of users: new practices

<figure><img src="image_12.png" /></figure>

WIKIPEDIA
The Free Encyclopedia

Main page

Contents

Current events

Random article

About Wikipedia

Contact us

Donate

Contribute

Help

Learn to edit

Community portal

Recent changes

Upload file

Tools

What links here

Related changes

<figure><img src="image_13.png" /></figure>

Special pages

Page information

Wikidata item

Languages

<figure><img src="image_14.png" /></figure>

<figure><img src="image_15.png" /></figure>

Not logged in

Talk

Contributions

Create account

Log in

Article

Talk

Read

Edit

View history

Search Wikipedia

<figure><img src="image_16.png" /></figure>

## United States Capitol: Revision history

<figure><img src="image_17.png" /></figure>

Help

View logs for this page (view filter log)

### Filter revisions

External tools: Find addition/removal (Alternate) · Find edits by user · Page statistics · Pageviews · Fix dead links

For any version listed below, click on its date to view it. For more help, see Help:Page history and Help:Edit summary. (cur) = difference from current version, (prev) = difference from preceding version, m = minor edit, → = section edit, ↔ = automatic edit summary

(newest | oldest) View (newer 20 | older 20) (20 | 50 | 100 | 250 | 500)

### Compare selected revisions

<table><tr><td>(cur | prev)</td><td>22:56, 6 January 2021</td><td>Sleyece (talk | contribs)</td><td>(83,551 bytes) (+96)</td><td>(Be Concise) (undo)</td></tr><tr><td>(cur | prev)</td><td>22:53, 6 January 2021</td><td>Thanoscar21 (talk | contribs)</td><td>m</td><td>(83,455 bytes) (-39)</td><td>(Rollback edit(s) by 49.195.0.222 (talk): per WP:NPOV (RW 16)) (undo) (Tag: Rollback)</td></tr><tr><td>(cur | prev)</td><td>22:52, 6 January 2021</td><td>9.195.0.222 (talk)</td><td>(83,494 bytes) (+39)</td><td>(undo) (Tag: Reverted)</td></tr><tr><td>(cur | prev)</td><td>22:52, 6 January 2021</td><td>Sleyece (talk | contribs)</td><td>m</td><td>(83,455 bytes) (-3)</td><td>(Grammar) (undo)</td></tr><tr><td>(cur | prev)</td><td>22:52, 6 January 2021</td><td>2605:a601:ada1:2a00:ad83:9ec8:20bc:44c5 (talk)</td><td>(83,458 bytes) (+4)</td><td>(→Major events: Fixed punctuation) (undo) (Tags: Mobile edit, Mobile web edit)</td></tr><tr><td>(cur | prev)</td><td>22:51, 6 January 2021</td><td>Sleyece (talk | contribs)</td><td>(83,454 bytes) (+423)</td><td>(Bot Reverted too Much) (undo)</td></tr><tr><td>(cur | prev)</td><td>22:49, 6 January 2021</td><td>2605:a601:ada1:2a00:ad83:9ec8:20bc:44c5 (talk)</td><td>(83,031 bytes) (+15)</td><td>(→Major events: Cleaned up wording on Trump recorded message) (undo) (Tags: Mobile edit, Mobile web edit)</td></tr><tr><td>(cur | prev)</td><td>22:47, 6 January 2021</td><td>2605:a601:ada1:2a00:ad83:9ec8:20bc:44c5 (talk)</td><td>(83,016 bytes) (-1)</td><td>(→Major events: Replaced one other instance of "rioters" with "people") (undo) (Tags: Mobile edit, Mobile web edit)</td></tr><tr><td>(cur | prev)</td><td>22:45, 6 January 2021</td><td>2605:a601:ada1:2a00:ad83:9ec8:20bc:44c5 (talk)</td><td>(83,017 bytes) (-8)</td><td>(→Major events: Typo) (undo) (Tags: Mobile edit, Mobile web edit)</td></tr><tr><td>(cur | prev)</td><td>22:45, 6 January 2021</td><td>2600:1700:2b9c:5010:a145:6992:7d5a:8714 (talk)</td><td>(83,025 bytes) (+81)</td><td>(→Major events) (undo)</td></tr><tr><td>(cur | prev)</td><td>22:44, 6 January 2021</td><td>2605:a601:ada1:2a00:ad83:9ec8:20bc:44c5 (talk)</td><td>(82,944 bytes) (+52)</td><td>(→Major events: Rephrased "rioters") (undo) (Tags: Mobile edit, Mobile web edit)</td></tr><tr><td>(cur | prev)</td><td>22:39, 6 January 2021</td><td>Jeswinj (talk | contribs)</td><td>(82,892 bytes) (-351)</td><td>(undo) (Tag: Visual edit)</td></tr><tr><td>(cur | prev)</td><td>22:39, 6 January 2021</td><td>ClueBot NG (talk | contribs)</td><td>m</td><td>(83,243 bytes) (-47)</td><td>(Reverting possible vandalism by 2603:9001:4903:D811:9052:EF E:155C:2134 to version by 81.167.188.42. Report False Positive? Thanks, ClueBot NG. (3860441) (Bot)) (undo) (Tag: Rollback)</td></tr><tr><td>(cur | prev)</td><td>22:39, 6 January 2021</td><td>2603:9001:4903:d811:9052:efe:155c:2134 (talk)</td><td>(83,290 bytes) (+47)</td><td>(undo) (Tags: Mobile edit, Mobile web edit, Reverted)</td></tr><tr><td>(cur | prev)</td><td>22:35, 6 January 2021</td><td>81.167.188.42 (talk)</td><td>(83,243 bytes) (+40)</td><td>(undo)</td></tr><tr><td>(cur | prev)</td><td>22:34, 6 January 2021</td><td>72.217.56.18 (talk)</td><td>(83,203 bytes) (-58)</td><td>(person shot has not been reported dead as of yet!) (undo)</td></tr><tr><td>(cur | prev)</td><td>22:33, 6 January 2021</td><td>2600:1700:1c60:41d0:e5a9:3248:c03e:eb02 (talk)</td><td>(83,261 bytes) (+73)</td><td>(Adding the President's reaction to the event.) (undo) (Tag: extraneous markup)</td></tr><tr><td>(cur | prev)</td><td>22:31, 6 January 2021</td><td>2603:8000:8e42:cb00:55ec:35dc:94e4:c9be (talk)</td><td>(83,188 bytes) (+1)</td><td>(undo) (Tag: Possible vandalism)</td></tr><tr><td>(cur | prev)</td><td>22:29, 6 January 2021</td><td>92.21.72.53 (talk)</td><td>(83,187 bytes) (+40)</td><td>(Adding info) (undo) (Tags: Mobile edit, Mobile web edit, Visual edit, Possible vandalism)</td></tr><tr><td>(cur | prev)</td><td>22:28, 6 January 2021</td><td>176.23.9.200 (talk)</td><td>(83,147 bytes) (+10)</td><td>(undo)</td></tr></table>

### Compare selected revisions

(newest | oldest) View (newer 20 | older 20) (20 | 50 | 100 | 250 | 500)
From users to community of users: new practices

<figure><img src="image_16.png" /></figure>

Example: Intergovernmental Panel Climate Change
(IPCC) assessment report editing

- Expert contributions: hundreds of scientists from different countries

- Review stages by experts and governments

- Approval sessions: government delegates and lead authors

- Editing teams: review editors
From users to community of users: new practices

<figure><img src="image_18.png" /></figure>

Example: Intergovernmental Panel Climate Change
(IPCC) assessment report editing

- Expert contributions: hundreds of scientists from different countries

- Review stages by experts and governments

- Approval sessions: government delegates and lead authors

- Editing teams: review editors
SCALABILITY

<figure><img src="image_17.png" /></figure>

PRIVACY
SCALABILITY

<figure><img src="image_19.png" /></figure>

PRIVACY
# Vision: Peer-to-Peer Collaborative Systems

<figure><img src="image_18.png" /></figure>
Vision: Peer-to-Peer Collaborative Systems

<figure><img src="image_20.png" /></figure>
## Collaboration Modes – Concurrent Changes

<figure><img src="image_19.png" /></figure>
## Collaboration Modes – Concurrent Changes

<figure><img src="image_21.png" /></figure>
Collaboration Modes – Offline Work

<figure><img src="image_20.png" /></figure>
Collaboration Modes – Offline Work

<figure><img src="image_22.png" /></figure>
## Collaboration Modes – Ad-hoc Collaboration

<figure><img src="image_21.png" /></figure>

<figure><img src="image_22.png" /></figure>

<figure><img src="image_23.png" /></figure>

<figure><img src="image_24.png" /></figure>

<figure><img src="image_25.png" /></figure>

<figure><img src="image_26.png" /></figure>
## Collaboration Modes – Ad-hoc Collaboration

<figure><img src="image_23.png" /></figure>

<figure><img src="image_24.png" /></figure>

<figure><img src="image_25.png" /></figure>

<figure><img src="image_26.png" /></figure>

<figure><img src="image_27.png" /></figure>

<figure><img src="image_28.png" /></figure>
Research issues

1. How to maintain consistency of different copies in the face of concurrent modifications?

2. How to secure collaboration data?

3. How to make a collaboration trustworthy?
Research issues

1. How to maintain consistency of different copies in the face of concurrent modifications?

2. How to secure collaboration data?

3. How to make a collaboration trustworthy?
Research issues

1. How to maintain consistency of different copies in the face of concurrent modifications?

2. How to secure collaboration data?

3. How to make a collaboration trustworthy?
Research issues

1. How to maintain consistency of different copies in the face of concurrent modifications?

2. How to secure collaboration data?

3. How to make a collaboration trustworthy?
# CAP Theorem [B00]

* Properties of shared-data systems

* Data consistency

* System availability

* Tolerance to network partition

* Only two out of three properties can be achieved at a given time

* Relax consistency for availability in the presence of network partitions
CAP Theorem [B00]

* Properties of shared-data systems

* Data consistency

* System availability

* Tolerance to network partition

* Only two out of three properties can be achieved at a given time

* Relax consistency for availability in the presence of network partitions
Operational transformation (OT) [EG89]

<figure><img src="image_27.png" /></figure>

T(ins(p1,c1), ins(p2,c2)) :-
  if (p1<p2) return ins(p1,c1)
else return ins(p1+1,c1)
endif

* Transforms non commuting operations to make them commute

* Genericity

* Time complexity
  Average: O(H.c)
  Worst case: O(H²)

H: #ops

c: avg. #conc. ops

* Difficult to write correct transformation functions

* State vectors used for detecting concurrency ⇒ scalability limitations

* **Not very suitable for large scale peer-to-peer collaboration**
Operational transformation (OT) [EG89]

<figure><img src="image_29.png" /></figure>

T(ins(p1,c1), ins(p2,c2)) :-
  if (p1<p2) return ins(p1,c1)
else return ins(p1+1,c1)
endif

* Transforms non commuting operations to make them commute

* Genericity

* Time complexity

Average: O(H.c)

H: #ops

Worst case: O(H²)

c: avg. #conc. ops

* Difficult to write correct transformation functions

* State vectors used for detecting concurrency ⇒ scalability limitations

* **Not very suitable for large scale peer-to-peer collaboration**
# Conflict-free Replicated Data Types (CRDT) [SPBZ11]

* Design operations to be commutative by construction

* Abstract data types

* Designed to be replicated at multiple sites

* Any replica can be modified without coordination

* State convergence is guaranteed

* State-based and operation-based approaches
Conflict-free Replicated Data Types (CRDT) [SPBZ11]

* Design operations to be commutative by construction

* Abstract data types

* Designed to be replicated at multiple sites

* Any replica can be modified without coordination

* State convergence is guaranteed

* State-based and operation-based approaches
# Conflict-free Replicated Data Types (CRDT)
## State-based Replication

<figure><img src="image_28.png" /></figure>

* Algorithm

* Periodically, replica at $p_i$ sends its current state to $p_j$

* Replica $p_j$ merges received state into its local state by executing $m$

* After receiving all updates (irrespective of order), each replica will have same state
# Conflict-free Replicated Data Types (CRDT)
## State-based Replication

<figure><img src="image_30.png" /></figure>

* Algorithm

* Periodically, replica at $p_i$ sends its current state to $p_j$

* Replica $p_j$ merges received state into its local state by executing m

* After receiving all updates (irrespective of order), each replica will have same state
# Conflict-free Replicated Data Types (CRDT)
## State-based Replication

* **Merge operator:**

* **Commutative:** $x \cdot y = y \cdot x$

* **Associative:** $(x \cdot y) \cdot z = x \cdot (y \cdot z)$

* **Idempotent:** $x \cdot x = x$

* A semi-lattice is a Partial order $\leq$ set $S$ with a least upper bound (LUB), denoted $\bigcup$

* $m = x \bigcup y$ is a LUB of $\{x, y\}$ under $\leq$ if and only if $\forall m', x \leq m' \land y \leq m' \Rightarrow x \leq m \land y \leq m \land m \leq m'$

* It follows that $\bigcup$ is commutative, associative and idempotent
# Conflict-free Replicated Data Types (CRDT)
## State-based Replication

* **Merge operator:**

* **Commutative:** $x \cdot y = y \cdot x$

* **Associative:** $(x \cdot y) \cdot z = x \cdot (y \cdot z)$

* **Idempotent:** $x \cdot x = x$

* A semi-lattice is a Partial order $\leq$ set $S$ with a least upper bound (LUB), denoted $\bigcup$

* $m = x \bigcup y$ is a LUB of $\{x, y\}$ under $\leq$ if and only if $\forall m', x \leq m' \land y \leq m' \Rightarrow x \leq m \land y \leq m \land m \leq m'$

* It follows that $\bigcup$ is commutative, associative and idempotent
# Conflict-free Replicated Data Types (CRDT)
## Operation-based Replication

<figure><img src="image_29.png" /></figure>

* An update split into $(t,u)$: $t$ is a side-effect-free prepare-update method and $u$ is an effect-update method

* Algorithm

* Updates delivered to all replicas

* Causally-ordered broadcast, every message delivered to every node exactly once w.r.t. happen-before order

* Commutativity holds for concurrent updates
# Conflict-free Replicated Data Types (CRDT)
## Operation-based Replication

<figure><img src="image_31.png" /></figure>

* An update split into (t,u): t is a side-effect-free prepare-update method and u is an effect-update method

* Algorithm

* Updates delivered to all replicas

* Causally-ordered broadcast, every message delivered to every node exactly once w.r.t. happen-before order

* Commutativity holds for concurrent updates
# Conflict-free Replicated Data Types (CRDT)
## Operation vs. State-based Replication

* Both approaches are equivalent

* A state-based object can emulate an operation-based object, and vice-versa

* Operation-based:

* More efficient since you only ship small updates

* But require exactly once causally-ordered broadcast

* State-based:

* Only require reliable broadcast

* Communication overhead of shipping the whole state

* Delta State-based [ASB18]:

* Small messages

* Dissemination over unreliable communication channels
# Conflict-free Replicated Data Types (CRDT)
## Operation vs. State-based Replication

* Both approaches are equivalent

* A state-based object can emulate an operation-based object, and vice-versa

* Operation-based:

* More efficient since you only ship small updates

* But require exactly once causally-ordered broadcast

* State-based:

* Only require reliable broadcast

* Communication overhead of shipping the whole state

* Delta State-based [ASB18]:

* Small messages

* Dissemination over unreliable communication channels
# Consistency Maintenance
# Conflict-free Replicated Data Types (CRDT)

<figure><img src="image_30.png" /></figure>

<figure><img src="image_31.png" /></figure>

<figure><img src="image_32.png" /></figure>

<figure><img src="image_33.png" /></figure>

bet365

<figure><img src="image_34.png" /></figure>

SCALITY

<figure><img src="image_35.png" /></figure>

TRIFORK

<figure><img src="image_36.png" /></figure>

akka

<figure><img src="image_37.png" /></figure>

ROVIO

<figure><img src="image_38.png" /></figure>

TomTom

<figure><img src="image_39.png" /></figure>

<figure><img src="image_40.png" /></figure>

PROJECTIO

* Register

* Last-Writer Wins

* Multi-Value

* Set

* Grow-Only

* 2-Phase

* Observed-Remove

* Observed-Update-Remove

* Map

* Counter

* Graph

* Directed

* Monotonic DAG

* Edit graph

* Sequence
# Consistency Maintenance
# Conflict-free Replicated Data Types (CRDT)

* Register

* Last-Writer Wins

* Multi-Value

* Set

* Grow-Only

* 2-Phase

* Observed-Remove

* Observed-Update-Remove

* Map

* Counter

* Graph

* Directed

* Monotonic DAG

* Edit graph

* Sequence

<figure><img src="image_32.png" /></figure>

bet365

<figure><img src="image_33.png" /></figure>

ROVIO

<figure><img src="image_34.png" /></figure>

SCALITY

<figure><img src="image_35.png" /></figure>

TomTom

<figure><img src="image_36.png" /></figure>

riak

<figure><img src="image_37.png" /></figure>

TRIFORK

<figure><img src="image_38.png" /></figure>

Tapjoy

<figure><img src="image_39.png" /></figure>

GAMES

<figure><img src="image_40.png" /></figure>

LEAGUES

<figure><img src="image_41.png" /></figure>

<figure><img src="image_42.png" /></figure>

HELIUM

<figure><img src="image_43.png" /></figure>

akka

<figure><img src="image_44.png" /></figure>

PROJECTIO

<figure><img src="image_45.png" /></figure>

ATOM
# Conflict-free Replicated Data Types (CRDT)
## (Text) Sequence [PMSL09] [WUM09]

* Document = linear sequence of elements

* Each element has a unique identifier

* Identifier constant for the lifetime of the document

* Dense total order of identifiers consistent with element order:

$$ \forall id_x, id_y: id_x < id_y \Rightarrow \exists id_z: id_z < id_x < id_y $$

* Different approaches for generating identifiers:

* TreeDoc, Logoot, LogootSplit, ...
# Conflict-free Replicated Data Types (CRDT)
## (Text) Sequence [PMSL09][WUM09]

* Document = linear sequence of elements

* Each element has a unique identifier

* Identifier constant for the lifetime of the document

* Dense total order of identifiers consistent with element order:

$$ \forall id_x, id_y: id_x < id_y \Rightarrow \exists id_z: id_z < id_x < id_y $$

* Different approaches for generating identifiers:

* TreeDoc, Logoot, LogootSplit, ...
# Conflict-free Replicated Data Types (CRDT)

## Logoot [WUM09]

* Logoot identifiers: $<p_1,s_1,h_1><p_2,s_2,h_2> \dots <p_k,s_k,h_k>$

$p_i$ integer

$s_i$ site identifier

$h_i$ logical clock at site $s_i$

ins(<3,2,5><13,1,7>, r)

ins(<12,3,1><7,8,2><13,3,6><7,2,9>, o)

<table><thead><tr><th></th><th></th><th></th></tr></thead><tbody><tr><td>&lt;1,2,1&gt;</td><td>c</td><td></td></tr><tr><td>&lt;1,2,2&gt;</td><td></td><td>o</td></tr><tr><td>&lt;2,1,2&gt;</td><td></td><td>n</td></tr><tr><td>&lt;3,1,3&gt;</td><td>c</td><td></td></tr><tr><td>&lt;3,1,3&gt;&lt;8,4,5&gt;</td><td></td><td>u</td></tr><tr><td>&lt;3,2,5&gt;</td><td></td><td>r</td></tr><tr><td>&lt;4,1,7&gt;</td><td></td><td>e</td></tr><tr><td>&lt;4,1,7&gt;&lt;9,2,6&gt;</td><td></td><td>n</td></tr><tr><td>&lt;7,2,8&gt;</td><td></td><td>c</td></tr><tr><td>&lt;9,1,7&gt;</td><td></td><td>y</td></tr><tr><td>&lt;10,2,8&gt;</td><td></td><td></td></tr><tr><td>&lt;12,3,1&gt;</td><td>c</td><td></td></tr><tr><td>&lt;12,3,1&gt;&lt;6,5,1&gt;</td><td></td><td>o</td></tr><tr><td>&lt;12,3,1&gt;&lt;7,8,2&gt;</td><td></td><td>n</td></tr><tr><td>&lt;12,3,1&gt;&lt;7,8,2&gt;&lt;12,3,5&gt;</td><td></td><td>t</td></tr><tr><td>&lt;12,3,1&gt;&lt;7,8,2&gt;&lt;13,3,6&gt;</td><td></td><td>r</td></tr><tr><td>&lt;12,3,1&gt;&lt;7,8,2&gt;&lt;14,3,7&gt;</td><td></td><td>l</td></tr></tbody></table>

* Time complexity

Average: $O(k \log(n))$

Worst case: $O(H*\log(H))$

H: #ops

n: doc. size (non deleted chars.)

k: avg. size of Logoot identifier

* No need for concurrency detection

* Identifiers storage cost

* New design for each data type

* Suitable for large-scale collaboration
# Conflict-free Replicated Data Types (CRDT)

## Logoot [WUM09]

* Logoot identifiers: $<p_1,s_1,h_1><p_2,s_2,h_2> \dots <p_k,s_k,h_k>$

$p_i$ integer

$s_i$ site identifier

$h_i$ logical clock at site $s_i$

ins(<3,2,5><13,1,7>, r)

ins(<12,3,1><7,8,2><13,3,6><7,2,9>, o)

<table><thead><tr><th>&lt;1,2,1&gt;</th><th>c</th></tr></thead><tbody><tr><td>&lt;1,2,2&gt;</td><td>o</td></tr><tr><td>&lt;2,1,2&gt;</td><td>n</td></tr><tr><td>&lt;3,1,3&gt;</td><td>c</td></tr><tr><td>&lt;3,1,3&gt;&lt;8,4,5&gt;</td><td>u</td></tr><tr><td>&lt;3,2,5&gt;</td><td>r</td></tr><tr><td>&lt;4,1,7&gt;</td><td>e</td></tr><tr><td>&lt;4,1,7&gt;&lt;9,2,6&gt;</td><td>n</td></tr><tr><td>&lt;7,2,8&gt;</td><td>c</td></tr><tr><td>&lt;9,1,7&gt;</td><td>y</td></tr><tr><td>&lt;10,2,8&gt;</td><td></td></tr><tr><td>&lt;12,3,1&gt;</td><td>c</td></tr><tr><td>&lt;12,3,1&gt;&lt;6,5,1&gt;</td><td>o</td></tr><tr><td>&lt;12,3,1&gt;&lt;7,8,2&gt;</td><td>n</td></tr><tr><td>&lt;12,3,1&gt;&lt;7,8,2&gt;&lt;12,3,5&gt;</td><td>t</td></tr><tr><td>&lt;12,3,1&gt;&lt;7,8,2&gt;&lt;13,3,6&gt;</td><td>r</td></tr><tr><td>&lt;12,3,1&gt;&lt;7,8,2&gt;&lt;14,3,7&gt;</td><td>l</td></tr></tbody></table>

* Time complexity

Average: $O(k \log(n))$

Worst case: $O(H*\log(H))$

H: #ops

n: doc. size (non deleted chars.)

k: avg. size of Logoot identifier

* No need for concurrency detection

* Identifiers storage cost

* New design for each data type

* Suitable for large-scale collaboration
# Conflict-free Replicated Data Types (CRDT)

## LogootSplit [AMOI13]

Aggregation of elements to limit metadata

LogootSplit identifiers

<figure><img src="image_41.png" /></figure>
# Conflict-free Replicated Data Types (CRDT)

## LogootSplit [AMOI13]

Aggregation of elements to limit metadata

LogootSplit identifiers

<figure><img src="image_46.png" /></figure>

<table><tr><td>1,1,[0,16]</td><td>concurrency contr1</td></tr></table>

<figure><img src="image_47.png" /></figure>

Insert r between "concur" and "ency contr1"

<table><tr><td>1,1,[0,5]</td><td>concur</td></tr><tr><td>1,1,5,2,1,[0,0]</td><td>r</td></tr><tr><td>1,1, [6,16]</td><td>ency<br>contr1</td></tr></table>

<figure><img src="image_48.png" /></figure>

Insert o between "ency contr" and "l"

<table><tr><td>1,1,[0,5]</td><td>concur</td></tr><tr><td>1,1,5,2,1,[0,0]</td><td>r</td></tr><tr><td>1,1, [6,15]</td><td>ency contr</td></tr><tr><td>1,1,15,3,1,[0,0]</td><td>o</td></tr><tr><td>1,1,[16,16]</td><td>l</td></tr></table>
# Conflict-free Replicated Data Types (CRDT)
## LogootSplit - Impact

* Implemented in MUTE P2P collaborative editor [NEOIC17] [github.com/coast-team/mute, OpenPaaS::NG, ADT MUTE]

* Better performances than GoogleDocs [DI16a]

<figure><img src="image_42.png" /></figure>

<figure><img src="image_43.png" /></figure>

* Related approach on wikis transferred to XWiki [IA021]
# Conflict-free Replicated Data Types (CRDT)
## LogootSplit - Impact

* Implemented in MUTE P2P collaborative editor [NEOIC17] [github.com/coast-team/mute, OpenPaaS::NG, ADT MUTE]

* Better performances than GoogleDocs [DI16a]

<figure><img src="image_49.png" /></figure>

<figure><img src="image_50.png" /></figure>

* Related approach on wikis transferred to XWiki [IA021]
# User Study: The effect of delay on users [IOFSC15]

* Delays in seeing modifications of other users

* Network delay

* Time complexity of consistency maintenance algorithms

* Types of architecture

<figure><img src="image_44.png" /><figcaption>Thin client architecture</figcaption></figure>

<figure><img src="image_45.png" /><figcaption>Thick client architecture</figcaption></figure>

* How does **delay influence group performance?**
# User Study: The effect of delay on users [IOFSC15]

* Delays in seeing modifications of other users

* Network delay

* Time complexity of consistency maintenance algorithms

* Types of architecture

<figure><img src="image_51.png" /><figcaption>Thin client architecture</figcaption></figure>

<figure><img src="image_52.png" /><figcaption>Thick client architecture</figcaption></figure>

* How does **delay influence group performance?**
Experiment design

• 20 groups of 4 students

* Perform several collaborative editing tasks

- A proofreading task

- A sorting task

- A note taking task

* Use the provided collaborative editor (Etherpad) + chat

- Each group experienced a **certain delay** (0, 4, 6, 8, 10 s)

- Registration of user keyboard inputs

- Video recording of user activities on desktop
Experiment design

• 20 groups of 4 students

• Perform several collaborative editing tasks

• A proofreading task

• A sorting task

• A note taking task

• Use the provided collaborative editor (Etherpad) + chat

• Each group experienced a **certain delay** (0, 4, 6, 8, 10 s)

• Registration of user keyboard inputs

• Video recording of user activities on desktop
## Note-taking [IOFSC15]

<figure><img src="image_46.png" /></figure>

Editing zone

Chat dialogue
## Note-taking [IOFSC15]

<figure><img src="image_53.png" /></figure>

Editing zone

Chat dialogue
Delay reduces Group Performance

<figure><img src="image_47.png" /></figure>

<figure><img src="image_48.png" /></figure>

* Delay increases error rate and redundancy
Delay reduces Group Performance

<figure><img src="image_54.png" /></figure>

<figure><img src="image_55.png" /></figure>

* Delay increases error rate and redundancy
Delay reduces Group Performance

<figure><img src="image_49.png" /></figure>

* Delay decreases proportion of keywords
Delay reduces Group Performance

<figure><img src="image_56.png" /></figure>

* Delay decreases proportion of keywords
Design implications

* Reduce the delay by the choice of the architecture and synchronisation algorithms

* Make users aware of existing delays such that they can compensate for the delay by coordination strategies

* Analyse real collaboration traces to understand collaboration patterns and behavior [NI18]
Design implications

* Reduce the delay by the choice of the architecture and synchronisation algorithms

* Make users aware of existing delays such that they can compensate for the delay by coordination strategies

* Analyse real collaboration traces to understand collaboration patterns and behavior [NI18]
Perspectives – Replication for complex data

* Composition of replication mechanisms for simple data

* Maintaining global invariants (e.g. integrity constraints) over CRDTs for replicated relational databases [IEB24]

* Replication mechanisms for P2P cloud storage [AII23]

* Automated approach to combine CRDTs meeting expressed constraints

* Validate with users the defined merge semantics
Perspectives – Replication for complex data

* Composition of replication mechanisms for simple data

* Maintaining global invariants (e.g. integrity constraints) over CRDTs for replicated relational databases [IEB24]

* Replication mechanisms for P2P cloud storage [AII23]

* Automated approach to combine CRDTs meeting expressed constraints

* Validate with users the defined merge semantics
Research issues

1. How to maintain consistency of different copies in the face of concurrent modifications?

2. How to secure collaboration data?

3. How to make a collaboration trustworthy?
Research issues

1. How to maintain consistency of different copies in the face of concurrent modifications?

2. How to secure collaboration data?

3. How to make a collaboration trustworthy?
Security in peer-to-peer collaboration

<figure><img src="image_50.png" /></figure>

- Client-side E2E encryption

- Group key management

- Access control without central authority
Security in peer-to-peer collaboration

<figure><img src="image_57.png" /></figure>

- Client-side E2E encryption

- Group key management

- Access control without central authority
# Encryption for mutable data by means of CRDTs

* CRDTs suitable for client-side E2E encryption

<figure><img src="image_51.png" /></figure>
# Encryption for mutable data by means of CRDTs

* CRDTs suitable for client-side E2E encryption

<figure><img src="image_58.png" /></figure>
# Group key management for large and dynamic groups

* TreeKEM - Message Layer Security (MLS) RFC 9420

* Operations: Add, Remove and Update

<figure><img src="image_52.png" /></figure>

Updating member B

<figure><img src="image_53.png" /></figure>

Adding member E

<figure><img src="image_54.png" /></figure>

Modified/updated keys

<figure><img src="image_55.png" /></figure>

Keys on co-path, used to encrypt new keys to subgroups

* Delivery Service: a central server that resolves conflicts among operations

* **Goal: Distribute the Delivery Service [PIFTI23]**

* Use of reliable broadcast protocols for operation delivery

* Use consensus between group members for operation commits
# Group key management for large and dynamic groups

* TreeKEM - Message Layer Security (MLS) RFC 9420

* Operations: Add, Remove and Update

<figure><img src="image_59.png" /></figure>

Updating member B

<figure><img src="image_60.png" /></figure>

Adding member E

<figure><img src="image_61.png" /></figure>

Modified/updated keys

<figure><img src="image_62.png" /></figure>

Keys on co-path, used to encrypt new keys to subgroups

* Delivery Service: a central server that resolves conflicts among operations

* **Goal: Distribute the Delivery Service [PIFTI23]**

* Use of reliable broadcast protocols for operation delivery

* Use consensus between group members for operation commits
# Access control for peer-to-peer systems without central authority

## Goals

- Replicated data

- Replicated access rights

- Multiple administrators

## Approach

- Compose CRDTs for data with CRDTs for access rights [RIP23]

- Dependencies

- Between access rights operations

- Between document and access rights

<figure><img src="image_56.png" /></figure>
# Access control for peer-to-peer systems without central authority

## Goals

- Replicated data

- Replicated access rights

- Multiple administrators

## Approach

- Compose CRDTs for data with CRDTs for access rights [RIP23]

- Dependencies

- Between access rights operations

- Between document and access rights

<figure><img src="image_63.png" /></figure>
# P2P Cloud Storage – Défi Alvearium with hive Replication and security mechanisms application

* A distributed peer-to-peer cloud exploiting unused capacity of computers

* +20% of computing resources remain unused

* Allows users to share these computing resources

* Builds a virtual cloud to offer compute and **storage services**

<figure><img src="image_57.png" /></figure>

* Sustainable

* Secure & private

* Data sovereignty

* Affordable
# P2P Cloud Storage – Défi Alvearium with hive Replication and security mechanisms application

* A distributed peer-to-peer cloud exploiting unused capacity of computers

* +20% of computing resources remain unused

* Allows users to share these computing resources

* Builds a virtual cloud to offer compute and **storage services**

<figure><img src="image_64.png" /></figure>

* Sustainable

* Secure & private

* Data sovereignty

* Affordable
# P2P Cloud Storage – collaboration with hive Research topics

* How to place data in the peer-to-peer storage in order to ensure high availability?

* How to manage data that can be modified by different peers?

* How to deal with Byzantine nodes? How to handle Sybil attacks?

* How to define a peer-to-peer security mechanism (manage access rights, client-side E2E encryption, group key management)
## P2P Cloud Storage – collaboration with hive Research topics

* How to place data in the peer-to-peer storage in order to ensure high availability?

* How to manage data that can be modified by different peers?

* How to deal with Byzantine nodes? How to handle Sybil attacks?

* How to define a peer-to-peer security mechanism (manage access rights, client-side E2E encryption, group key management)
Research issues

1. How to maintain consistency of different copies in the face of concurrent modifications?

2. How to secure collaboration data?

3. How to make a collaboration **trustworthy**?
Data Exchange Platform (DXP)

* Part of IPCEI-CIS (Important Project of Common European Interest – Next Generation Cloud Infrastructure and Services) supported by the France 2030 program

* Involves Amadeus and three Inria research teams (COAST, CEDAR and MAGELLAN)

* A federated and distributed data exchange platform (DXP), operating in an open, scalable, and massively distributed environment (cloud-edge continuum)
Trust in collaborative tools [L21]

* Crisis management – issues on information sharing

* Technical issues: tools' complexity, network delay, no interoperability

* Communicational issues

<figure><img src="image_58.png" /></figure>
Research issues

1. How to maintain consistency of different copies in the face of concurrent modifications?

2. How to secure collaboration data?

3. How to make a collaboration **trustworthy**?
## Peer-to-peer user trust

* Prediction of future collaborative user behavior based on the quality of user contributions

# Should I Trust You?

<figure><img src="image_59.png" /></figure>
# Trust in collaborative tools [L21]

* Crisis management – issues on information sharing

* Technical issues: tools' complexity, network delay, no interoperability

* Communicational issues

<figure><img src="image_65.png" /></figure>
Trust computation - contribution

* Evaluate collaborators trust based on their past behavior

* Contract-based collaborative editing

* Trust game
## Peer-to-peer user trust

* Prediction of future collaborative user behavior based on the quality of user contributions

# Should I Trust You?

<figure><img src="image_66.png" /></figure>
# Trust computation in collaborative editing

* Respect/Violation of contracts [TI11, TIBM11, TIM12, ID21]

<figure><img src="image_60.png" /></figure>
Trust computation - contribution

* Evaluate collaborators trust based on their past behavior

* Contract-based collaborative editing

* Trust game
Peer-to-peer trust metric in trust game [BDM95]

<figure><img src="image_61.png" /></figure>

* Design a trust metric dealing with fluctuating user behaviour [DI16a]

* For a round: $current\_trust_t = \log(send\_proportion_t * (e-1)+1)$

$$send\_proportion_t = \frac{sending\_amount_t}{max\_sending\_amount}$$

* For accumulated rounds:

$$aggregate\_trust_t = \alpha_t * current\_trust_t + (1-\alpha_t) * aggregate\_trust_{t-1}$$
# Trust computation in collaborative editing

* Respect/Violation of contracts [TI11, TIBM11, TIM12, ID21]

<figure><img src="image_67.png" /></figure>
# Validation of the trust metric – experimental design [IDS19]

* **Experiment with users** on 4 trust games: Simple Game, Identity Game, Score game and Combine game

<figure><img src="image_62.png" /></figure>

* Showing either trust score or identity improves the measure

* Showing both of them does not change the measure

* **Trust-based systems can be a replacement of identity-based systems**

* Collaboration with Department of Psychology Wright State University
Peer-to-peer trust metric in trust game [BDM95]

User1

<figure><img src="image_68.png" /></figure>

balance: 10€

<figure><img src="image_69.png" /></figure>

new balance: 2€

<figure><img src="image_70.png" /></figure>

final balance: 19€

<figure><img src="image_71.png" /></figure>

User2

User₁ sends 8€ to User₂
User₂ receives 3x8€=24€

<figure><img src="image_72.png" /></figure>

new balance: 34€

User₂ sends back 17€ to User₁

<figure><img src="image_73.png" /></figure>

final balance: 17€

* **Design a trust metric** dealing with fluctuating user behaviour [DI16a]

* For a round: $current\_trust_t = \log(send\_proportion_t * (e-1)+1)$

$$send\_proportion_t = \frac{sending\_amount_t}{max\_sending\_amount}$$

* For accumulated rounds:

$$aggregate\_trust_t = \alpha_t * current\_trust_t + (1-\alpha_t) * aggregate\_trust_{t-1}$$
PEPR eNSEMBLE (https://pepr-ensemble.fr/)  
PILOT – Practices and infrastructure for long term collaboration

* Socio-technical models for long-term collaboration

* Multi-organizational, sovereign, secure, interoperable collaboration platforms promoting trust and digital well-being

* Coordinators

• Claudia-Lavinia Ignat, Inria

• François Charoy, Université de Lorraine

• Myriam Lewkowicz, Université de Technologie de Troyes
# Validation of the trust metric – experimental design [IDS19]

* **Experiment with users** on 4 trust games: Simple Game, Identity Game, Score game and Combine game

<figure><img src="image_74.png" /></figure>

* Showing either trust score or identity improves the measure

* Showing both of them does not change the measure

* **Trust-based systems can be a replacement of identity-based systems**

* Collaboration with Department of Psychology Wright State University
PILOT – Project axes

* Axis 1: Understanding current and future forms of long-term collaboration

* Axis 2: Open technical frameworks and protocols for long-term collaboration

* Axis 3: Conceptual Frameworks for long-term collaboration

* Axis 4: Actionable guidelines and demonstrators for long term collaboration
PEPR eNSEMBLE (https://pepr-ensemble.fr/)
PILOT – Practices and infrastructure for long term
collaboration

* Socio-technical models for long-term collaboration

* Multi-organizational, sovereign, secure, interoperable collaboration platforms promoting trust and digital well-being

* Coordinators

* Claudia-Lavinia Ignat, Inria

* François Charoy, Université de Lorraine

* Myriam Lewkowicz, Université de Technologie de Troyes
PILOT architecture

1- Identify new
forms of
collaboration /
new social needs

<figure><img src="image_63.png" /></figure>

Collect, build and organize
a repository of up-to-date
analyses, use cases and
reports about future forms
of long-term collaboration,
their challenges and their
limits.

2- Investigate new
technological
capacities

<figure><img src="image_64.png" /></figure>

Foundations for the future
infrastructure for long-term
collaboration by providing
new technology
components that can be at
the heart of safe,
sustainable and secure
collaborative services.

<figure><img src="image_65.png" /></figure>

3-Define
conceptual and
analysis tools to
ensure socio-
technological
approaches

<figure><img src="image_66.png" /></figure>

4-Provide
actionable visions,
guidelines and
patterns

New conceptual constructs
for analysis, modelling, and
design for articulating
social needs and
technology capabilities in a
socio-technical perspective,

Prototypes and
demonstrators, guidelines,
visions, patterns
PILOT – Project axes

* Axis 1: Understanding current and future forms of long-term collaboration

* Axis 2: Open technical frameworks and protocols for long-term collaboration

* Axis 3: Conceptual Frameworks for long-term collaboration

* Axis 4: Actionable guidelines and demonstrators for long term collaboration
PILOT – Resources

* Budget: 5 M€

* Period: 7 years (Sept. 2023 – Aug. 2030)

* Non permanent resources

* 18 PhD theses

* 4 postdocs of 2 years

* 2 engineers of 4 years

* 12 internships of 6 months

* 14 partner institutions: Inria, CNRS, Univ. Paris-Saclay, Univ. Grenoble Alpes, Sorbonne Univ., IMT, UTT, INSA Lyon, UCB, Nantes Université, ENSAM, Univ. de Lille, Univ. de Toulouse
PILOT architecture

1- Identify new
forms of
collaboration /new social needs

<figure><img src="image_75.png" /></figure>

Collect, build and organize
a repository of up-to-date
analyses, use cases and
reports about future forms
of long-term collaboration,
their challenges and their
limits.

2- Investigate new
technological
capacities

<figure><img src="image_76.png" /></figure>

Foundations for the future
infrastructure for long-term
collaboration by providing
new technology
components that can be at
the heart of safe,
sustainable and secure
collaborative services.

<figure><img src="image_77.png" /></figure>

4-Provide
actionable visions,
guidelines and
patterns

<figure><img src="image_78.png" /></figure>

3-Define
conceptual and
analysis tools to
ensure socio-
technological
approaches

New conceptual constructs
for analysis, modelling, and
design for articulating
social needs and
technology capabilities in a
socio-technical perspective,

Prototypes and
demonstrators, guidelines,
visions, patterns
Large-scale trustworthy distributed collaborative
systems

* New uses and new practices due to large scale adoption

- New challenges

- Consistency of replicated complex data

- Security mechanisms without a central authority

- Trust in collaborative platforms and trust among collaborators
PILOT – Resources

* Budget: 5 M€

* Period: 7 years (Sept. 2023 – Aug. 2030)

* Non permanent resources

* 18 PhD theses

* 4 postdocs of 2 years

* 2 engineers of 4 years

* 12 internships of 6 months

* 14 partner institutions: Inria, CNRS, Univ. Paris-Saclay, Univ. Grenoble Alpes, Sorbonne Univ., IMT, UTT, INSA Lyon, UCB, Nantes Université, ENSAM, Univ. de Lille, Univ. de Toulouse
Large-scale trustworthy distributed collaborative
systems

* New uses and new practices due to large scale adoption

- New challenges

- Consistency of replicated complex data

- Security mechanisms without a central authority

- Trust in collaborative platforms and trust among collaborators
References

* [All23] Quantifying the Performance of Conflict-free Replicated Data Types in InterPlanetary File System. Q. Acher, C.-L. Ignat, S. Ibrahim. DICG@Middleware 2023

* [AMO113] Supporting Adaptable Granularity of Changes for Massive Scale Collaborative Editing. L. André, S. Martin, G. Oster, C.-L. Ignat. CollaborateCom 2013.

* [ASB18] Delta state replicated data types. P. S. Almeida, A. Shoker, C. Baquero. Journal of Parallel and Distributed Computing, 2018

* [B00] Brewer, E.A. "Towards robust distributed systems". In Proc. of PODC, 2000.

* [BDM95] Trust, social history, and reciprocity. J. Berg, J. Dickhaut, and K. McCabe, Games and Econ. Behav. 1995.

* [DI16a] Performance of real-time collaborative editors at large scale: User perspective. Q. V. Dang, C.-L. Ignat. Networking 2016

* [DI16b] Computational Trust Model for Repeated Trust Games. Q. V. Dang, C.-L. Ignat. Trustcom 2016

* [EG89] Concurrency Control in GroupWare Systems, C.A. Ellis and S.J. Gibbs. ACM SIGMOD Record 18(2), 1989.

* [EGR91] Groupware: Some issues and experiences, C.A. Ellis, S. J. Gibbs and G. Rein, Communications of the ACM, 1991
Thank you

COAST Team

http://team.inria.fr/coast/

<figure><img src="image_79.png" /></figure>
References

* [IAO21] Enhancing rich content wikis with real-time collaboration. C.-L. Ignat, L. André, G. Oster. Concurr. Comput. Pract. Exp. 2021

* [ID21] Users trust assessment based on their past behavior in large scale collaboration. C.-L. Ignat, Q.-V. Dang. ICCP 2021

* [IDS19] The influence of trust score on cooperative behavior. C.-L. Ignat, Q.-V. Dang, and V. L. Shalin. ACM Trans. Internet Technol. 2019

* [IEB24] Synql: A CRDT-based Approach for Replicated Relational Databases with Integrity Constraints. C.-L. Ignat, V. Elvinger, H. Ba. DAIS 2024

* [IOFSC15] How Do User Groups Cope with Delay in Real-Time Collaborative Note Taking. C.-L. Ignat, G. Oster, O. Fox, V. L. Shalin, F. Charoy. ECSCW 2015

* [J88] GroupWare: Computer Support for Business Teams. R. Johansen. The Free Press, New York, NY, USA, 1988.

* [L21] Confiance dans les situations de travail collaboratifs médiatisés par des environnements numériques. B. Linot. Thèse de doctorat, Univ. de Lorraine, 2021

* [NEOIC17] MUTE: A Peer-to-Peer Web-based Real-time Collaborative Editor. M. Nicolas, V. Elvinger, G. Oster, C.-L. Ignat, F. Charoy. ECSCW, 2017
References

* [All23] Quantifying the Performance of Conflict-free Replicated Data Types in InterPlanetary File System. Q. Acher, C.-L. Ignat, S. Ibrahim. DICG@Middleware 2023

* [AMO113] Supporting Adaptable Granularity of Changes for Massive Scale Collaborative Editing. L. André, S. Martin, G. Oster, C.-L. Ignat. CollaborateCom 2013.

* [ASB18] Delta state replicated data types. P. S. Almeida, A. Shoker, C. Baquero. Journal of Parallel and Distributed Computing, 2018

* [B00] Brewer, E.A. "Towards robust distributed systems". In Proc. of PODC, 2000.

* [BDM95] Trust, social history, and reciprocity. J. Berg, J. Dickhaut, and K. McCabe, Games and Econ. Behav. 1995.

* [DI16a] Performance of real-time collaborative editors at large scale: User perspective. Q. V. Dang, C.-L. Ignat. Networking 2016

* [DI16b] Computational Trust Model for Repeated Trust Games. Q. V. Dang, C.-L. Ignat. Trustcom 2016

* [EG89] Concurrency Control in GroupWare Systems, C.A. Ellis and S.J. Gibbs. ACM SIGMOD Record 18(2), 1989.

* [EGR91] Groupware: Some issues and experiences, C.A. Ellis, S. J. Gibbs and G. Rein, Communications of the ACM, 1991
References

* **[NI18]** An Analysis of Merge Conflicts and Resolutions in Git-Based Open Source Projects. H. L. Nguyen, C.-L. Ignat. Journal of CSCW, 2018

* **[PIFTI23]** Design of an Efficient Distributed Delivery Service for Group Key Agreement Protocols. L. Paillat, C.-L. Ignat, D. Frey, M. Turuani, A. Ismail. FPS 2023

* **[PMSL09]** A commutative replicated data type for cooperative editing, N. Preguica, M. Joan, M. Shapiro, and M. Letia. ICDCS 2009.

* **[RIP23]** Access control based on CRDTs for Collaborative Distributed Applications. P.-A. Rault, C.-L. Ignat, O. Perrin. TrustCom 2023

* **[SPBZ11]** Conflict-free Replicated Data Types, M. Shapiro, N. Preguica, C. Baquero, M. Zawirski. Research Report, RR-7687, INRIA, 2011

* **[TI11]** H. T. T. Truong, C.-L. Ignat. Log Auditing for Trust Assessment in Peer-to-Peer Collaboration. ISPDC 2011

* **[TIBM11]** A contract-extended push-pull-clone model. H. T. T. Truong, C.-L. Ignat, M.-R. Bouguelia, P. Molli. CollaborateCom 2011

* **[TIM12]** Authenticating operation-based history in collaborative systems. H. T. T. Truong, C.-L. Ignat, P. Molli. GROUP 2012

* **[WUM09]** Logoot : a Scalable Optimistic Replication Algorithm for Collaborative Editing on P2P Networks, S. Weiss, P. Urso and P. Molli. ICDCS 2009.
References

[IAO21] Enhancing rich content wikis with real-time collaboration. C.-L. Ignat, L. André, G. Oster. Concurr. Comput. Pract. Exp. 2021

[ID21] Users trust assessment based on their past behavior in large scale collaboration. C.-L. Ignat, Q.-V. Dang. ICCP 2021

[IDS19] The influence of trust score on cooperative behavior. C.-L. Ignat, Q.-V. Dang, and V. L. Shalin. ACM Trans. Internet Technol. 2019

[IEB24] Synql: A CRDT-based Approach for Replicated Relational Databases with Integrity Constraints. C.-L. Ignat, V. Elvinger, H. Ba. DAIS 2024

[IOFSC15] How Do User Groups Cope with Delay in Real-Time Collaborative Note Taking. C.-L. Ignat, G. Oster, O. Fox, V. L. Shalin, F. Charoy. ECSCW 2015

[J88] GroupWare: Computer Support for Business Teams. R. Johansen. The Free Press, New York, NY, USA, 1988.

[L21] Confiance dans les situations de travail collaboratifs médiatisés par des environnements numériques. B. Linot. Thèse de doctorat, Univ. de Lorraine, 2021

[NEOIC17] MUTE: A Peer-to-Peer Web-based Real-time Collaborative Editor. M. Nicolas, V. Elvinger, G. Oster, C.-L. Ignat, F. Charoy. ECSCW, 2017
## References

* **[NI18]** An Analysis of Merge Conflicts and Resolutions in Git-Based Open Source Projects. H. L. Nguyen, C.-L. Ignat. Journal of CSCW, 2018

* **[PIFTI23]** Design of an Efficient Distributed Delivery Service for Group Key Agreement Protocols. L. Paillat, C.-L. Ignat, D. Frey, M. Turuani, A. Ismail. FPS 2023

* **[PMSL09]** A commutative replicated data type for cooperative editing, N. Preguica, M. Joan, M. Shapiro, and M. Letia. ICDCS 2009.

* **[RIP23]** Access control based on CRDTs for Collaborative Distributed Applications. P.-A. Rault, C.-L. Ignat, O. Perrin. TrustCom 2023

* **[SPBZ11]** Conflict-free Replicated Data Types, M. Shapiro, N. Preguica, C. Baquero, M. Zawirski. Research Report, RR-7687, INRIA, 2011

* **[TI11]** H. T. T. Truong, C.-L. Ignat. Log Auditing for Trust Assessment in Peer-to-Peer Collaboration. ISPDC 2011

* **[TIBM11]** A contract-extended push-pull-clone model. H. T. T. Truong, C.-L. Ignat, M.-R. Bouguelia, P. Molli. CollaborateCom 2011

* **[TIM12]** Authenticating operation-based history in collaborative systems. H. T. T. Truong, C.-L. Ignat, P. Molli. GROUP 2012

* **[WUM09]** Logoot : a Scalable Optimistic Replication Algorithm for Collaborative Editing on P2P Networks, S. Weiss, P. Urso and P. Molli. ICDCS 2009.