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-json
anddag-pb
formats.
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/