Inbox veut (aussi) réinventer (encore) l’e-mail
Inbox ambitionne de réinventer l’e-mail en remplaçant l’IMAP et le SMTP par une « simple » API REST. Si l’idée vous semble familière, c’est normal : Google a la même. Mais là où l’API de Gmail est destinée à offrir à des (web)apps un accès ponctuel au courrier, Inbox entend construire une toute nouvelle plateforme destinée à devenir le nouveau standard.
Inbox est donc un projet open source, dirigé par Michael Grinich (ancien ingénieur chez Dropbox et designer chez Nest) et Christine Spang (qui a travaillé sur le noyau Linux). Écrit en Python et publié sous le régime de la licence GNU AGPL, il est accompagné par un SDK pour iOS et JavaScript. Il agit pour le moment comme une couche au-dessus de Gmail ou d’Exchange ; il sera disponible sous la forme d’un SAAS d’ici à la fin de l’année ; et il doit à terme « devenir le nouveau standard e-mail ».
L’API de l’Inbox Sync Engine offre une compatibilité point à point avec l’IMAP. Elle prend ainsi en compte les messages et les fils de discussion, les brouillons et les pièces jointes, les métadonnées et les filtres. Le développeur d’un futur client compatible n’a qu’à reprendre cette API, qui est accessible par le biais de simples requêtes HTTP — plus faciles à manipuler que l’IMAP — et retourne le contenu sous la forme d’objets JSON encodés en UTF-8 — sans que l’on doive s’inquiéter des types MIME.
Inbox représente-t-il le futur de l’e-mail ? Rien n’est moins sûr : d’autres se sont essayés à réinventer l’e-mail, et tous se sont cassé les dents. Mais à force d’essayer…
verbeux
et mime est là pour gérer le problème de quoi faire d'un blob binaire: c'est un Word X ou un XML générique, dois je le jeter à Word ou le faire bouffer par Pages ? Faut il respecter le choix de l'expéditeur, du destinataire ou du système ?
Quid des PDFs ? inline ou dans Acrobat ?
l'unique manière de remplacer imap:
- zéro brevets dedans
- normes avec zéro droits à payer dedans
- ne repose sur aucun service cloud propriétaire ou backend propriétaire tournant sur une plateforme dominante des postes de bureaux d'une entreprise installée à Redmond
- proposée pour intégration (donc licence compatible) pour des logiciels tels cyrus etc ou alors un logiciel serveur sous licence gpl/bsd pour linux/bsd
- utilise les pratiques habituelles des sysadmins : rfc, commandes à la unix, intégration redhat, openbsd, windows server (cron, services, etc)
- support et communauté
- réussir à convaincre Apple de foutre le support dans Mail (je range ça dans la catégorie "grimper l'Everest avec les dents")
- réussir à convaincre Mozilla de le foutre dans Thunderbird (catégorie "j'ai convaincu tout un forum de geeks que mon choix d'OS était pertinent, sensible et adapté à MON besoin")
- réussir à convaincre Microsoft de l'intégrer dans outlook/windows mail/autre (catégorie "cette fois c'est la bonne, on va convaincre microsoft d'intégrer nativement un format ouvert et alternatif à Office")
- être caricaturé par UserFriendly sur Slashdot.
C'est donc probablement possible.
----
Expliquez moi pourquoi pour mon boulot, je devrais me coltiner le support d'un énième protocole (quand imap marche très bien) et le tout en interface à des services tiers ? S'il s'agit de me vendre un énième middleware, dites le moi texto.
"The idea is to reduce the reliance on older protocols, like IMAP, when apps don’t have to work as an email client, "
ben vi, parce que pour ça on a IMAP (qui est extensible au fait, et + moderne et riche que la plupart des utilisateurs imaginent)
"but are rather focusing on a specific feature set – like snoozing messages," or only sending emails on behalf of an end user, for example."
vi parce que pour le "sending email" on a un truc super, ultra-répandu et qui marche bien : SMTP.
-
bref, c'est essentiellement une énième plateforme qui se propose de faire du microblogging sur le dos des gmail, yahoo, serveurs exchange et serveurs imaps.
-
"“I actually wrote my thesis at MIT on email tools, and discovered how difficult it was to add features to email apps,” explains Grinich of how Inbox came to be. “One big issue was the underlying plumbing – IMAP, MIME, character encodings, etc. – which is what Inbox fixes for developers.”"
et ouais, le Monde est une place pénible et compliquée...
MIME est incontournable. Ho on peut faire comme Apple et dire que MIME c'est pas assez bien et faire son propre système TOUT AUSSI COMPLEXE (mais + mieux) que personne sauf apple n'utilise. On peut. (on peut aussi faire du reverse DNS pour tout catégoriser)
et les "codages de caractère", ouais c'est pénible. Sont naze tous ces étrangers avec leurs caractères à eux et leurs machines farfelus, et leurs réseaux et services et autres qui sont pas foutus d'être tous en Unicode 32 (non utf8 ne résout pas l'univers).
D'une manière ou d'une autre la complexité du monde REVIENDRA dans le protocole
(à ce propos, amusons nous à voir ce que deviennent html, javascript et CSS.. au fur et à mesure qu'on les transforme en clone de PDF+Fortran brrrrrr )
mais y a quoi qui fonctionne mail dans le système de mail actuel (imap/smtp) que tout le monde veut le refaire .....
il est essentiellement gratos (sendmail, cyrus, postfix, on prend un linux, un serveur en carton à 3 sous, un domaine dns à 6 sous, et zou raoul)
donc SANS valeur
il est ouvert et décentralisé, c'est à dire sans médiateur unique.
autrement dit il est NAZE car on ne peut pas le VALORISER ! C'est à dire créer un marché avec des COUTS à balancer à la gueule des UTILISATEURS ou CREATEURS.
Bref, il est urgent de tuer le soldat SMTP et le soldat IMAP. (on a abandonné tout espoir de tuer ce chalo de soldat HTML)
@oomu :
Je plussoie.
Je plussoie aussi.... Mais j'émets des réserves sur quelqu'un qui n'aime pas FORTRAN... :-)
Ok smtp/pop3/imap4 marchent très bien, mais y'a quand même quelque chose a trouver pour authentifier les envoyeurs/expéditeurs de façon plus sûre, et réussir a diminuer ce fléau qui est le spam...
Imposer PGP/GPG par défaut ? Avec un vrai organisme centralisant les clés publiques ? Des mécanismes d'authentification plus évolués ? Je sais pas, mais perso j'en peux plus de tous ces spams, malgré l'armada de garde-fous que j'ai mis en place niveau serveur et clients... :-(
Y'a des trucs a améliorer, c'est évident !
Encore un TRUC de la NSA pour lire notre courrier avant qu'il arrive dans notre BAL.