Projet : du P2P dans une page web
J'ai beaucoup de convictions pour Internet. je considère la centralisation sur "Internet" comme uné énormité est un mauvais retour dans le lointain passé du 3515. Globalement, ce n'est pas mes machines à la maison et ma grande gueule qui va changer le monde. Comment faire avancer un peu plus le Schmilblick alors ?!
Depuis le début de la semaine je suis sur un projet qui vise à décentraliser le contenu d'un site internet. Dit comme ça, on s'imagine le mec qui va poser ces fichiers sur 50 serveurs HTTP différents et qui sera content de lui...bah vous n'avez presque pas tout à fait tort ! Ce que j'aimerais faire est simple à comprendre : à la place d'héberger un contenu potentiellement lourd sur mon serveur, je vais le proposer en torrent. Seulement, je ne veux pas un bête lien que l'utilisateur va ouvrir manuellement avec son client P2P favori. L'objectif est de coller une couche javascript dans la page qui va contacter le fameux client P2P et une fois le téléchargement terminé, affichera le contenu dans la page.
Voila un contenu HTML type avant :
<video src="torrent://tracker.du.torrent.com/fichier.ogv.torrent"></video>...et après :
<video src="file:///chemin/vers/fichier.ogv"></video>J'ai imaginé plusieurs méthodes et pour commencer (et prouver que ça peut fonctionner), je vais utiliser un daemon coté client (en plus du navigateur). Les websockets html5 auront la charge de communiquer avec celui-ci.
Je souhaite avoir un rendu fonctionnel et pouvoir utiliser des torrents dans une page (même si ce n'est pas pratique et rapide). Si une solution similaire est suivie et améliorer avec des gens 100 fois plus skillés que moi, alors monsieur Toutlemonde pourrait faire son Youtube dans sa grotte...euh garage...non : maison !
Cet article a été rédigé par Simon Vieille, développeur français animé par la culture du libre et du hacking.
Il intervient à Tinternet & Cie, une association d’éducation numérique populaire. Depuis septembre 2022, il est lead developer à Trinaps, un opérateur télécom local et indépendant.
t411-console : plugin Oh My Zsh
Un court article pour publier un plugin qui permet d'auto-compléter les commandes de t411-co…
T411 en console
Pour les addicts de t411, j'ai développé un outil en ligne de commande permettant d'accéder …
- Je serais toi, je jetterais un coup d'oeil à swift. Je me plante peut-être, mais je trouve que ça ressemble vraiment à ce que tu décris (à part que le transport est géré par un autre protocole que bittorrent). http://libswift.org/https://github.com/triblerteam/libswift.
- Super intéressant, je garde ça sous le coude, ça pourra m'aider ! Merci pour ces liens :)
- J'ai déjà testé ce logiciel, j'dois même avoir un article sur le dans ce blog. Mais même si je l'apprecie, le support n'est pas le même.
Je souhaite pouvoir placer une donnée disponible en torrent sur mon blog et que la charge d'upload soit répartie sur plusieurs peers. Effectivement j'ai donné comme exemple une vidéo mais on peut étendre ça à plein d'autres types de données (son, images, pdf, etc.). C'est un peu (beaucoup) ce que propose btappjs (http://btappjs.com/) sauf qu'il faut un soft indisponible sur Linux (Torque). Ça se modifie mais c'est dans le code du site....et si je ne veux ni uTorrent, ni Torque comme client, bah c'est mort.
- Quelque chose de similaire a déjà été tenté sous KDE, via un KIO slave (KIO est la VFS de KDE) qui fait appel à Ktorrent, permettant d'utiliser des liens magnet directement dans les pages Web (entre autres) :
http://kde-apps.org/content/show.php?content=136909
- Tu comptes te servir de l'ensemble du réseau bittorrent ou juste un tracker privé ? Parce que même si c'est juste expérimental pour le moment, sur un site web en prod confier des fichiers au réseau P2P ça peut poser des soucis de sécurité non ?
Et coté uplad des fichiers sur le réseau torrent, ça risque de compliqué leur gestion non ? Créer un .torrent etc.
tu y as déjà réfléchi ?
- J'imagine que l'idée c'est plus d'avoir un tracker privé en plus du serveur Web (même si ce n'est pas obligatoire c'est quand même mieux pour la décentralisation dont il est question) et entre mettre à disposition des fichier via HTTP ou via Torrent il n'y a pas de différence quand à la sensibilité des données. Le torrent intégré à la page permettrait simplement à un navigateur de récupérer le document en question via Torrent - donc potentiellement depuis plusieurs pairs - plutôt que via HTTP - c'est à dire uniquement depuis le serveur Web.
- Pour mes tests, j'ai un tracker privé mais tu pourras utiliser n'importe quel torrent associé à n'importe quel tracker.
Si par sécurité tu entends "zut, mon fichier est partout maintenant", confier un fichier en P2P n'est pas moins sécurisé qu'un fichier posé sur un serveur web classique : rien n'empêchera un utilisateur de mettre en P2P ce fichier. Du moment où une données est sur le web, cest foutue pour elle =D
Créer un tracker n'est pas compliqué. Créer un fichier torrent et l'accrocher à un tracker est aussi simple : http://wall.deblan.fr/x14b9/bash/1/ et XBT pour tracker par exemple.
- Pour la sécurité, je pense qu'il faut remettre les choses à leur place. Si on parle de faire des transactions sécurisées, alors un mode connecté et centralisé est peut être préférable.
L'idée c'est d'être capable de surfer avec les objets de bases que sont les liens http.
- Bonjour,
Comme dit plus haut, cette méthode a déjà été tenté par les gens de tribler sur wikipedia. Ils utilisent un service url2torrent et une detection de la présence ou non de l'extention en javascript, pour pouvoir afficher un lien qui marche que le visiteur est cette extention ou non.
Après, cela pose pleins de problèmes, certains sont évoqués ici, d'autres non:
- Utiliser un tracker ne rend pas le web moins centralisé. Ok le contenu est repliqué entre plusieurs clients, mais si le tracker tombe ... et bah ça fera comme napster !
- Évidement cela ne marchera pas avec les contenus un tant soit peu dynamique, et il faudra gérer leur invalidation pour ne pas remplir les disques dur des clients/peers de contenus anciens.
- Securité: qu'est ce qui empeche les peers de servir de faux contenus ? Les hash de bittorrent feront une partie du boulot, mais tu peux facilement bloquer les téléchargement (cela rejoin le point précédent, un contenu ancien mis à disposition avec la même URL n'aura pas le même hash).
- Déploiement: ton modèle repose sur une modification des clients et des serveurs/sites.
- Vitesse: Bittorrent est rapide, une fois la phase d'initialisation atteinte, pour des vidéos cela n'est pas trop problématique, pour des <img> un peu plus.
- Et enfin, privacy, tu veux broadcaster à tout le nainternet "et les mecs, qui a la bannière de youporn ?"
Bref, je ne dis pas que ça n'est pas interessant (je travail sur ce sujet depuis plusieurs mois), mais il y a du boulôt :)
- Tu peux avoir plusieurs trackers sur un torrent je crois ^^
Pour le reste, je souhaite rester à l'étape "ça fonctionne", après ce qu'on fait avec est un autre problème (moral, logique, etc.). C'est une preuve qui devrait être apportée.
- > Tu peux avoir plusieurs trackers sur un torrent je crois ^^
Ça reste une mauvaise réponse au problème AMHA. Plus tu augmentes le nombre de trackers plus tu augmente l'overhead, les problèmes de sécurité (quid d'un tacker malveillant ?) etc. Il y a moyen de faire sans tracker :)
> Pour le reste, je souhaite rester à l'étape "ça fonctionne", après ce qu'on fait avec est un autre problème
Et bien ça fonctionne: http://swarmplayer.p2p-next.org/ marche, ils ont en plus modifié un peu bittorent pour demander les chunks dans l'ordre (sinon pas pratique pour de la vidéo ... :) ) . Reste qu'à cause (notamment) des problèmes que j'ai évoqué, personne ne l'utilise...
- Il ne faut pas trouver de problèmes pour le moment bien que sur le fond tu soulèves de vrais questions :)
- IMO en permettant aux « petits » de mieux résister à la montée en charge pour les contenus statiques pourrait naturellement augmenter la décentralisation, puisque l'utilisation de services centralisés qui permettent de mutualiser les coûts deviendra moins nécessaire.
Pour la vitesse, j'imagine que le surplus de communications engendré par la communication avec les Peers est assez marginal et donc, lorsqu'il y a peu de demande, négligeable. En revanche lorsqu'il y a de la demande, l'intérêt du P2P prend tout son sens assez rapidement.
Par contre, les questions de vie privée et de la traçabilité des personnes posent de vrais problèmes. Mais plusieurs solution sont envisageables:
- trackers privés
- listes blanches et listes noires
L'authenticité des contenus est un autre problèmes, qui pourrait être résolu en signant les pages Web; on aurait ainsi - à mon avis - le même niveau de sécurité qu'en HTTP.
- Tu as aussi http://www.metalinker.org/ qui pourrait t'interesser :)
- Cela me fait énormément penser a http://fr.wikipedia.org/wiki/Freenet
- J'ai failli parlé de FreeNet hier :) En fait FreeNet n'est pas tout à fait pareil puisqu'il s'agit d'un "réseau décentralisé sur internet" qui rend disponible une "bande passante" et d'un "espace de stockage" communautaires, décentralisés, réparties, cryptés, etc. Plus tu as d'utilisateurs, plus le réseau dispose d'une bande passante importante et d'espace de stockage. L'utilisateur ne sait pas ce qu'il héberge car dès que ton "disque freenet" se connecte au réseau FreeNet, il commence déjà à recevoir des données (réception et stockage cryptés).
Bref, tu peux pas charger une page "freenet" sans être connecté au réseau freenet, alors que là la cible est d'utiliser les protocoles de transport standards.
- Vraiment, je trouve l'idée très intéressante!
Où en es-tu dans tes recherches?
Je pense que ce principe pourrait avoir beaucoup de succès, en particulier grâce au retour à la mode des sites "statiques" (hyde, jekykl, pelican). Pour s'autohéberger, le php/MySQL est lourd, tandis que ce principe d'internet via torrent simplifierait la vie de beaucoup de monde!
- Je n'ai pas encore achevé le travail, mais il est commencé et je pense que c'est encore jouable :)
- Et maintenant? (deux ans après en fait, que le temps passe vite!) :)
