Résultat du sondage de date: la visio aura lieu vendredi à 21h 
Mince, pas dispo vendredi soir. Je lirais le compte-rendu… 
@kimamila @Moul @bpresles @HugoTrentesaux @tuxmain @gerard94 @llaq @foopgp @devingfx visio dans 15min ici: https://jitsi.hadoly.fr/duniter-synchro
Désormais tous les comptes-rendus sont dans un dépôt git :
Merci à @foopgp pour cette excellente initiative
3 Likes
L’enregistrement de la réunion :
5 Likes
Désolé de ne pas avoir été présent à la réunion. J’ai lu le compte-rendu et écouté la visio, merci @tuxmain pour l’hébergement de l’enregistrement.
J’ai mis les timestamps sous la vidéo et fait une MR pour le compte rendu.
Mon intérêt pour le projet Duniter a peut-être été moins visible ces derniers temps car j’ai passé beaucoup de temps à m’intéresser à la théorie des graphes et des applications pour la toile de confiance ğ1 (notebooks de vulgarisation en cours) pour préparer le terrain à des études visant l’assouplissement des règles et l’augmentation de la sécurité. Je réfléchis aussi à des algorithmes de recommandations pour expliquer les règles de la WoT et guider les gens pour la rejoindre.
J’ai par ailleurs avancé sur le projet d’indexation de données DataJune dans le but d’avoir des données concrètes et précises pré-calculées et plotées. Exemple :
J’ai une bonne nouvelle à vous annoncer : j’ai été pris pour un poste d’ingénieur de recherche au CESBIO à Toulouse, j’espère déménager fin septembre. Cela signifie que je pourrai plus facilement voir d’autres devs comme @poka et @elois en présentiel, ce qui est indispensable pour que je me concentre sur un sujet.
Pour la migration substrate, je veux bien travailler sur les serveurs d’indexation mais j’aurais besoin d’aide pour les choix techniques des crates principales à utiliser. @elois, je veux bien qu’on se voie à ce sujet fin septembre si tu es dispo.
8 Likes
Si j’ai toujours le même taff d’ici là je serais dispo que les samedi et dimanche 
Salut, désolé aussi de pas avoir été présent à la réunion, j’avais dit que j’y viendrais, mais le SARS-CoV-2 L452R aka variant Delta en à voulu autrement …
> 
> 
<> 
> 
> 
J’écoutes la visio et je note mes réaction/commentaires au fur et à mesure…
Environ 22min : IPFS et annuaire
Si si IPFS peut être utilisé comme une base de données avec IPLD. C’est d’ailleurs cette couche sur laquelle est implémenté la notion de FS. Je vais pas rentrer dans les détails içi mais n’importe quel graphe de données peut être écrite dans IPFS (c’est même très universel comme système avec les multihash, ils ont implémenter des données BTC, mais aussi ETH et même du git …).
Pour ce qui est de l’annuaire, et donc de l’indexation de données, je vais utiliser la notion de fichiers/dossier car ça marche aussi, et c’est plus facile à comprendre dans IPFS en tant de système de fichier…
Dans IPFS chaque chunk de données est identifié par un hash. Un groupe de données peut aussi avoir des liens de graph nommés, comme par exemple les enfants d’un dossier seront des fichier ou dossier, et les enfants d’un fichiers sont les chunk de données qui composent ce fichier.
On peux accéder à une donnée par son hash, ou bien par son chemin de graphe. Donc on peut accéder à GmSH7D6F76SDG5/sous-dossier/fichier1.mp3
Donc imaginons le partage d’une liste de vidéos, on aurait un dossier hash, contenant plusieurs sous-dossier, d’abord “liste_complete” contenant toutes les vidéos, nommées, mais aussi des dossiers avec ces mêmes vidéos indexées dans un autre ordre, par exemple par longueur, ou par résolution d’image, etc…
Un client peut récupérer la liste commpléte de nom/hash du dossier complet et proposer une recherche texte locale au client. Ou bien aussi proposer un tri par taille en allant chercher la liste du dossier rangé par taille, etc…
Içi il s’agissais d’un instantané de la liste de films et index, car le moindre changement dans les données provoquent la création d’un nouveau hash pour chaque dossiers.
C’est là qu’IPNS leur système de nom de domaine entre en jeu: IPNS lie un hash unique public à autre hash sous-jacent qui peut changer dans le temps. C’est à dire que les clients appellent toujours le même hash mais tombent sur les hash IPFS réels desdits dossiers qui changent dans le temps en fonction des indexations et autre ajout de vidéos…
Donc le client peut accéder à la liste complete à jour simplement en vérifiant si le hash à changé et en rechargeant ce nouveau hash de dossier.
C’est comme ça que marche le “dynamique” dans IPFS. C’est inversé, il y’a d’abords des données immuables, et ensuite une surcouche de mutable par dessus…
Notez que toute duplication de donnée est impossible dans IPFS par nature, c’est à dire si dans la liste de vidéos, la même vidéo (aux bits prêt) est à nouveau ajoutée sous un autre nom, seul le dossier changera de hash car il contient un élément de plus, mais qui est une sorte de lien symbolique vers des chunk déjà existants.
Dans le cas d’un annuaire, il peut y avoir un dossier plein de fiches JSON de profil, avec ou non des photos, un dossier avec des sous-dossiers de lieux geo, ou encore un dossier “membres” et un “pas/membre” ou que sais-je. C’est lors de l’écriture d’une nouvelle données, qu’il est aussi recalculé les différentes indexations publique et/ou les indexations locale qu’un client particulier doit opérer, propre à ses besoins locaux.
24min
Oui @poka exactement chaque client partagera son index, ou utilisera des index “well-know”, ceux-ci étant de données partagées sur le swarm IPFS…
25min
@elois si je ne m’abuse il me semble que le DHT IPFS est un Cadmelia !!
https://rustipfs.com/
Are we IPFS yet?
Basic rust ipld library supporting
dag-cbor,dag-jsonanddag-pbformats.
Donc y’a au moins la couche de données JSON… L’Elastic search de @kimamila pourrait écrire ses données dans IPFS et les partager, les clients peuvent “relire” une requête qui aurait déjà été faite (cache distribué)…
Ha! Tiens! Substrate + IPFS 
https://rs-ipfs.github.io/offchain-ipfs-manual/
2 Likes
Je veux bien participer à un PoC IPFS …
1 Like
Oui on se fera ça d’ici quelques semaines si d’autres pense que c’est pertinent, mais honnêtement si @elois par sur son stockage libre en DHT Kademlia (ah, emule, que de souvenirs …) avec libp2p, on aura pas besoin d’IPFS pour ce cas d’usage, donc pas prioritaire.
Il faudrait plutôt qu’on réfléchisse à comment indexer ces données, et je pense qu’il faut partir sur une lib Rust parmi celles qui existes.
ahaha j’adore comment se termine la vidéo de la réunion, avec la phrase de Jbar ahaha
1 Like
En pratique serait-il possible de faire une recherche full-text via IPFS, avec peu de mémoire, peu de stockage, un bas débit et une latence de quelques secondes maximum ? (un téléphone en 3G)
S’il faut télécharger tout l’index pour la moindre recherche ou si plein de hashes changent à chaque mise à jour c’est mort. (et il paraît qu’IPNS est très lent, ça a peut-être changé, ou alors en swarm privé c’est rapide ?)
Il y a des moteurs de recherche full-text qui peuvent utiliser des optimisations spécifiques au support de stockage, des caches, etc. est-ce qu’IPFS permettrait cela ?
Mmmm pas exactement, ça dépend de l’indexation. Si tu fait un dossier liste complète, mais que tu découpe en dossier disons de la 1ere lettre du hash (donc les sous dossier 1er niveau seront A, B, C, … Z) alors le client qui stock déjà l’ancienne liste de hash pourra mettre a jour seulement le dossier des F, et J par exemple sans recharger tout la luste mais que ce qui a changé.
C’est ensuite le client qui recherche dans sa base locale dans requêtes réseau une fois l’index a jour en local… (Juste les hash, dans forcément la donnée complète).
Concernant l’indexation des données, on a besoin d’une solution demandant le moins de dev spécifiques possibles tout en accordant les meilleures performances possibles. Pour ça il faut privilégier une solution faite pour substrate si ça existe.
Dans le cadre de mon boulot UNL j’ai assisté cette semaine à une présentation de Hydra par un de leurs développeurs. je croyais (a tort), que ça générai juste une API graphql en proxy de l’API rpc, mais en fait c’est bien plus que ça: Hydra inclus tout ce qu’il faut pour historiser et indexer toutes les données émises par la blockchain, et fourni en plus un moteur de recherche full-text. En gros l’équivalent de ce que font les nœuds Cs+ concernant l’indexation des données issues de la blockchain ! Et comme c’est fait pour substrate ça nous demandera moins de travail que d’autres solutions. Concernant les perf c’est du postgres caché par du redis, et leur architecture deux tiers permet de suivre la blockchain quoi qu’il arrive.
GitHub - Joystream/hydra: A Substrate query node framework
J’ai pu poser quelques questions au développeur en question, et j’ai récupéré son mail et son telegram. Hydra nous permettrais de gérer toute la partie indexation et historisation des données, avec recherche full-text incluse. Et comme c’est fait pour substrate ça nous demandera moins de travail que d’autres solutions. Concernant les perf c’est du postgres caché par du redis, donc ça dépote.
Deux inconvénients toutefois:
- L’api générée (graphql) permet que de lire des données, pas d’écrire. Donc si on utilise que ça les clients devraient taper quand même l’api rpc pour soumettre des extrinsics, mais on peut faire une fédération graphql pour gérer la partie mutation sur une autre brique technique, bref c’est pas bloquant.
- Pour le moment ça n’indexe que les blocs finalisés, donc on aurait pas les dernières minutes, mais ils ont pour projet de gérer le revert donc c’est juste une question de temps.
Bon ça ne répond qu’aux besoins liés aux données générées par la blockchain (besoin essentiel), pour ce qui est de gérer les données qui ne sont pas générées par la blockchain je suis encore en pleine réfléxion.
Une piste que je creuse est d’avoir les hashs des données en blockchain et les données elles-mêmes dans une DHT. Je ne sais par encore si le mieux est que chaque nœud de la DHT soit un nœud substrate lui-même (car substrate inclus déjà la dépendante pour ça), ou si un binaire à part serait mieux pour ça, afin de partir sur une architecture micro-services (avec un docker compose pour déployer tout ça comme si c’était un seul nœud).
Reste à savoir comment indexer, car si on a pas le hash il faut pouvoir chercher d’une façon ou d’une autre.
Pour les noms de profil en particulier j’ai pas envie qu’on reproduise la même erreur de les stocker en double sur deux couches différentes (Duniter / Cs+).
Une possibilité est de les passer dans les extrinsics pour qu’ils puissent être indexés par Hydra.
Ce qui est passé en paramètre d’un extrinsics ne se retrouve pas forcément dan le storage on-chain, c’est la logique codée dans le runtime qui le décide. En fait un nœud substrate stocke deux choses différentes:
- L’état on-chain (nommé on-chain storage dans la doc de substrate)
- Les blocs.
Ce qu’on passe en paramètre d’un extrinsic se retrouve dans de bloc, mais pas forcément dans l’état on-chain, or seul l’état on-chain doit être obligatoirement conservé par tous les nœuds substrates, les anciens blocs peuvent être oubliés (paramétrable par nœud).
3 Likes
Ah oui niveau perf ça dépote, déjà que mariadb + redis ça monte en charge de ouf, c’est ce que j’ai fait pour yggtorrent (top50 des sites francophones les plus visités les premiers mois), mais avec pgql les index sont bien mieux géré que MySQL donc aucun doute sur les perf de pgql + redis (voir sphinx en plus pour l’indexation, c’est ce que j’ai mis pour ygg, plus léger que ES il me semble, a voir).
Hello @devingfx, comme dis dans la visio, j’ai bien compris IPFS et IPNS (et IPLS), mais encore une fois il s’agit des performances correct, avec des recherche full text. Tous ceux qui pratiquent les BDD savent bien qu’on n’a jamais les perf en gérant un système de fichiers nous-même, simplement parcequ’il faut alors nécessairement implémenter un système d’indexation (des fichiers en plus, ou la donnée est dénormalisés) et cela reveitn au final à écrire un nouveau SGBD…
Prenons quelques chiffres :
- il existe actuellement 14 000 comptes ayant un profil Cesium+ (compte membre, secondaire, etc.).
- pour 3300 comptes actifs de co-créateur du DU, dans la TdC
- la limite théorique de la TdC est de 10 millions (de mémoire), disons la moitié en pratique (fourchette haute)
- en utilisant le même rapport
profils / compte membre = 4.42, on arrive à21,2 millionsde profils Cesium+
La question est donc : le client va t’il analyser 21.2 million de profil localement ? Sachant qu’une recherche peut porter sur le nom du profil, la position, ville, etc. soit autant d’indexes à initialiser et maintenir.
Franchement, je vois pas trop la faisabilité (et la scalabilité) d’une telle solution.
En résumé :
- IPFS = stockage != indexation
- client != moteur d’indexation
un Poc pourrait au mieux utiliser IPFS pour le stockage offchain, mais il faut une API performante quelque part, sur les noeuds.
Comme disait mon prof de math de prépa (en hurlant de sa grosse voix roque, style sergent chef de l’armée): Des questions ?! Pas de questions ?! Vu !!
1 Like
@elois, super pour Hydra.
ok, donc ca ne concernera pas les profils… mais au moins on pourra faire de beauc graphs, performants Sais tu si l’API gère des fonctions d’agrégat (SUM, AVG,COUNT, etc.) et de filtrage (time, attributs, etc.)
Ah cool. Cela permettrait donc de normaliser ces documents de profils, via les extrinsics, sans polluer l’état on-chain.
Par ailleurs, l’API d’envoi serait directement accessible comme pour les autres extrinsics.
On peut essayer d’aller dans ce sens ? Quels seraient les autres contraintes/danger d’une telle pratique ?
1 Like
Oui et oui, hydra respecte la norme opencrud: https://www.opencrud.org/ 
Hum pas tout le document de profil, je pensais uniquement au nom du profil pour pouvoir rechercher par nom via l’API GraphQL qu’on génererai via Hydra, car les blocs doivent tout de même être conservés par certains nœuds, pour archivage et pour permettre une full sync.
Aussi ça pose le problème du droit à l’oubli, une donnée passée dans un extrinsic est archivée et historisée (par Hydra + par les nœuds d’archive) et n’est pas supprimable, c’est pour ça que les extrinsics ne doivent pas contenir de données personnelles ou le strict minimum.
On pourrait partir sur les champs suivants en blockchain:
- Le Did: Hash unique et non modifiable (sert d’identifiant unique, peut être le hash de documents d’identités ou d’autre données). Stocké dans le storage on-chain pour assurer l’unicité.
- Le Nom du profil associé a cette identité (modifiable via extrinsic et pas stocké dans le storage on-chain).
- Hash des données du profil (modifiable via extrinsic et pas stocké dans le storage on-chain).
L’API GraphQL qu’on générerait via Hydra pourrait aussi exposer le nom de profil et le hash des données du profil, et permettre une recherche full-text par nom.
Il faudrait alors une seconde requête pour récupérer les données du profil dans la DHT (je ne sais pas encore via quelle API).
À noter que cela autoriserait plusieurs profils à avoir le même nom, pour les différencier il faudrait que les UX affichent le Did (avec éventuellement une identicon dérivée du Did).
Je pense qu’il ne faut pas se baser sur la clé publique maître de l’identité (ni sur aucune de ses sous-clés), car il me semble important qu’une identité puisse changer de clé publique maître (peut-être avec l’accord d’une partie de ses certificateurs pour éviter l’appropriation de l’identité par un hacker).
Tout ça n’est encore que réflexion suite à l’évolution de ma compréhension des besoins
1 Like
Coucou tout le monde 
J’espère que vous vacances se sont bien passé, moi ça va, ça fait du bien de prendre un peu de recule et bouger un peu
J’ai lancé le sondage pour Septembre, je n’ai proposé que des horaires pour ce weekend car c’est ce qui correspond aux disponibilités d’Elois: Sondage - Visio Ğ1 teck Septembre - Framadate
Le message principal de ce topic a été mis à jour.
J’invite tous les nouveaux contributeurs potentiels à y participer, comme @Pini , @Mickael et @G0blin
PS: Bien sûr pour ceux qui ne sont pas dispo le weekend on peut très bien faire d’autre visio sans elois en semaine hein, moi ça me va aussi
Manifestez vous si c’est votre cas.
4 Likes
Bon, Elois m’apprends qu’il ne sera pas dispo à la réunion de ce soir finalement.
Du coup, moi je suis ok pour la maintenir quand même pour se synchroniser entre nous. Elois sera plus dispo à partir de mi-octobre, avant ça va être compliqué pour lui.
Bon étant donnée que je me suis connecté que à 22h et que personne n’était là, on reporte cette synchro à plus tard.
Merci d’avoir prévenu Poka, je ne pouvais pas être dispo. Je n’ai pas répondu au sondage car je ne tiens pas à ce que la réunion se calle en fonction de moi vu que je souhaite avant tout observer, je tacherai d’être présent pour la prochaine, plus tôt elle est callée, mieux ce sera en ce qui me concerne. Y a le lien d’un CR quelque part ?
1 Like