Bonjour,
j'écris ce journal pour vous présenter Bitmessage, un protocole d'envoi/réception de messages entièrement acentré et chiffré. C'est semble t-il basé sur un mécanisme simillaire à bitcoin.
J'ai trouvé le principe intéressant pour un internet en bonne santé, neutre, acentré, respectueux de la vie privée, et qui ne tue pas de chatons. Un des gros avantage de cette solution pour moi, c'est la possibilité d'avoir un client très simple d'utilisation.
Caractéristiques et comparaison avec une solution mail+PGP
- Envoi de pair a pair, pas besoin de créer un serveur, d'enregister un nom de domaine, ou de s'inscrire à un service. Vous pouvez créer autant d'adresses que vous le voulez.
- Pas besoin de faire confiance à un tier (autorité de certification par exemple).
- Résistant à la censure. Personne, y compris un gouvernement, ne peut supprimer votre adresse ou vos messages.
- Il n'est pas possible d'usurper l'identité d'un expéditeur (spoofing).
- Bitmessage possède une fonctionnalité de broadcast.
- L'identité de l'expéditeur et du destinataire des messages est plus facile a cacher qu'avec une solution mail+PGP.
- Contrairement à PGP, le sujet est chiffré par défaut.
- Devrait être plus simple à utiliser, pas besoin de conserver les clés publiques de vos correspondants.
- Possibilité de développer d'autres fonctionnalités basées sur le protocole.
Concrètement, c'est utilisable ?
Il existe un client fonctionnel développé en Python (PyQt et OpenSSL nécessaire, licence MIT). Ce n'est que le début du développement, et les créateurs sont demandeur de relecture et d'audit de leur code.
Le client se limite pour le moment à l'envoi de texte. Une adresse ressemble à ca : BM-orkCbppXWSqPpAxnz6jnfTZ2djb5pJKDb c'est en fait le hash de votre clé publique.
Liens
le wiki de bitmessage
whitepaper du protocole en pdf
FAQ
subreddit consacré à bitmessage
# Un mail en P2P...
Posté par kadalka . Évalué à -9.
C'est certain le projet en lui même est intéressant…
Maintenant il faut mettre la licence du projet clairement dans votre journal (MIT ?).
Si par exemple ce n'est pas Open Source ce sera nettement moins attrayant, du moins je ne vois pas l'intérêt de ce logiciel pour le grand public…
Le fait de choisir le Hash de la clef publique ce n'est pas bête…
C'est quoi * Requires Proof of Work * ?
Si on n'en veut pas on peut s'en passer ?
question bête :
Vous vous en servez au quotidien ?
Quelle est la taille maximale des pièces-jointes ?
[^] # Re: Un mail en P2P...
Posté par julmx . Évalué à 10.
Bonjour,
j'ai précisé la licence MIT du client, les sources sont sur github et la documentation du protocole est disponible.
Proof of Work correspond a un moyen de limiter le spam. D'après ce que j'ai compris, le principe est de demander un temps de calcul suffisament important avant l'envoi pour empécher l'envoi en masse. Sans ce "Proof of Work" les autres nodes ne transmettent pas ton message.
Je n'utilise pas au quotidien, faute de correspondants, le projet est encore en beta. C'est fonctionnel d'après mes tests.
Je précise que je ne suis pas spécialiste de bitmessage et que je n'ai aucune autorité sur le projet. J'ai simplement voulu partagé une découverte intéressante.
PS : je préfère le tutoiement, sinon j'ai l'impression de passer un examen…
[^] # Re: Un mail en P2P...
Posté par kadalka . Évalué à -3.
Désolé je ne savais pas. J'ai l'habitude de vouvoyer les gens.
N'hésites pas à me le rappeler.
Je ne prends pas mal même si on me le rappelle mille fois… :-)
(Oui je suis très souple.)
Vu sous cet angle c'est intéressant.
Mais alors, si il y a plusieurs destinataires, parfaitement identifiés, cela ne risque-t'il pas de s'engorger ?
(Cas des mailing list par exemple)
[^] # Re: Un mail en P2P...
Posté par julmx . Évalué à 1.
non, en gros tous le monde reçoit tous les messages donc le broadcasting est assez facile
[^] # Re: Un mail en P2P...
Posté par kadalka . Évalué à -8.
Ca fonctionne à la manière d'un téléphone cellulaire.
La routine.
Je constate qu'il n'a pas de version mobile. Ce n'est pas grave, seul Scayl a une version mobile en alpha…
En tout cas je
vouste remercie pour ce journal.J'espérais un jour lire quelque chose de ce genre, même en béta.
Bon je vois qu'il y a des concurrents mais le fait qu'il soit en python me fait dire qu'il sera plus portable.
[Pas besoin de compiler, etc.]
# Question de néophyte
Posté par Astaoth . Évalué à 7.
Sans serveur serveur centrale, comment est-ce Bitmessage trouve l'ordi de destination ?
Je me posais la même question pour BTSync d'ailleurs, comment est-ce que le client trouve le destinataire de la clef secrète sans serveur centrale ?
Emacs le fait depuis 30 ans.
[^] # Re: Question de néophyte
Posté par kadalka . Évalué à -9.
J'ai hésité avant de poser la question…
Je suppose qu'il fonctionne à la manière de TOR… ?
[^] # Re: Question de néophyte
Posté par julmx . Évalué à 1.
Le protocole fonctionne plus à la manière de bitcoin que tor. Par ailleur, bitmessage est utilisable à travers tor. Les proxys sont prévus dans la configuration du client.
[^] # Re: Question de néophyte
Posté par FDF (site web personnel) . Évalué à 4.
Pour répondre de manière très simple et uniquement sur le principe (et pas la technique) grace à la théorie du petit monde, qui veut qu'on ne soit jamais loin de qui que ce soit si on connait les contacts des contacts de ses contacts.
Voir les détails: Texte du lien
Ainsi sa propre appli communique avec ses voisines et leur dit qui elle est et qui elle connait. Les voisines font de même. Et ainsi on arrive a voir loin.
[^] # Re: Question de néophyte
Posté par barmic . Évalué à 3.
Pour que ça puisse s'applique il faut que le réseau pair à pair ai une topologie pas trop particulière (il ne doit pas être en anneau (pas une DHT, mais les cycles sont bien sûr acceptés), qu'il ne soit pas arborescent, qu'il n'y ai pas de clique (ou plutôt que l'unique clique contienne l'ensemble des nœuds, etc).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Question de néophyte
Posté par Astaoth . Évalué à 1.
Mais dans ce cas, qui est-ce qui est considéré comme proche ? On se base sur l'ip ? Et si peu de monde utilise le logiciel en question, il y a donc un risque élevé de n'avoir personne de proche capable de transmettre le message ?
Emacs le fait depuis 30 ans.
[^] # Re: Question de néophyte
Posté par Spack . Évalué à 4.
Eh ben ça alors… Cette application pourrait posséder une liste de ses voisines et en utilisant un protocole spécifique pourrait annoncer la liste de ses voisines. On appelerait ce protocole Message Information Protocol (MIP).
Quand le nombre de voisines deviendra trop grand, on pourra regrouper et former un ensemble d'applications voisines à qui on assignera un numéro d'identification Message System (MS). Ainsi à un niveau macro on pourra echanger des messages d'un groupe à un autre plutôt que de proche en proche. Il faudrait définir un nouveau protocole que nous appellerons Message Gateway Protocol (MGP).
Ça commence un peu à devenir le bordel. Il faut s'assurer que tout le monde parle le même langage. Mettons en place une organisation qui se chargera de normaliser tout ça et appelons la Message Engineering Task Force (METF).
[^] # Re: Question de néophyte
Posté par Victor . Évalué à 1.
:D
[^] # Re: Question de néophyte
Posté par lenod . Évalué à 6.
Ce n'est pas le message qui trouve la personne, c'est le contraire.
Si tu peux lire un message, alors il est pour toi.
[^] # Re: Question de néophyte
Posté par julmx . Évalué à 2.
En fait, tous les clients reçoivent tous les messages. Quand le nombre de message devient trop important, les noeuds se regroupent en sous réseaux.
Pour des explications plus précises regardez la partie scalability du whitepaper
[^] # Re: Question de néophyte
Posté par barmic . Évalué à 4. Dernière modification le 27 mai 2013 à 15:25.
Quand tu cherche un boulot, tu commence par demander à tous tes contacts s'ils ont une offre pour toi. Eux ils demandent à tous leurs contacts et ainsi de suite. Au final il a était prouvé que si c'est fait avec une profondeur de 5 à 6 ça suffit pour être presque certains de trouver l'offre d'emploi qui te convient.
Je crois si mes souvenir sont bons qu'on appel ça une requête cascadé.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# image
Posté par fredix . Évalué à 6.
Le client gère l'affichage en HTML, et les images s'affichent très bien, encodées en base64.
# Certification
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Pas de certification, donc il faut rencontrer son interlocuteur en personne au préalable en somme, n'est-ce pas ?
[^] # Re: Certification
Posté par julmx . Évalué à 2.
Le protocole te protège du spoofing d'adresse. Si tu reçois un message de BM-orkCbppXWSqPpAxnz6jnfTZ2djb5pJKDb tu es sur que c'est bien le propriétaire de cette adresse qui à envoyé le message. Par contre, le protocole ne propose pas de mécanisme pour assurer que telle adresse correspond bien à telle personne physique.
[^] # Re: Certification
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Bon, sur ce point précis, c'est comme PGP en utilisant les identifiants de clef donc : il faut rencontrer son interlocuteur en personne pour connaître son identifiant. Ou passer par une chaîne de certification externe, où quelqu'un de déjà connu te donne l'identifiant d'untel.
[^] # Re: Certification
Posté par Victor . Évalué à 4.
Je pense que d'une façon générale, le cas d'utilisation que tu décris n'est pas celui visé par ce genre d'outils.
Déjà je ne suis pas sûr que ce soit solvable sans une autorité centrale (ou une chaîne d'autorités en qui tu as confiance) : enfin bon, tu dois mettre ta confiance dans quelqu'un(s).
Sinon, je dirais qu'on est plutôt dans des cas où tu n'as pas forcement besoin de savoir qui est la personne dans le monde physique, tout ce que tu veux c'est être sûr que tu t'adresses à chaque fois à la même personne.
En gros tu as les avantages d'une approche centralisée style jabber où le serveur te garantie que c'est bien la même personne derrière une adresse, mais en décentralisé.
[^] # Re: Certification
Posté par julmx . Évalué à 1.
A ma connaissance, le seul moyen de le faire sans autorité centrale, est un mécanisme de type web of trust et ce n'est pas prévu dans le protocole. Il doit cependant être possible de l'étendre dans ce sens.
[^] # Re: Certification
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Le cas d'utilisation que je décris, c'est une communication chiffrée. Si on veut de la sécurité, de la vraie j'entends, il faut avoir rencontré son interlocuteur ou passer par des tiers de confiance. Si ce logiciel s'adresse à n'importe qui sans prétendre sécuriser quoi que ce soit, très bien. Mais prétendre sécuriser les communications sans rencontre face à face ni tiers de confiance, c'est du bidon.
[^] # Re: Certification
Posté par julmx . Évalué à 2.
c'est plutôt une communication authentifiée que tu décris. L'authentification peut être faite de manière différente. Par exemple, si tu es capable de me ressortir la blague pourrie que j'ai faite hier soir, je suis sur que c'est bien toi qui à pris l'apéro avec moi. La partie chiffrement est plus technique à mettre en oeuvre.
[^] # Re: Certification
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Pas du tout, ça prouve que je suis bien cette personne ou que je suis un pirate qui a bien accès au support de transmission entre cette personne et toi.
[^] # Re: Certification
Posté par Victor . Évalué à 2.
Attend, c'est un peu restreint ce que tu décris là, c'est qu'un cas particulier d'une conversation chiffrée/authentifiée.
Ça dépend de ce qui t'importe.
Par exemple je peux très bien commencer à discuter avec une personne sur le net, et ensuite vouloir m'assurer que ce soit toujours la même personne, mais à aucun moment je n'ai besoin de savoir qu'il est dans le monde physique !
Je veux pouvoir m'assurer que seul lui ne lise ce que je lui écrit, et ainsi de suite.
Je ne vois pas d'où vient le besoin absolu d'authentifier la personne. Vis-à-vis de quoi d'ailleurs ? de sa carte d'identité ? de son physique ? la couleur de sa peau ?
Tu vois ce que je veux dire ? Il te faut bien un critère dont tu as besoin pour vérifier cette authentification ! Peut-être que pour moi, le seul critère qui suffise c'est "on a rushé tout les deux en B1 à counter-strike la veille" ou "il m'a donné des informations secrète de je ne sais quelle administration", etc…
[^] # Re: Certification
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Sauf que ces idées n'apportent pas de réelle sécurité, tout ce que tu vérifies là, c'est que celui que tu as en face est bien la bonne personne. Pas que la ligne est sûre. S'il y a un pirate au milieu, tu ne t'en rendras pas compte.
[^] # Re: Certification
Posté par julmx . Évalué à 1.
J'ai du mal à te suivre, où est le problème selon toi ?
Ce que bit message essaye de garantir entre autre :
Ce qu'il ne permet pas de faire :
Garantir que telle adresse bitmessage est liée à telle identité.
En résumé ton adresse bitmessage peut être considérée comme une identité numérique, mais ne garantie pas la correspondance entre cette identité et tes autres identités dans le reste de l'univers.
Comme par le suite tu parles de sécurité du canal de communication et plus de l'authentification de l'auteur, j'ai du mal à voir où tu veux en venir.
[^] # Re: Certification
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3. Dernière modification le 27 mai 2013 à 17:56.
Tu as rencontré Untel sur IRC. Il t'a indiqué son identifiant Bitmessage. Tu communiques avec lui. Il reçoit bien tes messages. Tu reçois bien ses réponses. Tu crois que c'est sûr ?
Tu as tort : IRC n'est pas un moyen de communication fiable, or j'étais en interception-réécriture sur la ligne, et l'adresse Bitmessage que tu as lu sur ton client IRC, c'est la mienne, avant de le transmettre à ton interlocuteur. Le premier message que tu crois lui avoir envoyé, c'est à moi que tu l'as envoyé. Je n'y ai changé qu'une chose : ton adresse d'expéditeur, pour y mettre la mienne. Lorsqu'il croit t'écrire, c'est donc également à moi qu'il envoie ses messages, que je modifie à la volée de la même façon avant de te les envoyer.
Sans identification — ce qui ne désigne pas forcément l'identité civile mais simplement l'association entre la connaissance d'une personne et une personne physique, je dirais —, la crypto est vaine. Enfin pas tout ça fait : si cela ne sert à rien contre les intercepteurs déjà présents, cela bloque tout de même les nouveaux intercepteurs qui pourraient venir s'ajouter sur la ligne, ainsi que ceux qui sont en simple écoute.
[^] # Re: Certification
Posté par julmx . Évalué à 2.
Ah OK c'est plus clair, effectivement, au moment d'échanger l'adresse bitmessage, il peut y avoir une vulnérabilité. Il faut en avoir conscience mais ce n'est pas forcément au protocole de le gérer directement. Tu peux toujours ajouter une surcouche pour cet aspect.
Selon le niveau de sécurité nécessaire, ce n'est pas forcément très difficile de trouver un moyen satisfaisant. Quand tu télécharge une iso débian, tu vérifie l'intégrité avec la somme de contrôle généralement trouvé sur le site de débian. C'est suffisant dans la plupart des cas.
[^] # Re: Certification
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
On est d'accord, seulement sans couche de certification ou rencontre face à face, il ne faut pas prétendre qu'il s'agit d'un moyen de communication sûr, parce que c'est faux.
Quant aux sommes de contrôles pour les téléchargements, c'est un moyen de se prémunir des erreurs de transmissions, pas des attaques.
[^] # Re: Certification
Posté par julmx . Évalué à 1.
C'est vrai, tu as raison pour les sommes de contrôle même si ca peut aussi servir de protection quand on te passe l'iso sur un CD ou une clé USB.
Si je vais dans ton sans, je crois qu'il n'existe aucun moyen de communication sûr. Les autorités de certification sont bien tant qu'on n'est pas ciblé par le pays qui héberge la dite autorité. De même lors d'une rencontre physique, il peut être difficile d'être certain que la personne rencontrée est bien celle que tu crois.
Aucun système n'est parfait, il faut avoir conscience de ses limites.
[^] # Re: Certification
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
→ réseau de confiance
Aucune importance, comme je le disais, pas identité il ne faut pas entendre état-civil mais correspondance entre la personne qu'on connaît et une personne physique. Après une rencontre physique où M. Dupont t'a remis sa clef publique, tu n'es pas sûr de communiquer avec M. Dupont, en revanche tu es sûr de communiquer avec le type que tu as rencontré, ce qui est bien le but. Ou du moins, tu es sûr que si ce n'est pas le cas, c'est sa faute, comme toujours avec la crypto.
[^] # Re: Certification
Posté par Victor . Évalué à 2.
En même temps, quand tu rencontres le mec en vrai, qui te dit que c'est bien celui que tu crois qu'il est ? Qu'il a pas de faux papiers, etc… ?
C'est un peu un problème insoluble, il n'y a que la confiance qui marche en gros (que ce soit par un tiers ou au feeling…).
Non ?
(sinon, oui, je comprend mieux ton propos après ton explication, ça se tient :)
# Tor
Posté par hugoL . Évalué à 1.
La FAQ mentionne l'utilisation de bitmessage avec Tor.
Quel intérêt ? qu'est ce que ça apporte de plus?
[^] # Re: Tor
Posté par julmx . Évalué à 1.
réponse simple : c'était facile à faire alors ils l'ont fait
réponse moins simple : ca peut renforcer l'anonymat pour les plus parano. l'IP de laquelle tu reçois un message est probablement plus proche que toi de l'auteur original du message. Tor protège de ça.
[^] # Re: Tor
Posté par superna (site web personnel) . Évalué à 1.
Ouverture de ports et accès pair à pair sans contraintes sur à un firewall ?
# Excellente idée, mais…
Posté par al.jes (site web personnel) . Évalué à 2.
L'idée est excellente, et je la testerai très certainement, mais il reste un problème que le mail avait réglé et qui semble importer beaucoup de gens puisque c'est l'argument numéro un que l'on me donne quand il s'agit de défendre Facebook contre mes attaques : l'adresse est facile à identifier, à recopier, bref à employer. Un hash de clé publique, pourquoi pas, mais il faut alors ajouter des DNS ou équivalent, et c'est un point de plus à sécuriser (sinon toute cette sécurité devient inutile).
[^] # Re: Excellente idée, mais…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Bof, on se débrouille bien avec des numéros de téléphone. En revanche ça fait un peu long, là : un registre de numéros raccourcis comme avec les identifiants de clef PGP serait bienvenu.
[^] # Re: Excellente idée, mais…
Posté par al.jes (site web personnel) . Évalué à 2.
En effet, on se débrouille avec les numéros de téléphones. Cela dit on les supporte parce que le téléphone est là depuis longtemps. Pas sûr qu'il en soit de même pour un protocole de communication à peine naissant.
La question n'est pas de se demander ce que nous, a priori technophiles avertis, y voyons comme avantages, mais de se demander si monsieur tout-le-monde choppé dans la rue serait près à y passer. Il me semble inutile de rappeler que sans utilisateurs, un moyen de communication n'a pas d'intérêt, et que la famille Michu n'en a pas grand chose à faire de la fiabilité (sinon je pourrais utiliser GPG au quotidien, alors que là…). L'utilisateur lambda veut que ce soit facile à installer, que l'utilisation soit triviale et ergonomique mais dans la limite du clicodrome (les raccourcis clavier c'est déjà un « truc de geek »), et surtout qu'il y aie un élément « cool » dedans (à titre d'exemple, Twitter qui pourtant est simple d'utilisation n'a véritablement décollé auprès du grand public que quand les « stars » s'y sont montrées). Donc il faut résoudre ce problème d'adresse, déployer des clients rudimentaires dans différents environnements et trouver une solution à ce problème de « coolitude ».
Parce que s'il est clair que je vais le tester, ça l'est beaucoup moins que je l'utilise au quotidien : si l'avantage est la fiabilité de la communication, je ne vais pas l'utiliser que pour des échanges triviaux. Et si je ne peut pas communiquer avec des interlocuteurs non-technophiles il y a de fortes chances pour que ça se limite aux échanges triviaux.
Donc oui, on se débrouille avec les numéros de téléphone, mais s'arrêter à constater cela me semble une grossière erreur. Ensuite je peux me tromper, le grand public s'emparera de Bitmessage, etc, auquel cas j'en serai très heureux. Mais pour le moment je n'y crois tout simplement pas.
[^] # Re: Excellente idée, mais…
Posté par julmx . Évalué à 1.
Tu n'as pas tord, cependant, le logiciel est très simple à utiliser et il n'y a pas besoin d'inscription ou autre. Tu l'installe, tu clique pour générer une identité et sa marche…
L'un des buts est de proposer justement quelque chose de plus simple que GPG/PGP.
Une autre possibilité très intéressante qui n'a pas été évoquée est de générer une adresse à partir d'une passphrase. Cela supprime le probléme de sauvegarde des clé privés. On peut tout régénérer à partir de la même passphrase.
Après, c'est vrai que les adresses ne sont pas très sexy, mais on peut par exemple passer par des QRcodes pour les échanger.mot de passe
[^] # Re: Excellente idée, mais…
Posté par al.jes (site web personnel) . Évalué à 1.
Le coup de la passphrase, ça pourrait marcher. Faut voir à l'usage. Maintenant reste un dernier problème : si on échange nos passphrases, qui nous dit que les utilisateurs ne vont pas se connecter à notre compte ? Ou alors ça veut dire qu'on ne peut utiliser notre compte que depuis un seul poste ?
Troll à part, ça me fait très peur cette fonctionnalité. Quelqu'un peut-il m'expliquer que j'ai tort (et pourquoi) ?
[^] # Re: Excellente idée, mais…
Posté par julmx . Évalué à 1.
Attention ! il ne faut surtout pas donner ta passphrase, c'est à partir de celle ci que ta clé est générée. Ca serait comme donner le mot de passe de ton compte mail…
[^] # Re: Excellente idée, mais…
Posté par al.jes (site web personnel) . Évalué à 1.
C'est pour ça que j'ai trollé dessus… Puis je me suis dit que j'avais peut-être mal compris, d'où mon second paragraphe. Mais apparemment j'ai bien fait de troller.
# Mise à l'échelle? Spam?
Posté par Maclag . Évalué à 5.
Je ne suis pas expert et je ne suis pas sûr d'avoir bien compris comment ça marche:
-Je chiffre un message, je l'envoie au monde entier.
-Le monde entier tente de le décoder. Un seul destinataire va y arriver.
-Si ça devient trop gros, un "sous-réseau" se forme? Le sous-réseau inclue le destinataire et peut décoder une en-tête qui lui indique juste que le destinataire est quelque part parmi ses ouailles?
Qui est le "DNS" du sous-réseau? Une machine définie: on perd une bonne partie des avantages du système… Ou n'importe quel membre du réseau qui ne ré-émettra que dans le sous-réseau?
Étant donne le volume considérable de mail à travers le monde et les nouvelles tendances (appareils mobiles, etc.), quelles ressources seraient demandées à un client final pour analyser tout le traffic de son sous-réseau? Soit on est submergé par les tentatives de décodage de messages, soit par la lecture de milliards d'en-têtes??
Le spam est déjà difficile à contrôler aujourd'hui, comment le sera-t-il quand il n'y aura plus aucun moyen d'associer le spam à un "motif" (adresse IP, serveur smtp, etc.)? Ne risque-t-il pas d'engorger le système?
[^] # Re: Mise à l'échelle? Spam?
Posté par julmx . Évalué à 2.
Pour limiter le spam, l'idée est de faire payer l'envoi de messages en temps processeur pour empècher en masse ( Proof of Work). Ca consiste d'aprés ce que j'ai compris à résoudre un problème de collision de hash avant que les autres noeuds accepte de relayer ton message. La difficulté demandée pourra être ajustée.
Pour ce qui est du filtrage par motif, tu pourra toujours le faire sur les messages qui te sont destinés. Ces principes combinés devraient rendre le SPAM peu efficace. Tu peux aussi blaacklister une adresse.
Pour le système de broadcasting, c'est le destinataire qui souscrit au flux.
Pour le problème de mise à l'échelle, il n'y a pas de DNS pour le réseau principal. Chaque membre du sous-réseau reçoit la totalité des messages de ce sous-réseau. Si le volume de message devient trop important, il se subdivise à nouveau, etc… Le but est de maintenir une consommation acceptable en temps processeur et bande passante.
# Taille des messages ?
Posté par Anonyme . Évalué à 1.
Je n'arrive pas à trouver l'information concernant la taille maximale possible des messages envoyés…
Quelqu'un aurait cette info ?
[^] # Re: Taille des messages ?
Posté par Larry Cow . Évalué à 2.
J'ai vu passer hier une info à propos de messages de 180Mo max.
[^] # Re: Taille des messages ?
Posté par hugoL . Évalué à 1.
Ça répond pas tout a fait a ta question mais dans la conclusion du whitepaper il est indiqué:
[^] # Re: Taille des messages ?
Posté par Anonyme . Évalué à 1.
Merci pour la réponse. Dans le wiki, il est écrit dans le tableau comparatif que le système peut être utilisé avec de "petites" pièces jointes, sans en préciser la longueur. Je suppose du coups qu'il devait y avoir une limite technique à un moment ou à un autre.
# Merci
Posté par steph1978 . Évalué à 4.
Merci d'avoir partagé.
J'adore le concept.
Et en plus ça marche :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.