L'IRC est un vieux protocole et je l'ai toujours vu couplé avec DCC pour Direct Client Connection, du peer to peer avec donc éventuellement la contrainte d'ouverture de ports. Utilisé à l'origine pour pouvoir s'envoyer des fichiers, il permet de discuter en privé sans serveurs IRC comme intermédiaire. A cela on ajoute une couche SSL pour obtenir SDCC et l'on obtient un moyen de communication presque parfait. Pour ma part, j'ai remplacé les messages privés sur l'irc par des SDCC Chat (avec un trousseau de clés géré par un script kvirc).
Et pour ceux qui veulent du son et de l'image, je dirais que le son et l'image sont à IRC ce que le HTML est au mail : ça ne devrait pas exister.
Le son et l'image ne sera jamais dans le protocole IRC, mais il possèdent leur place dans DCC. Malheureusement le protocole DCC n'a jamais évolué. Même pire, comme c'est si bien dit sur le site de kvirc: DCC itself is not a well-defined protocol. J'avais trouvé un jour un site qui présentait l'union des programmeurs des principaux clients IRC (dont mIRC, le plus répandu sur Windows) dans le but de travailler ensemble sur des améliorations du protocole DCC. Mais le site était abandonné depuis plus de deux ans et actuellement je ne le retrouve plus du tout.
Des idées comme le Whiteboard (tableau blanc) avait vu le jour, on en trouve des traces dans KVirc (désactivé par défaut au moment de la compilation), mais rien de concret n'existe. KVirc possède à présent le support de la voix et de la vidéo (expérimental pour ce dernier), mais cela a été fait dans leur coin et ne fonctionne qu'entre clients KVirc.
C'est dommage de voir qu'avec toutes ces années, le DCC n'a pas du tout évolué. Un meilleur ou nouveau protocole permettrait de faire des choses comme:
des DCC Chat à plusieurs, certes c'est le principe des salons IRC de discuter à plusieurs, mais pouvoir sortir du réseau facilement peut être pratique
des DCC Chat avec smileys personnalisés, puisque l'image du smiley peut être envoyé dans le flux de données (ou même pourquoi pas ouvrir un nouveau socket)
s'affranchir d'une plage de ports à ouvrir: car seul le port permet de faire le lien entre ce qui se passe sur l'IRC (ctcp) et l'établissement de la connexion DCC, si on lance plusieurs requêtes DCC, il faut ouvrir plusieurs ports
à partir d'un DCC Chat: de pouvoir initier d'autres actions, par exemple une requête d'envoi de fichier ou de conversation audio/video... actuellement on est obligé de passer sur l'irc (CTCP) pour envoyer un fichier si on est déjà dans un dcc chat
gérer le charset convenablement en se mettant d'accord dessus, et même inclure cela carrément dans le protocole IRC serait un plus
Et bien sûr, ce protocole doit être extensible comme XMPP, que chaque client IRC peut étendre pour ajouter leur petits plus comme par exemple la miniature d'image si l'envoi d'un fichier est une image, une gestion d'avatar (kvirc le gère déjà à sa sauce d'ailleurs), des jeux (toujours par DCC)... bref, cette nouvelle version de DCC serait vraiment un plus à l'IRC.
Mais cessons de rêver, cela ne se fera jamais, l'avenir est à XMPP qui est d'ailleurs présenté comme une solution excellente dans ce journal et aucun développement ne devrait être fait pour améliorer la situation de l'IRC. Pour revenir sur la citation plus haut: l'IRC (incluant les protocoles liés comme CTCP et DCC) est capable de faire de la vidéo/audio, cela peut exister et cela existe même. Ce n'est pas une aberration puisque c'est prévu de pouvoir recevoir des flux binaire. C'est juste que la majorité des personnes sur l'IRC n'ont pas du tout le besoin d'avoir de l'audio ni de la vidéo: il n'y a pas de besoin donc cela n'existe pas.
Sinon, j'ai remarqué que Quakenet (et d'autres réseaux surement) offre un service pratique de webchat pour se connecter au réseau. Beaucoup de sites s'en servent et cela amène beaucoup de monde sur l'IRC à travers une belle interface web. Par contre, le client IRC semble être utilisé par contrainte. Celui-ci ne sert que pour la modération, les gens l'utilisent dans sa version non personnalisées (sans script) avec donc la police pourrie Fixedsys par défaut (j'ai pu voir cela grâce à plusieurs webtv).
Je vais en profiter pour dire que le SSL sans trousseau de clés ça ne sert à rien. KVIrc avait implémenté le support SSL sans cela et sans possibilité d'utiliser les données SSL avec le langage de script. C'est désormais possible suite à mon rapport de bug et ils ont été très réactif. Par contre il n'est toujours pas possible de se créer un certificat facilement comme avec Mumble. Voici les commandes pour ceux que ça intéresse:
[^] # Re: Chat et téléconférence
Posté par Thrillseeker . En réponse au journal État des lieux d'un internet décentralisé. Évalué à 1.
L'IRC est un vieux protocole et je l'ai toujours vu couplé avec DCC pour Direct Client Connection, du peer to peer avec donc éventuellement la contrainte d'ouverture de ports. Utilisé à l'origine pour pouvoir s'envoyer des fichiers, il permet de discuter en privé sans serveurs IRC comme intermédiaire. A cela on ajoute une couche SSL pour obtenir SDCC et l'on obtient un moyen de communication presque parfait. Pour ma part, j'ai remplacé les messages privés sur l'irc par des SDCC Chat (avec un trousseau de clés géré par un script kvirc).
Le son et l'image ne sera jamais dans le protocole IRC, mais il possèdent leur place dans DCC. Malheureusement le protocole DCC n'a jamais évolué. Même pire, comme c'est si bien dit sur le site de kvirc: DCC itself is not a well-defined protocol. J'avais trouvé un jour un site qui présentait l'union des programmeurs des principaux clients IRC (dont mIRC, le plus répandu sur Windows) dans le but de travailler ensemble sur des améliorations du protocole DCC. Mais le site était abandonné depuis plus de deux ans et actuellement je ne le retrouve plus du tout.
Des idées comme le Whiteboard (tableau blanc) avait vu le jour, on en trouve des traces dans KVirc (désactivé par défaut au moment de la compilation), mais rien de concret n'existe. KVirc possède à présent le support de la voix et de la vidéo (expérimental pour ce dernier), mais cela a été fait dans leur coin et ne fonctionne qu'entre clients KVirc.
C'est dommage de voir qu'avec toutes ces années, le DCC n'a pas du tout évolué. Un meilleur ou nouveau protocole permettrait de faire des choses comme:
Et bien sûr, ce protocole doit être extensible comme XMPP, que chaque client IRC peut étendre pour ajouter leur petits plus comme par exemple la miniature d'image si l'envoi d'un fichier est une image, une gestion d'avatar (kvirc le gère déjà à sa sauce d'ailleurs), des jeux (toujours par DCC)... bref, cette nouvelle version de DCC serait vraiment un plus à l'IRC.
Mais cessons de rêver, cela ne se fera jamais, l'avenir est à XMPP qui est d'ailleurs présenté comme une solution excellente dans ce journal et aucun développement ne devrait être fait pour améliorer la situation de l'IRC. Pour revenir sur la citation plus haut: l'IRC (incluant les protocoles liés comme CTCP et DCC) est capable de faire de la vidéo/audio, cela peut exister et cela existe même. Ce n'est pas une aberration puisque c'est prévu de pouvoir recevoir des flux binaire. C'est juste que la majorité des personnes sur l'IRC n'ont pas du tout le besoin d'avoir de l'audio ni de la vidéo: il n'y a pas de besoin donc cela n'existe pas.
Sinon, j'ai remarqué que Quakenet (et d'autres réseaux surement) offre un service pratique de webchat pour se connecter au réseau. Beaucoup de sites s'en servent et cela amène beaucoup de monde sur l'IRC à travers une belle interface web. Par contre, le client IRC semble être utilisé par contrainte. Celui-ci ne sert que pour la modération, les gens l'utilisent dans sa version non personnalisées (sans script) avec donc la police pourrie Fixedsys par défaut (j'ai pu voir cela grâce à plusieurs webtv).
Je vais en profiter pour dire que le SSL sans trousseau de clés ça ne sert à rien. KVIrc avait implémenté le support SSL sans cela et sans possibilité d'utiliser les données SSL avec le langage de script. C'est désormais possible suite à mon rapport de bug et ils ont été très réactif. Par contre il n'est toujours pas possible de se créer un certificat facilement comme avec Mumble. Voici les commandes pour ceux que ça intéresse:
Le fichier public.pem est le certificat, et paire.key c'est le fichier qui doit être utilisé comme clé privé dans KVIrc.