Journal Système de messagerie pour remplacer les e-mails

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
7
9
mai
2011

Salut,

Je réfléchis en ce moment à un système de messagerie au dessus du protocole HTTP qui pourrait replacer dans une certaine mesure les e-mails. Mes buts sont:

  • de permettre une implémentation simple, en particulier en utilisant XmlHttpRequest
  • de passer partout où HTTP passe
  • d'authentifier l'envoyeur

Je propose donc un mini protocole REST que je compte commencer à implémenter bientôt.

Ce qui m'a poussé à ça, c'est la découverte des sites en .onion. Et la constatation qu'il n'y avait aucun système de messagerie semblable aux e-mails pour le réseau Tor.

Pourquoi ne pas réutiliser le SMTP: parce que la gestion en est bien assez complexe, surtout en prenant en compte les problèmes de SPAM. J'ai l'impression que les verveurs .onion sont bien souvent auto-hébergés, et il faut rendre l'administration du serveur la plus simple possible.

Je pense d'ailleurs me fournir en plug computer pour mettre tout cela en pratique.

  • # Mauvais départ

    Posté par  (site web personnel) . Évalué à 10.

    À mon avis, tu pars de travers. HTTP n'est pas fait pour ça. Tu devrais plutôt chercher du côté de XMPP qui est bien mieux équipé pour implémenter un système de messagerie, synchrone ou asynchrone.

    • [^] # Re: Mauvais départ

      Posté par  (site web personnel) . Évalué à 3.

      Je trouverais ça bien, pour faire chier les admins réseaux ;)

      • [^] # Re: Mauvais départ

        Posté par  (site web personnel) . Évalué à 10.

        Je suis pas sur que ça soit judicieux d'aller sur ce terrain. Déja parce que l'admin va gagner à la fin et ensuite, ça va encore pousser à plus de filtrage en entreprise.

        • [^] # Re: Mauvaisdépart

          Posté par  . Évalué à -2.

          C'est faux, pour gagner il faut que le protocole soit bien confondu dans le trafic afin que l'admin ne s'en rende pas compte. Cela implique par contre de chercher à le garder pour soi.

        • [^] # Re: Mauvais départ

          Posté par  . Évalué à 5.

          Question bête:

          Vous avez souvent besoin d'envoyer des messages privés à des gens très particuliers (parce qu'il faut bien qu'ils aient un client pour le même protocole sinon vous communiquez avec vous-mêmes) au boulot, avec le matos du boulot, et avec un contenu si intéressant que vous ne voulez pas que ça passe par votre boite mail pro?

          Nan parce que l'admin à la fin, il va gagner, mais pas en filtrant, en faisant un ch'ti rapport aux petits oignons...

          • [^] # Re: Mauvais départ

            Posté par  . Évalué à 8.

            c'est lui qu'à commencé!!!

            Bon mise à part cette remarque de gamin, je vais tenter d'être plus constructif:
            d'un point de vue professionnel déjà

            j'ai déjà du contacter des potes pour avoir des réponses à des questions sur des points particuliers du code, et n'ayant pas la science infuse, mais presque, j'ai du poser la question à un de mes potes qui lui est plus précis que moi, le soucis c'est que son mail retour a de très forte chance de ne jamais passer l'anti spam.

            à foutre une sécurité débile, les gens qui ont vraiment envie de bosser vont ouvrir des brèches de la taille du Yan-Tse pour avoir accès au net dans le foutoire
            - blocage de google trad et autre
            - blocage des pages en fonction de leurs contenus (arggg un mot proxy, plus de pages)
            - blocage du cache google (heureusement suffit de passer en https)
            - blocage des url contenant forum dedans... (vive le https)

            Enfin raison personnelle.
            Quand je rentre chez moi j'ai pas forcément envie de lancer l'ordi; si en plus j'ai une soirée un peu longue, genre ciné, y a peu de chance que je soit chez moi avant 12H30, et généralement c'est dodo tout de suite.
            Ou est le mal de prendre 5 minute, un gmail et taper un mail pour ses potes; et non, le mail pro est justement réservé a l'usage pro, y a pas besoin d'archiver des discussions persos.

            Et le point final:
            Mon adresse pro est sur un webmail chez ovh, bloqué par ces cons d'admin (les joies de la presta) le compte mail de mission (qui peut ne pas exister au début, voire même un ou deux mois après) est temporaire, mes potes eux vont pas se farcir une mise à jour de contact chaque fois que je change de client non?

            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

            • [^] # Re: Mauvais départ

              Posté par  . Évalué à 10.

              à foutre une sécurité débile, les gens qui ont vraiment envie de bosser vont ouvrir des brèches de la taille du Yan-Tse pour avoir accès au net dans le foutoire
              - blocage de google trad et autre
              - blocage des pages en fonction de leurs contenus (arggg un mot proxy, plus de pages)
              - blocage du cache google (heureusement suffit de passer en https)
              - blocage des url contenant forum dedans... (vive le https)

              Moi j'ai pris l'option inverse : si mon employeur ou mon client ne me fournis pas les moyens me permettant de pouvoir bosser, je ne bosse pas. Je ne reste pas passif non plus, je lui remonte l'info, mais je ne prendrai pas l'initiative de trouer la securité de mon client ni de mon employeur.

              • [^] # Re: Mauvais départ

                Posté par  . Évalué à 7.

                Je n'ai pas encore utilisé de solution pour trouer la sécurité des clients;
                J'utilise le cache google en https, j'utilise des site de traduction (y'en a un paquet), j'utilise des sites de proxys non répertoriés par leur connerie de firewall.

                J'ai tenté par le passé de remonter l'info des sites bloqués alors qu'il n'auraient pas du: je donne le top des réponses
                - c'est pas nous qui gérons la liste
                - la boite de presta qui gère le firewall fait payer au ticket
                - on a pas le temps
                - et le top du top : faire une demande complétement officielle qui précise pourquoi on a besoin du site en question, et quelles informations précisément on cherche dessus; à ne faire uniquement que si on est certain de trouver la réponse dessus.

                Enfin pour faire bref lorsque le proxy se déclenche c'est généralement quand j'ai des questions assez pointues et les réponses ou questions similaires se trouvent dans des forum épars qui sont tous filtrés; il faudrait faire la demande pour tous les forums 1 à 1; cette demande devant être validé par un chef qui généralement répond qu'il a pas le temps.

                Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                • [^] # Re: Mauvais départ

                  Posté par  . Évalué à 3.

                  Et en parler aux supérieurs à ces incompétents ?

                  Envoyé depuis mon lapin.

                  • [^] # Re: Mauvais départ

                    Posté par  . Évalué à 4.

                    Ah si j'étais employé de la boite ça pourrait se tenter. Là ça va juste faire le gars qui tente de dénigrer la concurrence. Faut pas oublier qu'en général le gars a qui on va dire que le service info est aussi compétant que ma grand mère, est justement le responsable du recrutement dudit service; et généralement les chefs des grosses boites n'aiment pas quand on leur met le nez dans leur boulette.

                    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                    • [^] # Re: Mauvais départ

                      Posté par  . Évalué à 2.

                      On ne bosserait pas dans la même boite par hasard ?
                      Pour ma part je n'insiste pas : je ne cherche pas à obtenir les acces : je signale juste à la personne à qi je dois rendre des compte que la politique de sécurité de la boite ne me permet pas de travailler correctement et que je dois me débrouiller autrement donc les délais de réalisation seront plus long.

                      • [^] # Re: Mauvaisdépart

                        Posté par  (site web personnel) . Évalué à 3.

                        Le mardi 10 mai 2011 à 11:41 +0200, totof2000 a écrit :
                        > On ne bosserait pas dans la même boite par hasard ?

                        Elles sont sacrément flippantes ces boîtes, ils doivent en avoir du
                        temps/pognon à perdre pour avoir le temps de fliquer leurs collègues.

                        • [^] # Re: Mauvaisdépart

                          Posté par  . Évalué à 9.

                          C'est un petit peu plus compliqué; c'est des boites dont les dirigeant ont peur que leur employés fasse ce que eux voudraient faire ou font de leur journée. Pour ces preneurs de décisions, l'employé n'est qu'un glandeur en puissance.
                          Ils ne comprennent pas l'impact négatif que peut avoir ce genre de politique de sécurité
                          - on glande aussi bien, même plus à la machine à café. Lors de compile ou génération longue si le net est bloqué, c'est café, avec invitation des voisins. La pause est plus longue et implique plus de personne.
                          - Impossibilité de récupérer des outils pour bosser (emacs/vim/eclipse à jour/qtcreator/beyond compare/notepad++/perl/python/cygwin...) Résultat, prolifération de clés usb et des virus apparaissent sur des machine n'ayant pas d'accès au net...
                          - Enfin, le plus visible, on réinvente la roue, on tombe dans des pièges balisés, enfin bref on ne dispose pas de la plus grande encyclopédie du monde, et on perds du temps.

                          Le summum fut lorsque j'ai du bosser sur du code en tant qu'extérieur; théoriquement rien ne doit sortir; problème, j'ai qu'un ordi perso pour bosser => solution du client code foutu sur une clé usb elle aussi perso...

                          Bon tant que j'ai bossé, la bas j'ai laissé la clé, et une fois fini, j'ai effacé le code, mais bon c'est moyen.

                          Il ne faut pas décorner les boeufs avant d'avoir semé le vent

      • [^] # Re: Mauvais départ

        Posté par  . Évalué à 5.

        Faudra pas venir pleurer quand il y aura de la DPI partout...

        • [^] # Re: Mauvais départ

          Posté par  . Évalué à 5.

          bof un serveur distant, faisant un proyx http en changeant tous les mots de la page web selon un algo perso, le DPI il peut aller se rhabiller sans connaître l'algo utilisé c'est mort.

          Le seul filtrage qui peut fonctionner c'est la liste blanche. J'attends avec impatience la mise en place de ce genre de système; et j'observerai la productivité avec attention. En même temps ça ferai plus de postes ;)

          Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • # XMPP

    Posté par  (site web personnel, Mastodon) . Évalué à 10.

    Pourquoi ne pas utiliser XMPP ? Il y a des serveurs relativement simples à installer/administrer, et c'est un bon candidat au remplacement du courriel.
    Ton journal tombe pile quand je viens de poster une vidéo montrant l'utilisation d'un client courriel avec XMPP en utilisant Salut à Toi.

    J'ai posté un billet aussi il y a quelque temps, sur le remplacement du courriel par XMPP, ça peut peut-être t'intéresser.

    En plus via BOSH, tu passes par dessus HTTP, comme tu le désires.

    • [^] # Re: XMPP

      Posté par  . Évalué à 4.

      Tiens, j'ai dû rater les précédents articles sur ce client qui m'a l'air fort sympathique.

      Petite question:

      Tu dis préférer que ce soit le client Jabber qui gère la file des messages (et sert l'IMAP). Je connais mal le protocole XMPP sur les messages standards, mais avant d'arriver sur le client SàT, il est bien stocké sur le serveur?
      Donc l'argument sur la sécurité est un peu caduque.

      Enfin, c'est un grand débat, mais je suis plus à l'aise à savoir que mes messages sont gérés sur un serveur "dédié" avec sauvegardes régulières que sur mon PC de bureau avec lequel je fais beaucoup "mumuse" aux risques et périls de ses données...

      • [^] # Re: XMPP

        Posté par  (site web personnel, Mastodon) . Évalué à 3.

        Tiens, j'ai dû rater les précédents articles sur ce client qui m'a l'air fort sympathique.

        Je n'ai fait jusqu'ici que des journaux, mais je prépare une sortie assez importante d'ici très peu de temps, et je vais proposer une dépêche à l'occasion. J'attendais juste d'atteindre un certain stade avant d'en parler partout :)

        Donc l'argument sur la sécurité est un peu caduque.

        L'argument de la sécurité, c'est au niveau du serveur, pas du stockage: un serveur XMPP gère en général beaucoup de clients, et est donc plus exposé et plus intéressant à attaquer; ajouter des serveurs IMAP/SMTP dessus, c'est ajouter du boulot d'administration, des ports ouverts, et des risques de failles.

        De l'autre côté, si tu mets ces serveurs IMAP/SMTP sur ta machine perso, en local, et que tu bloques tout accès à l'extérieur, le risque est nettement plus faible.

        Mais ceci dit, rien n'empêche de faire la même chose côté serveur, c'est juste un choix.

        Enfin, c'est un grand débat, mais je suis plus à l'aise à savoir que mes messages sont gérés sur un serveur "dédié" avec sauvegardes régulières que sur mon PC de bureau avec lequel je fais beaucoup "mumuse" aux risques et périls de ses données...

        Oui en fait ce n'est pas dans cette optique de faire un gros serveur IMAP accessible de partout, c'était plus dans l'idée utiliser son client courriel à la maison pour les messages de type "normal" en XMPP. Mais ceci dit il est tout à faire possible de faire vraiment un gros serveur IMAP côté serveur XMPP, c'est juste plus de boulot.

  • # Je trouve un peu navrant ...

    Posté par  . Évalué à 10.

    ... de remplacer un truc qui marche pas trop mal et relativement simple par une nouvelle usine à gaz.

    Après chacun fait ce qu'il veut, mais ne serait-il pas judicieux, avant de réinventer la roue, de se poser et de voir ce qui ne marche pas dans SMTP pour le corriger ?

    • [^] # Re: Je trouve un peu navrant ...

      Posté par  . Évalué à 10.

      on ne dit pas "remplacer un truc qui marche pas trop mal et relativement simple par une nouvelle usine à gaz", on dit web2.0. Le monde sur le port 80...

      Vous voulez pas la jouer soft ? Je suis pas contraignant... vous voulez la jouer hard ? On va la jouer hard

    • [^] # Re: Je trouve un peu navrant ...

      Posté par  . Évalué à 10.

      Le truc simple qui marche pas trop mal c'est le système qui a du recevoir je ne sais combien de RFC pour pouvoir être un minimum sécurisé (problème d'authentification) qui oblige à utiliser 2 à 3 protocoles différents et oblige à être finement configuré ?

      Ensuite dès qu'on utilise HTTP c'est une grosse usine à gaz ? Faudras expliquer ça à tout les utilisateurs de subversion et de mercurial ainsi qu'à tout ceux qui utilisent git à travers HTTP.

      Comprends moi bien je ne pense pas que tout faire passer sur du HTTP soit génial bien au contraire, je pense juste deux choses :

      • c'est bête d'envoyer bouler un projet comme tu le fait, avoir des alternatives ça n'a rien de malsain. Je déteste ceux qui refusent une alternative avant même de voir une implémentation
      • je trouve que considérer le système de mail comme simple et qui fonctionne bien c'est tout de même se voiler la face. Le mail est ce qu'il est aujourd'hui parce qu'on arrive à peu près à le faire fonctionner et pour des raisons historiques.

      A ce niveau là autant dire que ssh ne sert à rien et que telnet dans un tunel SSL serais largement suffisant et fonctionnerais pas trop mal.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Je trouve un peu navrant ...

        Posté par  . Évalué à 10.

        Je suis pas sûr que l'implémentation de Subversion par HTTP soit un bon exemple de réussitee.

        Quant à celle de git, elle nécessite de lancer la commande update-server-info sur le serveur, et jusqu'à récemment, elle n'était pas du tout efficiente. Bref, ça demande plein de contorsions pour être au niveau d'un système véritablement adapté.

        Pour réinventer le mail, il faudrait proposer mieux − pas juste une implémentation HTTP REST qui n'apporte rien si ce n'est utiliser les dernières foutaises à la mode.

        DLFP >> PCInpact > Numerama >> LinuxFr.org

      • [^] # Re: Je trouve un peu navrant ...

        Posté par  . Évalué à 10.

        T'en fais pas de toute façon l'avenir c'est d'utiliser Facebook pour envoyer ses mails. Ça règle au moins le problème de l'authentification.

      • [^] # Re: Je trouve un peu navrant ...

        Posté par  . Évalué à 6.

        Je n'envoie rien bouler: je constate juste que la mode actuelle est de remplacer des trucs qui marchent pas trop mal et sur lequel on a du recul par un truc inconnu réinventé de zero, pour lequel on va tenter de gommer les inconvénients du mail, mais qui au final apportera d'autres inconvénients et qui au final sera plus contraignant que ce qui existe aujourd'hui.

        • [^] # Re: Je trouve un peu navrant ...

          Posté par  . Évalué à -4.

          On sent quand même de l'amertume, si ce n'est de l'agressivité, dans ta manière de l'exprimer.

          Dans tous les cas, on sent que tu n'utiliserai ce projet que sous la contrainte.

          • [^] # Re: Je trouve un peu navrant ...

            Posté par  . Évalué à 5.

            L'amertume vient du fait que ces dernières années, on a remplacé des applis qui juste marchaient bien (avec leurs inconvénients) opar des trucs lourds, qui certes corrigheaient les quelques défauts des trucs qui "juste marchaient bien", mais arrivaient avec leur lot de contrainte et de problèmes, et au final ces trucs ont été imposés et n'ont fait que me faire perdre en productivité et en efficacité.

            Un exemple tout bête : la tendance à systématiquement remplacer des lignes de commandes par des interfaces graphiques, sans se demander avant si c'est vraiment adapté au besoin.

            • [^] # Re: Je trouve un peu navrant ...

              Posté par  . Évalué à 6.

              ah, oui, le passage de KDE 3 à KDE 4... triste, triste.

            • [^] # Re: Je trouve un peu navrant ...

              Posté par  . Évalué à 2.

              J'ai pas l'impression qu'on puisse faire moins de chose en ligne de commande de nos jours, personnellement. Par contre je l'utilise probablement beaucoup moins perso.

            • [^] # Re: Je trouve un peu navrant ...

              Posté par  . Évalué à 0.

              Un exemple tout bête : la tendance à systématiquement remplacer des lignes de commandes par des interfaces graphiques, sans se demander avant si c'est vraiment adapté au besoin.

              C'est claire que le type de logiciel est directement impacté par le protocole sous-jacent. Par exemple il est impossible de faire du HTTP sans firefox ou chrome, tout le monde le sais.

              Bref ce que je trouve débile c'est que vous arrivez avec vos rancœurs et vous descendez quelque chose simplement parce que ça vous fait penser à de mauvaises aventure que vous avez faite. C'est un procès d'intention.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Je trouve un peu navrant ...

        Posté par  (site web personnel) . Évalué à 4.

        Le truc simple qui marche pas trop mal c'est le système qui a du recevoir je ne sais combien de RFC pour pouvoir être un minimum sécurisé (problème d'authentification) qui oblige à utiliser 2 à 3 protocoles différents et oblige à être finement configuré ?

        SMTP était simple. Après, effectivement, çà devient un gros bourbier parceque çà n'a pas été conçu pour faire des trucs compliqués à la base... Pour çà y avait X400. Les gens de l'internet adorent ré-inventer des protocoles plus simples pour les recomplexifier par la suite quand ils se rendent compte qu'il manque des trucs...

        'fin j'dis çà j'dis rien.

        • [^] # Re: Je trouve un peu navrant ...

          Posté par  (site web personnel) . Évalué à 6.

          En effet, il y a la technique des téléphonistes : réfléchir longtemps en club privé, pour pondre un système tellement compliqué dès le départ que personne n'est capable de l'implémenter.

          Et la technique des internautes : réfléchir un moment en groupe de travail ouvert, pour pondre un système simple qu'on étendra au besoin par la suite. Un bel exemple de cela, c'est XMPP avec les XEP.

          • [^] # Re: Je trouve un peu navrant ...

            Posté par  (site web personnel) . Évalué à 2.

            On s'est peut être mal compris : je ne dis pas que tout est bon dans ce procédé, mais qu'il y a sûrement un juste milieu...

          • [^] # Re: Je trouve un peu navrant ...

            Posté par  . Évalué à 2.

            S'il me semble que XMPP (dont tu es friand, il semble) est une réussite au niveau flexibilité et adaptabilité, il me semble que c'est clairement pas le cas de SMTP. On sens bien par exemple que l'authentification avec SMTP c'est pas terriblement bien fait (un coup on utilise POP un coup on utilise une autre extension).

            Comme dis plus haut, il y a déjà des cas où on a supprimer un protocole alors qu'il aurait était possible d'y coller quelques RFC pour résoudre le problème. C'est ce qui s'est passé avec telnet/ssh. Il n'y a eu aucune réutilisation de l'existant.

            Je ne dis pas que c'est bien de toujours tout remettre en cause, mais qu'il faut savoir le faire pour éviter de garder un héritage trop lourd.

            Enfin pour reparler un peu du sujet de ce journal, c'est toujours bien de voir arriver de nouvelles tentatives car il peut en ressortir des idées qui peuvent potentiellement être implémenté sur l'existant.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Je trouve un peu navrant ...

              Posté par  (site web personnel) . Évalué à 3.

              On sens bien par exemple que l'authentification avec SMTP c'est pas terriblement bien fait (un coup on utilise POP un coup on utilise une autre extension).

              POP avant SMTP c'est une merde sans nom inventée avant SMTP AUTH. Aujourd'hui tout le monde, sauf peut-être quelques dinosaures en voie de fossilisation, utilise SMTP AUTH.

              • [^] # Re: Je trouve un peu navrant ...

                Posté par  . Évalué à 1.

                POP avant SMTP c'est une merde sans nom inventée avant SMTP AUTH. Aujourd'hui tout le monde, sauf peut-être quelques dinosaures en voie de fossilisation, utilise SMTP AUTH.

                Comme tu dis c'est arrivé avant SMTP avait un gros manque et certains ont tenter de le résoudre (c'est vrai que c'est une fonctionnalité inimaginable de prévoir de l'authentification).

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: Je trouve un peu navrant ...

                  Posté par  . Évalué à 10.

                  c'est vrai que c'est une fonctionnalité inimaginable de prévoir de l'authentification

                  Dans un Internet beaucoup plus petit, statique, sans terminaux itinérants, sans "nouvelle économie" ni usines à spam ni virus ni autres comportements anti-sociaux et destructeurs, faire du simple contrôle d'accès à base d'adresse source était en effet probablement suffisant (et peut-être même superflu).

                  Critiquer une décision prise il y a ~30 ans sans considérer le contexte d'alors, ça n'apporte pas grand'chose.

                  • [^] # Re: Je trouve un peu navrant ...

                    Posté par  . Évalué à 3.

                    1. Internet comme arpanet était prévu comme un réseau mondial prévu pour et par l'armée à la base.
                    2. Je ne critique pas les choix de l'époque, je dis qu'il faut savoir les remettre en cause.

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # REST?

    Posté par  . Évalué à 10.

    J'espère qu'il sera sur le Cloud, et qu'il sera implémenté en NodeJS.

    DLFP >> PCInpact > Numerama >> LinuxFr.org

    • [^] # Re: REST?

      Posté par  . Évalué à 10.

      C'est B2B-compliant ? Je vais en parler à mon community manager.

    • [^] # Re: REST?

      Posté par  (site web personnel) . Évalué à 1.

      Ah ouais mais non, parce que node.js c'est pourri parce qu'ils ont pris un nom trop générique pour leur exécutable : node. Du coup ça fait une collision avec un projet existant et ça oblige à le renommer.

      • [^] # Re: REST?

        Posté par  . Évalué à 10.

        Je pense que tu es passé à côté de l'iRonie.

        DLFP >> PCInpact > Numerama >> LinuxFr.org

        • [^] # Re: REST?

          Posté par  . Évalué à 10.

          Connectez vous à l'aide de votre compte Facebook afin de lire cette réponse.

          THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

  • # Goggle Wave

    Posté par  . Évalué à 6.

    Tu peux regarder du côté de Google_Wave également,
    qui est une extension de XMPP, dont la partie serveur a été libérée par Google.

    Dommage que ce service n'ait pas pris, c'est vraiment révolutionnaire.

    • [^] # Re: Goggle Wave

      Posté par  . Évalué à 9.

      Oui, c'est lumineux !

      Plus sérieusement, en effet, j'ai trouvé que Google Wave avait un fort potentiel mais Google laché trop vite à la presse avec une interface graphique pas adapté pour monsieur tout le monde.

      Je pense que, malheureusement, il aurait fallu une IHM ressemblant a un client mail classique en tout début tout en affichant les nouvelles possibilités.

      Mais là, d'un coup, ca faisait trop de changement pour le pékin moyen, mais je pense que le protocole derrière doit etre pas trop mal pensé...
      www.waveprotocol.org

      Le projet a été abandonné par Google mais repris par la fondation Apache, donc d'apres moi, il vaut mieux travailler à améliorer ce protocole plutot que d'en créer un autre.

      Par contre, je ne considère pas que le mail actuel ne soit pas une usine à gaz. Il n'avait pas été pensé pour ce en quoi le net a évolué, et niveau sécurité, c'est pas terrible.

  • # hors sujet

    Posté par  . Évalué à 1.

    Pour moi, c'est hors sujet.

    Le vrai problème du courrier électronique, ce n'est pas le moyen de l'acheminer, mais plutôt:
    - Pouvoir formater correctement un document, (gras italique)
    - Pouvoir identifier les threads et les messages.
    - Faire du suivi de document et de version en mode asynchrone.
    - gérer l'authentification
    - le spam

    Tous ces problèmes ont des débuts de solutions qui marchotent avec le système actuel.

    Aucun de ces problèmes n'est résolu en passant sur de http.

    • [^] # Re: hors sujet

      Posté par  (site web personnel) . Évalué à 10.

      • Pouvoir formater correctement un document, (gras italique)

      Enriched text

      • Pouvoir identifier les threads et les messages.

      Message-ID et en-têtes In-Reply-To et References. Ça fonctionne à merveille depuis des lustres.

      • gérer l'authentification

      Là, ce ne sont pas les solutions qui manquent, vraiment.

      Tous ces problèmes ont des débuts de solutions qui marchotent avec le système actuel.

      Ah non. Certains de ces problèmes ont de vraies solutions qui fonctionnent à merveille avec le système actuel.

    • [^] # Re: hors sujet

      Posté par  . Évalué à 9.

      On 09/May - 15:54, grid wrote:
      > - Pouvoir formater correctement un document, (gras italique)

      Tu sais, ça c'est au dessus du SMTP, le multipart existe et tu peux faire tes mails en html.

      • Pouvoir identifier les threads et les messages.

      Message-ID et In-Reply-To.

      • Faire du suivi de document et de version en mode asynchrone.

      Je n'ai pas trop compris ce que tu veux dire.

      • gérer l'authentification

      GPG.

      • le spam

      spamassassin.

      • [^] # Re: hors sujet

        Posté par  . Évalué à 2.

        • Pouvoir formater correctement un document, (gras italique) Tu sais, ça c'est au dessus du SMTP, le multipart existe et tu peux faire tes mails en html.

        Que celui qui n'a jamais vu un courrier électronique mal formatté me [:inutilise]

        Que celui qui n'a jamais fait un "reply all " et observé que tout le message partait en vrac me jette un bidon d'outlook dans la gueule.

        gérer l'authentification
        GPG.

        Solution déployée partout, et très répandue. C'est clair.

        le spam
        spamassassin.
        Typiquement le genre de verrue qui viennent combler un manque au niveau du protocole.

        Alors, oui, il y a des solutions, mais je ne les trouve pas très satisfaisante.

        • [^] # Re: hors sujet

          Posté par  . Évalué à 1.

          Que celui qui n'a jamais vu un courrier électronique mal formatté me [:inutilise]

          Moi je n'en ai jamais vu depuis 1 ou 2 ans. Dans le pire des cas, je vois des balises HTML, et je sais que le message est à jeter immédiatement à la corbeille.

          Que celui qui n'a jamais fait un "reply all " et observé que tout le message partait en vrac me jette un bidon d'outlook dans la gueule.

          Chez moi le Répondre à tous ça marche™ (Claws Mail/KMail), sauf si j'ai mal compris ce que tu disais. De toute façon, je n'ai pas d'Outlook chez moi, il est allé voir ailleurs depuis longtemps.

          • [^] # Re: hors sujet

            Posté par  . Évalué à 4.

            i je n'en ai jamais vu depuis 1 ou 2 ans. Dans le pire des cas, je vois des balises HTML,

            donc tu en as vu.CQFD. l'intérêt du mail n'a rien à voir dans l'affaire

        • [^] # Re: hors sujet

          Posté par  . Évalué à 1.

          Alors, oui, il y a des solutions, mais je ne les trouve pas très satisfaisante.

          Donc face à un groupe de personnes ignorant l'existence d'un outil tu préconises donc de:

          1. faire connaître ces outils
          2. développer de nouveaux outils qu'elles apprendront peut-être à connaître?

      • [^] # Re: hors sujet

        Posté par  (site web personnel) . Évalué à 3.

        Message-ID et In-Reply-To.

        Et References, histoire d'identifier les réponses à une réponse qu'on n'a pas reçue.

      • [^] # Re: hors sujet

        Posté par  . Évalué à -3.

        Et comment tu recuperes le certif public gpg, et surtout, comment tu fais pour savoir que c'est bien celui de la personne qui pretend se presenter?

        If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

        • [^] # Re: hors sujet

          Posté par  (site web personnel) . Évalué à 6.

          Tu es au courant que ce problème :

          1. n'est pas spécifique au système OpenPGP ;
          2. se retrouve logiquement dans tous les systèmes de cryptographie asymétrique ?

          • [^] # Re: hors sujet

            Posté par  . Évalué à -3.

            Ca repond pas a la question.

            Sinon, oui, je le savais, c'est bien pour ca que j'ai pose la question figures toi.

            If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

        • [^] # Re: hors sujet

          Posté par  (site web personnel) . Évalué à 3.

          Et comment tu recuperes le certif public gpg

          Sur un serveur de l'anneau public synchronisé, ou sur le serveur du nom de domaine de ton correspondant.

          comment tu fais pour savoir que c'est bien celui de la personne qui pretend se presenter?

          Tu vérifies si sa clef est signée par des gens à qui tu fais confiance, ou tu le rencontres en direct pour vérifier manuellement.

          • [^] # Re: hors sujet

            Posté par  . Évalué à -3.

            Ca va etre pratique ca dis donc! Surtout la partie ou on rencontre physiquement des gens qui habitent a l'autre bout de la planete.

            If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

            • [^] # Re: hors sujet

              Posté par  (site web personnel) . Évalué à 4.

              Bon sang, elle sert à quoi ta question à la fin ?

              Tu cherches un système d'identification forte de ton correspondant ? Le problème de la vérification d'identité est imparable.

              Donc si ce que tu veux, c'est démontrer que PGP n'est pas une bonne solution, félicitations : tu viens démontrer qu'aucun des systèmes de cryptographie n'est une bonne solution.

              En revanche, si ce que tu veux, c'est savoir comment faire avec PGP, tu as la réponse, pas la peine de faire dans le cynisme.

              • [^] # Re: hors sujet

                Posté par  . Évalué à -1.

                Ma question etait bien evidemment rethorique. Le message initial suggerait laconiquement qu'il "suffit" d'utiliser gpg et paf ca marche. Je fais laconiquement remarquer que c'est pas si simple que ca.

                If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

    • [^] # Re: hors sujet

      Posté par  (Mastodon) . Évalué à 10.

      Pouvoir formater correctement un document, (gras italique)

      Un .doc attaché au mail

      Pouvoir identifier les threads et les messages.

      Des couleurs différentes dans le .doc pour voir qui écrit

      Faire du suivi de document et de version en mode asynchrone.

      Des couleurs différentes dans le .doc pour voir les modifications et ensuite, on envoit tout à la personne-qui-fait-la-synthèse

      gérer l'authentification

      Comme si je savais pas que c'était Gérard qui m'avait envoyé le .doc !

      le spam

      Grâce au firewall OpenOffice, plus de problème de spam !

      Tu vois, il y a des solutions à tout !

  • # Pas de messagerie via Tor?

    Posté par  . Évalué à 2.

    Il me semble qu'il y a quelque-chose de ce style du côté de http://guardianproject.info/ (des mecs qui cherchent à développer une surcouche paranoïaque à Android, en caricaturant un peu), mais je ne parviens pas à remettre la main dessus.

    Sinon, comme beaucoup te l'ont fait remarquer, XMPP aurait beaucoup d'avantages dans ta démarche : permettre un accès HTTP quand "il n'y a que ça" (cf. BOSH), et passer par quelque-chose de plus optimisé dans le cas contraire.

    Avec en outre l'avantage intrinsèque de faire un distinguo entre les contacts "connus" (i.e. ton roster) et les autres. Sachant qu'on entend de plus en plus souvent dire que c'est l'une des grosses faiblesses du courriel face au spam.

  • # Tor et smtp

    Posté par  (site web personnel) . Évalué à 7.

    Une chose qui serait amusante serait une passerelle smtp vers ton protocole. Ce qui permet d'utiliser tout les clients existants et de pouvoir ensuite faire passer les mails par http pour tor. Et de l'autre coté, en mettant un autre smtp, tu peux remettre le mail dans e circuit et bénéficier de ce qui existe.

    Même si j'aurais tendance à dire "regarde xmpp", je pense pas que les serveurs actuelles gérent comme il faut le fait d'avoir un .onion, ou un proxy socks. Alors que faire un proxy transparent pour http qui va vers tor, c'est trivial.

    Sinon, il y a le projet onioncat qui pemet de faire un vpn par dessus tor, je sais pas si ça réponds à ta problématique.

  • # Commentaire supprimé

    Posté par  . Évalué à 7.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 2.

      Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Wait and See

      Posté par  . Évalué à 2.

      o XMPP c'est mieux, parce que c'est en XML ;
      o l'existant est mieux, parce que ... euh ... ça existe ;
      o BulldozerMail est mieux : c'est du Java avec une JVM écrite en Ruby précompilé et bytecodé en Python pour passer sur GoogleApps.

      Moi je changerais l'ordre avec une autre raison pour le point 2 :
      o XMPP c'est mieux, parce que c'est en XML ;
      o BulldozerMail est mieux : c'est du Java avec une JVM écrite en Ruby précompilé et bytecodé en Python pour passer sur GoogleApps.
      o l'existant est mieux, parce que ya ni XML ni Java ( ni python d'ailleurs).

    • [^] # Re: Wait and See

      Posté par  . Évalué à 3.

      Et avec un système de messagerie privée à côt basé sur HTTP, ça serait pas mal

      Le répondeur de Tobybur< ne faisait pas déjà ça?

      « 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: Wait and See

      Posté par  (site web personnel) . Évalué à 1.

      Ce que j'ai compris, c'est qu'en fait, tu veux faire une application HTTP pour échanger des messages via des URLs définies et normalisée via ton API REST : les messages sont hébergés sur le serveur et seuls les utilisateurs de ce serveur peuvent lire ou échanger des messages. Si tu veux t'affranchir de cette limitation et pouvoir échanger entre serveurs, ça va être plus difficile car il faut trouver un moyen raisonnable d'échanger les données entre serveur, sûrement via une API REST qui te permet de tester la capacité du serveur à échanger des messages.

      En l'occurence, ce que je définis est l'API inter-serveurs. Au sein d'un même serveur, on peut réutiliser la même API mais on doit pouvoir se passer de la vérification.

      Idéalement, j'aimerais bien une API REST commune à tous les systèmes de PM qu'on voit de partout (en particulier sur Tor pour remplacer les e-mails) pour qu'on puisse communiquer entre plusieurs serveurs différents.

  • # Système de messagerie pour remplacer les mailing-lists (trololol)

    Posté par  (site web personnel, Mastodon) . Évalué à 2.

    Bon, désolé par avance de poser une question idiote, mais elle me taraude depuis un bon moment : pourquoi une majorité de projets FOSS utilisent encore des listes de diffusion pour discuter ? Y'a t'il un gain de fonctionnalités apporté par l'usage du mail ? Parce que de mon point de vue (à moins que je n'arrive simplement pas à m'en servir), c'est surtout de vieilles pages HTML austères, à la navigation guère user-friendly, et où participer demande un minimum de connaissances sous peine de voir sa boîte mail débordant de discussions. Pourquoi les forums Web (avec éventuellement des notifications mail) ne se sont pas davantage démocratisés ?

    • [^] # Re: Système de messagerie pour remplacer les mailing-lists (trololol)

      Posté par  . Évalué à 8.

      Y'a t'il un gain de fonctionnalités apporté par l'usage du mail ?

      Tout arrive au même endroit et tu filtres dans des dossiers de ta boite mail. L'inconvénient des forums web est qu'il t'en faudrait un par projet avec la multitude de bookmarks à gérer.

      Faut regarder la vérité en face : le mail tel qu'il est actuellement marche plutô bien, sinon on l'aurait remplacé depuis longtemps. Maintenant, c'est vrai qu'il souffre de certains inconvénients, notamment le SPAM. Mais est-ce en jetant le bébé avec l'eau du bain qu'on va résoudre les problèmes du mail ? Je ne pense pas. D'ailleurs ça fait longtemps que des prophètes en tout genre ont prédit la disparition du mail, mais ça n'arrive pas, tout simplement parce qu'il n'y a aucun remplaçant à la hauteur.

    • [^] # Re: Système de messagerie pour remplacer les mailing-lists (trololol)

      Posté par  . Évalué à 10.

      Par ce que si tu suit plusieurs projets tu doit surveiller plusieurs forums, avec des interfaces différentes, des logins différents etc.

      Alors qu'avec une mailing list tout arrive dans ton client mail, ou tu peut appliquer des règles de tri etc.

      Maintenant, perso je préfère NNTP (Usenet) mais bon chacun ses gouts.

      Il y a eu un débat du genre sur la mailing liste DjangoFr, au final il a été implémenté un connecteur mailinglist => forum, ça marche pas trop mal et ça contente tout le monde.

    • [^] # Re: Système de messagerie pour remplacer les mailing-lists (trololol)

      Posté par  . Évalué à 10.

      Entre aller sur un forum style phpbb àlacon™ et recevoir des messages de listes de diffusions tout chauds et mis dans leur propre dossier par un filtre qui se fait en 5 minutes dans Claws Mail, je sais ce que je choisis.
      Firefox/Konqueror/Midori/etc. n'est pas plus mon système d'exploitation qu'Emacs.

      et où participer demande un minimum de connaissances sous peine de voir sa boîte mail débordant de discussions.

      Il y a des listes de diffusion plus calmes que la LKML. slackbuilds-users, par exemple, a eu moins de 4000 messages depuis janvier 2009.

      Pourquoi les forums Web (avec éventuellement des notifications mail) ne se sont pas davantage démocratisés ?

      Je crois que j'ai déjà répondu, mais répétons-le (la répétition c'est la pédagogie):
      Les forums web c'est de la merde.

    • [^] # Re: Système de messagerie pour remplacer les mailing-lists (trololol)

      Posté par  (site web personnel) . Évalué à 9.

      Y'a t'il un gain de fonctionnalités apporté par l'usage du mail ?

      Un peu mon n'veu: avec un forum (si RoR soit-il) tu as:

      • aucune maîtrise sur le tri des messages;
      • aucune possbilité d'effectuer les traitements de ton choix sur les messages publiés;
      • aucune liberté dans l'élaboration de stratégies de sélection des messages.

      En gros dans un forum la forme et le fond sont confondus et tun ne peux rien faire, alors que dans une mailing list le serveur délivre le fond et le client de l'utilisateur (c'est-à-dire l'utilisateur) décide de la forme.

      La façon correcte de créer un forum de discussion à la linuxfr serait une mailing list un peu customisée, genre avec des dossiers contenant les votes (anonymisés) et une petite extension pour Thunderbird et Seamonkey et une autre pour Gnus qui permette de voter.

      Pourquoi les forums Web (avec éventuellement des notifications mail) ne se sont pas davantage démocratisés?

      (Ils le sont trop à mon goût.) Parceque un navigateur web, c'est presque toujours le plus mauvais outil possible. Si encore les forums exposaient publiquement la BDD qu'ils permettent de consulter, on pourrait écrire des clients adaptés à nos besoins ou une interface NNTP.

      • [^] # Re: Système de messagerie pour remplacer les mailing-lists (trololol)

        Posté par  . Évalué à 1.

        Avec une extension pour chaque "site" que tu visites ? L'avantage du navigateur web, c'est sa polyvalence, et la personalité du site web justement versus la généricité d'une ML.

        Sinon tu veux faire du mailer une sorte de navigateur fourre tout, avec des capacité d'extensibilité standardisées ? Tu veux retrouver la même flexibilité que ton navigateur internet avec ton mailer ... Mon petit doigt me dit que tu convergerait vers un truc fourre tout à la web d'aujourd'hui.

        • [^] # Re: Système de messagerie pour remplacer les mailing-lists (trololol)

          Posté par  (site web personnel) . Évalué à 10.

          Avec une extension pour chaque "site" que tu visites?

          Je pensais plutôt à une extension des RFCs sur les mails qui supporteraient quelques fonctions sympas qu'on trouve sur les forums comme les votes.

          L'avantage du navigateur web, c'est sa polyvalence,

          T'as fumé tout le StMaclou ou quoi?

          C'est tellement polyvalent et facile à programmer que toutes les interfaces aux forums de discussion dans un navigateur WEB sont bien plus fonctionnelles et bien mieux intégrées à l'OS que ne le sont les mailing lists et les forums usenet.

          Par exemple avec un navigateur WEB pour visiter un forum c'est super facile de:

          • sauvegarder ton message en cours de saisie pour interrompre celle-ci et reprendre plus tard;
          • reformater un message mal tapé (d'un autre);
          • rechercher les messages pondus par glandu entre le 2 et le 15 janvier de l'année dernière qui contiennent le mot OpenGL parceuque j'ai envie de retrouver un message particulier dans cette période;
          • archiver quelques messages sur ton disque;
          • préparer des templates de réponses;
          • ignorer automatiquement tous les fils de discussion où deux trolls que tu connais enchaînent les réponses (out toute autre stratégie de sélection des messages)
          • plonker les boulets;
          • imprimer le message;
          • faire des statistiques sur les messages avec un outil extérieur;
          • faire un CAESAR 13 sur un bout de message pour planquer un spoiler;
          • filtrer les messages avant de les envoyer avec les correcteur orthographique de ton choix.

          Allez je blague, en fait ça c'est le monde heureux des clients mails.

          Mon petit doigt, tu sais sait ce qu'il me dit?

          • [^] # Re: Système de messagerie pour remplacer les mailing-lists (trololol)

            Posté par  . Évalué à 1.

            Et tu ne peux pas faire :

            • un facebook like sans 42000 RFC
            • une tribune avec le site qui va autour (sans utiliser IRC) sur le même site
            • un système de tag
            • un système de notation personnalisé sans système de RFC
            • pour les sites de "contenu" associer facilement un thread à chaque contenu, et c'est quand même ultra courant d'avoir un thread de commentaire associé à un contenu sur le net.

            C'est des fonctionnalités qui sont très demandées pourtant, mélangées sur le web aujourd'hui et on imagine mal déporter ces fonctions "ailleurs" (un autre logiciel). Au final les utilisateurs ne recherchent pas les fonctions "avancées" mais plutôt les fonctions basiques et les trucs qui ont réellement du succès c'est plus un facebook avec un panel de fonctionnalité qui n'ont rien à voir. Pourtant certaines fonctionnalité recouvrent celles des newsgroup, mais les newsgroup ont lentement déclinés parce qu'ils sont trop figés et ne répondent pas à la demande globale, quelles que soient les fonctionalités avancées qu'ils offrent.

            • [^] # Re: Système de messagerie pour remplacer les mailing-lists (trololol)

              Posté par  (site web personnel) . Évalué à 5.

              Et tu ne peux pas faire
              [...]

              Tu pourrais faire une liste d'affirmations précises, justifiées et faciles à vérifier ou lieu de spéculer? Ça m'aiderait un peu à croire que tu as raison et ça permettrait de garder un minum d'intérêt à la discussion.

              Par exemple pour les points que j'ai cités: presque tous sont des fonctionnalités assez standard des lecteurs de mails ou newsgroups, on les trouve par exemple sur Thunderbird, Seamonkey et sûrement beacuoup d'autres. Les fonctionnalités d'après moi moins courantes sont:

              1. reformater un message mal tapé (d'un autre);
              2. ignorer automatiquement tous les fils de discussion où deux trolls que tu connais enchaînent les réponses (out toute autre stratégie de sélection des messages)
              3. faire un CAESAR 13 sur un bout de message pour planquer un spoiler;
              4. filtrer les messages avant de les envoyer avec les correcteur orthographique de ton choix

              Tout ça c'est (au moins) dans Gnus.

              1. faire des statistiques sur les messages avec un outil extérieur

              On peut utiliser fetchmail par exemple, et passer le courrier dans la moulinette de son choix.

              mais les newsgroup ont lentement déclinés parce qu'ils sont trop figés et ne répondent pas à la demande globale

              C'est sûr que comparé à 1992 il y a sûrement vachement moins d'utilisateurs de newsgroups et de mailing lists aujourd'hui :) Tu as des informations précises à ce sujet ou c'est une impression générale ou encore un préjugé?

              • [^] # Re: Système de messagerie pour remplacer les mailing-lists (trololol)

                Posté par  . Évalué à 5.

                Personnellement, je me suis désabonné de toutes les mailings lists où j'étais pour, entre autres, les raisons suivantes :

                • Il y a trop de sujets de discussion qui ne m'intéressent pas et que je suis obligé de télécharger, traiter et analyser
                • Il y a trop de messages pour ne rien dire (les gens qui citent tout le fil avant eux pour rajouter un mot ou une phrase qui n'apporte rien)
                • Il y a trop de bruit de fond
                • Ça prend trop de temps à télécharger, traiter et surtout analyser pour en retirer quelques informations
                • Ça prend de la place sur mon disque dur (et accessoirement sur le disque dur de tous les abonnés)
                • Ça n'économise pas de bande passante, puisque de toutes façons tout le contenu est téléchargé par tous les abonnés
                • Ça n'est pas dynamique ni collaboratif, dans le sens où on ne peut pas corriger un message une fois posté, ou indiquer qu'un message est pertinent, inutile ou du spam par exemple, de manière à éviter aux autres de se taper son traitement et sa lecture inutilement
                • Une mise en page des plus foireuse entre les différents messages
                • Rarement un lien vers la partie du projet concernée par la discussion, et inversement
                • Il faut s'abonner (aucune différence avec la création d'un compte donc)
                • L'adresse email est rendue publique
                • Souvent les fils de discussions sont cassés en plusieurs morceaux suivant qui a répondu et comment
                • Je ne peux faire des recherches que dans les messages que j'ai téléchargé
                • Si les infos que je cherche ont été postées avant que je ne m'abonne, je n'en dispose pas à moins d'aller faire le tour des archives sur le Web

                Ce que j'attends, entre autres choses :

                • Avoir un compte, qui me permette de conserver mon adresse email privée
                • Que je puisse ignorer des comptes de manière à ne pas voir leurs messages
                • Que je puisse ajouter en favoris des contacts, de manière à suivre leurs interventions
                • Que je puisse ajouter des contacts en amis, ce qui ferait un lien automatiquement entre les adresses emails, IM, réseaux sociaux, etc.
                • Une syntaxe de mise en page évoluée, du type wiki créole
                • La possibilité de corriger mes messages (voire d'accéder à l'historique des modifications)
                • La possibilité de noter de manière collaborative et dynamique la pertinence des messages, et de supprimer les spams
                • La possibilité de tagger et administrer un fil de discussion (classer dans diverses catégories, relier à des parties du projet, etc.) de manière dynamique
                • Un lien entre les discussions et les parties du projet concernées par la discussion
                • Un lien entre les parties du projet et les discussions correspondantes
                • Ne pas me télécharger des milliers de messages alors que seuls une dizaine m'intéressent
                • Pouvoir choisir des sujets d'intéressement (tags) et les voir mis en évidence dans l'interface générale, pour faciliter le tri visuel (et inversement, indiquer les tags dont on a RAB pour les masquer)
                • Pouvoir faire des recherches dans l'intégralité de la base
                • Pouvoir mettre en suivi ou en signets des fils de discussion ou des messages

                • [^] # Re: Système de messagerie pour remplacer les mailing-lists (trololol)

                  Posté par  (site web personnel) . Évalué à 3.

                  Pas mal de points concernent les habitudes des abonnés: je ne crois pas qu'un outil ou l'autre privilégie tel ou tel type de comportement

                  * Ça prend trop de temps à télécharger, traiter et surtout analyser pour en retirer quelques informations

                  Ça concerne encore le volume des informations, ce n'est pas vraiment lié à l'outil.

                  * Ça prend de la place sur mon disque dur (et accessoirement sur le disque dur de tous les abonnés)

                  Si tu choisis de garder ad vitam eternam tous les messages, beaucoup de logiciels de messagerie permettent de ne garder que les n dernier messages où vieux de mons de j jours.

                  * Ça n'est pas dynamique ni collaboratif, dans le sens où on ne peut pas corriger un message une fois posté, ou indiquer qu'un message est pertinent, inutile ou du spam par exemple, de manière à éviter aux autres de se taper son traitement et sa lecture inutilement

                  Sur les newsgroups on peut corriger les messages, c'est un règlage du serveur.

                  * Une mise en page des plus foireuse entre les différents messages

                  Ça dépend des utilsiateurs et de la communauté particulière, de ce que j'en ai vu les forums et les mailing lists n'ont vraiment rien à s'envier.

                  * L'adresse email est rendue publique

                  En général on crée une adresse ou un alias dédié.

                  * Je ne peux faire des recherches que dans les messages que j'ai téléchargé

                  Mais d'un autre côté tu as des critères de recherche beaucoup plus fins.

                  * Si les infos que je cherche ont été postées avant que je ne m'abonne, je n'en dispose pas à moins d'aller faire le tour des archives sur le Web.

                  Il me semble que le point vraiment important est l'histoire des votes.

                  * Avoir un compte, qui me permette de conserver mon adresse email privée

                  Ou créer une addresse dédiée.

                  * Que je puisse ignorer des comptes de manière à ne pas voir leurs messages
* Que je puisse ajouter en favoris des contacts, de manière à suivre leurs interventions

                  C'est possible.

                  * Que je puisse ajouter des contacts en amis, ce qui ferait un lien automatiquement entre les adresses emails, IM, réseaux sociaux, etc.

                  Je ne comprend pas ce que tu veux dire/

                  * Une syntaxe de mise en page évoluée, du type wiki créole

                  On peut envoyer des messages HTML, c'est un chox de la liste de l'interdire ou pas.

                  * La possibilité de corriger mes messages (voire d'accéder à l'historique des modifications)

* La possibilité de noter de manière collaborative et dynamique la pertinence des messages, et de supprimer les spams

* La possibilité de tagger et administrer un fil de discussion (classer dans diverses catégories, relier à des parties du projet, etc.) de manière dynamique

* Un lien entre les discussions et les parties du projet concernées par la discussion
* Un lien entre les parties du projet et les discussions correspondantes

                  Je ne comprend pas ce que tu veux dire (de quel projet parles-tu?).

                  * Ne pas me télécharger des milliers de messages alors que seuls une dizaine m'intéressent

                  Sur les newsgroups tu ne télécharges en général que les enveloppes, tout comme sur un forum (la ligne de sujet).

                  * Pouvoir choisir des sujets d'intéressement (tags) et les voir mis en évidence dans l'interface générale, pour faciliter le tri visuel (et inversement, indiquer les tags dont on a RAB pour les masquer)

* Pouvoir faire des recherches dans l'intégralité de la base

* Pouvoir mettre en suivi ou en signets des fils de discussion ou des messages

                  C'est possible.

                  En gros je retiens que les principaux défauts (inhérents à l'outil, pas à sa pratique) des mailing-lists sont l'absence de gestion interactive de contenu par des utilisateurs et des facilités de recherche à l'archive des discussions. Si quelqu'un s'attelle à la tâche il peut sûrement pondre quelque chose de plausible.

                  • [^] # Re: Système de messagerie pour remplacer les mailing-lists (trololol)

                    Posté par  . Évalué à 2.

                    * Ça prend trop de temps à télécharger, traiter et surtout analyser pour en retirer quelques informations

                    Ça concerne encore le volume des informations, ce n'est pas vraiment lié à l'outil.

                    Si des outils peuvent être conçu pour être capable de traiter un volume plus ou moins important d'information (regarde POP et IMAP).

                    * Une mise en page des plus foireuse entre les différents messages
                    Ça dépend des utilisateurs et de la communauté particulière, de ce que j'en ai vu les forums et les mailing lists n'ont vraiment rien à s'envier.

                    Et tu as voulu le démontrer avec ta réponse ? D'ailleurs les quelques fois ou j'ai expliqué à quelqu'un que la fonction prévisualisation était vraiment cool pour vérifier la mise en page, on m'a répondu Weboob et qu'il fallait s'y faire parce que c'est comme ça. Les gens qui utilisent leurs mails semblent :

                    • ne pas connaître markdown
                    • ne pas avoir envi de le connaître et préfèrent reporter la faute sur le site (et ainsi avoir une syntaxe sur le site qui n'est pas du markdown, mais presque et qui n'est donc utilisé nul part ailleurs)

                    * L'adresse email est rendue publique
                    En général on crée une adresse ou un alias dédié.

                    C'est super lourd.

                    * Une syntaxe de mise en page évoluée, du type wiki créole
                    On peut envoyer des messages HTML, c'est un chox de la liste de l'interdire ou pas.

                    J'en ai pas encore vu qui l'autorisez et c'est bien normal quand on connais les dérive possible de ce truc.

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Pourquoi pas, mais…

    Posté par  . Évalué à 2.

    J'imagine que l'idée émanant de la découverte de tor, c'est dans l'idée de faire du confidentiel.
    Je trouve ça étonnant (et dommage) de partir sur du http.
    Mais pourquoi pas.

    Par ailleurs, et c'est surtout la raison de ma réaction, je voulais signaler l'existence du projet retroshare, qui est un logiciel de messagerie instantanée (qui permet aussi d'échanger des mails (ça à l'allure de mails, mais ça n'en est pas vraiment), ou des fichiers) qui fonctionne en p2p, et où tous les flux sont chiffrés à base de pgp.

    Brayf, je trouve le projet intéressant, et de plus il est assez actif (en plus d'être déjà assez avancé)

  • # F2F

    Posté par  (site web personnel) . Évalué à 2.

    Certains logiciels "friends to friends" proposent un système de messagerie décentralisé et sécurisé. Plutôt que de réinventer la roue, pourquoi ne pas développer une interface web pour ces logiciels? Par exemple pour retroshare?

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # Pourquoi pas ?

    Posté par  (site web personnel) . Évalué à -1.

    Bonjour,

    Le système de mail actuel pour moi souffre de nombreux maux :

    • le spam
    • le tri / suivi de dossiers / de discussions
    • formattage des informations

    Le spam : j'ai une adresse mail crée le siècle dernier, donc avant le spam
    et ma participation à certains forums a permis de récolter cette adresse automatiquement
    résultat :
    de 200 à 300 spams / jour et depuis les anti spams => entre 30 et 50 qui passent a travers

    le tri : déformation professionnelle j'aurais tendance a mettre tout cela en base de données ( SQL / NoSQL a voir) car bien souvent le besoin de retrouver certain mail en fonction de contenu ou de destinataire ou de CC: etc...
    Quelques champs libres avec Projet / type d'informations etc ... serait judicieux

    ce qui nous amène au formattage des informations :
    Exemple : je demande un chiffrage a un fournisseur (Delai / Prix / remise etc ...)
    un tag PUBLICITE serait le bienvenu mais qui ne serait pas des spams
    un tag FICHIER VOLUMINEUX fonctionnant un peu comme dl.free.fr (cela éviterait que certain catalogue soit diffusé et copié sur tout les postes de manière systématique :) )

    mais pour cela il faut admettre que le e-mail en tant que tel n'est pas que le messager
    mais aussi une base de données et donc une source d'informations avec tout ce que cela engage (sauvegarde, publication, sécurité etc...)

    Et la il faudrait franchir un pas ...

  • # Pourquoi le HTTP

    Posté par  (site web personnel) . Évalué à 3.

    À l'origine, je ne suis pas fan du tout des interfaces web. Et pas tellement fan du HTTP à toutes les sauces. Mais j'ai du me rendre à l'évidence:

    Si je veux faire un client web (parce que les gens ne veulent pas installer un client lourd), j'ai à ma disposition du HTML pour la description de l'interface et du Javascript pour le comportement. Et javascript ne peux communiquer qu'avec XmlHttpRequest -- du HTTP.

    Su je veux gérer un canal de communication sécurisé, je dois soit me palucher tout SSL à la main sur mon flux TCP, soit réutiliser un protocole de plus haut niveau (HTTPS en l'occurence)

    Si je veux pouvoir faire plus d'une chose sur le même port TCP, délimiter des messages, soit je prend un formalisme que je définis moi même, soit je réutilise quelque chose d'existant comme HTTP, WebSockets, ...

    J'aurais aussi pu réutiliser XMPP (j'en suis pas mal fan), mais je dois admettre qu'il dispose de moins de libs et est bien moins démocratisé. Au final, j'ai fini par choisir HTTP.

    Au final, j'adore quand les interfaces sont documentées et normalisées, ça permet d'écrire des clients lourds ... je n'aime pas trop les clients légers.

    • [^] # Re: Pourquoi le HTTP

      Posté par  (site web personnel) . Évalué à 2.

      Et si on veut de l'authentification, HTTp gère ça nativement (même si pas forcément trop bien). Je n'ai pas non plus envie de rajouter une couche login à un protocole.

    • [^] # Re: Pourquoi le HTTP

      Posté par  (site web personnel) . Évalué à 6.

      Au final, j'adore quand les interfaces sont documentées et normalisées, ça permet d'écrire des clients lourds ... je n'aime pas trop les clients légers.

      Surtout qu'en général, les « clients lourds » en question, plus précisément les clients natifs, sont légers, alors que que les « clients légers » en question, plus précisément les clients web, sont bien lourds dans leur genre.

      • [^] # Re: Pourquoi le HTTP

        Posté par  . Évalué à 3.

        Là où le client web prend tout son sens c'est dans les « smartphones », ça permet d'être utilisable sur Android/Symbian/iOS/BlackBerry/PalmOS/autres au lieu de se palucher X clients, on en écris un seul.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Pourquoi le HTTP

      Posté par  (site web personnel) . Évalué à 3.

      Au final, j'ai fini par choisir HTTP.

      Je comprends bien ce choix de HTTP. Par contre le pingback que tu proposes montre a quel point il est inadapté à ce type d'échanges.

      Ce n'est pas spécifique à ton projet.

      Sans même parler de sa mauvaise utilisation (requêtes get a effet de bord, sous utilisation de mime), de ses bidouilles (keepalive ...), on voit clairement qu'on passe son temps a faire des requêtes http dans tous les sens en se demandant si petit scarabée est bien celui qu'il dit qu'il est ; côté serveur (auth bypass, vols de sessions ...) comme côté client (phishing ...).

      La solution n'est pas de commencer par réfléchir a un protocole fiable pour ouvrir des sessions chiffrées et authentifiés. Puis transporter le reste après.

      • [^] # Re: Pourquoi le HTTP

        Posté par  . Évalué à 2.

        Bof, je suis pas spécialement partisan du tout HTTP mais c'est vrai que pour le coup son protocole REST répond assez bien au problème.

  • # Passerelles?

    Posté par  (site web personnel) . Évalué à 3.

    L'idée est intéressante, mais comme tout nouveau "réseau", il risque de mourir par manque d'utilisateurs. Est-ce que les premiers modules à développer ne serait pas des passerelles vers smtp et imap, voire vers XMPP?

    Tu parles de plug computer, donc je suppose que tu vas orienter le système vers l'auto-hébergement? Comment penses-tu résoudre le problème du serveur qui tombe en panne? Avec SMTP une vague règle dit qu'il faut attendre au moins 5 jours avant de balancer les messages. Hors 5 jours c'est court, par exemple pour un particulier qui part en vacances 2 semaines...

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Suivre le flux des commentaires

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