Avec IPFS je ne sais pas comment contrôler finement les entrées que je stocke et celles que je relaie. Je n’ai pas trouvé de doc précise sur les formats de données donc pas moyen de vérifier des hashes par exemple. Et à chaque fois qu’on se pose une question, la réponse est que c’est magique.
Les explications sur le site de Veilid sont très claires et aucune magie noire bullshittique n’est invoquée. Pour moi c’est bon signe.
Par contre je ne sais pas si ça nous conviendrait, ni si il vaut mieux utiliser un réseau public, privé, voire uniquement la couche réseau et le coupler fortement à la blockchain. L’avantage est qu’il n’y a pas à recoder une DHT, et qu’on a l’anonymat des clients et une certaine interopérabilité.
Ce n’est pas magique, IPFS s’occupe de conserver un essaim p2p synchronié en utilisant le protocole DHT de emule, puis le mode “torrent” à la demande. A cela s’ajoute l’usage de la libp2p (avec “firewall punching”)
On peut y écrire au format “bor json” dans des “dag” (merkel tree)
Mais aucun format de donnée n’est imposé, on peut même y stocker l’arborescence de fichiers. Ajouter une application revient à ajouter un simple “index.html”
S’agissant de données “en clair” l’ensemble du réseau peut accéder au hash ajoutés. On peut en accélérer le relai (avec le protocole Scuttlebutt) en forçant les demande de réplication. Ensuite, il s’agit de chiffrer les données convenablement pour en contrôler “la visibilité”. Protocoles et clefs de chiffrement. Rien de magique.
La difficulté avec IPFS est la séparation de la DHT réseau avec la DHT navigateur, utiliser “webrtc-star” permet de s’en affranchir.
Je recommande la lecture de ce fil. Il est intéressant et on retombe sur les mêmes problématiques aujourd’hui. Je pense que la solution de merkle root est applicable hors chaîne, il pourrait juste exister plusieurs merkle root simultanés. Et l’avantage d’un tel système (par exemple sur ipfs) est qu’il serait totalement indépendant de la Ğ1, ce qui est à mon avis un avantage.
Réponse avec deux ans de retard
Il me semble que ce critère est non souhaitable. Au contraire, pour ce qui est des données, il faut tolérer plusieurs visions.
Il faut donc un critère qui fait consensus et qui peut être opéré sur la donnée, ça me semble également non souhaitable.
Ça aussi ça me semble illusoire. Le réseau est évolutif, la découverte réseau est essentielle à la décentralisation. De plus IPFS répond à cette question, on n’a pas besoin de réinventer une solution (ni les ressources pour le faire, soit dit en passant).
Dans cette section il me semble que tu réinventes des solutions déjà apportées par Filecoin. On peut faire du stockage de données un marché, mais je préfère en faire un commun non marchand.
Et moi j’ai mis du temps, mais je suis convaincu qu’il nous faut un système de stockage réellement décentralisé qui ne se base pas sur une blockchain ou quoi que ce soit de centralisé. Ça me semble idiot d’essayer de créer un consensus là où non seulement il n’y en a pas besoin, mais en plus il n’est pas désirable.
Non, le besoin de simplicité implique juste qu’il y ait une forme d’accord (mais pas nécessairement un consensus) entre les nœuds de bootstrap préconfigurés dans les clients et la donnée servie. Mais plusieurs clients pourraient vouloir servir des données différentes pour des raisons tout à fait valable. Le consensus se fera uniquement sur un sous-ensemble des données, mais pas leur intégralité.