Bonjour à tous,
On le sait tous, pour garder la maîtrise de ses données à commencer par ses mails, mieux vaut garder le contrôle de sa messagerie plutôt que d'utiliser un service "cloud" public. Idem pour le stockage de fichiers. Sinon, la NSA…
Il existe bien sûr des services et solutions prêtes pour assembler un service qui permette les fonctions de messagerie, partage de fichiers, idéalement intégré à la messagerie (du type Gmail + Google Drive), mais en général c'est plutôt long et fastidieux. Et puis certaines solutions sont assez consomatrices de ressources et pas toujours modernes.
Je voulais donc vous parler en avant-première d'une solution française qui cherche à répondre à cette problématique : PEPS. En avant-première car pour l'instant la release officielle n'a pas été faite même si le projet est déjà sur GitHub.
Alors, l'interface ressemble à :
et globalement le produit gère pour l'instant les fonctions suivantes :
- messagerie,
- partage de fichiers et répertoires,
- contacts.
Plus de fonctions sont prévues car une API (bientôt documentée) ce qui permet de développer des extensions. Deux sont déjà bien avancées : la discussion temps-réel "chat" et les calendriers.
Pour les curieux, PEPS est intégralement développé en Opa et comme vous pouvez le voir, la solution est packagée sous forme de containers Docker, ce qui permet de déployer un nouveau service très rapidement en suivant la doc.
Les technologies d'exécution sont NodeJS + MongoDB + Solr + Haraka.
Vos avis ?
# Serveur de courrier
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6. Dernière modification le 30 janvier 2015 à 17:34.
Il s'agit donc d'un logiciel qui fournit les fonctions suivantes, si j'ai bien compris :
C'est bien ça ?
[^] # Re: Serveur de courrier
Posté par |-| . Évalué à 5.
Il n'y a pas encore tout…
Pour les services manquants, le but est de les écrire sous forme de plugin (il y a déjà les API REST qu'utilise par exemple l'import de boîte IMAP qui est écrit en python).
# RainLoop c'est bien et c'est stable
Posté par HLFH . Évalué à -1. Dernière modification le 30 janvier 2015 à 19:51.
J'utilise RainLoop qui supporte :
- serveur de courrier (SMTP) ;
- serveur de boîte aux lettres (IMAP) ;
- webmail ;
- synchronisation avec serveur CardDAV (ownCloud par exemple) ;
- chiffrement PGP ;
- les serveurs web Apache et Nginx.
Bref, c'est le seul sur le marché libre à être fonctionnel, design et stable (ce n'est pas le cas de Mailpile ou ownCloud Mail) tout en supportant la synchronisation CardDAV et le chiffrement PGP.
[^] # Re: RainLoop c'est bien et c'est stable
Posté par |-| . Évalué à 3.
Oui, il y a des alternatives c'est sûr.
Par rapport à une solution de mail "pure", PEPS inclut directement les fonctionnalités de partage de fichiers/répertoires, ainsi qu'un chiffrement "transparent".
Le chiffrement des messages (pas tous, ceux qui ont une classification qui impose le chiffrement) utilisent PBKDF2+HMAC. Nous allons écrire un article à ce sujet, le but étant de chiffrer les messages sans connaissances particulières pour les utilisateurs.
Concernant le serveur IMAP, le but est d'écrire un plugin pour un serveur IMAP existant, par exemple dovecot. Cela reste à faire.
Au passage, RainLoop n'est pas libre non plus (CC BY-NC-SA) (ce qui est aussi une solution envisagée pour nous).
[^] # Re: RainLoop c'est bien et c'est stable
Posté par rakoo (site web personnel) . Évalué à 3.
Ah, intéressant. J'imagine que vous n'utilisez pas juste PBKDF2 et HMAC et que ce ne sont que des briques (d'ailleurs j'aime pas le namedropping comme ça, mais bon).
Ce qui m'intéresse surtout c'est de voir pourquoi vous n'avez pas utilisé PGP et êtes partis sur autre chose. J'attends avec impatience !
[^] # Re: RainLoop c'est bien et c'est stable
Posté par |-| . Évalué à 3.
A la base, nous voulions une implémentation client donc JS. Nous avons regardé openpgpjs et trouvé le code un peu long pour être facilement auditable. Nous avons à la place implémenté une crypto applicative sur la base de tweetnacl-js.
Au passage, PEPS sera distribué selon une licence libre.
[^] # Re: RainLoop c'est bien et c'est stable
Posté par Zenitram (site web personnel) . Évalué à 10.
Contrairement a ce que tu affirmes, RainLoop n'est pas libre, la licence est claire à ce sujet.
[^] # Re: RainLoop c'est bien et c'est stable
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 1.
Et de plus ça n’est pas le seul du marché !
Horde/IMP fait tout ça, et il y en a sans doute d’autres aussi.
[^] # Re: RainLoop c'est bien et c'est stable
Posté par |-| . Évalué à 3.
Bonne nouvelle : PEPS sera distribué selon une licence libre.
Du coup, tout le monde pourra comparer sur pièce !
[^] # Re: RainLoop c'est bien et c'est stable
Posté par El Titi . Évalué à 3.
Super nouvelle !
Un grand bravo et merci.
Ca va marcher les gars.
# Docker c'est bien mais...
Posté par Rolinh (site web personnel) . Évalué à 6.
Et quand on n'utilise pas Linux ? FreeBSD ou DragonFly BSD par exemple ?
Je ne vois rien de documenté pour une installation plus "classique".
Ah, et la licence en format HTML dans les sources c'est curieux. D'ailleurs, pourquoi pas une licence OSI approved ?
[^] # Re: Docker c'est bien mais...
Posté par |-| . Évalué à 3.
On est encore pre-launch, on est donc preneur de tout retour !
Pour FreeBSD, Docker semble supporter Jails (et pas seulement lxc) et tous les composants d'exécution sont aussi supportés, donc il me semble que cela est tout à fait faisable, en partant du repository actuel.
Concernant la licence, c'est une licence temporaire (il faut bien quelque chose) en attendant un choix. Open source ou pas, libre ou pas rien n'est arrêté. Pour info, nous sommes les auteurs d'Opa qui est utilisé pour développer PEPS et qui est libre (licence AGPL et MIT).
# PEPS is free for up to 30 user accounts.
Posté par Julien04 (site web personnel) . Évalué à 10.
Si je comprends bien la licence, c'est donc open-source mais pas du tout libre.
Les créateurs peuvent-ils s'exprimer sur ce point ? C'est par peur de ne pas avoir de clients ?
Merci
[^] # Re: PEPS is free for up to 30 user accounts.
Posté par |-| . Évalué à 4.
En l'état, oui—mais la licence actuelle est probablement temporaire.
Nous sommes justement en train de préparer notre lancement et envisageons plusieurs possibilités de licence et de modèle commercial :
- propriétaire : proche de la licence actuelle, gratuit jusqu'à une limite d'utilisateurs à définir, payant au delà ;
- CC : par exemple BY-NC-SA, avec une licence payante pour les organisations (entreprises et institutions publiques) ;
- open source, et libre : par exemple AGPL. Dans ce cas, nous commercialiserions support / maintenance en comptant sur le fait d'être les auteurs pour justifier l'expertise / valeur ajoutée.
Il est difficile de choisir. Le but est bien sûr de créer une structure rentable, qui nous permette de vivre et de développer le produit bien plus loin, tout en permettant la diffusion la plus large possible. Et si, à titre personnel, je suis pour la solution libre, c'est un risque qui reste tout de même à mesurer…
Si vous avez un avis / feedback sur des situations similaires, nous sommes preneurs !
[^] # Re: PEPS is free for up to 30 user accounts.
Posté par Zenitram (site web personnel) . Évalué à 8.
1er avis : il manque 50% du logiciel.
En effet, la licence est une fonctionnalité majeure, et elle manque.
perso, si pas libre --> poubelle, en pas libre on a deja gmail, Zimbra (libre que pour des trucs de base sinon passe a la caisse), exchange…
[^] # Re: PEPS is free for up to 30 user accounts.
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 3.
Y'avait déjà RainLoop comme truc pas libre, je vois donc pas trop l'intérêt. Faites un truc libre non ?
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: PEPS is free for up to 30 user accounts.
Posté par André Rodier . Évalué à 5.
Si vous voulez avoir une chance de vous imposer, vous devez être 100% libre et encourager autant que possible la participation de tiers.
Le web est plein de solutions mail alternatives qui n'ont pas pu s'imposer face à Exchange, même si je reconnais volontiers que vous ne visez pas la même cible.
OPA pour le language de base est un bon choix, AMHA.
[^] # Re: PEPS is free for up to 30 user accounts.
Posté par El Titi . Évalué à 9.
Déjà, ne t'offusque pas trop de l'accueil un peu suffisant de certains ici.
On croirait qu'il prennent un malin plaisir à casser les velléités.
Concernant la licence, il est vrai qu'il existe pléthore de solutions fermées de ce type.
Pour les alternatives libres, je serai un peu plus mesuré que certains.
Même si elles existent, elles sont la plupart du temps écrites en PHP et vielissantes (Zimbra, …) ou font parfois partie de solution cloud plus larges et pas forcément bien intégrées.
Blue Mind est une solution à vocation professionnelle est écrite en Java.
La vôtre fait, semble t'il, appel à des technos en vogue et plus accessibles.
Je vous remercie de m'avoir fait découvrir au passage OPA que vous développez et qui semble assez prometteur.
Bref, il serait assez dommage d'ouvrir au maximum votre logiciel aux contributions (GitHub, JS coté backend et frontend, Bootstrap, …)
et de ne pas décoller faute de licence.
La tentation de la licence CC-BY-NC-SA est en général une mauvaise idée. Qu'est-ce qu'une utilisation commerciale ? C'ets assez flou.
Vous pouvez par contre faire comme d'autres acteurs du libre et demander à ce que les contributeurs vous reversent le copyright ce qui facilite les changements de licence par la suite.
Pour le modèle économique il y a le modèle de double licence pour l'usage professionnel. (On a le droit de ne pas reverser le code si on vous paye pour ça), rendre certaines fonctionnalité pro payantes (compatibilité outlook, annuaire LDAP, …), le hosting payant (tout le monde n'a pas envie de s'autohéberger), …
Mais ca serait dommage de se priver de contributeurs potentiels en fermant la licence
```
[^] # Re: PEPS is free for up to 30 user accounts.
Posté par rakoo (site web personnel) . Évalué à 3.
Attention: les gens de Creative Commons déconseillent eux-même d'utiliser les CC* pour le logiciel. Ça se comprend, les CC sont surtout faites pour les "oeuvres de l'esprit" qui ont des spécificités bien différentes des logiciels, sans compter l'incompatibilité avec les autres licences pour ceux qui veulent réutiliser/mixer votre logiciel.
La CC0 est par contre possible, c'est le choix que je fais pour mes projets, mais ça force à renoncer à un peu plus de choses que les autres licences. À méditer.
[^] # Re: PEPS is free for up to 30 user accounts.
Posté par Xavier Teyssier (site web personnel) . Évalué à 4.
- open source, et libre : par exemple AGPL. Dans ce cas, nous commercialiserions support / maintenance en comptant sur le fait d'être les auteurs pour justifier l'expertise / valeur ajoutée.
Cela me paraît une bonne idée pour assurer une diffusion la plus grande possible du produit.
Ensuite, au-delà du support, il est toujours possible d'avoir des greffons/fonctionnalités supplémentaires propriétaires et payantes.
Et/ou de de proposer des développements spécifiques aux clients. Tarif "normal" : développement libre. S'il paye plus cher, proprio. Au client de choisir.
En regardant les différentes boites qui gravitent autour du libre, partir sur une base libre et générer du revenu autour me semble aujourd'hui une alternative courante.
[^] # Re: PEPS is free for up to 30 user accounts.
Posté par |-| . Évalué à 4.
Merci pour les retours.
Et comme indiqué dans un autre commentaire, nous allons effectivement partir sur une licence libre AGPL ! Attendez-vous à une dépêche bientôt pour le lancement :)
Pour information, nous sommes en phase de commercialisation avancée avec plusieurs grands comptes et les mentalités ont bien changé et heureusement : le logiciel libre est désormais un point qui rassure.
# Retour volontairement agressif pour aller à l'essentiel et provoquer le débat (qui lit les sujets ?)
Posté par Sufflope (site web personnel) . Évalué à 6.
Au delà de ce que vous comptez gérer (mais que vous ne gérez pas encore) pour être "acceptables" (IMAP, SMTP, synchro de contacts… le minimum syndical de 1998 quoi), vous comptez apporter quoi ?
Je veux dire, la référence de ce que j'attends d'une solution de "présence sur internet" (ou peu importe comment vous l'appelez), c'est AU MIMINUM une unification des courriels et de XMPP, et de la catégorisation souple à la tags/labels… Parce que ma commande chez Amazon du dernier album de Manson, elle va où, dans mon dossier Amazon ou Musique (celui qui me répond "configure des smart folders dans TB sur ton poste" est prié de retourner dans ses années 90) ? Et pourquoi je dois chercher dans deux logiciels différents mes courriels et mes chats échangés avec Céline Tran ?
Bref pour l'instant je vois un 57ème concurrent de Google (oui c'est ce que j'ai décrit plus haut, tout simplement car ils sont les meilleurs techniquement), à la Kolab / HORDE / Zimbra, sauf que ces 3-là proposent 33% de la qualité de Google, mais ont au moins le bon goût d'être libres et installables chez moi. Vous, vous proposez 10% et vous êtes même pas encore sûrs d'être libres.
[^] # Re:
Posté par HLFH . Évalué à 5.
Le projet d'unification des courriels et de XMPP est l'un des éléments fonctionnels du projet expérimental, innovant et libre CaliOpen, projet de Laurent Chemla, cofondateur de Gandi.
[^] # Re: Retour volontairement agressif pour aller à l'essentiel et provoquer le débat...
Posté par |-| . Évalué à 7.
Ouvrons donc le débat (sachant que PEPS se veut une solution de communication professionnelle, pas forcément B2C) :
Commençons par le plus simple : les labels sont gérés par PEPS. C'est même une des fonctionnalités les plus développées, puisque nous avons des labels privés (comme Gmail), des labels partagés (par exemple un label peut être proposé par l'expéditeur) ainsi qu'un mécanisme de classification des messages basé sur les labels (gestion du besoin d'en connaître, fonctionnalité très B2B). Ce dernier inclut tout le champ de produits complémentaires de messagerie comme "Titus".
Minimum syndical de 1998 : justement, en commençant PEPS fin 2010 (il y a déjà 4 ans, développé à la base pour un grand compte français) le but était de partir sur des bases neuves et pas se limiter avec de l'existant. Du coup, tout le coeur de PEPS est basé sur les API REST nouvelles, ce qui permet plein de nouvelles fonctionnalités qui n'ont pas été évoquées ici (statut réel d'envoi/lecture pour les messages internes, gestion des équipes, envoi de messages aux équipes pour gérer les fonctions de boîtes de délégation, de mailing list, etc.). Nous assumons tout à fait le fait de ne pas être une solution de messagerie "classique".
Par exemple, le serveur IMAP n'a pas été retenu dans la base. Il y a des API dans PEPS suffisantes pour écrire un serveur IMAP en tant que service externe, par exemple via un backend dovecot client des API . Pour moi, il était essentiel d'avoir une codebase propre et modulaire et je pense que nous y sommes arrivé.
-Pour XMPP : nous avons déjà développé une application de chat pour PEPS que nous n'avons pas encore distribuée (initialement dans le cadre d'un projet avec un autre grand compte français). XMPP n'est pas encore supporté, mais oui il le faudrait, nous allons en faire une priorité.
# de la simplicité, des coquelicots et de mon avis.
Posté par maboiteaspam . Évalué à 1.
C'est surtout l'idée d'utliser docker, avec toute la compléxité que cela apporte qui me chagrine.
J'aurais tout fait en nodejs. Tellement plus facile à installer in fine. De plus je doute qu'aucun de ces composants n'ai pas son équivalent dans npm.
De ce point de vue là, je préfère cozy light.
De même que d'avoir choisit OPA. Je ne sais pas si cela rend votre plateforme incompatible avec du njs brut, mais de but en blanc, cela me semble rebutant en tant que développeur. En tout cas, moi, ça me rebute.
Encore une fois, je regarde vers la concurrence.
Finalement, ce que j'aime bien, car il y à tout de même un point qui me plaît.
C'est l'API unifiée, cf ici https://github.com/MLstate/PEPS/wiki/Developer-Manual.
Je regrette cependant, indecrottable que je suis, qu'il n'y ai pas déjà une défintion json schema compatible, http://jsonschema.net/#/
Je dis : déjà. Car comme vous, pour l'heure, je n'ai pas encore trouver de cas d'usage.
Car je crois qu'il est à créer ; )
Hey sinon quid du pair à pair ? Je vois transferts de fichier ? Qu'entendez vous par là ? Comment cela fonctionne ? A t'on besoin d'un dns pour faire tourner votre système ? Comment ça marche dedans ?
[^] # Re: de la simplicité, des coquelicots et de mon avis.
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
jsonschema c'est le "soap" des api rest/json ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: de la simplicité, des coquelicots et de mon avis.
Posté par maboiteaspam . Évalué à 1.
Oui.
Sauf que je n'ai jamais trouvé de projet qui implémente la négociation et la mise en relation entre un fournisseur et un consomateur.
Sans cela c'est un peu inutile dans l'état.
[^] # Re: de la simplicité, des coquelicots et de mon avis.
Posté par G.bleu (site web personnel) . Évalué à 2.
Au contraire je trouve qu'utiliser Docker est une bonne idée pour déployer facilement : un service web peut être développé en ouatmille technos (typiquement ici OPA qui te rebute…) mais cela n'est d'aucun intérêt pour l'utilisateur (comprendre : celui qui va déployer, et qui veut le faire vite sans galérer et sans devoir apprendre un nouvel environnement) qui se focalise légitimement sur ce qui le concerne (i.g. fonctionnalités, performances, stabilité…)
[^] # Re: de la simplicité, des coquelicots et de mon avis.
Posté par maboiteaspam . Évalué à 0.
C'est marrant on est d'accord, mais pas tellement.
Docker ca me semble bien pour des gens qui trainent pas ici, ou des services hébergés. Dans cette optique cela prend tout son sens.
Mais pour tout un chacun, qui n'est pas madame michu, mais pas non plus lecteur actif de linuxfr, j'attends de voir cet object déployé à grande echelle. C'est surtout ca qui me deplait.
Pour ce qui est de savoir quelle stack est la plus fonctionnelle, performante, stable je ne sais pas, il faudrait le benchmarker.
Après tu fais un amalgame de mes propos selon moi, je n'ai pas dit que mes utilisateurs devait savoir comment ca fonctionnait à l'intérieur. Par contre je m'inquiète autant de la simplicité de développement, que de la simplicité d'utilisation..
[^] # Re: de la simplicité, des coquelicots et de mon avis.
Posté par |-| . Évalué à 5.
Mais on ne peut pas "tout" faire en Node.js.
Par exemple, il n'y a aucun moteur d'indexation en Node.js, que des bindings vers des outils écrits en Java/C/C++/Go (récent, pour bleve) et qu'il faut déployer de toute façon. Et il n'y a pas mieux que Docker pour standardiser un déploiement.
Pour les fichiers, PEPS inclut une plateforme centralisée équivalente à Dropbox/Google Drive et qui ne repose pas sur des protocoles P2P. On ne cherche pas du tout à concurrencer BitTorrent Sync ou des équivalents libres.
Un point qui moi me chagrine : le commentaire sur Opa. Comme indiqué dans la discussion, nous sommes les auteurs d'Opa, qui est une solution libre. Je peux comprendre que tout le monde ne veut pas coder en Opa, mais reprocher aux auteurs d'une solution libre, que l'on maîtrise donc parfaitement et que l'on sait exploiter au mieux pour bien écrire un logiciel je ne comprends pas.
[^] # Re: de la simplicité, des coquelicots et de mon avis.
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Pourquoi prendre node.js alors?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: de la simplicité, des coquelicots et de mon avis.
Posté par |-| . Évalué à 2.
Parce que Node est un très bon choix pour le serveur applicatif, les interfaces REST.
Mais dans un produit un peu complexe comme PEPS, il faut de toute façon des technologies différentes car chacune a ses forces/faiblesses.
Et pour revenir sur Docker, cela va au-delà de la bonne configuration des composants pris séparément. En faisant make build run, on a par défaut une configuration correcte de l'interconnection, des ports, des règles de firewall. Alors oui, il y a (surtout ici) des gens qui savent faire seuls et qui sont aussi à même de changer ce qu'ils veulent, mais pour les autres par défaut ça marche.
[^] # Re: de la simplicité, des coquelicots et de mon avis.
Posté par maboiteaspam . Évalué à -1.
bon bon, on n'est pas d'accord. Je ne voulais froisser personne ici, c'est seulement mon feeling au sujet de ces outils. probablement mal exprimé.
OPA j'ai testé, il y à longtemps, je n'y suis pas revenu. Est ce un avantage ou un inconvénient pour l'adoption de votre proposition. J'émet un doute, qu'on me prouve le contraire je change ma suite d'outils.
Même doutes au sujet de docker, mais je n'ai pas suffisament testé.
Pour la question des bindings, il y à node gyp, et plus particulièrement node pre gyp. Ce que JS ne peut faire tout seul correctement, on le délègue à un language approprié, mais la philosophie reste la même derrière, fournir un service multi plateforme de qualité.
Cela prends du temps, mais j'y crois car je le vois.
Simplicité de déploiement et d'usage, c'est surtout une question de savoir faire des techniciens qui sont derriere.
Mais en réduisant le nombre d'outils (ie : un seul binaire pour tous, au lieu de nn binaires), on réduit sa surface de développement, de test, de controle, d'intéractions et autre comportements inattendus.
Je crois.
De plus j'ai le sentiment qu'en nodejs, tout est plus petit, plus simple à manipuler, déployer.
Ok ce n'est qu'un sentiment.
Au sujet de bitorrent, il faut faire la part des choses nous avons dht, et bittorrent. Il est avisé de prendre avantage de la dht pour trouver des peers (enfin, je voudrait bien voir tourner kadnode irl et obsrver ce que cela donne : ), et il y à bt, pour échanger des données publique. Lorsqu'il s'agit de partager un document privé entre deux peers, on peut demander si bt est vraiment la manière la plus efficiente.
M'enfin bref, on devrait surtout se focaliser sur ce que l'on peut partager, par exemple ces schémas d'api. L'utilisateur ne devrait pas souffrir d'avoir choist tel ou tel backend pour gérer ces services et pouvoir switcher de l'un à l'autre facilement. Voir plus simplement décorellés toutes ces dépedances pour donner la possibilité à d'autres d'intégrer ces services, ou de s'y intégrer facilement.
Ces querelles de techniciens ne nous mènent pas bien loin comme on le constate. Essayons plutot trouver des points de convergences non ?
# Kolab
Posté par Fabien PRORIOL . Évalué à 2.
Personnellement, j'utilise Kolab, certe c'est pas 100% français, mais c'est libre, ça utilise que des briques standard (cyrus, postfix…), et ça répond a tout les besoins cité ci-dessus…
On trouve même le moyen de le couplé avec un serveur XMPP…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.