L'autre jour, je suis tombé sur un projet de navigateur P2P (beakerbrowser). Personne n'en à parler ici pour le moment (d'après mes recherches). Alors j'ai décidé de partager.
Le navigateur permet de consulter des sites en http/https et aussi des sites basés sur le protocole Dat (qui lui est P2P et chiffré).
L'avantage promis pas le créateur du projet et qu'au plus un site a de succès, au plus il est seeder de la même manière qu'avec bitorrent. Aussi… Et ça j'aimerai bien avoir confirmation… Du moment que l'on visite un site on devient seeder sans rien avoir à configurer niveau firewall/redirection de port
Si j'ai compris c'est basé sur electron, il s'agirait donc de chromium avec en ajout le support du P2P.
Le projet va un peu plus loin que ça en proposant de publier sont site depuis le navigateur et aussi édité puis re-publier la nouvelle version.
Un peu comme git, il y a de la gestion de version directement au sein du protocol P2P si j'ai bien compris.
Il y a aussi des CLI et api pour créer/lire/editer un site au format Dat.
J'ai testé très rapidement le navigateur. Ça à l'air de marché correctement. Je me demande si je suis bien seeder à partir du moment où je visite un site.
Le créateur du projet parle de pouvoir facilement créer et héberger un site comme twiter. Mais c'est des sites entierment statique dont on parle ici (avec du versioning). Et donc je ne vois rien qui permettrai de supporter des requêtes utilisateurs pour ensuite re-générer un nouvelle version du site uniquement avec le protocol Dat. Je pense qu'il faut créer service classique pour ça (http api ou autre).
M'empêche que c'est intéressant pour créer un blog, portfolio, SPA ou tout autre projet statique (et on peut faire beaucoup avec ça aujourd'hui).
Je trouve l'idée bonne et noble mais je pense que ça sera un flop. Car comme d'habitude il n'y aura pas de contenu exclusifs sur le réseau P2P (car nous publions sur le web pour plus de visibilité…) et parce que les utilisateurs préféreront utiliser se qui sera le plus rapide.
Par contre, je pense que nous autres techniciens, nous pourrions utiliser un tel projet (couplé a un server classique http) pour publier tout en proposant aux visiteurs la version P2P alternative. Cela expliquant au lecteur que ça diminue les frais de bande passante. Un peu comme le font les distro qui proposent de télécharger avec Bittorrent et http/ftp.
# Au sujet de l'adoption
Posté par freem . Évalué à 1.
Ce ne sera sûrement pas utilisé par les masses, quand on voit le temps qu'il a fallu pour que windows XP ne soit plus utilisé en majorité (même sans MàJ de sécu…).
Ceci dit, ce genre de technologies n'est pas dénuées d'intérêt, tant qu'il est possible d'identifier que les modifications sont bien l'oeuvre de l'auteur originel ou validées par lui.
De nos jours, on se base surtout sur le DNS (et ses failles) ainsi que les certificats SSL (la fameuse chaîne de confiance, dans laquelle un seul élément véreux peux corrompre une arborescence longue comme le bras…). Sur quoi se baseraient ces versions de site statique pour identifier la branche fiable?
Vu que c'est dans l'ère du temps, une blockchain peut-être?
[^] # Re: Au sujet de l'adoption
Posté par arnodevo . Évalué à 1.
c'est sans blockchain. Je pense que c'est simplement basé sur la cryptographie/signature pour prouver qu'on est bien l'auteur.
[^] # Re: Au sujet de l'adoption
Posté par FDF (site web personnel) . Évalué à 3.
Sur la philosophie, rien à redire, c'est le principe d'internet, décentralisé… Donc bien sur que c'est le bienvenu.
Sur l'adoption, il y a les freins des utilisateurs, mais aussi ceux des centralisateurs (GAFA et autres). Eux veulent au contraire que Internet soit centralisé chez eux, et ils mettront en oeuvre des solutions pour qu'un outil potentiellement dangereux comme celui-ci ne puisse pas décoller en utilisant leur position dominante. C'est bien eux qui ont poussés pour les DRM dans les règles du W3… Il n'y a pas de raison qu'ils n'agissent pas si un tel outil commençait à faire vraiment parler de lui.
Mais, la réussite du libre montre qu'avec le temps de bonnes idées rentre. Prenons 15 ans en arrière, le libre en entreprise c'était presque impossible, c'est une évidence aujourd'hui.
Je ne me prononcerai donc pas à long terme.
[^] # Re: Au sujet de l'adoption
Posté par Marco . Évalué à 1.
Je te trouve bien optimiste, aujourd'hui l'évidence pour une boîte c'est qu'il ne faut pas réinventer la roue : si une bibliothèque non contaminante existe ne pas hésitez à s'en servir. Et même si elle est contaminante, comment les détenteurs des droits peuvent prouver que la société a utilisé une bibliothèque GPL ?
C'est loin d'être une évidence : je n'ai toujours pas accès au code source de certains logiciels que j'utilise : windows/microsoft office (au taf), eagle, jeux vidéos, les logiciels embarqués dans ma voiture et je n'ai toujours aucune idée du code source de l'algo de google.
[^] # Re: Au sujet de l'adoption
Posté par nico4nicolas . Évalué à 1.
Ce n'est pas le sujet présenté ici mais je me pose la question de ces logiciels embarqués dans la voiture pour l'ordinateur de bord "infodivertissement" (GPS, radio, bluetooth…). Il me semble que ces logiciels sont basés sur un coeur Linux, n'est-il pas question de la fourniture du source dans ces cas ? Ou est-ce que ces logiciels tournent sur un coeur propriétaire ?
[^] # Re: Au sujet de l'adoption
Posté par Renault (site web personnel) . Évalué à 5.
Ça dépend des modèles.
Et ce n'est pas parce que le noyau et certains composants de base sont libres que l'interface utilisateur doit l'être. Et la fourniture des sources n'est exigible que si un client le réclame, dans le cadre d'un licence type GPL (pour les trucs sous BSD tu peux te brosser).
Après des constructeurs jouent le jeu, mon Opel Corsa a un menu dédié pour lister les composants libres employés et la licence qui va avec.
[^] # Re: Au sujet de l'adoption
Posté par nico4nicolas . Évalué à 1.
Merci pour ce début de réponse. Bien évidemment que l'interface n'a pas à être libre mais un Linux sans outil GNU, je ne connais pas. J'essaye infructueusement de faire l'analogie avec les "box" Internet avec des enjeux financiers et sécuritaires qui me semblent encore plus importants.
[^] # Re: Au sujet de l'adoption
Posté par Renault (site web personnel) . Évalué à 4.
Mais ça existe, les systèmes embarqués sont peut être l'endroit où tu as la plus grande probabilité d'entrer dans ce cas de figure. Même si ce n'est pas la situation la plus courante.
Il ne faut pas se voiler la face, la plupart des appareils avec un Linux embarqué ont le bas niveau en GPL certes, mais en dehors du noyau c'est rarement modifié en interne. La plu valu de l'appareil se situe dans les couches plus hautes, là où le code source peut être proprio.
Car bon, que Opel par exemple soit obligé de me donner le code source de la glibc de la voiture, dans 99% des cas ce n'est pas intéressant car en allant sur gnu.org je pourrais télécharger le code source moi même que ce serait pareil (en plus rapide). Le noyau est probablement le seul composant intéressant à récupérer systématiquement sur chaque périphérique dont c'est obligatoire de le faire si l'utilisateur le demande.
[^] # Re: Au sujet de l'adoption
Posté par freem . Évalué à 2.
Compte tenu que la distribution VoidLinux n'utilise pas que la libc, mais aussi musl, peut-on considérer le build musl comme sans GNU? Remplacer bash par dash (ou zsh) est quelque chose que bien des distribs ont déjà fait pour le coeur des systèmes (problèmes de performances, je crois), pour gawk il y a awk et mawk, perl c'est pas gnu, sed et grep, p'tet? Mais on dois pouvoir porter ceux des *BSD de toute façon…
Bref, je ne crois pas que nos jours le GNU/Linux soit réellement pertinent. Sinon, y'a-t-il un GNU dans l'androïde? Je n'en suis pas si sûr.
Dans le cas des box, ce n'étais pas un problème de GNU, mais un problème de GPL tout court me semble. Je crois que les licences et les composants n'étaient pas cités, ce qui enfreignait des licences, justement.
[^] # Re: Au sujet de l'adoption
Posté par Renault (site web personnel) . Évalué à 4.
Non, la défense de Free sur la question était que les box appartenaient à Free et non au client, ce dernier bénéficiant d'une location de la box durant le contrat.
Du coup, selon ce principe, le code en GPL n'a pas à être divulgué car c'est considéré comme interne à l'entreprise. Ce qui en soit peut être valable.
Le soucis est que la FSF a préféré un règlement à l'amiable avec accord de confidentialité avec Free et du coup nous ne savons pas juridiquement qui avait raison dans l'histoire.
[^] # Re: Au sujet de l'adoption
Posté par jerX . Évalué à 1.
Ou alors ils se diront qu'ils pourraient faire pas mal d'économies en externalisant la bande passante gratuitement..
[^] # Re: Au sujet de l'adoption
Posté par arnodevo . Évalué à 1. Dernière modification le 27 mars 2018 à 12:40.
Oui c'est l'argument de poids de ce projet je trouve. Encore faut-il qu'il y ai un nombre suffisant d'utilisateurs du navigateur pour pouvoir justifier 1h de travail à configurer/installer un serveur Dat en plus du serveur HTTP.
Par contre on pourrait le faire systématiquement sur nos projet perso et mettre un lien "site disponible en P2P à l'URL: dat:/xxx" avec un lien vers le navigateur.
Si le protocole était supporté par un des principaux navigateurs c'est un no-brainer de servir le site en dat
# lapin compris
Posté par dinomasque . Évalué à 5.
Existe-t-il une version en français de ce journal ?
BeOS le faisait il y a 20 ans !
[^] # non peut-être...
Posté par arnodevo . Évalué à -1.
Je l'ai écris dans ma langue perso. Mais tu peux fork le post, le traduire dans ta langue perso à toi aussi et puis faire une pull request
[^] # Re: non peut-être...
Posté par cacatoès . Évalué à 2.
Pour info, c'est à peu près ce que j'ai fait ici : https://wiki.p2pfr.com/p2p/dat
Je ne dis pas que c'est beaucoup mieux, j'ai aussi tendance à me mélanger les fils lors de la rédaction de ce genre d'articles ;)
Merci pour le partage car je ne connaissais pas ces projets.
[^] # Re: non peut-être...
Posté par arnodevo . Évalué à 1.
Chouette le wiki! Je suis bien d'accord avec toi le projet à une bonne doc et un site assez propre
# Dommage
Posté par voxdemonix . Évalué à 1. Dernière modification le 27 mars 2018 à 12:57.
Dommage de ne pas avoir vraiment testé.
Ça aurait été appréciable de tester avec l'installation d'un CMS, voir comment réagissent les scripts php (par exemple afficher l'heure qui va changer a chaque actualisation, observer la réaction des variables $_SERVER) le comportement des requêtes get en javascript, tester de wget|curl une page du site, etc), nous expliquer quel type de serveur tourne derrière (est-ce un démon dédié comme Freenet ou on peut choir entre apache2, nginx et co?).
Le mode P2P est-il désactivable (afin d'accéder aux données sur mobiles sans faire pèter la 4G et la batterie par exemple)?
Si non l'idée est intéressante, ça pourrait être pas mal pour diminuer la charge de bande passante pour les auto-hébergés.
[^] # Re: Dommage
Posté par arnodevo . Évalué à 1.
C'est pour servir du statique. Donc on peut oublier la génération de page html sur requête HTTP. Par contre il est possible de créer une web API (pas P2P donc) qui elle prend en compte les requêtes utilisateurs et qui va générer puis publier un nouvelle version du site Dat par exemple (Il y a une CLI et une Api pour ça).
Par exemple pour chaque commentaire reçu sur mon blog statique mon api va générer une nouvelle version du site qui cette fois contient le commentaire.
1) Utilisateur visite le site en Dat,
2) Via javascript ajout d'un commentaire en envois requête post sur Api http
3) l'Api génère et publie la nouvelle version du site comprenant le commentaire en Dat
5) le client est informé qu'il y a une nouvelle version du site via le protocole Dat et recharge le site
Je ne sais pas si le mode P2P est désactivable par contre on peut complètement charger le site et le visiter tout en étant déconnecter
[^] # Re: Dommage
Posté par voxdemonix . Évalué à 1.
Il n'y a pas non plus de possibilité d'utiliser des mécanismes de session si?
Merci pour tes réponses.
[^] # Re: Dommage
Posté par arnodevo . Évalué à 1.
je crois pas qu'il y ai de session non plus
# ZeroNet
Posté par alexis211 (site web personnel) . Évalué à 2.
Dans la même veine du web distribué il y a ZeroNet qui propose quelques solutions aux problèmes que tu as évoqué :
possibilité de contrôler ce que l'on seed : tu as une page d'accueil où sont listés tous les sites que tu héberges localement, tu peux facilement analyser la taille et le trafic de chacun
contenu dynamique : il y a un système pour permettre aux utilisateurs de publier un fichier de données sur le site, par exemple les commentaires d'un blog. Ces fichiers sont agrégés par le moteur ZeroNet et après tu as typiquement un code javascript qui génère dynamiquement les pages qui vont bien. Ça ne passe pas à l'échelle par contre car tout le monde stocke les contenus de tout le monde, donc sur un gros forum ou un outil collaboratif comme Wikipédia ça ne pourrait pas fonctionner.
Par contre je crois qu'il n'y a pas de gestionnaire de versions type git.
Site Officiel
[^] # Re: ZeroNet
Posté par Larry Cow . Évalué à 3.
Il y'a un github-like dans ZeroNet, mais sinon en effet : ZeroNet ne versionne pas ses contenus (il suffit donc de publier une nouvelle version d'un contenu pour faire disparaître le précédent, sauf si quelqu'un archive dans son coin).
Sinon, en alternative à DAT (à se demander pourquoi Beaker ne le gère pas, d'ailleurs), il y'a IPFS.
[^] # Re: ZeroNet
Posté par arnodevo . Évalué à 1.
Bonne question pour IPFS un début de réponse dans la FAQ de Dat:
https://docs.datproject.org/faq#how-is-dat-different-than-ipfs
[^] # Re: ZeroNet
Posté par oinkoink_daotter . Évalué à 2.
Comment ces trucs gèrent ils le fait qu'un noeud qui sert du contenu peut être malveillant ? Genre j'héberge un site d'un tiers et je modifie les pages pour rajouter du javascript avec un mineur de cryptomonnaie pour payer mon électricité.
[^] # Re: ZeroNet
Posté par arnodevo . Évalué à 1.
par signature électronique j'imagine. je pense d’ailleurs que les urls correspondent à des clés publiques
[^] # Re: ZeroNet
Posté par oinkoink_daotter . Évalué à 2.
Dans ce cas, ça veut dire que pour un site dynamique, seul le noeud maître peut modifier les parties d'origines ?
[^] # Re: ZeroNet
Posté par abakkk . Évalué à 1.
Je confirme qu'il est tout à fait possible, en javascript et via des api, de faire du web dynamique en p2p avec zeronet.
En gros un utilisateur s'identifie grâce à un site tiers dédié (zeroId par exemple), se connecte sur le site concerné avec cette identification, et peut laisser des données dans un .json à lui sur le site. Lorsque le .json est modifié (ajout d'un commentaire dans un article par exemple), il est synchronisé sur toutes machines qui hébergent le site. L'administrateur peut filtrer et limiter la taille du .json pour éviter les actes de malveillance. En étant ingénieux et inventif, il y a beaucoup de possibilités.
D'ailleurs pour le moment zeronet est plus orienté réseaux sociaux que blogs statiques.
Les manques de zeronet sont :
- L'absence de vrai moteur de recherche
- la difficulté de trouver les premiers visiteurs indispensables pour héberger le site (un visiteur devient automatiquement seeder)
- L'inflation de l'espace disque au fur et à mesure des visites. Les principaux sites sont hébergés par 100% des utilisateurs
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.