En décembre dernier, nous avions pris en main un nouveau venu dans le domaine du stockage en ligne, hiveDrive. Le service fonctionne exclusivement en P2P, est chiffré de bout en bout et permet d’obtenir un espace équivalent à celui que l’on propose soi-même.
Il s’agissait alors d’un projet neuf et les limitations étaient nombreuses. La version 1.10, sortie la semaine dernière (une mise à jour par mois) apporte d’importantes améliorations, dont l’intégration complète dans l’Explorateur Windows, des téléversements trois fois plus rapides (ils étaient particulièrement lents), une taille maximale de 3 Go pour les fichiers et une plus grande fiabilité.
Signalons également que l’application peut enfin se mettre à jour seule et qu’une application Android est disponible. Celle pour iOS arrivera plus tard.
Le potentiel technique du projet étant intéressant, nous referons un point sur ses évolutions d’ici quelques mois.
Commentaires (42)
#1
Je pige pas trop l’utilité, c’est du stockage dans le cloud ? donc plutôt de la sauvegarde de fichiers perso, ou du partage ?
Ce n’est pas trop possible ça non ? il faut forcément une redondance des données, ainsi l’espace disponible et forcément moindre que celui qu’on propose ?
#1.1
Cas de base : une panne et tu perds tout.
Essaie de réfléchir au RAID5 ou RAIDZ0 :
Si tu as 1 disque de data, il te faut 50% d’espace perdu pour prévenir 1 panne
Si tu as 10 disques de data, il te faut 10% d’espace perdu pour prévenir 1 panne.
Bon, tu as 10x plus de proba de panne dans le 2e cas,
mais l’idée est d’éviter le cas de base;
après plus tu as de disques, plus tu as de granularité dans la redondance et comment l’organiser.
Donc prenons le cas de 10 personnes qui ont 1Go qu’on applique à Hive:
On a donc 10x1Go à stocker, et 10x1Go disponibles en partage. ce que tu présentes.
1 personne perd ses datas et demande la reconstitution.
En fait les 9 autres vont pouvoir le faire non pas en puisant exclusivement dans la partie partage, mais en faisant la parité entre la zone partagée qui contient un magma et leur zone de data.
La zone partagée ne serait que le disque de redondance qui contient l’ensemble des parités, pas la totalité des datas.
Après c’est un schéma grossier, tout est une question d’échelle, de nombre minimum disponible etc
#1.2
Sauf qu’avec du RAID, tous les disques sont en permanence disponibles.
Dans le cas de hiveDrive, ce n’est absolument pas de le cas, donc on ne peut pas comparer au RAID.
D’ailleurs, la description du lien en référence “Si un fichier est ainsi divisé en 50 morceaux, 100 sont répartis chez les autres. Tant que Hive dispose de 50 fractions sur les 100, le fichier peut être reconstitué.” est complètement fausse, car il faut 50 fractions qui couvrent l’intégralité du fichier, donc pas n’importe quelles fractions, ou alors la division couvre plus que le fichier initial. Donc pour 1 fichier de 1Go, il faut minimum 2Go d’espace partagé.
#1.3
J’ai eu un doute après avoir posté, du coup je l’ai installé pour tester…
Ça upload là, je reviens après test
#1.4
Effectivement ce n’est pas du dropbox like, c’est bien du stockage distant.
#2
Exact. Mais Hive est capable de :
déterminer si un contributeur (=stockage) est souvent/toujours allumés (NAS, Data Center…) ou intermittents (PC) => Les fractions qui assurent la complétude de la reconstruction sont réparties en priorité sur les contributeurs souvent/toujours allumés.
détecter la disparition longue/définitive d’un contributeur => les fractions disparues sont reconstruites à partir des autres fractions disponibles, puis sont réparties sur les contributeurs restants.
#2.1
Ca veut juste dire qu’il est probable qu’on arrive à reconstruire un fichier mis sur hiveDrive, mais ce n’est jamais une certitude. Pour une solution de backup, c’est juste inutilisable pour un utilisateur lambda, ou alors faut accepter une petite probabilité de perte définitive.
Par contre, ça peut être envisageable dans une entreprise qui dispose de beaucoup d’ordinateurs.
#3
La probabilité d’une perte définitive existe pour toutes les solutions de backup, d’où la stratégie 3-2-1.
Mais c’est vrai qu’avec Hive on peut difficilement évaluer le risque d’indisponibilité des données stockées sur le Cloud (le “1”). Sur ce point, Hive ressemble davantage à un pari sur la future popularité du service.
#4
Je n’ai pas l’impression que hiveDrive se présente comme une solution de sauvegarde de toute façon, ils peuvent donner des garanties sur la disponibilité de la donnée, éventuellement un historique de modification, mais ça n’en fait pas une vrai sauvegarde pour autant.
Tout comme le raid n’est pas une sauvegarde, ça peu éviter des problèmes, mais ne répond pas à des problématique de suppression ou de corruption de données.
hiveDrive, c’est une alternative aux autres drive type dropbox, one drive ou google drive avec un partis pris décentralisé et chiffré.
Le prestataire technique n’a non seulement pas la clé de déchiffrement, mais en plus n’a pas les données centralisée dans des datacenter.
Le modèle décentralisé P2P soulève beaucoup interrogations et de challenges technique, sans parler du modèle économique pour pérenniser le projet dans le temps.
#4.1
Dans ce cas, c’est quasi identique à ce que proposais le logiciel japonais WinNY il y a 20 ans (le chiffrement en plus histoire de ne partager qu’avec qui tu veux plutôt qu’avec le monde entier). Le problème, c’est que tu peux héberger du contenu pédoporno chez toi avec ce genre de truc.
https://fr.wikipedia.org/wiki/Winny
#5
C’est marrant, le service Hive me rappelle celui de LaCie et son service Wala à la fin des années 2000.
ça marchait bien mais je pense que la bande passante des gens avait été un frein à l’époque, d’où son abandon.
#5.1
Oui le service s’appelait wuala ( https://wuala.com/ ). Je l’avais utilisé et j’ai regretté sa disparition. De mémoire, je crois que l’espace disque était dépendant de la taille de disque que tu mettais a disposition et de ton taux disponibilité (temps ou le stockage était on-line).
#5.2
Ah ui Wuala, pas Wala ^^
ça fait un petit moment dans ma mémoire, le nom m’échappait.
#6
Avec quelques modifications, ça pourrait devenir un excellent système de partage p2p.
Le principe est connu : les espaces de stockages sont mis en communs, et tout le monde pourrait télécharger les fichiers de tout le monde sous forme de chunks chiffrés / encodés.
Dans ces cas-là, la redondance est la clé, vu que tout le monde n’est pas connecté en même temps au même moment.
Le système pour anonymiser les connections est aussi bien connu : chaque node (client connecté) devient un proxy / VPN chiffré pour les autres nodes. Pour pouvoir être téléchargé, un chunk doit passer au travers d’au moins deux autres nodes.
#7
Ça me fait l’impression qu’il y a des gens qui déploient une grande quantité d’éfforts pour ré-inventer une architecture de stockage qui n’est pas fiable et qui consomme plus d’énergie.
À rebours de ce qui est nécessaire.
Du simple fait de la nécessité de redondance des données, ce n’est pas possible d’assurer la disponibilité des fragments sans consommer sensiblement plus d’énergie qu’avec un système de stockage classique, surtout quand certains espaces de stockages peuvent être déconnectés sans prévenir.
Je ne vois qu’une seule direction d’amélioration qui puisse apporter des réponses à ces problèmes : utiliser en masse l’espace inutilisé sur les ordinateurs quand ils sont allumés. Cela revient à consommer une petite fraction supplémentaire d’une énergie déjà utilisée ; et peut permettre une redondance suffisamment forte pour permettre aux données d’être suffisamment disponibles.
Par contre, même comme ça, l’efficience énergétique n’y est pas, puisque les équipements informatiques domestiques consomment trop d’énergie par Go comparé aux centres de données…
Du coup, à quoi ça sert Hive ?
#8
Il y a des gens qui déploient beaucoup d’effort pour maximiser les revenus et minimiser les dépenses.
Le “Cloud” permet de garder les clients captifs (et accessoirement de collecter des data).
Le “P2P” permet de réduire les coûts internes.
Si tu proposes un Cloud en P2P, c’est le jackpot.
#9
Donc l’utilisateur fournit XYZ Go d’espace de stockage avec son matos à ses frais et sa connexion à ses frais, et en échange il obtient (XYZ moins redondance moins indisponibilités) Go d’espace en P2P chiffré et sans savoir ce que les autres stockent en chiffré sur son matos.
De mon point de vue, ça revient au même que de droguer une eMule au LSD pour partager des VHDX chiffrés sans avoir la clé.
#10
Il me semble que dans la roadmap du services, c’est voué à rémunérer ceux qui mettent à disposition un espace de stockage supérieur à celui qu’ils utilisent.
#11
Ca ressemble beaucoup à ce que proposait Wuala, tout au moins au début: du stockage hybride traditionnel / P2P, avec un système de bonus qui encourageait à offrir de l’espace de stockage et un uptime correct. Démarche assez intéressante, bien qu’en closed-source.
Wuala sur wikipedia
#12
Quitte à faire du P2P, autant ajouter une surcouche blockchain et payer les gens en HiveCoin.
#13
Je vois pas comment ça pourrait marcher en étant à la fois moins cher et moins polluant que les centres de données normaux. Sur leur blog ils allèguent que si, mais sans chiffres à l’appui, et en revoyant vers des articles où « on vous explique la conso des data centers ».
Mais sans la comparaison avec la conso du même espace de stockage chez M. Tout le monde, sachant que M. Tout le monde doit alimenter tout son ordi et sa box pour un seul disque en général (voire 1 HDD + 1 SSD).
En comparant avec des baies de disques dans les centres de données, je vois vraiment pas comment la surconso des ordis et box persos pourrait être “absorbée” par la mise en réseau en P2P.
Ça me fait penser à l’idée qu’un email pollue moins qu’un courrier : c’est pas si simple !
#13.1
Tout simplement parce que ton ordi et ton DD est allumé que le logiciel tourne ou pas.
#13.2
De mémoire, avec eMule ou autre, pour qu’un DL ne stagne pas il fallait des dizaines de sources, et non pas juste 2.
Ton argument ne marche pas : imaginons que la Reine Rouge stocke 3 Go de données pour Alice, le Lapin et le Chapelier fou. Si la Reine Rouge n’a que 1 Gb/s en upload, elle ne pourra pas servir les 3 en même temps instantanément.
Donc il faut ajouter la conso des ordis d’Alice, du Lapin et du Chapelier fou pendant qu’ils attendront leurs données. Et peu importe alors que l’ordi de la Reine Rouge consomme ou ne consomme pas.
#13.3
“une taille maximale de 3 Go pour les fichiers”
J’ai essayé justement et bon, c’est en bêta au passage hein.
Ce n’est pas prévu ni pour Alice ni pour ses merveilleux amis.
Ce n’est pas du partage entre ordis, c’est du cloud perso décentralisé.
Ce n’est pas fait pour de la vidéo, je dirais plutôt des docs ou de la musique max.
Ça consomme un peu de CPU pendant que ça prépare les fagots, très peu de BP quand on a la fibre, et pis c’est tout.
Tes fichiers sont posés un peu partout chez les gens qui ont un peu de place.
On verra comment le truc évolue, à ce stade c’est expérimental et vous allez tous continuer à foutre vot’ bordel ailleurs.
Le concept doit avoir une algorithmie assez chiadée je pense pour fonctionner.
#13.4
La Reine Rouge a :
Total : 3 Go, ça passe dans la limite, non ?
J’ai pas dit “en un seul fichier” non plus.
Upload max de la Reine Rouge : 1Gb/s, soit 125 Mo/s
On va arrondir et dire qu’il faut 8 secondes pour UL 1 Go (j’ai pas dit Gio après tout).
Bien entendu, Alice, le Lapin pressé et le Chapelier fou sont modernes et fibrés, ils peuvent DL à plus que 1Gb/s.
Si les 3 demandent leur données en même temps à la Reine Rouge, le troisième va attendre au final 3 × 8 = 24 secondes.
Si les 3 demandent leurs données en même temps à un centre de données robuste et moderne lui aussi, cela ne va prendre que 8 secondes (les 3 téléchargement en même temps).
Donc dans le cas du P2P Hive, la conso d’énergie d’Alice, du Lapin pressé et du Chapelier fou est collectivement multipliée par 3 à cause de la limite en UL de la Reine Rouge.
Et des gens qui demandent des données simultanément, c’est le cas le plus commun en fait, même sans parler de vidéo ou autres : plus il y a d’usagers, plus il y a de chances que leurs horaires d’utilisation se recoupent…
…Hé, d’ailleurs c’est le principe sur lequel ils ont construit l’idée de Hive
Donc même si ça fonctionne, même si ce n’est qu’en bêta pour le moment,…. je vois pas comment ce truc pourrait faire faire des économies d’énergie ! C’est un peu comme l’auberge espagnole : on invite ses potes, chacun ramène un plat… ça marche bien à 5 potes, ça marche moyen à 50 potes puisqu’on a déjà trop de fois les mêmes plats… ça ne marchera plus du tout à 500.000 potes !
#14
Le raisonnement est que tu ne laisses pas ton PC allumé exprès pour ce service. Si tu utilises ça sur un PC de boulot qui tourne déjà 10h/jour en temps normal, ça ne fait qu’un léger surcoût d’énergie (quelques cycles CPU supplémentaires et surtout le transfert). Par contre, s’ils commencent à inciter les gens à laisser tourner leur PC pour avoir plus de stockage, effectivement le gain n’est plus du tout là !
#15
Ce n’est pas possible, il y’a du chiffrement bout-en-bout : Les fichiers sont privés et seul toi à la clé ! Le système p2p que tu as décrits est un P2P tout ce qui a de plus commun (c’est TOR d’ailleurs :) ) : les fichiers partagés sont en clair, seul l’échange est anonymisé. Pour le typiaking ça ne fonctionne plus du tout, car tu es responsable de ce qui sort de ta connexion, y compris quand c’est chiffré : le fait d’être un proxy de contenu illégal est déjà illégal.
#16
En général, quand ça commence par « Le raisonnement est que… » c’est qu’on est en train de lire le commentaire d’un prof qui essaie de sauver la copie d’un mauvais élève qui a pondu n’importe quoi. 😝
Et en particulier, tu n’as pas lu mon commentaire en entier, puisque je parlais du problème posé par la limite de bande passante qui est à l’origine de l’augmentation de la consommation d’énergie non pas de celui qui fournit le stockage mais de ceux qui demandent les données stockées (ils sont “servis” moins vite donc ils consomment “à vide”).
En clair, il y a pour moi plusieurs problèmes dans le fonctionnement P2P de Hive, je vais quand même pas récrire ce que j’ai déjà mis plus haut ?!?!
Et précisément à propos de cet argument : où sont les chiffres ? C’est facile d’alléguer que c’est léger ! Moi je dis que même léger c’est quand même plus que dans un centre de données (qui est conçu pour être efficace énergétiquement, au contraire des PC de bureau), et que cela va à rebours de ce dont on a besoin de nos jours.
#16.1
Je n’essaie rien de sauver, je pense également que ce système est bancal.
En tout cas je ne saisis pas comment on pourrait garantir :
Je te retourne l’argument : où sont les chiffres qui te permettent d’alléguer qu’un serveur dédié dans un centre de données consommerait moins que le surplus de charge d’un logiciel qui tourne sur une machine laissée allumée pour d’autres usages.
#17
Mega est basé sur un système de ce genre, ce qui permet au site d’invoquer la “deniable plausibility” (ou un truc comme ça…) : à aucun moment dans l’échange, le site n’a la possibilité de savoir ce que contient ni même ce qu’est le fichier échangé, vu qu’il ne connaît ni la clé publique, ni la clé privée. Le fichier est décodé seulement par l’utilisateur final, et plus exactement par le navigateur, en local.
Dans un système p2p sans serveur central, cette possibilité peut être transposée de la façon suivante : les proxys - qui s’intercalent entre l’émetteur et le récepteur - n’ont aucune possibilité de décoder les données qui passent par eux, ni même de connaître la taille et le nombre de fichiers échangés, vu que des données aléatoires sont ajoutées en permanence.
Pour épicer le tout, il est très difficile de faire la différence entre les données aléatoires et les données réellement utiles.
Pour résumer ça de façon ludique, le scénario pourrait être le suivant :
Alice cherche un fichier précis.
Pour cela, Alice connecte son client, qui a auparavant généré une clé privée qui n’appartient qu’à Alice, et fait une recherche, qui est relayée par tous les clients connecté à ce moment précis. La priorité est donnée aux clients proches d’Alice, ceux dont la réponse est la plus rapide. Aucune donnée géographique n’est échangée, seule la vitesse compte.
Il se trouve que le Lapin a le fichier que cherche Alice, youpi !
Pour être plus exact, les chunks (tout petits morceaux de quelques Ko, ou Mo, comme on veut) qui composent ce fichier pourraient très bien être à plusieurs endroits à la fois, c’est même fortement conseillé, mais on va faire simple.
Alice demande le téléchargement, ce qui déclenche l’envoi de sa clé publique au Lapin.
Le programme client du Lapin va alors chiffrer le fichier en question en local avec la clé publique d’Alice. A partir de ce moment, personne d’autre qu’Alice ne peut plus déchiffrer le fichier, avec sa clé privée (qui elle est secrète et n’est jamais échangée avec, ni envoyée à, qui que ce soit). Le fichier est ensuite découpé en “chunks” (numérotés), qui sont envoyés immédiatement (dans le désordre) à tout client connecté à ce moment-là (priorité aux plus rapides).
Les “chunks” passent par au minimum 2 proxys (en réalité, c’est le même programme qui joue le rôle de client, de proxy et de serveur, donc n’importe qui dont le client est connecté peut jouer sans qu’il le sache n’importe lequel de ces trois rôles, le plus souvent en même temps).
Des données aléatoires sont mélangées aux données utiles, les deux types de données ne pouvant être différenciées que par le client d’Alice, en effet au fichier est joint un petit fichier xml (chiffré avec la clé publique d’Alice) qui indique au client d’Alice que (par exemple) : seul les deux premiers octets de chaque “Mot” de 64 bits sont utiles (ou les troisièmes, vingtièmes, quarantièmes… cette “décision” aléatoire est prise par le client, les possibilités sont quasi-infinies).
Et voilà, Alice a reçu son fichier et son client l’a assemblé et déchiffré automatiquement, elle est si heureuse !
…Ou peut-être a-t-elle un peu trop abusé de certains champignons, difficile de trancher…
Bon d’accord, l’inconvénient est que ce genre de système est leeeennnnt… Mais alors d’un leeennnt….
#18
J’ai un peu de mal à comprendre l’ordre des choses. A ma connaissance, le but est justement que l’information confidentielle (la clé privée - connue du seul destinataire du message) serve à déchiffrer ce que l’information publique (la clé publique - connue de n’importe qui ayant besoin d’envoyer au destinataire) a permise de chiffrer sans être elle-même capable d’inverser le résultat. Là façon dont tu le présentes, tout le monde a la clé privée Oo
Après c’est pareil, je ne suis pas un expert en expertise sur la crypto, mais ça ne ressemble pas aux schémas dont j’ai connaissance.
#19
Et là c’est le drame :) pour que Lapin chiffre le fichier il faut qu’il soit en clair chez lui. Tu as décrit un P2P d’échange de fichier entre deux personnes. Pour du stockage chiffré, ça ne fonctionne plus : Alice va chiffrer son fichier avec la clé public de Lapin et du coup Alice ne pourra récupérer son fichier que quand Lapin est en marche.
Bon j’imagine que le système est plus proche d’un bitlocker : les données sont chiffrées avec une clé aléatoire qui ne change jamais, cette clé est ensuite chiffrée de différentes façons (avec ton PIN tapé au démarrage, avec le code de déverrouillage admin…) Quand tu changes ton PIN les données ne sont pas déchiffrées, seul le stockage de la clé est rechiffré avec ton nouveau code.
#20
…MAIS, on peut imaginer un système dans lequel tes fichiers perso sont encodés en local avec ta clé publique, puis découpés en petits morceaux qui sont envoyés et dupliqués en plusieurs exemplaires à tous les nodes connectés à ce moment-là, charge à eux ensuite de renvoyer les chunks à d’autres clients afin d’assurer une redondance maximale (en fait le nombre de copies ne dépends que de l’espace total disponible à un instant T), sachant que plus ton fichier est gros, moins il sera dupliqué (ex.: si l’espace collectif disponible à un instant T n’est que de 6 To, une image de ton disque dur de 3To ne ne pourra être dupliquée en tout que deux fois).
Pour déterminer les priorités, on pourrait imaginer un système de points (un peu comme avec ed2k) attribués par ton client :
Plus tu réserves d’espace aux autres…
Plus tu es souvent connecté (le top étant que ton client soit connecté 24⁄24)…
Plus la bande passante que tu mets à disposition du réseau est rapide (ceci est relatif : on parle ici de la rapidité de X par rapport à toi et non aux autres. Un même node peut être considéré comme “lent” par Alice et “rapide” par le Lapin) (Note : je ne parles pas ici de la proportion de BP que tu mets à dispo, mais bien de la vitesse effective, réelle, d’upload / download dont un client proche de toi peut profiter)…
…plus tu accumules des points, et donc plus vite tu auras la priorité pour sauvegarder tes propres fichiers dans l’espace collectif.
Cela pourrait constituer un système de sauvegarde chiffrée d’appoint, avec un fonctionnement général (interface html) aussi simple que possible, très proche du Cloud.
L’inconvénient, d’un point de vue p2p : seul toi peut décoder tes fichiers, il n’est alors plus question de partage de fichiers, mais de partage d’espace.
#21
Hey, non, ce n’est pas comme ça que ça marche. Ce sont aux entreprises de justifier de leur emprise environnementale, et non pas l’inverse. C’est un système déclaratif, et c’est une fois les déclarations de l’entreprise faites qu’elles peuvent être relues et contestées le cas échéant.
Il n’y a pas d’autre solution respectueuse des règles de confidentialité en entreprise en général : dans le système accusatoire que tu proposes, il faudrait que n’importe qui puisse se mêler de ce qui se passer dans toutes les entreprises.
#21.1
Pour la conso c’est simple:
Si tous les PCs perso sont éteints, le serveur n’a pas lieu d’exister. Il consomme pour rien.
Si tous les PCs perso sont allumés, la solution de hive est la meilleure.
Entre les 2 justement, hive essaie de proposer un truc qui tend à dire que le serveur consomme pour rien. Enfin si, pour que le GAFAM puisse se servir.
A quel moment tu optimises la conso à concentrer au fait ?
Tu optimises à partager 1 ressource entre plusieurs, tu sécurises en rajoutant une redondance partielle, mais cela reste faisable d’un point de vue individuel.
Le fait de concentrer, c’est de la chaleur à climer en plus. Les ressources c’est les mêmes sinon.
#22
Et alors puisque c’est simple, il est où le chiffre final de l’énergie consommé par Go ?
En plus tu ne tiens pas compte des limites de bande passante dont j’ai parlé et qui augmentent la consommation, ni du fait qu’un rack à plusieurs disques dans un centre données limite la conso d’énergie par Go par rapport à un PC entier avec un seul disque. (même avec la clim’ dans le centre de données)
L’idée de Hive, c’est de se défausser de toutes les obligations d’un fournisseur d’espace de stockage en disant que c’est le problème des proprios des PC puisque les PC sont utilisés à autre chose principalement. Idée lumineuse d’un point de vue strictement économique, indubitablement.
Mais moi je veux voir les chiffres qui prouvent que c’est aussi une bonne idée pour l’environnement. On connaît déjà d’autres exemple de boites qui veulent pratiquer la dilution de la pollution pour s’en laver les mains (par exemple, transport de colis en P2P en voitures), et à chaque fois le bilan environnemental est négatif.
#22.1
En fait tu essaies de t’en servir pour ce qu’il n’est pas :
un disque dur.
Pour rester dans cet usage, de sûr la conso par Go la plus faible sera si tu possèdes ce disque dur @home.
Pareil la BP n’est qu’un problème que parce que tu veux que ce soit externe et du gros débit.
Ce n’est pas un disque dur parce que dans cet usage pourquoi prêter 5Go pour avoir 5Go, autant s’en servir localement.
C’est un “NAS like” pour stocker quelques Mo que tu peux retrouver facilement n’importe ou.
Il faut utiliser les outils à disposition de façon adéquate, c’est juste ça ton soucis.
#23
Et c’est toi qui choisi ce qui est adéquat en fonction de critères invérifiables ?
J’étais en train d’expliquer que sans chiffres montrant que Hive pollue réellement moins, alors il n’y a pas d’usage pour un tel outil. Un peu comme l’Hyperloop : c’est pas parce qu’un type l’a fait creuser que c’est une bonne idée pour autant.
#24
Oui c’est probablement plus proche de ça, mais ça soulève plusieurs interrogations :
dans le pire des cas tout le monde a les fichiers de tout le monde, ton espace de stockage est 1% de ce que tu mets à disposition, avec aucune redondance ton fichier n’est rarement accessible que quand les personnes qui ont un de tes chuncks sont en ligne (c’est le principe des téléchargements emule avec peu de sources, il fallait parfois attendre de longs jours que le paquet rare soit dispo, et là ça ramait à fond, car ce paquet rare était sur-demandé). Bref c’est pas du cloud.
Vraiment je ne vois pas comment ces promesses seraient tenables, il faudrait des chunks assez petits pour que par hasard des morceaux des différents fichiers une fois chiffrés fassent le même chunk. Ou alors que quand t’éteins ton PC, le logiciel rame de longues minutes à uploader ces données ailleurs sur le réseau (serveur, ou autres membres du réseau p2p) mais là aussi la balance de conso n’y est plus du tout.
#24.1
C’est vrai, le système que je décris est plus vaguement théorique qu’autre chose. En fait dans un tel système, je ne vois pas l’intérêt du chiffrement bout en bout, étant donné que (théoriquement) :
1- Des données aléatoires sont introduites dans le flux, impossibles à distinguer des données utiles.
Inconvénient : bouffe de la BP pour rien, avantage : difficile à intercepter / décoder par un MITM, en admettant que le “man” en question soit capable de craquer ta clé publique.
2- Et donc on pré-suppose que le chiffrage de tes clés est suffisamment fort pour que seul toi soit en mesure de déchiffrer le bazar.
Inconvénient : lent à déchiffrer, bouffe du CPU / GPU / RAM Avantage : les opérations de chiffrement / déchiffrement se font uniquement en local, hors ligne.
Comme je disais, ce genre de système - que je décris un peu maladroitement - n’est pas fait pour partager quoi que ce soit, mais plutôt comme une sauvegarde de dernier recours, si tu pètes tes HDD / SSD / NAS / Cloud, tu sais que tu auras toujours cette bouée de secours, même si ta sauvegarde va forcément être lente à rapatrier (stockage “froid”).
C’est une façon comme une autre de mettre en commun de l’espace de stockage qui serait sinon inutilisé (gaspillé ?), et donc de retarder voire d’économiser l’achat d’une nouvelle unité de sauvegarde / abonnement Cloud. Et qui dit économie d’achat, dit moins de pollution due aux déchets électroniques.
Bon d’un autre côté, ce n’est pas aussi fun que l’échange de fichiers p2p “old school”, c’est même plutôt carrément “boring”. MAIS si un gros noyau de gens motivés laissent leur programme client connecté 24⁄24 et mettent à dispo un espace conséquent (mini 1To chacun), ça peut être sympa aussi, qui sait ?
#25
P.S. : Pour le rendre moins “boring”, on pourrait aussi imaginer un système de récompenses / crypto genre : pour tant d’espace mis à dispo pendant un laps de temps T, tu gagnes tant de “coin-coins”…
Je crois d’ailleurs qu’un tel système existe déjà dans le monde “merveilleux” de la blockchain, du genre tu rends tel nombre de services, tu gagnes tant de pépettes… Virtuelles évidement.
#26
Bonjour a tous,
Je suis David Gurle ([email protected]) et je suis le fondateur de Hive. Tout d’abord, je suis tres ravi de voir que NextInPact a pris le temps d’ecrire cet article, et encore plus que ravi que vous ayez pris le temps de lire notre page web, d’essayer notre logiciel hiveDrive, parteger vos impressions, ainsi que vos doutes et convictions. J’aurai jamais espere tant.
Nous sommes tout debut de notre aventure, on a deja fait pas mal, mais il reste encore tant a faire. Notre approche pour construire un cloud P2P en utilisant les resources partages des ordinateurs (pendant qu’ils sont allumes) est vraiment difficile a mettre en oeuvre. Les defis technologiques sont multiples, mais malgres ces defis on a tout meme reussit a mettre en place la platforme initiale qui fonctionne. Je suis tres fier de l’equipe Hive qui a bosse tres dur pour arriver la ou nous en sommes.
Notre roadmap va amener d’ici fin Juillet beaucoup de fonctionalites supplementaires tant sur les platformes qu’on va supporter (Windows, MacOS, iOS, Android, Linux et les NAS les plus populaires), que sur l’infrastructure P2P de notre reseau qui se nomme hiveNet, et bien sur l’interface utilisateur.
Devant les questions et les reponses excellentes et pertinentes que j’ai pu lire (je suis impressione par la profondeur de vos connaissances !) je vous propose de faire une session Q&A en direct avec notre equipe. Je pourrais essayer d’apporter des reponses ici et la et serai tres heureux de le faire, mais les experts sont nos ingenieurs qui travaillent sur ce sujet depuis pas mal de temps. C’est eux qui codent, et qui savent ce qu’on sait faire et ce qu’on ne sait pas encore faire.
Qu’est ce que vous en pensez ? On pourrait facilement et rapidement mettre en place un webinar sur ce sujet la semaine prochaine.
Si pour une raison ou une autre la communaute prefere ce forum au lieu d’une session en directe nous serons present avec plaisir aussi.
Au plaisir de vous lire.
David