C-toxcore: Proposition de fonctionnalité : videur de réseau

Je pense que cette fonctionnalité est probablement mieux implémentée dans un bot et non dans la bibliothèque principale.

Vous devriez pouvoir écrire une bibliothèque videur qui expose l'interface tox.h afin que les clients puissent être construits dessus comme s'il s'agissait de toxcore, sans avoir besoin de modifier le code client. Par exemple, le premier appel qu'un client fait à la fonction tox_bootstrap() dans cette bibliothèque videur peut être traité comme adresse:port :pubkey d'un démon videur auquel la bibliothèque videur doit se connecter. Une fois la connexion établie, toutes les fonctions tox_ sur le client seraient RPC pour le videur distant, par exemple le client faisant tox_friend_send_message() enverrait un RPC au démon lui demandant d'envoyer ce message sur notre nom et renvoyez-nous le code de fonction pour le rendre au client. La bibliothèque videur peut utiliser tout ce qu'elle veut pour communiquer avec le démon videur exécuté sur le serveur distant, du HTTPS simple (ce qui est probablement ce que vous voulez si vous voulez réduire l'utilisation du réseau) aux paquets personnalisés de toxcore.

Ouais, je suis d'accord avec @ sudden6 , c'est quelque chose qui devrait être une bibliothèque distincte, pas une partie de la bibliothèque toxcore.

Je ne pensais même pas à une bibliothèque RPC, mais plutôt à un bot qui stocke simplement les messages et les transmet sur une commande textuelle.

Comment communiqueriez-vous avec le bot ? S'il s'agissait d'un bot Tox, n'auriez-vous pas besoin d'être connecté au DHT, ce que zer0def veut éviter ?

@ sudden6 Je pensais plus à un videur IRC qu'à un bot. Vous ne savez pas si vous êtes familier avec les videurs IRC, alors imaginez simplement le client qTox, qui est une interface graphique + toxcore, mais au lieu d'avoir une interface graphique et toxcore en cours d'exécution sur votre machine locale, vous exécutez toujours l'interface graphique en cours d'exécution sur votre machine mais le toxcore l'interface graphique communique avec s'exécute sur un serveur distant. Vous pouvez y parvenir en écrivant une bibliothèque qui prétend être toxcore, de sorte que qTox compilerait sans qu'aucune modification de code ne soit nécessaire, mais en réalité, ce ne serait pas un toxcore mais plutôt une bibliothèque qui communique avec l'instance distante de toxcore.

Mais n'est-ce pas implémenté dans les nœuds complets que les clients mobiles utilisent via le mode TCP ? Le mode TCP ne participe pas au réseau DHT à ma connaissance.

@dingosan , vous devez toujours être connecté en permanence au nœud TCP. D'après ce que j'ai compris, un videur stockerait également les messages ?

@ sudden6 , il devrait probablement maintenir la cohérence des journaux, sinon exécuter vos clients en tant que nœud TCP suffirait probablement

Salut, je fais un travail comme celui-ci sans modifier le protocole toxcore.
Ce n'est pas un videur comme IRC, mais plutôt un pont.
Il utilise gRPC/websock pour prendre en charge le client de programme natif et l'application Web.
Le pont stocke tous les messages lorsqu'il est en ligne. Et tous les clients de bridge peuvent recevoir des messages synchronisés.
Les clients peuvent extraire tous les messages d'historique, et plusieurs clients peuvent synchroniser les messages entre eux avec l'aide du pont.

C'est un travail en cours, encore une démo, toute personne intéressée peut y jeter un œil :
https://github.com/envsh/tox-homeserver

Le problème est maintenant que le groupe est temporaire, il n'y a pas de bon moyen de fusionner les messages de groupe après avoir recréé le groupe.

Soigné :) ça a l'air génial !

Le problème est maintenant que le groupe est temporaire, il n'y a pas de bon moyen de fusionner les messages de groupe après avoir recréé le groupe.

Nous avons le même problème dans qTox. Ce sera possible avec des groupes persistants, car ils ont des identifiants uniques. Une autre façon pourrait être de traiter chaque groupe créé comme séparé et de les afficher tous comme un historique distinct pour l'utilisateur. Comme ça:

26.05.2018 12:45 Tox Public Chat
26.05.2018 11:31 #toktok
26.05.2018 10:15 meeting
25.05.2018 08:10 meeting
24.05.2018 01:20 Tox Public Chat

Ce n'est pas aussi bon, mais toujours utilisable. Certaines personnes préféreraient peut-être même voir l'histoire de cette façon.