Communication autour de la "décentralisation" future de nos serveurs Semapps

Projets SemApps
, ,
1

Hello,

Via ce post, je souhaite anticiper la communication sur la décentralisation des données Semapps, le jour où nous passerons de 1 serveur à « N » serveurs.
L’objectif est que dès le début, lorsqu’on demande les informations aux utilisateurs (qui sont à l’origine des données), ces derniers comprennent bien le cycle de vie que ces données vont vivre.
Et pour cela, je souhaite faire un schéma, qui pourra être partagé pour tous les projets qui ont vocation à être « distribués ».

Je viens de faire un point avec Valentin Noilhetas pour le projet Glocal Low-tech

Ils bossent sur un sondage pour récupérer des données du terrain, et j’aimerais donc faire un schéma pour expliquer la VISIO SEMAPPS (= les différentes étapes de « décentralisation » d’un semapps à moyen terme).

En effet, pour l’instant, dans chacun de nos projets, nous utilisons des instances de Semapps « centralisées », en attendant la férération des Semapps en cours de dev.

Les personnes qui participent au renseignement des données peuvent ne pas comprendre quel est l’utilité de les intégrer dans un Semapps plutot qu’un autre outil centralisé (à part le côté open data ++, qui est déjà cool…).

Donc pour de nombreux projets, nous allons devoir expliquer comment, à l’avenir, grâce à l’interopérabilité entre les Semapps, les données vont se rapprocher de ceux qui les maintiennent.

Je propose donc de commencer à dessiner un schéma (qui me servira pour GLT) qui propose 3 étapes :

  • Etape 1 : sondage (RGPD) + saisie des données > Centralisation dans un seul Semapps
  • Etape 2 : validation du terrain qu’ils sont bien OK que leurs données sont hébergées comme ils l’entendent.
  • Etape 3 : chacun son semapps ! > On déplace les données sur de multiples serveur SOLID en fonction des orgas présentes dans le Semapps d’origine.

Par exemple, Glocal commencerait par un serveur Semapps, puis au bout d’un certain temps de communication auprès du terrain pour qu’ils se responsabilisent sur l’hébergement de leurs données, chaque sous-orga low-tech s’équipe de son serveur semapps, et les données sont alors distribuées sur chacunes des instances, tout en gardant un lien.

Il faudrait d’ailleurs prévoir un outil (financé dans le chantier interrop ?) pour cette migration de « distribution »…

Qu’en pensez-vous ? Avons-nous déjà des super schémas pour ça ?
Sinon, j’en commence un sous Figma :slight_smile: :slight_smile:

3 « J'aime »
2

Je trouve ça très cool comme approche @fluidlog !
Comme nous le suggérait Louis Cousin hier, il faudra tout de même faire attention à tester les performances avant de communiquer trop largement sur la possibilité de tou.te.s avoir un POD … On pourra déja tester entre nous !

Concernant les schémas, il n’y en a que des vieux, qui n’allaient pas jusqu’au niveau des PODs individuels, mais je ne suis pas sur que ce soit ton objectif Yannick (de faire un schéma avec les niveaux :

  • micro : POD (Personal Online Datastore - Pour les gens qui débarquent)
  • méso : COD (Collective Online Datastore : acronyme co-inventé par Seb, Alice, AV & SIB)
  • macro : Instances d’agrégation type Glocal-LT ou Archipel-Av

Un trouveras par exemple un schéma ici à la slide 9 :wink:

Concernant les PODs individuels, hâte que @srosset nous dise si on pourra en créer d’ici la fin de l’année, si c’est le cas, ça va complètement changer la manière dont on gère nos données et ça peut être de la bombe !

3

@fluidlog dispo pour t’aider sur ce sujet. Parlons-en quand tu veux.

4

Hello, merci pour ta réponse @guillaume.rouyer, mais je n’allais pas jusqu’à parler de PODs.

D’après ce que m’a dit Seb, la configuration avec PODs, très bien décrite dans ses Slides : Ajouter de l’intelligence aux PODs grâce à ActivityPub - Google Slides
Reste optionnelle. C’est un choix d’architecture interne à un serveur. Cela ne signifie pas qu’on fait de la fédération ou de l’interopérabilité. Si j’ai bien compris, sur un même serveur, il peut y avoir la notion de « POD » pour chaque utilisateur interne au Semapps. Chacun gère ses droits au niveau de son POD et partage les ressources qu’il a dans son POD, c’est juste une segmentation interne…

C’est donc différent des « POD » qu’on entend par exemple sur les fédération de serveurs « décentralisés » de type Mobilizon, Mastodon ou Diaspora, pour lequel un POD est un serveur, contenant une communauté…

→ Je ne souhaite donc pas parler de POD dans mon schéma.

L’objectif de ce dernier est de montrer une stratégie de décentralisation, en passant de 1 serveur Semapps à plusieurs serveurs Semapps, pour le même projet, sans forcément utiliser l’option de PODs.

L’objectif étant toujours de « rapprocher la maintenance des données des utilisateurs qui les maitrisent », pour avoir constemment des données fraiches, et à jour.

En utilisant un exemple concret, par exemple Archipel :
Par exemple, dans le Semapps du projet Archipel, on fait référence au projet Glocal Low Tech… Or, sur le serveur Archipel, la fiche de Glocal est dupliquée entre notre serveur Semapps et celui de Glocal. Et la fiche AV est aussi dupliquée.
L’avenir sera donc de faire un lien entre les deux semapps en utilisant ce qui est en cours d’être développé pour l’interop, pour avoir la fiche AV sur le serveur Archipel, et la fiche Glocal sur le serveur Glocal, que la navigation soit fluide entre les deux, sans que l’utilisateur ne se rende compte qu’il va consulter les infos sur un autre serveur (comme le web à l’origine…).

Autre exemple avec le lowtechlab.
Si le lowtechlab partent sur un serveur Semapps, dans lequel ils mettent tous les lowtechlab de France dedans, alors, il sera d’abord « centralisé » (pas plus d’apport que leur serveur actuel à part que les données sont sémantiques).
Quelques temps après, on passera à la deuxième phase, on ira sur le terrain pour responsabiliser les utilisateurs sur la gestion de leurs données, en proposant autant de serveur semapps que d’ « agence » lowtechlab (Bordeau, Paris, Concarneau, Grenoble…), ainsi, chaque entité sera responsable de maintenir ses données, mais l’interface pourra quand même permettre aux utilisateurs de Concarneau de voir les données de Bordeaux, comme s’ils étaient sur le même serveur. C’est la magie de l’interopérabilité (telle que je la comprends).

Dernière exemple, les tiers-lieux :
Imaginons que la compagnie des tiers-lieux souhaite aussi un semapps. Au début, il sera centralisé, avec tous les tiers lieux, peut-être d’ailleurs en dupliquant la fiche du PETR Sud Bourgogne…
Lorsque l’interop sera là, on leur proposera autant de Semapps qu’il y a de Tiers-lieux ou de « région de tiers-lieu ».

On pourrait même pousser la décentralisation jusqu’aux utilisateurs, qui auraient chacun leur serveur Raspberry dans leur salon avec un POD Solid dedans, mais je ne souhaite pas effrayer les utilisateurs pour le moment, on n’y est pas… restons au niveau des orgas.

J’espère que je ne suis pas le seul à avoir cette vision ? :slight_smile:

Merci de me confirmer @srosset @simon.louvet.zen ou @pierre que c’est bien ce qu’on « vend » à nos clients pour nous différencier d’un serveur banal centralisé.

1 « J'aime »
5

POD signifie « Personal online datastore », c’est ta base de donnée personnelle. Ce n’est pas du tout utilisé pour Mobilizon, Mastodon, etc. On parle seulement d’instances.

C’est difficile en web sémantique pur car les URL sont les identifiants. On pourrait mettre des redirections HTTP mais il y aura sans doute des problèmes de bord. C’est ce problème que cherche à adresser le projet DREAM, en utilisant notamment des hash (type IPFS) plutôt que des URI (@niko.plp me corrigera si je me trompe).

La vision de @guillaume.rouyer me semble plus réalisable:

Concernant le fait qu’on ne peut pas bouger des données avec des URL, il y aurait quand même une solution, qui pourrait s’appliquer aux PODs: permettre aux utilisateurs d’utiliser leur propre nom de domaine (ou sous-domaine) pour leur POD, ce qui leur permettrait de changer de POD provider en changeant l’IP liée au nom de domaine. On pourrait même proposer un service de type dyndns pour faciliter ce type de « déménagement ».

2 « J'aime »
6

Concernant les « POD », c’est certainement un abu de langage, mais dans le monde du « décentralisé », j’ai souvent entendu parler de POD pour dire en effet « instance » pour une communauté = installation du logiciel sur un serveur…
Par exemple ici pour Diaspora : Mr Mondialisation sur Diaspora*

Pour le reste, il faut que je prenne le temps de comprendre… :slight_smile:

https://fairsocialnet.ch/

image
image1135×384 102 KB

https://framablog.org/2017/04/12/plus-de-chatons-plus-de-confiance-en-mastodon/

image
image797×146 23.8 KB

Pour peertube aussi…

image

1 « J'aime »
7

Ah je savais pas qu’ils utilisaient le même terme. Je pensais que Solid l’avait inventé, mais peut-être qu’ils l’ont juste … volé :stuck_out_tongue_winking_eye:

Cela dit je pense que ce serait bien, dans le cadre de nos échanges, de limiter POD à la vision de Solid. Cela me semble plus proche de la réalité. Car le fonctionnement en fédéré type diaspora ou Mobilizon, ça reste quand même très loin d’un « personal online datastore ».

1 « J'aime »
8

Je confirme que ce dont les « COD » que nous promettons aux clients de Data Players et que une contribution de DP à L’AV en cours.

1 « J'aime »
9

Que pensez-vous de ce schéma ?

10

Je comprends pas trop à ce stade, mais apparemment tu es encore en train d’y toucher (petit ajout, je suis daltonien :slight_smile: )

11

Pour nous aider à trouver un consensus, voici d’autres schémas / articles sur la décentralisation :
https://web.itu.edu.tr/~yucesoyb/Centralized-decentralized-distributed.html

image

1 « J'aime »
12

sur les schéma du figma le le décentralisé, tu à relié les différents cluster. Dans le paradigme semapps ce n’est pas le cas. Si on arrive à relier deux cluster par seulement 1 point c’est qu’on peut déjà faire du distribué.

1 « J'aime »
13

Je ne comprends pas ton retour, car en mode « décentralisé », je n’ai rien relié, les deux serveurs sont « isolés » comme dit Pierre, et c’est ce qui m’embête aussi. Mais je voulais quand même différencier les logiciels « propriétaires » comme FB des logiciels « libre et open-source » avec lesquels ont peut reprendre le code pour l’installer sur plusieurs instances… Dans ce cas, je n’utilise peut-être pas les bons mots… Et a-t-on besoin de le spécifier ?.. Personnellement, j’aimerais qu’il y ait tout dans les schémas…

Suite à notre discussion avec Pierre ou celle de la réunion d’hier soir, je retiens :

  • qu’il ne faut pas confondre un « mode d’organisation de pouvoir » décentralisé avec un "mode de gestion de données décentralisées (ou distribuées). Il faudrait peut-être donc mieux préciser les choses. Disons qu’à gauche, les dessins en noir & blancs ajoutés expliquent la notion de « pouvoir » décentralisé, alors que dans Semapps, j’indique juste où sont les données et quelles données pointent sur quelle donnée. Je ne devrais même pas appeler ça « décentralisé », mais juste « installation sur deux serveurs différents ».
  • je vais aussi ajouter un schéma pour parler de « qui rempli le semapps », pour aller d’un remplissage par des robots ou depuis un sondage, au remplissage « distribué » par chaque utilisateur, afin que chacun maitrise la mise à jour de ses données.
  • J’ai retiré les notions de « N » ou « … » avec mes ronds ou carrés gris qui n’était pas une notion simple à transmettre, et compliquait la compréhension (désolé de ne pas avoir gardé l’ancienne version pour les nouveaux…).
  • Le fait d’utiliser 3 types d’objets ne collent pas non plus à la réalité, ce qui peut aussi perdre le lecteur par rapport à un serveur Semapps, mais je ne vois pas comment simplifier les choses autrement.
  • Je vais à présent « versionner » les schémas pour ne pas perdre l’évolution… et le compléter avec des données réelles pour un projet.

Merci en tous cas de vos retours.

1 « J'aime »
14

Si tu regardes l’image que tu as posté pour le mode « décentralisé », il y a deux serveurs qui sont reliés entre eux. C’est typiquement le mode utilisé par Mastodon, Mobilizon, etc, qui utilisent ActivityPub pour communiquer entre eux. On peut parler aussi de fonctionnement « fédéré ».

Si les serveurs n’étaient pas reliés entre eux en mode « décentralisé », ce serait exactement la même chose qu’un système centralisé (chaque serveur est un silo).

1 « J'aime »
15

Ah oui, vous parlez de l’image à gauche… OK
En effet, jusqu’à présent, je « rangeais » Mastodon, Peertube, Mobilizon… comme des logiciels décentralisés, et non distribués.
Mais là, pour être plus précis, je refais mes schémas en parlant de « pouvoir », d’hébergement, de chargement des données… Comme ça, on saura de quoi on parle à chaque fois.

16

Je parle de l’image au centre, « Decentralized system »

C’est exactement ça. Ce sont des logiciels décentralisés, non distribués.

17

Voilà, j’ai fait une v0.2 plus abouties et plus précise, merci de me donner votre avis.

Je la présenterai vendredi midi aux membres du projet Glocal.

image
image589×538 80.2 KB

1 « J'aime »
18

hey ! J’ai lu rapidement cette discussion très intéressante !
La v2 du schéma semble pas mal du tout !
Merci pour ce travail et cette réflexion collective !!
J’espère que ca s’est bien passé avec Glocal !

19

Merci, oui, super, c’était trop court, on a tant de choses à dire… :slight_smile:
J’ai hate d’avoir cette réunion avec le low-tech lab le 30/11.

20

Suite à la discussion avec Simon (merci à lui), j’ai ajouté des cas à droite, car en effet, même en hébergement centralisé et dé-centralisé, l’utilisateur peut effectuer la saisie de ses données.

image
image709×470 82.8 KB