Chatavion, une messagerie passe-partout

Tu devrais envisager ce service dans ton avion. Désolé je pouvais pas m’en empêcher 😅

Je pense sincèrement que ton projet a du potentiel. Ça simplifierait vraiment beaucoup de chose, et comme l’a déjà dit @Zenith, si on pourrait avoir tout le Web, ce serait vraiment intéressant.

J’ai poussé la version NodeJS du serveur d’envoi sur GitHub dans la branche "node". C’est bien plus simple à installer avec cette version.

Je planche sur une version monoserveur de Chatavion qui s’appuierait entièrement sur Node.js. Ce serait encore plus simple à installer. Il faut "juste" que j’implémente les fonctions de réception en NodeJS. Moyennant un peu de travail supplémentaire, il y aura moyen de faire du multi-salons en créant de nouvelles entrées DNS qui pointent toutes vers le même serveur.

Et si tu venais à te servir de ton Chatavion sur un réseau internet par satellite (type bateau), ça pourrait aussi fonctionner ? Ça me rappelle une idée que j’avais eut qu’en gros vu que de nos jours c’est SMS illimité, que le client sur son téléphone envoie le lien d’un site web à un numéro qui sur un serveur avec support GSM + carte SIM renvoie la page web à une application Android qui la fairait apparaître (puisque les données mobiles ne sont pas illimités)

J’ai rien vu sur GitHub Edit: Je viens de voir la branche! Tu sais faire finalement

Pour l’avoir déjà utilisé en avion, oui, sur satellite ça fonctionne. C’est même pour ça que ça a été conçu.

J’apprends sur le tas. C’est comme NodeJS, il y a une semaine je n’y avais jamais touché, là j’ai quasiment fini la version mono-serveur entièrement en Node. Je dois nécessairement changer la syntaxe des requêtes, cette version ne sera pas compatible avec les programmes de réception d’origine (recep.sh, rnum.sh, recepauto.sh…).

La branche mono est poussée ! Cette version réduit les dépendances en n’utilisant qu’un seul serveur. Voici quelques schémas illustrant le fonctionnement de Chatavion mono.

Il a été nécessaire de modifier la syntaxe des requêtes pour récupérer les messages (mXnY.get / mXoY.get au lieu de mX.nY.get / mX.oY.get). Ainsi, le client de réception de la branche mono n’est pas compatible avec le(s) serveur(s) des autres branches, et inversement.

Branle-bas de combat et choc de simplification. Tout est passé sous NodeJS. La branche master a été archivée dans la branche first, pour ne conserver que 2 fichiers de code : le client et le serveur. Dès que je peux, je fais un vrai tuto et j’ouvre mon serveur aux membres qui veulent essayer sans faire leur propre serveur. Question éditoriale : est-ce que je peux publier sur ZdS un tuto pour utiliser mon propre programme ?

Le fonctionnement reste celui des schémas ci-dessus.

Dès que je peux, je fais un vrai tuto et j’ouvre mon serveur aux membres qui veulent essayer sans faire leur propre serveur. Question éditoriale : est-ce que je peux publier sur ZdS un tuto pour utiliser mon propre programme ?

Cela n’engage que moi mais je pense que ça serait plus intéressant de montrer le fonctionnement de ce principe (IP over DNS et requêtes à travers les serveurs DNS). Cela n’empêcherait pas de présenter ton programme mais je pense qu’ici aussi il faudrait à la limite faire des TP.

Ça existe et ça s’appelle iodine https://github.com/yarrick/iodine

Tu veux gérer ton dépôt comme une application ou comme un module node qui est publié sur npm ?

Je te conseillerai de publier la structure de ton application comme un module node, je peux t’aider à atteindre cette structure de code si tu veux. Par contre j’ai une erreur à l’exécution. EDIT : Ça vient du dépôt node-named, le module est abandonné par son auteur (il n’a pas merge les PR qui fixent ce problème), je vais essayer de devenir mainteneur pour prendre la suite de ce module.

@A-312 Ah oui, ce bug d’udp6 qui m’a tellement pris la tête. J’ai oublié de le mentionner. Tu vas faire en sorte de pousser la correction dans le paquet npm directement ?

Faire un module node sur npm permettrait d’installer les dépendances directement ? Une fois que le paquet serait installé, comment faudrait-il le lancer pour qu’il s’exécute en tâche de fond (je pense au serveur) ?

Pour la partie client, même chose : si c’est un paquet npm, comment on le lance ensuite ?

En daemon, il y a pm2 (en tout cas ZdS utilise ça pour zmarkdown)

Il faudrait séparer la déclaration des fonctions, de la partie configuration & initialisation. Je ne sais pas trop expliqué, un peu comme le module http où tu ne définis pas createServer, on et autre.

Je ne voyais pas de séparation de module entre client et serveur mais entre déclaration et utilisation.

Pour faire simple et reprendre mon explication ci-dessus, le côté utilisation ressemblerait à un code très simplifié comme ceci :

const chatavion = new Chatavion();

chatavion.listen(53, '0.0.0.0');

chatavion.on('message', (text) => {
   console.log(text);
});

J’ai un module qui pourrait être utile : serverline qui permet d’avoir l’output et l’input en même temps sans bug.

Je pense que c’est trop compliqué par rapport à juste faire "node chatavion.js".

C’est quoi, ce package.json dont tu parles sur GitHub ?

Je pense que c’est trop compliqué par rapport à juste faire "node chatavion.js".

Tu n’as pas compris ce que je voulais dire, je parlais côté structure du code, pas en terme d’utilisation finale. Il s’agirait de séparer la logique code et la gestion de la vue. Ca permet de séparer le code en plusieurs fichiers et ça permet aux personnes d’utiliser ton module et de personnalisé sa vue (son usage) sans pour autant devoir le fork.

Ma proposition était :

• Créer un module dns-communication (ou un autre nom) qui va gérer toute la logique du code et le mettre sur npm ;
• Et un autre module Chatavion qui va s’occuper du côté interface (vue) et qui utilise l’api de dns-communication.

C’est dans l’idée de zmarkdown où le projet est constitué de façon modulable.

C’est un fichier indispensable pour définir les commandes d’entées et quelles dépendances à installer.

Désolé, ça me dépasse. Il y a 15 jours encore, je n’avais jamais touché NodeJS et je ne savais pas créer une branche ou un répertoire sur GitHub. Il va me falloir un moment pour comprendre ce que tu me dis. Si tu veux faire ça, c’est avec grand plaisir.

J’ai créé une branche "community" sur le GitHub. Cette version permet de faire fonctionner plusieurs communautés en parallèle sur un même serveur et réduit le nombre de domaines : celui d’envoi et de réception deviennent le même. Le fonctionnement ne change pas, si ce n’est que le nom du fichier de conversation devient le nom de la communauté suivi de ".log". Le client ne bouge pas non plus, les adresses de RECV et de SEND sont juste les mêmes dans le cas d’un serveur Chatavion Community.

Edit : si vous voulez vous amuser, j’ai ouvert le domaine solo.chatavion.space. Tapez ça quand le client vous demande les serveurs SEND et RECV. Si vous êtes sous Termux et que vous testez depuis un hotspot, saisissez l’adresse du serveur DNS fourni par le point d’accès au lancement de Chatavion : Node ne peut pas le récupérer pour des raisons propres à Android.

Évitez de tout casser, ça reste encore un prototype instable qui peut planter à cause d’un cas imprévu.

J’ai fais ma fameuse PR ! (J’espère que ça va te plaire)

(On pourra générer une doc avec jsdoc si tu fais des pages github.io, j’ai ajouté des commentaires dans le code pour ça ).

Et j’ai du travaille pour toi :

• Activer travis sur le dépôt : https://github.com/marketplace/travis-ci (je ferais une prochaine PR pour mettre en place les premiers tests unitaires (faudra voir comment s’en sortir avec les ip en local) )
• Choisir un meilleur nom pour dnscom et changer toute les références à dnscom ;
• Te créer un compte sur npm ;
• Une fois un meilleur nom choisi, faire : npm publish dans les deux sous répertoire de packages\ ;

Veux-tu mettre un changelog en place pour les deux modules ? comme ceci

EDIT : J’ai oublié : Il faut que tu choisisses une licence, as-tu une préférence ? MIT ?

J’ai déjà bien utilisé Iodine par le passé. Ton projet est intéressant pour de la messagerie (qui sera forcement plus efficace que d’encoder un paquet IP entier).

@A-312 J’ai regardé ta PR, ça a l’air très bien, sauf que je n’y comprends rien. Est-ce qu’on pourrait s’appeler pour que tu m’expliques cette structure et le fonctionnement de ta version ? As-tu testé et éprouvé le programme ?

Question licence, je partirais plutôt sur du CC BY-NC-SA.