vlamy a écrit 751 commentaires

Premièrement, il ne faut pas prendre mal ma remarque, elle vise à être constructive malgré tout. Le terme « bûcher » étant une vielle habitude que j'ai pris au côté de certains libristes, mais rien de méchants, que ce soit dit ! Si j'avais trouvé ce projet inutile ou inintéressant, je n'aurais pas pris la peine de réagir.

De plus on est sur DLFP, alors si je ne trolle pas, je perds 99% des lecteurs potentiels :)

Sinon, de ma modeste expérience dans les systèmes pair-à-pair, le terme résilience est associé à la dynamique des pairs (le « churn » comme on dit), ce qui n'est pas le cas dans ce que tu cites !

Désolé, le mot est malheureux, j'entendais simplement par "résilient" qu'il surmonte les obstables. Disons "tout terrain" ! L'objective est d'avoir une application qui "juste marche" même dans un environnement limité comme tous ces pseudos accès Internet où la plupart des protocoles sont filtrés, surtout ce qui ressemble à du Bittorrent (du genre point d'accès wifi public, résidence universitaire, 3G, etc). Ce n'est pas selon moi un problème de facilité d'utilisation.

Eureka ! je comprend où vous voulez en venir : le filtrage du protocole Bittorent ! Là, effectivement le discours se justifie, mais je n'avais pas compris le point sur le filtrage, est-il explicité dans l'explication ? si non, il le devrait, car c'est primordial et c'est visiblement un des points forts de Teaponet ! Donc mettez ce point en avant !

Au passage, je trouve vos objectifs d'« accessibilité » très louables, judicieux et pertinents. Mais cela ne vous autorise pas à troller les autres protocoles pair-à-pair :)

Par contre, je n'ai je pense pas été clair, le protocole n'est pas sur HTTP, car ce serait inutilement couteux pour le transport des messages.

C'est là ou j'ai besoin d'une doc, car on comprend que HTTP est utilisé « intelligemment » (juste quand on en a besoin pour traverser du filtrage,…). C'est bien ça ? Si oui, ça soulève plein de questions intéressantes :) et je reste sur ma faim pour savoir si votre solution tient la route (i.e. est-ce que quand tout le monde utilisera Teaponet, le filtrage sera toujours impossible ?).

PS : je viens de comprendre l'aspect filtrage, que j'avais compris totalement de travers en première lecture. Je pensais au filtrage des pairs, non à un filtrage TCP/IP du protocole au niveau routeur. Si ça peut aider à travailler le discours…

Oui j'ai lu plusieurs papiers pendant ma thèse sur ce sujet spécifique, si tu es vraiment intéressé je te trouves ça !

Sinon n'hésites pas à me pinger sur vlamy[at]vlamy(dot)fr. Je te répondrai.

Si Teaponet prend le l'ampleur, il se peut que j'aille y mettre mon grain de sel, pour éclaircir cette méprise vis à vis des protocoles pair-à-pair.

L'erreur de comparer Teaponet aux protocoles classiques vient, apparemment, du journal et non du site de Teaponet !

• Accessibility Unlike BitTorrent Sync, Teapotnet is available from any Internet connection, since its protocol is very resilient (it can even automatically mimic HTTP sessions if needed). Indeed, BitTorrent Sync requires you to be on a sufficiently open Internet connection, which means you won't be able to use it at work, from a Wi-Fi hotspot, at McDonald's or even your hotel.

Cela dit : la confusion sur la résilience devient plus vicieuse et plus inexacte encore, car l'auteur laisse penser que plus un réseau pair-à-pair est accessible facilement, plus il sera résilient. Ce qui est faux ! Par exemple, des études montrent que les protocoles non structurés (ex : Gnutella) sont plus résilients que les DHT.

Même si j'apprécie le journal, une ignominie s'y est introduite, et je ne peux pas la laisser passer :

À la différence des protocoles P2P classiques, le protocole réseau se veut résilient et difficilement filtrable

J'ai retrouvé cette « connerie » sur le site de Teaponet. Le fait est que les auteurs comparent Teaponet avec Bittorent Sync et font deux erreurs :

• Ils confondent résilience (capacité du protocole à absorber les pannes, coupures de réseaux, comportements byzantins, etc) et facilité d'utilisation (ce connecter sans avoir à configurer un NAT manuellement). Et là, je dis : « au bûcher ! ».
• Ils ré-inventent, semble t'il le principe du « Nat-traversal » avec relais, au dessus de HTTP. Donc pour moi, cela n'apporte rien par rapport à Bittorent Sync, qui semble très bien fonctionner derrière un NAT avc Upnp ou autre. Sur ce coup là, j'ai peut-être raté une subtilité, alors je reste calme :)
• Dans la vie (des P2P hackers) il n'y a pas que Bittorent Sync, loin de là. J'inclurais dans les classiques au moins Gnutella, Pastry, Tapestry, Chord, CAN, qui sont la base de tous les autres (le fait est que la plupart ne fonctionnent par derrière un NAT, mais présentent, au moins via des extensions, une résilience certaine et qui a fait ses preuves). Donc là encore : « au bûcher ! ».

Si Teaponet prend le l'ampleur, il se peut que j'aille y mettre mon grain de sel, pour éclaircir cette méprise vis à vis des protocoles pair-à-pair.

Sinon l'initiative à l'air sympathique, si ce n'est que je n'ai pas trouvé de documentation sur le protocole en lui même (Je vais pas lire du C++ quand même !). Bref, merci pour le journal, Teaponet à l'air bien, mais pour un intégriste du P2P comme moi, une phrase comme :

À la différence des protocoles P2P classiques, le protocole réseau se veut résilient et difficilement filtrable

implique un déshonneur à tous les hackers de protocoles pair-à-pair, ce qui…. mérite le bûcher !

Il y a pas de problème, je dis juste qu'il faut peut être être développeur de ce code là pour comprendre le choix du fork (le diable étant dans le détail et donc hors de portée des non-développeurs Bitcoin/Namecoin).

Celui de la clef privée donc ! L'autre étant commun à tous, si je ne me trompe pas.

Tu peux appeler cela "fermer son compte".

Oui sachant que les nœuds qui stockent de la donnée pourraient supprimer (selon leur bon vouloir) les données associées à un compte « en fermeture ».

Sinon, je ne comprend pas de quel mot de passe on parle, puisque l'authentification se fait par crypto asymétrique avec un couple clé publique/ clé privée. Il y a bien un mot de passe local, pour le clef privée et pour le compte bitcoin, mais ils ne sont utilisés que localement (et encore je crois que le couple user+password Bitcoin est le même pour tous).

Ai-je raté une étape ?

La correction aura encore plus d'effet sur la page Wikipedia de Namecoin et sur la page de référence de Namecoin, car les deux pages citées font le même amalgame. Cela se comprend, car très peu de gens, en dehors des « académiques » et autres chercheurs, parlent de « protocoles de nommage », même si c'est le terme correct.

Encore une preuve que l'élite se trouve sur DLFP :)

Il existe déjà un système P2P d'attributions de noms basé sur le principe de bitcoin: Namecoin. Pourquoi ne pas avoir réutiliser Namecoins plutot que de diviser les efforts?

Un indice de réponse : la présence de développeurs Bitcoin dans les premiers contributeurs de Twister. Ils sont parti du code qu'il connaissent et qu'il maîtrisent, je pense, simplement.

Cela ne doit pas empêcher de repartir de Namecoin, si la POC s'avère être une réussite. Après pour tout savoir, il faudrait demander directement aux développeurs :)

-Comme tu dis, rien contre le namesquatting: dès que ça aura un peu de succès, ça sera un joyeux bordel

On peut prévenir le « namesquatting », mais en décentralisé c'est compliqué : il faut une autorité centralisée pour décider de l'attribution des noms (comme dans les solution non p2p) et ça marche pour les utilisateurs qui sont d'accord pour faire confiance à cette autorité. C'est compliqué à mettre en œuvre, donc inutile pour une POC, mais ça reste faisable.

-Peut-on récupérer un mot de passe perdu avec le protocole Bitoin? Rappelons que les solutions "soyons bien organisé" ne marchent pas avec le grand public. Réponse dans la FAQ: non, on ne peut absolument plus rien faire une fois la clé privée perdue.

La dessus : générer un certificat de révocation devrait pouvoir résoudre le problème, mais je suis d'accord avec toi : on en est pas encore à faire comprendre tout ça à Mme Michu.

-Peut-on effacer un compte et les données associées?

Idem, pour moi c'est faisable (peut être difficilement), mais une fonctionnalité à mettre dans la beta.

-Peut-on facilement faire une interface web (oui oui, une interface web, centralisée, tout ça) pour permettre à l'internaute moyen de découvrir le service avant de l'installer sur sa machine? Ça suppose un client anonyme pour regarder les contenus publics, ou un client qui tient une sacrée charge de comptes poubelles.

Je ne vois rien qui l'empêcherait, si ce n'est le coût d'hébergement du serveur de test.

Globalement, il faut retenir que c'est une « POC », c'est-à-dire un prototype destiné à être utilisé par des experts (c'est clairement mentionné sur le site). Son objectif est de valider la faisabilité du projet, puis peut-être d'évoluer vers une version plus « user friendly » dans l'avenir.

Il faut laisser le temps aux choses de se mettre en place :)

Tes remarques sont justes, mais je rappelle que c'est vendu comme étant une « POC », donc même pas une version alpha.

Il faut bien commencer petit pour valider la faisabilité :)

confidentialité dans le sens ou il n'y aurait que ton noeud qui dispose de tes données, et pas les serveurs de google, twitter, facebook

Pas « que ton nœud » justement, le stockage des messages est fait dans la DHT et n'importe qui peut mettre un serveur dans la DHT car le réseau est public. Le chiffrement sert, entres autres, à certifier la source et à authentifier l'auteur d'un message.

Enfin, à moins que tu appelles données tout ce qui n'est pas message.

Je viens de voir en compilant que « miniupnpc » fait parti des dépendances (pour faire le NAT-traversal) et qu'il existe un projet « twister-seeder » permettant de faire tourner une « graine » DNS. Ce qui tendrait à confirmer tes dires.

Tant mieux !

Bitcoin sert simplement à enregistrer son pseudo de manière unique sur le réseau et s'authentifier

Bon, je grince des dents, mais je suis forcé de reconnaître que c'est à tort : faire un protocole d'identification décentralisé, robuste et éprouvé, c'est pas facile ! Et il faut reconnaître que Bitcoin réussi plutôt bien dans ce domaine. J'aurais pris un serveur centralisé pour gérer les comptes dans la V1 (comme le fait Skype depuis des lustres avec succès), mais bon, passons.

Quant à JKLM, je grince aussi des dents (probablement à tort encore), en voyant que c'est du « Mac OS only » pour le moment (compilable sous Linux apparemment).

Une question de première importance, faut-il avoir une adresse IP publique pour que cela fonctionne ou Twister sait-il faire du « NAT traversal » ? Dans la négative, cela limitera le nombre d'« early users » (moi au boulot par exemple). Je sais que c'est difficile à faire, mais ce que je constate depuis que je m'intéresse au P2P, c'est que les protocoles qui ne le proposent pas ont la vie courte :(

Je vais surveiller Twister de près, merci pour le lien.

Le P2P, c'est pour les chiens ?

Non, mais avec un client et un serveur, je préfère ftp :)

Merci pour la réponse :)

Bonjour et félicitation pour l'initiative !

Je vois que vous mentionnez HornetQ dans les briques utilisées. Travaillant dans une équipe qui développe un concurrent français d'HornetQ (JORAM, présenté ici il y à 10 mois), libre également, je me permet de vous demander simplement : connaissez-vous JORAM ? l'avez vous évalué ? et éventuellement, pourquoi avoir choisi HornetQ ?

Merci d'avance si vous pouvez répondre à ma question.

Mon passage préféré :

Le Crédit agricole a tenu à démentir « tout lien entre les deux incidents rapportés », et rappelle au passage qu'il « traite quotidiennement des millions d'opérations similaires dans de bonnes conditions ».

Ils ne sont pas joueurs quand même, ils ratent une occasion de bonne publicité et préfèrent passer pour des branquignoles. Moi une banque qui me verse mon salaire en double, je suis prêt à essayer.

Le problème n'est pas que c'est illégal, mais qu'effectivement ce n'est simplement pas possible de renoncer à ces droits d'auteur. Je ne pense même pas que la publication anonyme soit possible (à vérifier), c'est-à-dire que si un auteur met à disposition une œuvre sur un site lambda, le site en question peut être tenu pour auteur. C'est du droit, alors je ne suis pas sûr d'interpréter la chose comme il faut, mais c'est ce que j'ai compris en tous cas : le droit d'auteur est attribué automatiquement, sans qu'on ai besoin de le revendiquer.

Finalement, en France le CC0 n'est pas mal, il se rapproche au plus possible d'une cessation au domaine public.

Allez j'ose, même si je peux m'attirer les foudres de ceux qui n'apprécient pas la prolifération des licences,te conseiller la licence CeCILL standard, la première étant compatible GPL (et même en fallback GPL en cas de "doute", par ex une partie du code est GPL, le GPL contamine tout le projet sous licence CeCILL) et les trois licences CeCILL sont protégées par le droit français.

Le problème des licences françaises est leur visibilité à l'internationale. J'hésite toujours à mettre mon code sous CeCILL et je me ravise en me disant que les non-français y pigeront rien et que cela peut nuire à la diffusion/adoption de mon code à l'international. J'espère avoir tort, mais comment savoir ?

Une question dans ce sens :

Considères-tu ce projet comme pouvant aider ta carrière professionnelle, ou plutôt comme un projet strictement fun et qui restera toujours un hobbi ? Dans le second cas, reste sur du copyleft, dans le premier cas je ne suis pas sûr. Plus précisément :
Est-ce que ça te dérangerait si un gros éditeur de jeux vidéo proposait de t'embaucher à prix d'or pour faire une version non-libre utilisant ton moteur libre ? Est-ce un de tes objectifs ? Si oui, le copyleft n'est peut être pas le meilleur choix.

Après c'est un pari, un éditeur peut aussi utiliser ton code sans toi, c'est le risque du non copyleft.

Sympa l'idée du shoot'em up :)

Sinon pour la licence, tu peux utiliser le site « http://choosealicense.com/ ». Pour le code la GPL paraît répondre à tes souhaits (du copyleft). Pour les sprites et autres objets graphiques, tu peux utiliser une licence différente, soit complètement propriétaire, soit choisir une licence Creative commons avec les clauses qui te plaisent.

Et n'hésites pas si tu as besoin de plus de précision. Les réponses devraient être nombreuses :)

Effectivement !

En plus pour trouver des infos sur les gens qui sont derrières, il ne faut pas compter sur le site.
Contenu de la page « Qui sommes nous ? »

Accueil, Qui sommes-nous
Qui sommes-nous?

Notre réseau de ventes couvre la plupart des villes majeures dans nombreux pays et nos produits se vendent actuellement bien en Amérique du Nord, l'Australie et l'Europe. Comme une société de prestige, nous continuerons avec nos efforts incessants à améliorer nos produits et fournirons à nos clients le meilleur service dans la mesure du possible. Nous vous invitons à nous contacter immédiatement et espérons que vous ferez des affaires avec nous.

Notre Ambition

Nous comptons sur les clients pour vérifier tous les détails des commandes et nous fournir les informations correctes si bien que nous pouvons livrer sans erreur une commande le plus vite possible. Si une commande ne peut pas arriver à destinataire à cause d'une mauvaise adresse, ou si le client s'est trompé sur la commande, il sera facturé pour les frais de réexpédition.

Le paiement sécurisé en ligne

Nous ne vous demandons jamais de communiquer les informations de carte de crédit sur xxxxxxx . Les paiements effectués avec une carte de crédit sur Paypal sont sécurisés par Paypal, ainsi que les informations concernant ces opérations. Grâce à Paypal, votre achat sur xxxxxxx sera plus rapide, pratique et sécurisé.

A noter: xxxxxxx ne conserve aucune information concernant votre paiement par carte de crédit ainsi que vos informations privées. En cas de problème concernant la transaction bancaire ou autres, veuillez prendre contact avec Paypal.com ou l'établissement bancaire distributeur de votre carte pour bénéficier d'une assistance. xxxxxxx n'est responsable d'aucun de vos paiements effectués par la carte de crédit ou de débit. Ces entreprises sont faites dans le seul but d'identifier les fabricants d'ordinateurs avec lesquels nos produits (sont de remplacement pour) peuvent être utilisés. Notre société et le site ne sont ni affiliés avec, ni autorisés par, ni une licence par, ni les distributeurs pour, ni liés en aucune façon à ces fabricants d'ordinateurs, pas plus que les produits proposés à la vente sur notre site construits ou vendus sous l'autorisation des fabricants d' ordinateurs avec lesquels nos produits [sont de remplacement pour] peuvent être utilisés.

Ça sent la grosse arnaque non ?

À ce propos, quelqu'un connaît une démarche « intelligente » à faire quand on découvre un site comme ça ?

NdM: les liens ont été masqués

Un nouvel article vient d'enrichir ce dossier : Le fouillis des licences open data s’éclaircit.

Le lien n'est pas bon pour moi :(

Allez je leur fait de la pub, car je les aime bien : les gens de cozy cloud proposent une application bookmark.

Tu peux essayer la démo ici.