Journal Teapotnet, un réseau social privé pour l'échange de fichiers

35
17
jan.
2014

Bonjour Nal,

Je te présente ici Teapotnet (site en anglais), un réseau social libre, privé et décentralisé facile d'utilisation orienté vers l'échange de fichiers. Il se veut une tentative de reprise en main de la vie privée sur Internet.

Teapotnet est une manière alternative de fournir un service libre de cloud privé. Il se présente comme un réseau social distribué et privé de type ami-à-ami axé sur l'échange de fichiers, avec une interface Web facile à prendre en main. Le programme lui-même est développé en C++ sous AGPLv3 et est multi-plateforme, il est compilable sans bibliothèque externe spécifique et n'utilise que des API POSIX, ainsi que quelques équivalents Win32 dans le cas de Windows. L'interface Web repose sur une bonne dose de Javascript avec l'excellente bibliothèque jQuery.

Les contacts sont localisés et les sessions chiffrées avec un système cryptographique à secrets pré-partagés. Ajouter un contact est donc simple : il suffit de connaitre l'identifiant du contact et le secret commun. Cependant, pour des raisons de facilité, un système d'invitation centralisé utilisant des emails a été ajouté en supplément. À la différence des protocoles P2P classiques, le protocole réseau se veut résilient et difficilement filtrable, il peut au besoin imiter des sessions HTTP dans un environnement réseau limité (pare-feu, proxy, etc), et prévoit un système de redirection pour les clients derrières des NAT, bien que le support de l'UPnP et du NAT-PMP permette de configurer automatiquement la plupart des routeurs domestiques.

Un aspect intéressant est qu'il permet de lire des fichiers distants en direct et de fournir ainsi une forme de "streaming" dans un lecteur externe (par exemple VLC). La reprise des téléchargements après coupure et le téléchargement multi-sources (bienvenu dans le cas du débit montant indigent de l'ADSL) sont supportés.

Il est possible d'accéder facilement aux fichiers d'un contact ou d'un autre appareil où il est installé, et la possibilité d'autoriser l'accès aux fichiers des amis d'amis est en développement.

Les fonctions de réseau social sont basiques :
- Messages privés (sous forme de chat)
- Messages publics (sous forme de news feed)
- Possibilité de lier des fichiers de n'importe quelle taille
- Support simpliste des avatars et des profils

Des versions précompilées sont disponibles pour Microsoft Windows, Mac OS X et Android (Google Play, bientôt F-Droid), et un paquet AUR permet de faciliter l'installation sous Arch Linux. Des paquets Debian et Ubuntu seront disponibles prochainement.

  • # Teapotnet ?

    Posté par . Évalué à 3. Dernière modification le 17/01/14 à 09:35.

    Heureusement que c'est un pot de thé, si c'était un pot de miel, j'aurais eu des doutes sur les intentions de l'auteur.

    Y'a-t-il un lien avec camlistore http://camlistore.org/ ? C'est une sorte de système de fichier qui peut d’héberger n'importe ou, avec une couche de cryptographie.

    "La première sécurité est la liberté"

    • [^] # Re: Teapotnet ?

      Posté par (page perso) . Évalué à 3.

      C'est assez proche, Camlistore est un projet vraiment sympa. La différence majeure est que Teapotnet n'est pas spécifiquement un système de stockage, il permet aussi d'envoyer des messages et ainsi de fournir une sorte de réseau social (avec synchronisation des messages et contacts entre les instances). Il est plus orienté vers l'accès à des fichiers distant qu'au stockage proprement dit.

      Bref, pour stocker mes fichiers entre un NAS et un serveur Amazon, Calimstore semble très bien. Pour accèder aux photos et vidéos que mes parents ont pris en vacances, Teapotnet est tout à fait indiqué.

  • # Au bûcher !

    Posté par (page perso) . Évalué à 3. Dernière modification le 17/01/14 à 09:48.

    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 !

    • [^] # mea culpa

      Posté par (page perso) . Évalué à 3.

      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.

      • [^] # Re: mea culpa

        Posté par . Évalué à 2.

        T'aurais une source pour cette histoire de structure (Gnutella vs DHT) ?

        • [^] # Re: mea culpa

          Posté par (page perso) . Évalué à 2.

          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.

          • [^] # Re: mea culpa

            Posté par . Évalué à 2.

            Si tu les cites dans ta thèse, ça me va aussi, je bosse sur l'auto-organisation et justement la question d'avoir une structure particulière ou non est un de mes intérêts du moment :)

        • [^] # Re: mea culpa

          Posté par (page perso) . Évalué à 2.

          Alors , pour comprendre pourquoi les DHT ne sont pas très résilientes par nature : un article Usenix de référence.

          Pour ce qui est du reste, les protocoles non structurés ont une résistance naturelles plus forte au churn (dynamisme du réseau lié aux départs/arrivées des pairs). J'ai déjà fait l'expérience (en simulateur) de faire tomber 60% du réseau sur un système utilisant des protocoles épidémiques pour maintenir la structure du réseau, et ça tient !

          Pour approfondir les réseaux non structurés, tenant compte du NAT, il faut commencer par le papier « NAT-resilient Gossip Peer Sampling », malheureusement il n'est pas libre, comme beaucoup de papier de recherche. Je pourrais vous en faire un résumé au besoin.

          • [^] # Re: mea culpa

            Posté par (page perso) . Évalué à 3.

            C’est d’ailleurs dommage qu’il ne soit pas sur HAL (archives-ouvertes), car il est quand même écrit (en partie) par deux chercheurs INRIA.

            • [^] # Re: mea culpa

              Posté par . Évalué à 3.

              Certainement l'éditeur qui ne veut pas, malheureusement, c'est pas parce que c'est fait avec les sous du contribuable sur le temps des chercheurs publics avec aucun travail de l'éditeur que l'on a le droit de rendre le document accessible :( c'est complètement stupide mais bon.

              Le document est accessible si tu es dans une université qui a un accès à IEEE, ce qui est le cas d'à peu prêt toutes les universités, je pense que c'est pour ça tout le monde s'en fout que le document ne soit pas sur HAL.

              • [^] # Re: mea culpa

                Posté par (page perso) . Évalué à 0.

                Le document est accessible si tu es dans une université qui a un accès à IEEE, ce qui est le cas d'à peu prêt toutes les universités, je pense que c'est pour ça tout le monde s'en fout que le document ne soit pas sur HAL.

                Je ne suis pas tout à fait d'accord, tes arguments préalables sont valables. Maintenant que je ne travaille plus pour la recherche je n'ai plus accès à ces articles et je suis bien embêté. Si les prix des articles étaient raisonnables cela m'ennuierait moins, mais généralement c'est prohibitif pour un jeune hacker libriste :)

                • [^] # Re: mea culpa

                  Posté par . Évalué à 3.

                  Oui oui, je ne dis pas que c'est justifié, je dis juste que c'est certainement pour ça que tout le monde s'en fout :)

          • [^] # Re: mea culpa

            Posté par (page perso) . Évalué à 5.

            il faut commencer par le papier « NAT-resilient Gossip Peer Sampling », malheureusement il n'est pas libre

            Tu pourrais aussi le faire tomber par inadvertance, et il se trouverait qu'on le ramasserait, mais que ne retrouvant pas le propriétaire, on le lirait. Par pure curiosité scientifique.

            • [^] # Re: mea culpa

              Posté par (page perso) . Évalué à 2.

              Tu pourrais aussi le faire tomber par inadvertance, et il se trouverait qu'on le ramasserait, mais que ne retrouvant pas le propriétaire, on le lirait. Par pure curiosité scientifique.

              J'aime cette idée ! Mais je préfère le donner par mail à ceux qui le veulent. D'ailleurs j'en ai plein d'autres…

              Puisqu'il y a des courageux masochistes dans l'assistance, il y a la thèse d'Alessio Pace qui résume développe le papier en une quarantaine de pages. Plus sérieusement, si certains sont intéressés pour s'instruire sur les réseaux pair-à-pair non structurés, je conseille la thèse d'Alessio qui est très bien faite. Pour les non anglophones, vous pouvez lire la mienne aussi, mais c'est plus généraliste et le protocole en question n'y est pas décrit.

    • [^] # Re: Au bûcher !

      Posté par (page perso) . Évalué à 3.

      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.

      Le NAT n'a pas grand rapport avec cet aspect. Je sais bien qu'une bonne partie des protocoles P2P dignes de ce nom fonctionnent derrière des NAT, et heureusement d'ailleurs ! Je disais seulement que le NAT traversal fonctionnait. 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.

      Désolé pour la doc, ça sera vite disponible !

      • [^] # Re: Au bûcher !

        Posté par (page perso) . Évalué à 7.

        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…

  • # Intéressant mais...

    Posté par . Évalué à 2.

    Il y a juste un truc que j'ai pas capté : c'est quoi ce truc "tracker" quand on créé son compte ?

    Est-ce qu'il faut qu'un truc particulier tourne sur l'adresse de ce "tracker" ? Est-ce que ça correspond à l'adresse de la machine où tourne le daemon ?

    • [^] # Re: Intéressant mais...

      Posté par (page perso) . Évalué à 2.

      Pour l'instant la localisation des pairs est fournie par des trackers uniquement. Le tracker est simplement une table pour relier des hashs anonymisés à des adresses sur le réseau. Il est possible d'en déployer un avec l'option --tracker en ligne de commande (et éventuellement rediriger avec le serveur web déjà présent les requêtes sur l'URL /tracker), mais un tracker en PHP, nettement plus simple à déployer, sera bientôt disponible.

      Un tracker fonctionne à l'adresse teapotnet.org, et il est utilisé par défaut.

  • # Excellente idée

    Posté par . Évalué à 3.

    Super projet, je découvre seulement. L'idée est simple (même si techniquement ça doit être un sacré challenge) et efficace.

    Par contre, s'il y en a qui ont essayé, on peut avoir des retours ? Peut-on configurer la taille maximum qu'on est prêt à dédier à "héberger les fichiers des autres" ? Qu'en est-il des débits ? Ca plombe pas trop le système et notre connexion internet si un peer se met à télécharger un de ses fichiers à partir de chez nous ?

    • [^] # Re: Excellente idée

      Posté par . Évalué à 1.

      J'ai essayé et j'utilise tpn quotidiennement avec quelques amis. J'ai pas grand chose à dire de particulier : ça fonctionne.
      Au niveau des débits, je pense que ça fournit le max, mais je n'ai pas fait de test d'utilisation de ma connexion pendant un upload important. Je ne suis pas au courant d'une config plus précise (mais je n'ai pas cherché non plus !).

  • # RetroShare

    Posté par . Évalué à 6.

    Cette description de Teapotnet me fais beaucoup penser au logiciel Retroshare, qq sait si il y a un lien entre les deux ?

    • [^] # Re: RetroShare

      Posté par (page perso) . Évalué à 4.

      Effectivement, ça m'a tout l'air d’être du retroshare avec la capacité de se faire passer pour du HTTP pour passer les pare-feu nazis. L’énorme avantage que je vois a retroshare est qu'il ne s’arrête pas aux amis mais peut aller sur l'ensemble du réseau via les amis des amis des amis […] sans pour autant dévoiler son identité.

      • [^] # Re: RetroShare

        Posté par (page perso) . Évalué à -1.

        peut aller sur l'ensemble du réseau via les amis des amis des amis […] sans pour autant dévoiler son identité.

        Retroshare le fait depuis 10 ans.

        http://devnewton.bci.im

        • [^] # Re: RetroShare

          Posté par (page perso) . Évalué à 3.

          Faut croire que je sais pas m'exprimer. Ce que tu cites est justement ce que sait faire Retroshare qui en fait une plateforme super intéressante et qui n'a pas l'air d'exister dans HoneyTeaPotNet

          • [^] # Re: RetroShare

            Posté par (page perso) . Évalué à 3.

            Je t'avais compris, je pense que devnewton t'a lu un peu vite.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: RetroShare

      Posté par . Évalué à 2.

      Réponse a moi meme , au niveau du code, rien de commun par contre c est plus simple a prendre en main ( et plus pauvre en fonction )
      Dommage de ne pas avoir réutiliser le coeur de retroshare celui ci ayant été séparer de l' interface en qt exprès pour pouvoir plus facilement l utiliser dans le cas d une interface web

      • [^] # Re: RetroShare

        Posté par . Évalué à 3.

        le coeur de retroshare […] ayant été séparer de l' interface en qt exprès pour pouvoir plus facilement l utiliser dans le cas d une interface web

        C'est effectif ce truc-là? Parce que c'était un des gros trucs bloquants, et que la dernière fois que j'ai testé c'était encore inexploitable sans interface graphique.

        Pour revenir à TPN, quelques questions :

        • si on indique le "tracker" à l'ajout de contact, c'est qu'on peut envisager de communiquer entre utilisateurs de différents trackers?
        • si on souhaite faire tourner son propre tracker, on fait comment?

        En tous cas, ça a l'air simple et propre, à suivre.

        • [^] # Re: RetroShare

          Posté par . Évalué à 2.

          Je me réponds tout seul, mais ça m'apprendra à lire : le tracker se lancer avec ./teapotnet --tracker. Voilà voilà.

          • [^] # Re: RetroShare

            Posté par (page perso) . Évalué à 2.

            Exact, ./teapotnet --tracker [mon_port] lance un tracker sur le port indiqué. Le plus pratique est ensuite de transférer sur le serveur web local le chemin /tracker sur http://localhost:[mon_port] (ProxyPass dans le cas d'apache)
            Pour répondre à ton autre question, on peut évidemment ajouter comme contacts des utilisateurs sur d'autres trackers. À noter que le tracker sert surtout à bootstrapper car les instances retiennent les adresses des contacts.

            • [^] # Re: RetroShare

              Posté par . Évalué à 2.

              Donc tu confirme, le tracker est du HTTP? Le protocole est fort complexe? Il y a un peu de crypto dessus?

              • [^] # Re: RetroShare

                Posté par (page perso) . Évalué à 3.

                Oui, le tracker utilise des requêtes HTTP par simplicité.
                Le protocole lui-même est sur TCP, c'est un protocole texte relativement simple (malheureusement il n'y a pas encore de doc digne de ce nom), et toutes les connexions sont chiffrées avec AES après authentification et dérivation des clés de session. La négociation avant chiffrement est obfusquée en chiffrant avec une clé préétablie pour éviter des motifs facilement filtrables. Actuellement les dérivations de clés sont faites avec PBKDF2 (HMAC-SHA512, 10000 iterations). La méthode actuelle ne permet pas la confidentialité persistante pour l'instant mais cela pourrait être implémenté à l'avenir.

                • [^] # Re: RetroShare

                  Posté par . Évalué à 4.

                  (Note: c'est quoi l'intérêt de le moinsser systématique? il répond aux questions qu'on/je lui pose, non? bref.)

                  (Note2: c'est bien toi qui est à l'origine du truc, Paulo? si ce n'est pas le cas, merci d'ignorer consciencieusement tout ce qui suit).

                  Ok. J'ai rien contre les requêtes HTTP, au contraire. Après tout, ça ne sert que pour l'établissement de la liste de contacts, si j'ai bien compris. Et limite ça vaudrait le coup de parler divers "dialectes" permettant ce genre de choses (XMPP, …).

                  Le seul truc que je trouve un peu dommage sur l'établissement des relations, c'est de ne pas pouvoir directement échanger la clé publique complète dans les cas où c'est possible (à la Retroshare, donc). Le tracker est très bien, mais ça serait plus sympa de pouvoir faire l'échange d'infos (clé+IP, je suppose) par le moyen de notre choix (si ça se trouve, j'ai un compte SSH sur le serveur de mon contact, et souhaite lui filer mes infos par ce biais, qui sait).

                  Ceci étant, j'ai jeté un coup d’œil rapide. En résumé, j'aime beaucoup :

                  • la compilation se passe sans souci, ça donne une impression de simplicité. Pas de dépendances bizarres (camlistore, si tu me lis), pas de warnings, rien. Bravo.
                  • ça ne nécessite pas d'installation, ni de droits root, ni rien. Ok, ça ne devrait pas en avoir besoin de toutes manières. Mais quand on voit ce qu'on voit de nos jours…
                  • l'interface web est bien, dans l'ensemble. On trouve ce qu'on cherche, c'est cohérent et sobre. C'est réactif.

                  Ce que j'ai moins aimé (ou pas encore compris) :

                  • entre deux utilisateurs NATés, je n'ai jamais pu obtenir de connexion directe. J'ignore les paramètres de leurs NAT, mais c'est un peu rebutant. Heureusement, le fait de rajouter un troisième larron (à chacun des deux) non-NATé a réglé le problème.
                  • par contre, la mise en relation est leeeenntte. Compter plusieurs minutes (jusqu'à une petite dizaine, je dirais) avant de voir tout le monde comme Online (le "Found" est quasi instantané par contre, mais c'est d'autant plus frustrant). C'est d'autant plus incompréhensible s'il n'y a pas de passage de NAT.
                  • quelques incohérences/imprécisions dans l'interface. Type "Send another file" comme bouton d'envoi de fichier (même pour le premier fichier). Ou le bouton "Refresh" sur mes dossiers partagés (puisqu'apparemment ce n'est pas un dossier local, mais un espace vers lequel j'ai uploadé des choses, il ne devrait pas avoir besoin de se rafraîchir, si?).
                  • la licence dans /static n'est pas claire. Elle parle à la fois de BY-SA et de NC. Quid?
                  • ça n'a pas l'air d'être prévu pour l'i18n. C'est un peu dommage.

                  Enfin ce qui pourrait valoir le coup, selon moi, pour des versions futures :

                  • un mode multi-utilisateur. C'est con, mais ça arrive que toute la famille utilise le même ordinateur. Certes, on peut lancer un teapotnet par personne sur un port différent (enfin je suppose que ça marcherait), mais ça serait sympa aussi de ne pas tout lancer en triple, d'autant que ça aiderait pour le point suivant.
                  • des identités. Je n'ai pas forcément envie de partager la même chose avec mes parents, mon patron et mes compagnons de beuverie. Le point ci-dessus fournirait un palliatif suffisant selon moi (i.e. je change d'utilisateur selon mes envies, pas besoin de "lier" mes différentes identités plus que cela).
                  • dans la mesure où ça s'y prête, une ouverture à d'autres types de communication : VPN "ad hoc" (à la Hamachi/n2n), V/V, …

                  Les points ci-dessus sont évidemment à prendre avec des pincettes : la force principale de ton truc me semblant être une relative simplicité, au moins apparente. Ce qui joue nettement en sa faveur par rapport à RetroShare, par exemple (i.e. je mets plus facilement ma maman devant TPN que devant RS si je veux éviter de devoir intervenir dessus toutes les semaines). Ce serait donc dommage de perdre un tel atout en voulant trop embrasser.

                  • [^] # Re: RetroShare

                    Posté par (page perso) . Évalué à 2.

                    Merci pour tes tests exhaustifs et tes retours très instructifs. Je suis effectivement à l'origine du projet même si maintenant on est deux.

                    entre deux utilisateurs NATés, je n'ai jamais pu obtenir de connexion directe. J'ignore les paramètres de leurs NAT, mais c'est un peu rebutant. Heureusement, le fait de rajouter un troisième larron (à chacun des deux) non-NATé a réglé le problème.

                    En fait il faut au moins que l'un des deux noeuds ait un ami non NATé. Ce sera étendu quand on pourra faire des requêtes aux amis d'amis.

                    par contre, la mise en relation est leeeenntte. Compter plusieurs minutes (jusqu'à une petite dizaine, je dirais) avant de voir tout le monde comme Online (le "Found" est quasi instantané par contre, mais c'est d'autant plus frustrant). C'est d'autant plus incompréhensible s'il n'y a pas > de passage de NAT.

                    C'est bizarre, je ne sais pas trop d'où ça vient. En tout cas c'est un bug, ça devrait aller raisonnablement vite (quelques dizaines de secondes tout au plus).

                    quelques incohérences/imprécisions dans l'interface. Type "Send another file" comme bouton d'envoi de fichier (même pour le premier fichier). Ou le bouton "Refresh" sur mes dossiers partagés (puisqu'apparemment ce n'est pas un dossier local, mais un espace vers lequel j'ai uploadé des choses, il ne devrait pas avoir besoin de se rafraîchir, si?).

                    C'est vrai, l'interface est encore un peu "brute" et demande à être améliorée. Le bouton refresh sert quand certains partages sont définis avec des dossiers déjà présents (avec "Add existing directory"), car dans ce cas des fichiers peuvent avoir été ajoutés de l'extérieur de Teapotnet, et les dossiers de ce type ne se ont pour l'instant pas surveillés, juste réindexés incrémentalement à intervalles réguliers.

                    la licence dans /static n'est pas claire. Elle parle à la fois de BY-SA et de NC. Quid?

                    Je vais jeter un oeil à ça.

                    ça n'a pas l'air d'être prévu pour l'i18n. C'est un peu dommage.

                    Exact, c'est dommage. Ça serait une fonction utile à ajouter.

                    Pour les versions futures, c'est presque exactement ce que l'on veut ajouter ! Les utilisateurs et identités sont en fait juste une question d'interfaçage, le programme gère déjà des utilisateurs multiples. Il est d'ailleurs possible d'ajouter des utilisateurs comme décrit dans INSTALL: echo myusername mypassword > users.txt puis lancer Teapotnet qui lit puis supprime le fichier.

                    Mais comme tu le dis, notre objectif principal et de rester simple d'utilisation.

                    • [^] # Re: RetroShare

                      Posté par (page perso) . Évalué à 2.

                      une version native du client en Qt est-elle prévue ?

                    • [^] # Re: RetroShare

                      Posté par . Évalué à 2.

                      En fait il faut au moins que l'un des deux noeuds ait un ami non NATé. Ce sera étendu quand on pourra faire des requêtes aux amis d'amis.

                      En attendant (ou pas, d'ailleurs), pourquoi ne pas profiter des infrastructures STUN existant (et de l'ensemble d'ICE, si on va pas là)?

                      C'est bizarre, je ne sais pas trop d'où ça vient. En tout cas c'est un bug, ça devrait aller raisonnablement vite (quelques dizaines de secondes tout au plus).

                      Je n'ai pas vraiment pu le reproduire de manière fiable, hélas.

                      C'est vrai, l'interface est encore un peu "brute" et demande à être améliorée. Le bouton refresh sert quand certains partages sont définis avec des dossiers déjà présents (avec "Add existing directory"), car dans ce cas des fichiers peuvent avoir été ajoutés de l'extérieur de Teapotnet, et les dossiers de ce type ne se ont pour l'instant pas surveillés, juste réindexés incrémentalement à intervalles réguliers.

                      Oui, j'ai fini par trouver tout seul. Et c'est vrai que c'est plutôt sympa.

                      Exact, c'est dommage. Ça serait une fonction utile à ajouter.

                      Voire indispensable pour toute une catégorie d'utilisateurs (dont nos mamans).

  • # Restroshare

    Posté par . Évalué à 3. Dernière modification le 17/01/14 à 11:56.

    Comment ça se compare avec Retroshare ?

    edit: grillé…

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.