En tout cas moi je serai présent qu’a 21h 
ok pour 21h aussi
1 Like
Je serai un peu en retard, le temps de finir de faire manger tout mon petit monde
A toute !
1 Like
Ping @tuxmain, @Luke, @gerard94, @matograine, @ji_emme, @AliHalo et tous ceux qui veulent. Réunion à 21h00 !
Publication du CR de réunion, pour que le lien ne soit pas perdu :
https://pad.p2p.legal/MOuH81opROiLAf-8hbzfwg?both
3 Likes
Le CR indique :
Kimamila demande l’ajout à BMA d’un champ pour savoir à quel timestamp les tx ont été:
- reçues en mempool si non encore inscrites
- inscrites en BC
Après vérification dans le code, il existe déjà un champ dans BMA qui indique le timestamp d’inscription en blockchain: c’est le champ "time". En revanche, ce champ vaut null pour les transactions en attentes. J’ai travaillé ce WE sur la valorisation de ce champ au timestamp de réception du document dans le cas des transactions en attente, j’ai pu tester aujourd’hui et ça semble fonctionner 
J’en ai profité pour exposer également cette information côté GVA : Prototype de GVA - #133 by elois
4 Likes
heu non 
@kimamila @vit @Moul @poka @bpresles @HugoTrentesaux @tuxmain @gerard94 @llaq @foopgp @devingfx et tous les contributeurs techniques qui le souhaitent:
J’aimerais qu’on reprenne des visios régulières (au moins 1 fois par mois), pour parler de la migration de la Ğ1 sur substrate et des nombreux choix que ça va impliquer. Je ne suis dispo que les week-ends (et vendredi soir), donc j’ai créé un sondage de dates en conséquence:
https://framadate.org/kVTgKY8K5LipZVD3
J’aimerais que participe également à ces visios des gens qui ne viennent plus sur ce forum, comme Boris ou Jbar, j’ai plus le temps d’aller sur plusieurs espaces différents pour travailler avec les uns et les autres.
7 Likes
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 ?