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 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 (site web personnel) . Ă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?
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # 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.
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # 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.
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # 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 !
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # 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 :-)
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # 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 (site web personnel, Mastodon) . ĂvaluĂ© Ă 4.
Pourquoi ?
[^] # Re: Consommation de ressources
PostĂ© par devnewton đș (site web personnel) . ĂvaluĂ© Ă 3.
Pour passer les firewall/proxy nazis.
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # 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, et sans pubs ni télémétrie.
# 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.
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # 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.
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # 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.
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # 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, et sans pubs ni télémétrie.
Suivre le flux des commentaires
Note : les commentaires appartiennent Ă celles et ceux qui les ont postĂ©s. Nous nâen sommes pas responsables.