Voici un projet très intéressant : IPFS, The permanent Web. Son ambition est de créer un nouveau protocole (comme HTTP) permettant de décentraliser l'hébergement de sites web (ou de n'importe quelle ressource statique). Ce protocole se base sur BitTorrent et Git (gestionnaire de version). Chaque ressource est identifiée par son hash (une empreinte unique), et les nœuds du réseau hébergent chacun des copies de certaines ressources, de manière décentralisée.
Cette infrastructure est une DHT. C'est une technique déjà utilisée dans les back office des applications web et dans les bases de données NOSQL. La nouveauté est d'en faire un protocole client et d'utiliser le réseau Torrent existant pour que ce réseau serve directement des contenus statiques, l'instar des CDN.
On obtient ainsi une infrastructure résiliente, hébergeant des resources versionnées. Il devient impossible de supprimer un contenu, à moins de faire tomber tous les nœuds qui en contiennent une copie.
Il existe déjà deux implémentations alpha, en Go et en Node.js hébergées sur GitHub. IPFS permet aussi de monter l'ensemble du réseau sur son système de fichier.
Une vidéo de démo assez impressionnante est disponible sur le net. Elle montre le démarrage d'un nœud du réseau, agissant comme passerelle HTTP, et permettant d'accéder aux ressources avec un navigateur web.
Aller plus loin
- IPFS.io (site officiel) (924 clics)
- Vidéo de démo (570 clics)
# Hem
Posté par macadoum . Évalué à -10.
C'est normal que les news ici se mettent à ressembler à du bullshit produit par clubic, pc inpact et autres merdiats numériques?
[^] # Re: Hem
Posté par ptit_poulet . Évalué à 10.
C'est normal que des gens comme toi venant de clubic ou autres postent ici ?
Merci de laisser ce magnifique site en paix et va jouer ailleurs ;)
(Désolé pour mon commentaire qui n'apporte rien à l'article initial… mais c'était plus fort que moi)
[^] # Re: Hem
Posté par Franck Routier (Mastodon) . Évalué à 8.
Si je peux me permettre, l'emploi des termes "révolutionnaire" et "résilient" dans le titre nuisent fortement à la crédibilité de la suite… je me suis même dit qu'il manquait Big Data, mais non, finalement, Big Data, c'est sooo 2014 :-)
[^] # Re: Hem
Posté par madhatter (site web personnel) . Évalué à 10.
Déjà, ça fait quelques mois que ce n'est plus PC Inpact, mais Next Inpact.
Et ensuite, en quoi ils produisent du bullshit ?
There is no spoon...
[^] # Re: Hem
Posté par CHP . Évalué à 4.
Ca c'est amélioré à ce point là, clubic ? Par exemple, dans ce journal, je vois des liens vers des sites externes…
[^] # Re: Hem
Posté par sparklyon . Évalué à -9.
Où est le problème ? Ce n'est pas interdit il me semble …
[^] # Re: Hem
Posté par CHP . Évalué à 9.
T'as pas compris.
C'est pas un problème : c'est meme plutot un point positif.
C'etait une petite pique envers les sites qui ont pour habitude de faire des articles qui sont vides en info, mais qui mettent un lien tous les 2 mots (lien qui mène vers un autre article du meme site, tout aussi vide en info, mais tout aussi truffé d'auto-liens) afin de faire croire qu'il y a du contenu, de la recherche et de faire croire que les affirmations sont sourcées.
[^] # Re: Hem
Posté par KiKouN . Évalué à 5.
T'as oublié les pubs.
[^] # Re: Hem
Posté par let antibarbie = xp <- xp - 1 . Évalué à -2.
[mauvaise foi certes..]
je pose la question, c'est quoi le bullshit ? ici on est sur linux fr.org…
[/mauvaise foi]
# javascript superstar
Posté par Anonyme . Évalué à 10.
Si je comprends tout bien, tel que cela est présenté, JavaScript est le seul langage de traitement de données possible puisque commun à tous les nœuds du réseau. Tout se fait en local, sauf si l'application utilise un lien vers avec un classique serveur HTTP.
Je me pose également la question de l'interfaçage d'une base de données qui sera, il me semble, forcément centralisée.
Est ce qu'on met en place un équivalent distribué de la base et de ses données, ou bien est ce qu'on va piocher dans une bonne vieille base centralisée ?
Pour ce qui est du protocole, le projet cherche-t-il vraiment à installer un remplaçant de HTTP, ou bien est-ce une surcouche, ou encore un complément qui pourrait être utilisé conjointement ?
La première impression que j'ai eu a été "tiens voilà Gopher le retour sauce 2015", mais j'ai peu connu la version original.
En tout cas, j'ai hâte de voir comment cela peut évoluer et surtout quelle stratégie va être mise en place pour diffuser et faciliter l'adoption d'un tel protocole.
[^] # Re: javascript superstar
Posté par Guigui . Évalué à 4.
Je pense plutôt qu'il s'agit d'un outil très similaire à darknet.
Aucun contenu dynamique (génération de pages HTML par un serveur) n'est possible sur ce genre de réseau.
Le JavaScript ne pourra sans doute être utilisé que dans le navigateur, pour agrémenter les pages.
[^] # Re: javascript superstar
Posté par maboiteaspam . Évalué à 2. Dernière modification le 25 février 2015 à 07:34.
/hs/
Javascript superstar, évidemment :D On peut tout faire avec celui ci. Il est multi plateforme, et simple à programmer mais n'en est pas moins puissant.
/hs/
Pour le reste de tes questions, pareil ici. Il faudra creuser pour en savoir plus.
[^] # Re: javascript superstar
Posté par totof2000 . Évalué à 2.
Pourquoi ?
[^] # Re: javascript superstar
Posté par Anonyme . Évalué à 3.
parce que je ne connais pas de base de données décentralisée sur le modèle bittorrent
[^] # Re: javascript superstar
Posté par ptit_poulet . Évalué à 1.
BangDB peut-être ?
[^] # Re: javascript superstar
Posté par neokod . Évalué à 1.
J'adore l'idée d'un site décentralisé, mais il faut parfois avoir recours à une base de données en effet, et même avec une base décentralisée telle que BangDB, comment pouvons nous s'assurer que seul notre site Internet puisse écrire dans cette base de données ?
À priori, un site décentralisé divulgue les sources à la vue de tous, donc également les identifiants / mot de passe pour accéder/modifier la DB.
[^] # Re: javascript superstar
Posté par Plume . Évalué à 2.
Tu devra être capable de signer/chiffrer/hacher tes données, non ?
[^] # Re: javascript superstar
Posté par neokod . Évalué à 5.
Malheureusement ça ne répondra pas à toutes les questions.
Imaginons la création d'un forum en site décentralisé. Partons du principe que l'on puisse déjà envoyer des mails en JavaScript ( via les API expérimentales RAW Socket / TCP Socket )
Roméo poste un message sur le forum, Juliette y répond, il faudrait que le site décentralisé envoie un email à Roméo pour le prévenir, mais pour cela, le site a besoin de lire en DB l'email de Roméo qui lui a été indiqué lors de son inscription.
Si on sauvegarde en clair les emails, n'importe qui pourra les extraire et spammer les gens.
Si on chiffre les emails avec une clef de chiffrage… celle-ci doit être dans le code quelque part… et vu que le JavaScript est un code interprété, il sera facile de la trouver pour déchiffrer tous les emails… et spammer les gens !
Autant pour le mot de passe de Roméo, on peut stocker en DB son mot de passe hashé ( MD5 / SHA1 … ) et comparer avec sa saisie hashée de la même manière, mais autant quand on a besoin de stocker une donnée en clair mais sans la laisser visible à tous… ça pose problème ….
Si quelqu'un a la solution, ça m'intéresse beaucoup !
[^] # Re: javascript superstar
Posté par rpnpif . Évalué à -2.
Un forum, c'est dynamique. On a dit statique seul.
[^] # Re: javascript superstar
Posté par neokod . Évalué à 4. Dernière modification le 25 février 2015 à 22:43.
Bien que ta remarque me semble un peu sèche et manquant de réflexion, je vais tenter de t'expliquer pourquoi selon moi tu as tord… tout en restant aimable :)
IPFS permet de transmettre des fichiers statiques, par exemple des fichiers HTML et JavaScript qui seront exécutés par le navigateur.
Il est donc tout à fait possible de développer un forum entier en JavaScript avec des appels AJAX / Raw Socket / WebSocket, en s'appuyant pour la partie DB sur une DB décentralisée comme le soulignait ptit_poulet dans cette discussion.
Néanmoins, la problématique que je soulevais dans mon précédent commentaire était de trouver un moyen ( s'il existe ) pour protéger certaines données aux yeux de tous puisque la DB et les sources sont visibles.
[^] # Re: javascript superstar
Posté par Mildred (site web personnel) . Évalué à 3.
En fait, cela revient, dans le cas du forum, au problème du spam. Il serait possible via IPFS de faire un forum ou tout autre type d'application similaire en ajoutant des éléments au graphe d'objets, mais sans moyen fiable de modération.
Après, on peut imaginer des mises a jour régulières de l'équipe de modération qui vont ajouter au forum, soit une liste blanche de sujets modérés et acceptés, soit une liste noire de sujets explicitement rejetés. Cela serait intéressant a faire d'ailleurs.
Alors, comment avec IPFS on peut ajouter des éléments au graphe d'objet ? Grâce a la partie IPNS qui permet de mettre a jour un noeud en conaissant sa clef privée (en signant le contenu du noeud). Si la clef privée est publique, chacun peut ajouter des éléments en plus au noeud.
IPNS prévoir des mécanismes supplémentaires pour valider un noeud signé. Comme par exemple, un noeud signé ne peut pas remplacer un autre noeud signé si il est plus vieux. Cette notion de plus récent étant extensible. Dans notre cas, on pourrait exiger que les nouveaux noeuds contiennent une référence vers les noeuds anciens. Ainsi on a une chaine de noeuds (comme des commits Git) et on a donc l'intégralité des versions (et donc des commentaires).
[^] # Re: javascript superstar
Posté par neokod . Évalué à 2.
Très intéressant, merci pour ces précisions Mildred !
J'avais en effet survolé la documentation et vu qu'il y avait un système de clef privée/publique pour les noeuds.
Je trouve le concept génial, penses-tu que cela pourrait fonctionner dans un réseau MESH, où les machines/téléphones seraient juste connecté entre eux via WiFi sans passer par Internet ? ( cf. la discussion "Solution ultime contre la censure ?" pour plus de détails ).
[^] # Re: javascript superstar
Posté par Mildred (site web personnel) . Évalué à 3.
Pas de raison que ça ne fonctionne pas sur un réseau mesh. C'est un protocole P2P classique qui a besoin de TCP/UDP et d'adresse IP routables. Si tu as ça, alors c'est bon.
Coté support IPv6, je ne sais pas trop où ça en est. A priori, c'est prévu que ce soit compatible, mais je ne sais pas si quelqu'un a testé. Après, je me disais qu IPFS pourrait très bien complémenter cjdns qui lui cherche a remplacer la couche IP pour faire justement un réseau maillé.
[^] # Re: javascript superstar
Posté par totof2000 . Évalué à 2.
L'occasion d'en inventer une ?
[^] # Re: javascript superstar
Posté par Mildred (site web personnel) . Évalué à 10.
IPFS, à la base, c'est un système de fichier unique sur Internet, dont chacun peut avoir un petit bout. Ce système de fichiers peut être monté avec FUSE ou encore visualisé avec un gateway HTTP. Après, cela rend possible plein d'applications possibles.
Le système fonctionne à l'aide d'un graphe acyclique direct, un peu comme Git, où chaque noeud est immuable et est identifié par son hash. Dans ce système de fichiers, on peut accéder aux noeuds comme ça :
Au niveau web, cela signifie que nous pouvons majoritairement créer des sites statiques. Pas de base de donnée ou d'exécution coté serveur, il n'y a pas de serveur. Si on veut du dynamisme, cela se passe coté client, en javascript (ou autre, on peut imaginer utiliser XSLT aussi).
Cela veut dire réorganiser un peu notre conception du Web, pour le meilleur je pense. Si on a besoin de faire une aplication, au lieu de mettre en place a la va vite un serveur HTTP, on va a la place réfléchir a un protocole spécialisé. Et pour les choses simples, rien n'empêche d'utiliser IPFS comme une base de donnée pour stocker des données applicatives. Les commentaires d'un billet de blog par exemple.
Je vous ai dit que IPFS était en lecture seule, c'est partiellement vrai. En fait, il existe une suite au protocole, nommée IPNS, qui permet de changer le contenu d'un noeud. En fait, l'identifiant du noeud sera non pas le hash du contenu, mais le hash de la clef publique qui a été utilisée pour signer le contenu. Le détenteur de la clef privée pouvant a n'importe quel moment récrire le noeud en le signant avec sa clef privée.
Cela nous fait des chemins de type /ipns/KEYHASH/lien/lien
Et un dernier petit bonus pour la route, c'est prévu (ou peut être déjà réalisé) d'utiliser un enregistrement TXT dans les DNS pour faire un lien vers un objet IPFS/IPNS. Comme ça, on pourra directement accéder aux noeuds en utilisant un chemin tel que /ipfs/DOMAIN_NAME/link au lieu de devoir obligatoirement spécifier un HASH.
Plus de détails par ici :
[^] # Re: javascript superstar
Posté par Larry Cow . Évalué à 2.
Ça ressemble beaucoup à un mélange de Tahoe-LAFS et Freenet, quand même, non?
# Huh ? Un nouveau protocole ?
Posté par maboiteaspam . Évalué à 4.
Super initiative. Qui n'est pas des plus simple à résoudre.
Ceci dit, mais je n'ai pas encore eu le temps de m'y plonger, pourquoi faire un nouveau protocole ?
Question subsidiaire sous le capot c'est toujours du tcp ou on switche sur un udp / utp / (y'en à troisimème mais j'ai oublié….) ?
En ce qui me concerne je n'ai pas encore dépassé ce problème de punch hole pour faire du tcp et je n'ai pas non plus d'implémentation d'http over udp… du coup je me demande !
[^] # Re: Huh ? Un nouveau protocole ?
Posté par Mildred (site web personnel) . Évalué à 5.
En fait, l'accès HTTP, c'est juste un gateway. D'un coté ça parle le protocole IPFS, de l'autre du HTTP.
Sinon, IPFS fonctionne a l'origine avec du tcp, mais il y a du travail de fait pour migrer vers de l'UDP, et intéger des techniques pour passer les NATs. C'est pas encore finalisé : https://github.com/jbenet/go-ipfs/issues/57
# Solution ultime contre la censure ?
Posté par neokod . Évalué à 3.
Je trouve l'idée très bonne, j'avais déjà vu des solutions allant dans ce sens ( Vole.cc, Syncthing/Pulse ) et celle-ci va encore une fois dans le bon sens.
Je pense que l'arme ultime pour que la population soit totalement libérée de la surveillance et de la censure, serait d'utiliser ce type d'outil mais SANS avoir besoin d'Internet, juste en étant inter-connecté avec les autres machines / téléphones mobiles du voisinage grâce au WiFi.
Un peu à la manière dont fonctionne FireChat, qui permet de chatter sans Internet, sur un réseau MESH de gens connectés les uns aux autres en WiFi/Bluetooth, chaque noeud aidant à faire transiter les messages vers d'autres personnes plus éloignées.
Le tout avec une bonne couche de chiffrage entre les noeuds.
Qu'en pensez-vous ?
[^] # Re: Solution ultime contre la censure ?
Posté par madhatter (site web personnel) . Évalué à 5.
Que bien que l'idée soit bonne, ça ne fonctionnerait que dans des zones suffisamment denses en population.
There is no spoon...
[^] # Re: Solution ultime contre la censure ?
Posté par neokod . Évalué à 1.
En effet, il serait difficile d'être inter-connectés pour certains qui sont éloignés physiquement des autres, néanmoins ça laisse malgré tout un énorme potentiel de liberté pour ceux habitant dans les villes denses.
Il serait techniquement impossible de censurer un contenu. Les communications fortement chiffrées pourraient être espionnées mais sans doute difficilement déchiffrables ( d'autant plus si les clefs sont uniques à chaque noeud et à durée déterminée ).
Quant à ceux ne pouvant vraiment pas y accéder, peut-être qu'un relais par Internet pourrait être mis en place, avec des serveurs dans un pays défendant la vie privée ( ex: Suisse ), le tout connecté en direct vers les adresses IP ( pour éviter la censure DNS ) mais cela n'empêchera pas l'État ou les FAI de bloquer tous les échanges avec ces adresses IPs.
Sans doute faudrait-il avoir en plus, des IPs miroirs où des partisans de la liberté re-dirigeraient le trafic de leur IPs non blacklistées vers les IPs des serveurs relais… à méditer :)
[^] # Re: Solution ultime contre la censure ?
Posté par Mildred (site web personnel) . Évalué à 5.
C'est une problématique un peu orthogonale a IPFS. Tu cherches peut être le protocole cjdns ?
En gros, ton IPv6, c'est la clef publique (littéralement, avec du ed25519, un algo indépendant de la NSA, une clef publique c'est 128bits, comme une IPv6). Tout est chiffré par couche, et le routage est assuré par une DHT.
[^] # Re: Solution ultime contre la censure ?
Posté par neokod . Évalué à 0.
Très intéressant également cjdns, merci pour l'information ! :-)
[^] # Re: Solution ultime contre la censure ?
Posté par Kerro . Évalué à 4.
J'imagine que chaque nœud fait transiter les informations via TCP ou UDP (peut-être pas pour le Bluetooth).
Donc c'est internet.
C'est juste qu'il y a une découverte « géographique » des nœuds.
[^] # Re: Solution ultime contre la censure ?
Posté par neokod . Évalué à 0.
À partir du moment où des machines sont connectées les unes aux autres, cela devient littéralement "un internet" parmi d'autres, mais j'ai mis un "I" majuscule pour bien parler de "l'Internet", celui de l'ICANN avec lequel on se relie par le biais de nos chers Fournisseurs d'Accès Internet et dépendant de certains protocoles tels que la gestion des DNS avec ses 13 serveurs racines…
Là, l'idée est juste des les inter-connecter, comme un réseau domestique, indépendant à toute organisation de régulation.
[^] # Re: Solution ultime contre la censure ?
Posté par DoubleNain . Évalué à 1.
Je pense que le PC de la mère Michu va encore davantage ramer si elle doit router des paquets à ses voisins, me trompe-je ? ;)
[^] # Re: Solution ultime contre la censure ?
Posté par neokod . Évalué à 1.
La liberté a parfois des inconvénients, néanmoins, une sorte de QoS pourrait être développée de sorte à trouver le meilleur équilibre entre le trafic qui le concerne et le trafic qui doit simplement être relayé.
À la manière d'ailleurs des FreeBox et BBox, qui permettent à des inconnus de se connecter sur votre box ADSL pour être connecté à Internet.
# similaire à Tahoe-LAFS
Posté par DoubleNain . Évalué à 1.
A première vue, la philosophie de la solution est similaire au projet Tahoe LAFS. Est-ce le cas ?
[^] # Re: similaire à Tahoe-LAFS
Posté par Mildred (site web personnel) . Évalué à 7.
Je connais mal Thoe LAFS, mais je crois que le but est de stocker des fichiers privés. Ici, le but est d'aggréger des fichiers publics. Et n'importe qui peut devenir miroir de n'importe quel resource publique.
Un peu a la manière de BitTorrent, plus un site web sur IPFS devient populaire, plus il est partagé par beaucoup de noeuds et plus il est rapide a charger. Aussi, tant qu'un noeud reste intéressé par un contenu, il ne disparaîtra pas du réseau.
C'est pour ça qu'on l'appelle le Web permanent.
[^] # Re: similaire à Tahoe-LAFS
Posté par Zorro (site web personnel) . Évalué à 1.
Moi, j'ai l'impression de voir un autre de ces projets à la Freenet ou i2p, qui promettent toujours monts et merveilles, mais qui restent toujours ultra-confidentiel des années après.
Remarquez, i2p, ça marche très bien, ceci dit.
# Hyperconvergence ?
Posté par Kwiknclean . Évalué à 1. Dernière modification le 27 février 2015 à 20:58.
La philosophie me fait un peu penser à cette "mode" , ou "évolution" qu'est l’hyper-convergence que l'on retrouve sur les machines virtuelles, le stockage et même le réseau avec des technos, comme Nutanix, SanSynphony ou VirtualSAN … (pour les propriétaires).
En gros de la dématérialisation sur N noeuds, la ressource est partout et nul part à la fois.
Ca me semble plutôt cool :)
# Marchera pas
Posté par geb . Évalué à 7.
Pour avoir un peu travaillé un peu sur le sujet, des projets qui font du buzz là dessus mais ne sortent rien de viable, il y en a tous les 3 mois. Et pour cause:
Ça ne marchera simplement pas, ou, dit autrement, ça ne passera pas à l'échelle, ce sera d'une lenteur abominable.
Une DHT (Distributed Hash Table), c'est simplement un gros tableau distribué avec des mécanismes de routage. Ça permet facilement d'indexer l'ensemble des contenus disponibles sur un réseau, mais les temps de réponse sont mauvais à grand échelle. De l'ordre de la minute [1]. Quand c'est pour trouver des peers pour télécharger un torrent de la taille d'un DVD sur TPB c'est pas si grave, quand c'est pour choper un .css de 2Ko un peu plus.
Une DHT c'est bien pour faire du cache avec un très bon taux de hit, mais pour du web, on s'intéressera sans doute un peu plus à avoir un cache très réactif, que prendre 5 minutes pour attendre la réponse qui dit "cette donnée n'est pas disponible en cache".
Et ça n'est pas le seul soucis dans leur modèle, dont il y a assez peu de docs d'ailleurs (par exemple, comment est gérée l'invalidation de cache, comment on déploie à l'échelle d'internet…)
[1] http://conferences.sigcomm.org/imc/2007/papers/imc150.pdf
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.