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).
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 nico4nicolas . É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 :
[^] # Re: Clarification
Posté par Psychofox (Mastodon) . Évalué à 10. Dernière modification le 07 février 2019 à 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 nathanaelh . É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 ptit_poulet . Évalué à 9.
[chiffrage] => chiffrement, sinon cela signifie que tu les comptes tout simplement ;)
[^] # Re: Clarification
Posté par nico4nicolas . Évalué à 1. Dernière modification le 08 février 2019 à 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
Chiffrement
Chiffrage
[^] # Re: Clarification
Posté par Kerro . É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 nico4nicolas . Évalué à 1.
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 Kerro . Évalué à 2. Dernière modification le 11 février 2019 à 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 ptit_poulet . Évalué à 4.
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 nico4nicolas . É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.
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".
Juste pour être complet, "chiffrer II" c'est :
Wikitionnaire va également dans ce sens (avec "chiffrement" comme synonyme :
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 :
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 ptit_poulet . É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 Kerro . Évalué à 2.
Du coup ça fait sauter la clause « définition non prouvée » de mon commentaire plus haut.
# Sympa
Posté par benoar . É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 Zenitram (site web personnel) . Évalué à 2. Dernière modification le 07 février 2019 à 15:50.
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 dire qu'il aurait pu utiliser la RFC 6120… Mais sans doute trop simple.
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é.
D'après les RFC utilisés, c'est un client mail (user agent pour être précis).
[^] # Re: Consommation de ressources
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
L'existence?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Consommation de ressources
Posté par benoar . Évalué à 10.
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 KiKouN . Évalué à 6. Dernière modification le 08 février 2019 à 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 barmic . Évalué à 7.
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 Grunt . É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 barmic . Évalué à 7.
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 devnewton 🍺 (site web personnel) . Évalué à 8. Dernière modification le 08 février 2019 à 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.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Consommation de ressources
Posté par rewind (Mastodon) . Évalué à 8. Dernière modification le 08 février 2019 à 11:24.
Ç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 devnewton 🍺 (site web personnel) . É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.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Consommation de ressources
Posté par eingousef . Évalué à 3.
Si on le refaisait aujourd'hui, ça s'appellerait xmpp.
*splash!*
[^] # Re: Consommation de ressources
Posté par devnewton 🍺 (site web personnel) . Évalué à 8. Dernière modification le 08 février 2019 à 15:29.
C'est bien la preuve que réinventer la roue ne marche pas !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Consommation de ressources
Posté par Gabin_2 . Évalué à 1.
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 barmic . É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.
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 Psychofox (Mastodon) . Évalué à 7.
En ouvrant ton client, mais surtout tes yeux.
Avec ton client xmpp
Non en utilisant le bouton forward
Certe.
On te parle de protocole, tu réponds à côté de sur des questions d'UI.
[^] # Re: Consommation de ressources
Posté par barmic . É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 Kerro . Évalué à 4.
HTTP n'est donc pas un protocole spécifique ?
[^] # Re: Consommation de ressources
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Plus maintenant :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Consommation de ressources
Posté par freem . Évalué à 8.
En effet, HTTP est le nouvel IP, et il à plus de succès qu'IPv6 d'ailleurs.
[^] # Re: Consommation de ressources
Posté par Tonton Th (Mastodon) . Évalué à 4.
Pourquoi ?
[^] # Re: Consommation de ressources
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Pour passer les firewall/proxy nazis.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Consommation de ressources
Posté par Yves (site web personnel) . É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 barmic . Évalué à 3.
Ils ne l'auraient pas fait sur les autres protocoles ?
[^] # Re: Consommation de ressources
Posté par Yves (site web personnel) . É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 :
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.
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 Kerro . Évalué à 7.
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 Astaoth . Évalué à 3.
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é.
Emacs le fait depuis 30 ans.
# Matrix/Riot
Posté par Papey . É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 Papey . É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 barmic . É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 neilux . Évalué à 5.
À la fin du nourjal :
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 barmic . É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 Tom D . É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 devnewton 🍺 (site web personnel) . É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.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Ca semble extra, risque de spammer les contacts?
Posté par Renault (site web personnel) . É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 :
Tu auras plutôt plusieurs courriels construits ainsi :
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 devnewton 🍺 (site web personnel) . Évalué à 0.
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.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Ca semble extra, risque de spammer les contacts?
Posté par ckyl . Évalué à 10.
(⊙…⊙)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 dani . É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 ?
[^] # Re: Et la latence dans tout ça ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
En ralentissant l'utilisateur via l'usage d'un clavier virtuel tactile.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Et la latence dans tout ça ?
Posté par Astaoth . Évalué à 7.
Il me semble que dans les RFC, un courriel peut mettre jusqu'à 5 jours pour être livré. Le clavier tactile ralentira assez les utilisateurs pour ca ?
Emacs le fait depuis 30 ans.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.