 Je vais commencer avec une overview du software, puis je vais parler de ce système de gXS. Finalement, je vais vous expliquer comment vous pouvez utiliser pour créer l'application décentralisée. C'est plus d'aide pour les développeurs parce qu'on a vraiment besoin de les développeurs dans notre équipe. Donc, RetroShares est une de nos links. Pour cela, nous utilisons TLS, et nous utilisons TLS sur TCP, UDP, mais aussi sur Tor optionnellement et I2P. Donc, sur le top de cela, nous avons implementé quelques services qui permettent de distribuer des données. La première, c'est le transfert de combat. C'est un transfert de combat en cryptique anonymé avec des capacités d'armée. Un système d'email qui est complètement synchronisé. Un chat distribué qui fonctionne comme IRC, des forums, et des canons qui permettent aux utilisateurs de distribuer des données authentiquées en permettant d'assurer que les utilisateurs puissent commenter sur le poste. Donc, RetroShares est disponible sur macOS, Linux, Windows. C'est aussi en train d'être disponible sur Android. Nous avons un prototype. Le projet est au bout de 10 ans. JXS est principalement créé par Dr. Bob, Chris et moi-même. Nous n'avons pas beaucoup d'utilisateurs. C'est difficile d'estimer exactement ce qu'il y a. Mais nous l'estimons à être des milliers d'utilisateurs similitaires, qui nous expliquent que c'est très difficile pour bootstrap. Quand vous installez le software, vous devez connecter avec quelqu'un. Si vous êtes seul, vous n'aurez pas de données. Donc, vous devez convaincre votre ami pour l'utiliser ou vous joindre une existing network. Mais, quand vous avez terminé, vous devez être parfaitement décentralisé pour ne pas s'occuper d'un network confidentiel. Donc, c'est tout implémenté dans C++. Il dépend des libraries standard. Et nous avons une interface graphique en QT. Et tous ces systèmes, chanels, forums, e-mails, ils sont tous basés sur le même système de distribution abstract, qui est le sujet de cette présentation. Donc, qu'est-ce qui est le problème ? Nous avons une maitre de compétences qui ne parlent qu'à leurs voisins. Et nous voulons distribuer des données sur les amis. Et nous voulons faire ça en favorisant des contenus intéressants, préférablement, mais aussi en préventant des attaques fluides, des spams, et donner des garanties d'authentication ou des anonymités, selon le genre d'utilisation. Et enfin, le network ne ressemble pas à ce nice graphique. Il ressemble à quelque chose comme ça. C'est un snapshot de ce que je peux voir Et comme vous pouvez le voir, des gens ont beaucoup de friends, des gens n'ont pas. Et aussi, ces connections, elles ne peuvent pas travailler en temps d'exchanger des données. Donc, nous devons être robustes pour tous ces problèmes. Donc, nous avons designé ce genre d'exchange système, qui s'appelle GXS. Et il s'occupe de la distribution, d'authentication, de privacy et de données. Et il s'agit de deux principes. Le premier, c'est que les abonnés s'advertissent aux friends. C'est-à-dire, quand vous voulez accesser des données, vous serez abonnés à ça, puis vous obtenez les données de vos amis. Et quand vous êtes abonnés, vous faites que vos amis s'assurent que ces données existent et qu'ils peuvent s'inscrire, etc. Le deuxième principe est que les notes dans le network participent à la intégrité de données incluant les contrôles, etc. Et au-dessus de ça, les services sont implémentaires. Donc, dans le corps de GXS, vous avez trois blocs. L'une est l'incrypted storage, pour laquelle nous utilisons SQL Safer. Un component de synchronisation du network, qui compte pour qui est le droit de voir les données. Il s'agit d'un système de transaction multichannel. Et le dernier bloc, le troisième bloc, est la validation, qui vérifie les signatures de toutes les données et passe les données à la France quand elle a été vérifiée, validée. Donc, d'ici, un service spécifique implémentaire leur propre type de données privée. Par exemple, si vous implémentairez des forums, vous avez des messages de forums dans vos types privés, c'est le nom des forums. Ils défendent aussi ce qui devrait être la synchronisation et l'authentication des policies pour le service, selon le type de service que vous voulez implémentaire. Cela peut varier beaucoup. Et aussi, implémentaire des actions spécifiques. Par exemple, pour le système de synchronisation de la synchronisation, les services de l'email sont lesquels la réception a été reçue, etc. Donc, cela fonctionne comme je vais le décrire. Nous avons ces 5 services, des groupes, des messages, des identités et des cycles. Par exemple, le forum est un service que vous expliquez. Les services distribuent deux choses, des groupes et des messages, qui sont des objectifs hierarchiques. Ils diffèrent par les groupes de leur propre distribution et des policies d'authentication. Donc, la distribution signifie que l'authentication signifie que les messages dans ce forum ou dans ce service sont signifiés par leurs utilisateurs. Donc, les signatures sont offertes par les identités qui suivent les groupes où ils sont utilisés et cela peut être groupé dans deux cycles qui sont utilisés pour déterminer la distribution de la data. Par exemple, j'ai parlé des forums si vous voulez voir ce que c'est pour les forums, chaque forum est un groupe et le message dans le forum sera GXS Messages. Et puis, les cycles ont décidé qui est capable de voir ce forum et de poster ce forum. Si nous allons plus loin, je ne vais pas déterminer mais les groupes et les messages ont deux parties, la metadata et les données privées. La metadata est ce que GXS utilise pour la synchronisation. Les groupes et les données privées sont les idées de cycle qui limitent la visibilité. Et les données privées sont les services que nous utilisons pour l'application spécifique que vous avez designée. Comme je l'ai dit, les identités suivent les groupes. Elles sont synchronisées en requête et en fait, elles sont gérées par un service GXS. Mais ça nous permet de bénéficier de l'infrastructure existante en GXS pour synchroniser les identités. Comme vous pouvez le voir ici, elles peuvent être optionnellement signées par un nœud qui permet à ces identités d'être connectées à quelqu'un dans la vie réelle, dans la chaine. Mais c'est optionnel, les identités peuvent toujours être anonymes et il n'y a pas de moyen de traiter les identités de leur nœud. Les cycles sont aussi distribués par un service GXS. Mais non, leur subscription et la synchronisation sont automatiques. Et c'est ce que le système travaille pour être un membre de un cycle. Vous avez besoin de deux choses. Vous devez être dans la liste des gens qui sont invités à ce cycle. Donc ceci est contrôlé par l'autor d'un groupe de cycles, qui s'occupe d'un administrateur de ce groupe. Et vous devez aussi avoir invité un membre à ce cycle. Donc, ce système double permet à l'administrateur de contrôler le membre. Mais aussi, il permet à chaque membre de vivre le cycle. Et personne ne peut forcer quelqu'un à être dans un cycle. Et par exemple, utilisez ce cycle de distribution et de data sur la réseau. Il y a aussi un bâtiment d'un cycle, dans un service GXS qui peut être restricter dans un cycle, incluant le même cycle. Et si vous faites ça, vous obtenez un cycle restricé qui sera seulement visible aux gens qui sont dans ce cycle. Donc ça nous permet de distribuer de la data dans un moyen confidentiel au niveau de la réseau. Donc, dans les groupes et les messages GXS ils viennent avec des signatures. Les groupes ont leurs signatures admins qui contrôlent tout. Et optionnellement, ils ont un signe d'autor mais le groupe peut être anonymous. Les messages GXS ont aussi un signe d'autor si c'est nécessaire par la police d'authentification. Mais ils peuvent aussi avoir un signe d'autor qui va pouvoir contrôler que certains utilisateurs ont le droit d'accès à certaines groupes. Donc tous ces signatures sont vérifiées par tous les utilisateurs dans la réseau quand ils distribuent la data. Ouais, c'est... c'est... Qu'est-ce qu'il y a de synchronisation ? Donc ça fonctionne par un algorithme cascal qui basically fait la suivante chose. Donc chaque peer actant comme client va broadcast à ses amis la dernière timestamp de la data de les amis qui a été prévue par les amis pour les clients. Donc en faisant ça nous comparons seulement les temps qui ont été issus de cette machine. Nous ne comparons pas les temps entre différentes machines. Si le service réalise que sa data est nouvelle alors il va envoyer la liste de nouvelles groupes ici avec la timestamp de chaque groupe pour laquelle le client va demander la liste de groupes qu'il veut pour obtenir une update et puis obtenir la liste de groupes. C'est assez le même pour les messages donc je ne vais pas le détailler. La seule chose que je veux ajouter c'est que certaines de ces transactions puissent limiter la visibilité de la data et l'accessibilité de la data pour les personnes qui sont dans le cycle d'identités qui permettent de l'accessibiliser. Donc nous devons avoir le système de management de réputation. Quand vous designz un système comme ça vous avez des trôles et nous avons des trôles nous devons faire ça mais en fait c'est assez efficace. Il y a un problème d'un chic et un onnet ici parce que vous voulez les nouveaux commerçants pour pouvoir poser des données mais vous aussi voulez présenter des utilisateurs pour créer de nouvelles identités pour poser de nouvelles données. Parce que le réseau est statique c'est possible d'actuellement trouver un bon compromis entre ces deux. Donc ce que nous faisons c'est que nous nous avons toujours reçu les données nous avons toujours reçu si l'identité a un score de réputation qui est plus grand que ce qui a été défini pour le groupe d'un service spécifique. Et ce score de réputation s'est confusé par la mixation de votre propre opinion de l'identité avec l'opinion de votre ami et cela permet d'épargner très efficacement sans le besoin d'évaluer tout le monde dans le réseau. Finalement, qu'est-ce qu'il y a pour les transferts ? Nous avons distribué des files dans les messages de GXS c'est pas trop parce que de la redundancy des données dans le réseau et donc nous avons designé un système qui est basé sur le système turtle fin-to-fin c'est anonyme des tunnels qui je ne vais pas détailler l'encryption mais dans la question si vous voulez plus d'informations qu'on peut donner. Qu'est-ce que nous faisons ? Bien la question c'est comment est-ce qu'il faut impliquer qu'est-ce que vous voulez impliquer des forums ? Qu'est-ce que nous faisons ? Qu'est-ce qu'il faut prendre ? La question est de 200 lignes de codes plus l'interface graphique je ne le fais pas. Donc ici, par exemple, vous devez créer votre service de forums qui se dérive d'actuellement du service GXS et vous passez au service d'authentification qui signifie que les messages sont signés ou qu'il faut être signé et les messages des enfants sont aussi signés. Pourquoi nous séparons les deux ? Parce que ça vous permet, pour exemple, de créer des services où les messages doivent être signés mais vous pouvez avoir des communs anonymes sur chaque poste. Alors, qu'est-ce que vous voulez faire pour votre message ? C'est la classe actuelle je n'ai pas évoqué mais c'est juste qui dérive d'un objectif du message GXS Il y a un processus de serialisation qui est assez compact et c'est le message que vous passez dans le forum, c'est tout. Alors, quand vous voulez passer le message, l'opération est instantiée mais pour les forums, on l'a déjà fait, donc vous pouvez voir que c'est assez un grand nombre d'informations je ne vais pas l'entraîner mais je vous ai demandé de essayer le software. Alors, qu'est-ce que nous voulons faire avec ça ? Je pense que c'est possible d'utiliser le même principe pour développer ces choses, donc ce que j'ai dans la mémoire c'est que nous avons déjà commencé mais nous ferons vraiment d'utiliser les développeurs pour les créer. Alors, notre target est ce Facebook style de social network où nous serons d'avoir un système où les gens peuvent poser leurs idées, et autres utilisateurs peuvent le commenter. Donc c'est possible de faire ça avec des groupes, des subgroupes et des messages GXS. Donc, je suis terminé. Donc, il me reste 5 minutes d'informations. Je voudrais remercier Freifunk.net pour financer mon compte ici. Merci. C'est Joe. Donc, si vous avez des questions, on partage probablement. Bonjour. Merci pour le projet de RetroShare. Je l'ai entendu depuis beaucoup de temps. Mais je vous parle de l'identité. Comment beaucoup d'identités peut la personne avoir ? Il n'y a pas de limites. Il n'y a pas de limites. Donc, vous pouvez avoir plusieurs identités et plusieurs groupes. Ok. Merci beaucoup. C'est le problème qu'on a avec Spam, en fait. D'accord. C'est le problème qu'on a avec Spam parce qu'on a créé de nouvelles identités. Exactement. Bonjour. J'ai une question qui est importante parce que vous avez mentionné que l'un des goals pour RetroShare est de protéger la privacy des utilisateurs. Mais, en même temps, le réseau entièrement s'étendu entre les amis. C'est-à-dire que je vous montre l'ensemble du réseau que mes amis sont. Est-ce qu'il y a quelque chose pour protéger cette information et pour protéger mes amis de voir qui les autres les communiquent avec ? Ok. Il y a une grande spectrum des utilisateurs et des utilisateurs. Donc, nous avons offert différents compromis pour les utilisateurs. Si vous voulez la plus visible réseau que vous avez évoqué le système de discovery qui s'adverte à vos amis, vos propres amis, si vous voulez faire des amis avec eux. Mais vous pouvez les dévoiler. Si vous les dévoilez, vous devez évoquer votre IP adresse de votre propre ami, parce que vous avez une connexion pour les voir. Si vous voulez faire ça, vous pouvez utiliser un code éden qui fonctionne sur Tor. Et puis, vous avez seulement des connexions pour les localistes. Et vos amis ne savent pas où vous êtes et qui vous êtes. Ok. Vous m'avez mentionné cette histoire, à quel point vous avez développé ces sortes de tools ? Vous comprenez qui c'était ou quel point spécifique ? Nous ne savons pas qui c'était. Mais quand vous avez été évoqués par des messages qui se sont agressifs ou parfois des fondations pour la cause nous avons aussi. Et c'est le système, le contrôle des comptes qui est distribué, donc tout le monde décide qu'est-ce que le contenu est approprié pour eux ou pas. En fait, le système n'a pas besoin de police, parce que tout le monde s'occupe du contrôle du contenu qui est distribué. C'est-à-dire qu'il n'y a pas de manière qu'on peut banter quelqu'un de toute la chaine. Vous ne verrez pas le gars et vous n'aurez pas le temps. Vous avez mentionné l'une des grosses zones d'attention qu'on doit faire à l'EUY et j'imagine qu'il y a une bonne partie de ce projet d'interface. Vous avez considéré qu'il y a plein de projets d'open source pour des clients et d'exposer l'IMAP ou les protocoles pour que l'utilisateur utilise l'une des clients existants. Oui, mais vous devez connecter de toute façon à la chaine. Nous ne faisons pas ça. Il y a des expériences où il y a des expériences où quelqu'un a une sorte de gateway pour faire l'email en rétro-share. C'est possible aussi, mais il n'y a pas de prototype. Merci pour la question. J'ai une question très courte. Je l'ai installée sur ma mac. Je pense que votre audience est des gens qui souhaitent l'anonymité et la sécurité. Je réalise que l'app n'a pas de signature de code et il s'agit de connecter à des places comme displaymyip.com et ainsi que l'app pourrait être changée. T'as-tu considéré mettre sur l'app Store d'avoir un Sandbox ? Non, pas encore. Ok, cool. Je pense que ça m'a fait feel better en particulier que Github n'a pas l'opportunité d'avoir des connectants pour leur site. Nous devons signer nos billes. Et oui, c'est bien sûr. Si vous connaissez quelqu'un qui voulait mettre sur l'app un Sandbox, nous aiderons. Merci, tout le monde.