Journal Delta Chat est prêt pour le bureau

29
7
fév.
2019

Delta Chat est un logiciel de messagerie instantanée comme il en existe des milliers: on ajoute des contacts, on crée des groupes et s'envoie des mots doux ou des insultes.

Il a toutefois un avantage majeur sur ses concurrents: tous vos contacts ont déjà un compte sur le réseau qu'il utilise.

Plutôt que de réinventer un nième protocole, les auteurs de Delta Chat ont fait le choix de se baser sur IMAP, SMTP et les diverses RFC qui définissent les courriers électroniques.

Il était déjà disponible pour les OS privateurs mobiles (Android, iOS) et la dernière version est disponible pour des bureaux privateurs (MacOS) et libres (Linux).

android
ios
bureau

Une version Windows est aussi en développement cours.

Je trouve l'initiative très intéressante, les messageries instantanées interopérables étant rare (à part XMPP, je n'en connais pas d'autre).

  • # Clarification

    Posté par . Évalué à 4.

    J'ai un peu de mal à comprendre mais peut on dire que Delta Chat est un client email ? Je ne vois pas en quoi il diffère d'un client email traditionnel sauf de par sa présentation (et le chiffrage des messages). Je me base sur ma compréhension de la FAQ :

    Que se passe-t’il si le destinataire n’utilise pas Delta Chat?
    Le destinataire recevra un courriel normal - s’il y répond, vous verrez la réponse dans l’application Delta Chat.

    • [^] # Re: Clarification

      Posté par . Évalué à 10. Dernière modification le 07/02/19 à 15:50.

      C'est un client mail avec un UI de messagerie instantanée. Il prend partie de la multitude de serveurs mails qui supportent maintenant le push-IMAP.

      Je l'utilise un peu mais ce qui est dommage c'est qu'il n'est pas dans le google play ce qui fait que les gens qui ne connaissent pas f-droid et ne savent pas installer une application qui vient d'ailleurs ne l'installeront jamais. L'avantage c'est que même sans tu peux leur envoyer des messages et ils peuvent te réponde sans que tu aies à connaître leur messagerie instantanée préférée.

      • [^] # Re: Clarification

        Posté par . Évalué à 2.

        Bonsoir, ton message m'a intrigué car je pensais en parler à la famille. Puisqu'ils sont des utilisateurs non passionnés de leurs smartphones ils utilisent surtout le play store (avant que /e/ OS ne sorte en version stable ;). Et si Delta Chat n'est pas dessus, ça risque de ne pas être pratique pour qu'on s'y mette. Heureusement la publication sur le play store est prévu : https://github.com/deltachat/deltachat-android/issues/697
        NH

    • [^] # Re: Clarification

      Posté par . Évalué à 9.

      [chiffrage] => chiffrement, sinon cela signifie que tu les comptes tout simplement ;)

      • [^] # Re: Clarification

        Posté par . Évalué à 1. Dernière modification le 08/02/19 à 16:26.

        Larousse indique que le chiffrage est l'action de chiffrer qui lui même signifie "Transformer un message par un procédé de chiffrement".

        Chiffrer

        Transformer un message par un procédé de chiffrement.

        Chiffrement

        Opération qui consiste à transformer un message à transmettre, dit « message clair », en un autre message, inintelligible pour un tiers, dit « message chiffré », en vue d'assurer le secret de sa transmission.

        Chiffrage

        Action de chiffrer, de calculer.

        • [^] # Re: Clarification

          Posté par (page perso) . Évalué à 6.

          La définition du Larousse n'est pas claire : il n'est pas indiqué si l'action de chiffre se rapporte à toutes les significations du mot « chiffrer », ou seulement à celle qui est apparentée à « calculer ».
          Tu ne peux donc pas t'appuyer dessus.

          Jusqu'à présent, chiffrage n'est pas synonyme de chiffrement.

          • [^] # Re: Clarification

            Posté par . Évalué à 1.

            La définition du Larousse n'est pas claire
            Tu ne peux donc pas t'appuyer dessus.
            Jusqu'à présent, chiffrage n'est pas synonyme de chiffrement.

            Tu ne peux pas prétendre qu'un argument n'est pas valide et en conclure que l'inverse de l'argument est vrai. Je ne conteste pas le fait que la définition n'est pas claire mais penser qu'elle ne s'applique qu'à une partie du mot employé me parait être une interprétation (qui est peut être valide).

            • [^] # Re: Clarification

              Posté par (page perso) . Évalué à 2. Dernière modification le 11/02/19 à 18:53.

              Je ne conclue pas que l'inverse est vrai : l'inverse était la définition qui existait jusqu'ici :-)

              Tu montres que la définition est éventuellement plus large, ou nouvelle, ou a évolué, ou etc. Si cette nouveauté n'est pas « prouvée » alors l'ancienne définition reste la bonne. Dans 10 ans elle sera peut-être à la mode, pour l'instant non.

              note : je trouve ton commentaire relativement pertinent. J'ai plussé et j'ai vu qu'il était préalablement moinssé. Est-ce un moinssage « je ne suis pas d'accord » ou j'ai raté un élément qui rend le commentaire non pertinent ?
              Ce n'est pas une pique contre les moinssage, c'est juste que j'ai l'impression d'avoir raté un truc (sur un sujet pas important du tout, nous sommes d'accord).

        • [^] # Re: Clarification

          Posté par . Évalué à 4.

          Action de chiffrer, de calculer.

          Oui c'est exact mais là chiffrer veut simplement dire calculer et non chiffrer une donnée ou autre.
          Par exemple un menuisier te fait un devis pour changer une porte, il va donc te chiffrer le coût des travaux.

          • [^] # Re: Clarification

            Posté par . Évalué à 2.

            Pour être très clair : je continue la discussion car j'aime nager à contre courant. Je n'ai jamais vu le mot "chiffrage" employé dans le sens de "chiffrement" comme je l'ai fait après le commentaire me corrigeant, je voulais vérifier la validité (ou non) de l'usage.

            Oui c'est exact mais là chiffrer veut simplement dire calculer et non chiffrer une donnée ou autre.

            Ca, c'est une pure interprétation (tout comme l'est ma compréhension de la portée de la définition). Sur le site du CNRTL (Centre National des Ressources Textuelles et Lexicales) la page correspondant au mot chiffrer indique très clairement que le mot "chiffrage" peut être employé dans le sens de "chiffrement".

            Chiffrage, subst. masc.Action de chiffrer.
            d) [Correspond à chiffrer II] Chiffrage d'une dépêche. La plupart des dict. gén. enregistrent aussi le subst. masc. chiffrement, synon. de chiffrage dans cet emploi.P. métaph. Vient le psychanalyste : l'obscurité du poème ne sera pour lui qu'un effet de chiffrage du subconscient ou de l'inconscient (Ricœur, Philos. de la volonté,1949, p. 381).

            Juste pour être complet, "chiffrer II" c'est :

            II.− [Avec une idée de secret] Transcrire des messages en un langage secret. Synon. coder; anton. déchiffrer, décrypter.Chiffrer des dépêches de quinze ou vingt pages (Stendhal, La Chartreuse de Parme,1839, p. 14).

            Wikitionnaire va également dans ce sens (avec "chiffrement" comme synonyme :

            1. Action de chiffrer un document.

            Un autre outil que j'aime beaucoup et que je trouve très performant pour les traductions, c'est le site deepl.com, si j'essaye de traduire "chiffrage" en anglais, j'obtiens :

            encryption n
            costing n
            .
            less common:
            coding n
            quantification n
            encoding n

            Conclusion personnelle : j'ai bien conscience que l'usage de "chiffrage" dans le sens de "chiffrement" n'est pas habituel et peut paraitre incorrect mais cet usage semble toléré en se basant sur les définitions citées.

            • [^] # Re: Clarification

              Posté par . Évalué à 1.

              Ba écoute fait comme tu veux. Mais si tu me sors ça dans une discussion je te mets une tape façon Gibbs dans NCIS ;)

            • [^] # Re: Clarification

              Posté par (page perso) . Évalué à 2.

              Du coup ça fait sauter la clause « définition non prouvée » de mon commentaire plus haut.

  • # Sympa

    Posté par . Évalué à 6.

    J'ai regardé la spec pour comprendre un peu mieux :
    https://github.com/deltachat/spec/blob/master/spec.md

    C'est assez intéressant. J'ai déjà eu des idées similaires pour un autre type de projet, et j'avais également déjà voulu faire du chat par e-mail, sans y penser sérieusement… bravo à vous.

    En ce qui concerne les groupes, j'avais tenté de voir comment était supporté la gestion de groupe « historique » de l'e-mail (https://tools.ietf.org/html/rfc5322#page-17) et ça marchait dans Outlook, ce qui m'avait motivé pour creuser un peu, celui-ci étant pour moi le plus petit dénominateur commun. Manque de bol, j'ai l'impression que c'est le MUA qui gère le mieux cette feature… Effectivement, tracker les modification d'état du groupe de manière non-stricte est à faire, et le système présenté ici est pas mal.

    Bon courage pour la suite !

  • # Consommation de ressources

    Posté par (page perso) . Évalué à 2. Dernière modification le 07/02/19 à 15:50.

    Plutôt que de réinventer un nième protocole, les auteurs de Delta Chat ont fait le choix de se baser sur IMAP, SMTP et les diverses RFC qui définissent les courriers électroniques.

    Je me demande quel est l'overhead (octets utiles sur octets pour transporter) pour dire "salut" suivi de "salut" suivi de "je t'ai pas vu en ligne hier" (chose qu'on ne fait pas avec des mails) par rapport aux autres protocoles.

    et les diverses RFC qui définissent les courriers électroniques.

    Et dire qu'il aurait pu utiliser la RFC 6120… Mais sans doute trop simple.

    Il a toutefois un avantage majeur sur ses concurrents: tous vos contacts ont déjà un compte sur le réseau qu'il utilise.

    On a inventé un truc qui s'appelle passerelle, pour avoir un protocole optimal quand on peut et passer en "pas adapté" quand on ne peut faire autrement.
    Donc la désolé mais je cherche toujours quel est l'avantage par rapport à d'autres solution technique genre protocole pour faire du chat + passerelle mail pour ceux sans clients contre ici (si je comprend bien) utiliser en permanence du vieux truc pas adapté.

    logiciel de messagerie instantanée

    D'après les RFC utilisés, c'est un client mail (user agent pour être précis).

    • [^] # Re: Consommation de ressources

      Posté par (page perso) . Évalué à 10.

      je cherche toujours quel est l'avantage par rapport à d'autres solution technique genre protocole pour faire du chat + passerelle mail

      L'existence?

      Incubez l'excellence sur https://linuxfr.org/board/

    • [^] # Re: Consommation de ressources

      Posté par . Évalué à 10.

      Je me demande quel est l'overhead (octets utiles sur octets pour transporter) pour dire "salut" suivi de "salut" suivi de "je t'ai pas vu en ligne hier" (chose qu'on ne fait pas avec des mails) par rapport aux autres protocoles.

      Sûrement 100 fois moins que la somme des JS utilisés sur chaque page Web pour visionner le-dit message ;-)

      • [^] # Re: Consommation de ressources

        Posté par . Évalué à 6. Dernière modification le 08/02/19 à 08:51.

        Si on parle en pourcentage, je pense que le message avec juste "salut" gagne haut la main. Surtout s'il passe par des prestataires gourmands en headers rajoutés par leur système de mail comme outlook. On doit facilement atteindre le mail de 5ko pour 5o de données utiles.

        On ne parle même pas quel mail est passé deux fois dans des antispams, antivirus, antibidule, super-AI et autres cervelles de cafard, des 50 requêtes DNS mini pour éviter un faux mail. Franchement, la charge pour afficher le message commence à devenir négligeable comparer à tout le traitement qu'à subit le mail.

        C'est bien d'utiliser l'existant. Mais dans ce cas, si l'existant pouvait disparaître, ça serai pas un mal. Je pense même que les ours polaires viendraient nous remercier.

        • [^] # Re: Consommation de ressources

          Posté par . Évalué à 7.

          Si on parle en pourcentage, je pense que le message avec juste "salut" gagne haut la main. Surtout s'il passe par des prestataires gourmands en headers rajoutés par leur système de mail comme outlook. On doit facilement atteindre le mail de 5ko pour 5o de données utiles.

          Les SMS ne sont pas particulièrement mieux, je ne vois pas d'intifada écologique contre l'usage de ces protocoles pourtant particulièrement coûteux. Les protocoles comme XMPP demandent le maintiens d'une connexion avec éventuellement des ping réguliers (en plus pour XMPP le fait d'utiliser XML pas particulièrement compact ni léger en temps de traitement).

          La question écologique est intéressante mais il faut véritablement comparer plutôt que de sortir des trucs à l'emporte pièce.

          • [^] # Re: Consommation de ressources

            Posté par . Évalué à 7.

            Il me semble que pour les SMS c'est l'inverse : le canal existait déjà pour des raisons techniques et les opérateurs se sont mis à le rendre disponible pour échanger des messages humains. Ça n'a rien demandé comme adaptation au niveau du réseau. Et pour m'être retrouvé parfois avec une batterie faible, j'ai pu remarquer que les SMS consomment beaucoup moins d'énergie au niveau du téléphone, que la communication audio. Sans doute parce qu'on économise les conversions numérique <-> analogique nécessaires pour la voix.

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

            • [^] # Re: Consommation de ressources

              Posté par . Évalué à 7.

              Ça n'a rien demandé comme adaptation au niveau du réseau.

              Passer de quelques milliers de messages par jours à quelques millions avec de gros pics ? Se mettre à router ses messages entre opérateurs ? Permettre à des tiers de se connecter à se réseau pour faire des numéros cours et gérer des serveurs de SMS ?

              Oui je suis sûr que ça n'a pas demandé d'adaptation, ou alors vraiment très peu.

        • [^] # Re: Consommation de ressources

          Posté par (page perso) . Évalué à 8. Dernière modification le 08/02/19 à 09:46.

          Ce serait intéressant de comparer avec l'overhead des autres protocoles de messageries instantanées en prenant en compte une dizaine de conversation sur une semaine plutôt qu'un seul message.

          Incubez l'excellence sur https://linuxfr.org/board/

        • [^] # Re: Consommation de ressources

          Posté par . Évalué à 8. Dernière modification le 08/02/19 à 11:24.

          C'est bien d'utiliser l'existant. Mais dans ce cas, si l'existant pouvait disparaître, ça serai pas un mal. Je pense même que les ours polaires viendraient nous remercier.

          Ça c'est le commentaire typique de celui qui va réinventer la roue carrée. Les protocoles mails ont un passif énorme où tout un tas de problèmes sont réglés depuis très longtemps. Si tu veux remplacer le mail par un truc qui a les mêmes fonctionnalités, tu vas retomber sur les mêmes problèmes et tu vas avoir les mêmes solutions (ou des solutions moins bonnes).

          • [^] # Re: Consommation de ressources

            Posté par (page perso) . Évalué à 4.

            Le mail n'a pas vraiment de problème d'architecture. Si on le refaisait aujourd'hui, ce serait plus propre (HTTP au lieu de protocoles spécifiques, un format de message décrit par un langage type XSD, une enveloppe type zip pour éviter d'encoder en base64…), mais pas très différent.

            Incubez l'excellence sur https://linuxfr.org/board/

            • [^] # Re: Consommation de ressources

              Posté par . Évalué à 3.

              Si on le refaisait aujourd'hui, ça s'appellerait xmpp.

              splash!

              • [^] # Re: Consommation de ressources

                Posté par (page perso) . Évalué à 8. Dernière modification le 08/02/19 à 15:29.

                C'est bien la preuve que réinventer la roue ne marche pas !

                Incubez l'excellence sur https://linuxfr.org/board/

                • [^] # Re: Consommation de ressources

                  Posté par . Évalué à 1.

                  C'est bien la preuve que réinventer la roue ne marche pas !

                  Oui et non :)
                  C'est surtout que XMPP avait image de protocol de chat only pendant 10ans.

                  Ça aurait été une super alternative au mail qu'on connait. Là, c'est plutôt GMAIL et Outlook/Exchange qui mènent la danse avec des ajouts sympa mais limités à leur stack.

                  • [^] # Re: Consommation de ressources

                    Posté par . Évalué à 8.

                    Tu lis comment tes messages XMPP hors connexion ?
                    Tu fais comment pour trier tes messages XMPP ?
                    Le forward de message tu le fais par copier/coller ?
                    Les mailing list c'est différent des salons.

                    C'est surtout que XMPP avait image de protocol de chat only pendant 10ans.

                    Non c'est qu'il a passé 10 ans à tenter d'être un protocole de chat avant de se dire qu'il pourrait réinventer la roue lui aussi.

                    • [^] # Re: Consommation de ressources

                      Posté par . Évalué à 7.

                      Tu lis comment tes messages XMPP hors connexion ?

                      En ouvrant ton client, mais surtout tes yeux.

                      Tu fais comment pour trier tes messages XMPP 

                      Avec ton client xmpp

                      Le forward de message tu le fais par copier/coller ?

                      Non en utilisant le bouton forward

                      Les mailing list c'est différent des salons.

                      Certe.

                      On te parle de protocole, tu réponds à côté de sur des questions d'UI.

                      • [^] # Re: Consommation de ressources

                        Posté par . Évalué à 3.

                        Non on parle de techno, je vous surtout des gens dire que c'est pas bien d'utiliser imap pour du chat et vendre d'utiliser xmpp pour du mail. Donc on a le droit de tordre les protocoles ou pas ? Dire que ça doit être dans le client c'est bien mais quel client le fait ? Comment tu suit plusieurs conversations différentes avec un seul et même destinataire ? Avec plusieurs tu dois perpétuellement créer des conversations ?

                        On peut implémenter IP au dessus de XMPP, donc oui on peut tout imaginer mais qu'est ce qui existe à l'heure actuelle ? Pourquoi est-ce que toutes ces bonnes idées ne sont pas implémenter ?

                        Se plaindre du tout http c'est une chose mais si c'est pour le remplacer par du tout xmpp ça ne change pas fondamentalement le problème.

            • [^] # Re: Consommation de ressources

              Posté par (page perso) . Évalué à 4.

              HTTP au lieu de protocoles spécifiques

              HTTP n'est donc pas un protocole spécifique ?

            • [^] # Re: Consommation de ressources

              Posté par (page perso) . Évalué à 4.

              (HTTP au lieu de protocoles spécifiques,

              Pourquoi ?

              * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

              • [^] # Re: Consommation de ressources

                Posté par (page perso) . Évalué à 3.

                Pour passer les firewall/proxy nazis.

                Incubez l'excellence sur https://linuxfr.org/board/

                • [^] # Re: Consommation de ressources

                  Posté par (page perso) . Évalué à 2.

                  Mouai… sauf qu’à cause de ça les sysadmins se sont vite rendus compte qu’il y avait tout et n’importe quoi en HTTP, et du coup on a maintenant droit à du « deep packet inspection » et à du MITM officiellement installé en proxy. Génial.

                  • [^] # Re: Consommation de ressources

                    Posté par . Évalué à 3.

                    Ils ne l'auraient pas fait sur les autres protocoles ?

                    • [^] # Re: Consommation de ressources

                      Posté par (page perso) . Évalué à 1.

                      Probablement pas.
                      Avant, le filtrage en entreprise, en gros c’était : HTTP ça va ; FTP, SMTP, IMAP, XMPP, etc. refusés. Et HTTPS… c’est compliqué, alors oui ou non selon là où on bossait.

                      Puis 2 choses sont arrivées :

                      1. Le contenu HTTP s’est mis à migrer vers HTTPS, et au lieu d’avoir HTTPS pour les banques et autres sites « sérieux » (c’était en fait un préjugé), on s’est mis à avoir HTTPS pour tout, y compris les loisirs, sites sociaux, etc.

                      2. HTTP(S) s’est mêlé de la messagerie avec les webmails, du transfert de fichiers directement en HTTP, de la messagerie instantanée (et assimilée : Facebook, etc.), des jeux, des bureaux distants, et j’en passe.

                      Les administrateurs de réseau n’ont donc pas eu d’autre choix que d’inspecter le HTTP et le HTTPS, pour savoir si c’est du HTTP normal ou de la messagerie (ex-SMTP/IMAP), ou du transfert de fichiers (ex-FTP), ou encore autre chose…

                      • [^] # Re: Consommation de ressources

                        Posté par (page perso) . Évalué à 7.

                        Les administrateurs de réseau n’ont donc pas eu d’autre choix que d’inspecter le HTTP et le HTTPS

                        Les admins ont :
                        - soit décidé d'inspecter les protocoles (ce sont ceux qui ont trop de temps libre)
                        - soit reçu l'ordre de le faire (ceux-là du coup on beaucoup moins de temps libre)
                        - soit rien du tout : l'immense majorité des cas

    • [^] # Re: Consommation de ressources

      Posté par (page perso) . Évalué à 3.

      Je me demande quel est l'overhead (octets utiles sur octets pour transporter) pour dire "salut" suivi de "salut" suivi de "je t'ai pas vu en ligne hier" (chose qu'on ne fait pas avec des mails) par rapport aux autres protocoles.

      J'avais déjà vu cette app y a un bout de temps, et je me suis posé la même question.
      Et franchement, je doute que beaucoup de monde ait envie de voir après, quand ils ouvrent leurs boites mail, un fil de discussion de message de ce genre, avec au milieu les courriels plus classique. Ou alors faut se créer une boite mail dédiée ? Mais quand je vois déjà l'énorme boulot que c'est pour inciter les gens à voir ailleurs que chez gmail (au moins pour se renseigner), je doute réussir à avoir des contacts qui utilisent cette solution quand y a whatsapp a côté.

      Opera le fait depuis 10 ans.

  • # Matrix/Riot

    Posté par . Évalué à -5.

    Matrix est un serveur de messagerie instantanée libre, et le client Riot est disponible en version web pour les ordinateurs de bureau, et sous forme d'app pour les appareils mobiles.

    Riot permet de passer des appels y compris video en VOIP, et il existe des passerelles matrix pour IRC, slack, github…

    https://riot.im

    • [^] # Re: Matrix/Riot

      Posté par . Évalué à 2.

      Pour mon édification personnelle, mes moinseurs pourraient-ils m'expliquer la ou les raisons du moinsage ? Ayant fait ce commentaire en toute bonne foi, je tombe un peu des nues.

      • [^] # Re: Matrix/Riot

        Posté par . Évalué à 9.

        Ton message présente un logiciel de chat pas en quoi il différe de celui présenté dans le journal ou en quoi il est mieux ou moins bien. Bref il n'y a pas vraiment de lien entre ton commentaire et ce journal. Énumérer les solutions de chat n'est pas plus intéressant que ça.

        • [^] # Re: Matrix/Riot

          Posté par . Évalué à 5.

          À la fin du nourjal :

          les messageries instantanées interopérables étant rare (à part XMPP, je n'en connais pas d'autre).

          Il me parait donc plutôt pertinent de citer un système (protocole ouvert + serveurs + clients) de messagerie instantanée aux fonctionnalités poussées dont l'auteur du nourjal n'a pas encore fait la connaissance.

          Bon d'accord, on peut rajouter que Riot permet le chiffrement de bout en bout, qu'il existe des librairies dans plusieurs langages pour interagir avec Matrix, que les projets liés à ce système sont dynamiques…toussa toussa.

          Je suppose que le commenteur qui parle de Matrix/Riot veut signaler qu'il existe des choses tout à fait intéressantes dans le domaine de la messagerie instantanée libre. N'est-il pas ?

          • [^] # Re: Matrix/Riot

            Posté par . Évalué à 8.

            Oula je ne dois pas que ce qu'il décrit est fondamentalement inintéressant juste qu'il n'a probablement pas suffisamment mis en évidence le lien avec le contenu du journal.

            Le journal comme tu le cite parle d'interopérabilité et pas d'ouverture. C'est assez différent sans être antinomique.

            Dis plus clairement : ce qui fait qu'une solution de communication marche ou pas est sa quantité d'utilisateurs. Avoir une démarche pour maximiser son nombre d'utilisateurs est vraiment important. Sachant que faire déplacer les utilisateurs d'ICQ, MSN, bbm, hangout, slack, fb messenger, WhatsApp sans avoir la force de frappe d'un GAFAM est très compliqué. Donc une démarche comme xmpp (un standard et une fédération pour que les instances ne soient pas concurrentes) ou comme delta (utilisation de protocoles déjà massivement utilisés est intéressant).

            Que propose Matrix pour cet aspect particulier ? Qu'est ce qui fais que les gens vont pouvoir utiliser Matrix ? Il y a des passerelles vers WhatsApp, hangout et fb messenger ?

            (à noter que je n'est pas inutilé moi même juste tenté de répondre à la question de l'auteur du commentaire)

  • # Ca semble extra, risque de spammer les contacts?

    Posté par . Évalué à 3.

    Je trouve l'idée vraiment bonne. Presque tout le monde a accepté d'utiliser WhatsApp, mais quid du jour où Facebook voudra vraiment monétiser son investissement?

    Par contre, quelle est la réaction des correspondants qui n'utilisent pas l'appli? Est-ce que chaque message envoyé est un email séparé ou est-ce que les messages consécutifs sont consolidés avant d'être envoyés pour ceux qui n'utilisent pas Delta Chat? Si chaque message est un email, ça doit vite ressembler à du spam.

    • [^] # Re: Ca semble extra, risque de spammer les contacts?

      Posté par (page perso) . Évalué à 2.

      Ça fait un email par message. Ça n'est pas plus bizarre pour le non utilisateur qu'une discussion sur un groupe mail un peu intense.

      Incubez l'excellence sur https://linuxfr.org/board/

      • [^] # Re: Ca semble extra, risque de spammer les contacts?

        Posté par (page perso) . Évalué à 10.

        En théorie tu as raison, en pratique le comportement risque d'être différent.

        Dans une messagerie instantanée, car ici l'interface utilisateur le présente comme telle même si cela repose sur les protocoles liés au courriel, la manière d'écrire les messages est différente.

        Dans une messagerie instantanée, les messages sont plus courts, les utilisateurs ont une tendance naturelle à scinder le contenu.

        Au lieu d'avoir un courriel écrit ainsi :

        Bonjour,
        Blablablabla
        Blablabla
        Blablabla
        Salutations
        Madame Michu

        Tu auras plutôt plusieurs courriels construits ainsi :

        Salut,

        Blablabla

        Blablabla

        Blablabla

        Celui qui lit les messages avec son client courriel traditionnel, il aura ainsi 4 messages dont le contenu par message sera faible par rapport à la méthode traditionnelle où le courriel contient tout en un seul courriel.

        Du coup, si cela reste lisible et accessible même sans appartenir aux utilisateurs du client, cela risque d'être quand même assez usant.

        Cela me fait penser un peu à ceux qui utilisent Twitter comme une plateforme de blogs. Où pour contourner la limitation du nombre de caractères par message qui est assez réduit, ils enchaînent les messages dans un seul fil de discussion. Cela rend plus complexe la lecture que sur un blog où le contenu entier du message tient dans un seul article.

        Twitter ayant une interface optimisée pour justement des messages individuels courts.

        Bref, je pense qu'il ne faut pas sous estimer ce genre d'impact dans l'utilisabilité au quotidien du machin.

        • [^] # Re: Ca semble extra, risque de spammer les contacts?

          Posté par (page perso) . Évalué à 0.

          Bref, je pense qu'il ne faut pas sous estimer ce genre d'impact dans l'utilisabilité au quotidien du machin.

          A voir, mais la plupart des clients mails savent grouper les conversations/threads. Au boulot, recevoir plusieurs milliers de mail par jour est courant.

          Si Delta Chat devient populaire, les autres clients mails seront incités à implémenter eux aussi Email chat, tout comme l'introduction de mail HTML a forcé tout le monde à évoluer.

          Incubez l'excellence sur https://linuxfr.org/board/

          • [^] # Re: Ca semble extra, risque de spammer les contacts?

            Posté par . Évalué à 10.

            A voir, mais la plupart des clients mails savent grouper les conversations/threads. Au boulot, recevoir plusieurs milliers de mail par jour est courant.

            (⊙…⊙)

            Qui trouve normal de recevoir plusieurs milliers de mails par jour ?

            Si tu passes ne serait ce que 3 secondes par message ça nous fait minimum 100 minutes tu peux donc tabler sur 2 à 3 heures par jour. C'est absurde et idiot… T'as déjà un sérieux problème à l'ordre de grandeur en dessous.

  • # Et la latence dans tout ça ?

    Posté par . Évalué à 10.

    Si le but est de réutiliser les infra mails existantes, il faut composer avec l'existant. Et les serveurs de mails existants ne sont absolument pas conçus pour du temps réel. Même quand il n'y a aucun pb de connexion, il est courant de voir le traitement d'un mail prendre quelque part entre 1.5 et 4 secondes selon les filtres mis en place (virus/spam principalement).

    Pour du mail classique, ce délais est à peu près imperceptible. Pour de la messagerie instantanée c'est..comment dire….. loin d'être instantané (et je ne compte pas les délais d'établissement de connexion et de transfert hein, là c'est juste le filtrage).

    Si on ajoute à ça les délais qui peuvent se présenter en cas de deferal (remise dans le spool si connexion impossible à la première tentative, greylisting, deferal du destinataire à cause d'une surcharge temporaire etc…), on commence à avoir des conversations qui sont remises dans le désordre, voir dont il peut manquer certains morceau (mise en spam d'un message).

    Quelqu'un peut expliquer rapidement comment ces problèmes sont gérés ?

Suivre le flux des commentaires

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