OTR n'a rien à voir avec XMPP, c'est un bricolage de l'utiliser avec, dont l'intérêt principal est à mon sens est d'être utilisable avec les passerelles (c.-à-d. quand on sort de XMPP). Ce n'est certainement pas la méthode qui va être standardisée (pas plus que PGP qui était un usage historique maintenant obsolète). Le journal est d'ailleurs faux sur ce point.
OTR est censé être utilisé sur l'instant, comme un journaliste parlerait à une de ses source: sur le moment il sait à qui il parle, mais après coup on ne peut plus le prouver. Ça n'est pas fait pour laisser des messages hors ligne, ni même pour quoi que ce soit d'autre que de la discussion instantanée (pas de mise en forme, pas d'état de discussion, pas de correction de message, etc. Les clients qui font de la mise en forme font aussi un bricolage, ça devient du bricolage par dessus du bricolage).
Déja XMPP, avec son multi-ressoureces non synchronisées sur la même adresse foutait le bazar mais là c'est le ponpon, en plus les messages recus sont illisibles.
ça veut dire quoi multi resources non synchronisées sur la même adresse ? Le sysème de resources de XMPP fonctionne très bien, quel est ton problème au juste ?
@inlineCallbacks rend l'écriture de code Twisted plus aisé, mais ce n'est pas utilisé pour tout et ça reste un peu du bricolage dans Twisted.
l'inconvénient principal des inlineCallbacks est une perte de performances énorme dans pypy (de ce que j'en ai lu, je n'utilise pas -encore ?- pypy).
Pour l'écriture et le débogage, l'écriture est en effet un peu difficile, c'est une habitude à prendre, par contre pour le débogage je n'ai pas trop de soucis, surtout grâce à leur système qui permet de tracer l'origine d'un Deferred en mode debug.
Bon en tout cas faut voir les évolutions de tout ça, mais si ça peut effectivement interagir comme promis, l'avenir devrait être très intéressant.
Tu vois là l'(un des) intérêt(s) d'une ligne éditoriale. Le système de notation et d'étiquettes ou encore les moteurs de recherche te donnent une certaines vue des choses, une ligne éditoriale en est une autre, subjective. Rien ne t'empèche de te faire ta propre sélection d'articles et de la mettre (ou les mettre si les articles sont redistribuables) sur un site public, voire d'associer ça avec d'autres.
En fait c'est une réflexion intéressante, peut-être que le journal est un peu confus par contre. Les articles ne sont pas « oubliés » (on peut les retrouver dans les archives), mais peu mis en valeur et ils disparaissent rapidement sous d'autres journaux/dépêches ou après « l'effet buzz ».
Il y a de toute façon un certain consumérisme de l'information qui explose depuis quelques années (surtout avec des choses comme Twitter). Ce qu'il faudrait, c'est ralentir la cadence; reste à savoir de quelle manière. Une sélection d'articles sur un site à part, me semble une piste.
Bon ben super. Reste à voir si mon blog rentre dans le cadre (a priori je pense, mais comme je parle surtout d'un logiciel, pas sûr que ça passe), mais je n'ai plus trop de raison de râler. Merci :)
Ah apparemment les liens vers l'article complet pour les derniers articles ne pointent plus sur planet-libre, c'était le point le plus bloquant pour moi. Tu confirmes que c'est bien que ça qui a été changé ?
Merci en tout cas, c'est appréciable de voir que les critiques sont écoutées :)
Avec pendatactyl la barre d'url n'est pas visible non plus (enfin ça se remets avec :toolbarshow Navigation Toolbar), et à l'usage c'est très pratique. Mais bon là ça triche un peu, l'url est dans la barre de statut, et il suffit d'appuyer sur o pour ouvrir une autre, ou O pour modifier celle courante.
peu importe (j'ai un exim avec à peu de choses près le conf de base, c'est possible que ça soit limité *), ce que j'indique c'est qu'avec le courrier SMTP s'il y a un élément limitant dans la chaîne t'es marron. Je viens de tomber sur ça par exemple: http://www.outlook-apps.com/maximum-email-size/
Le tableau indique que des MUA (ici outlook et windows live mail, il n'y en a pas pour Thunderbird) imposent des limites, et tous les serveurs cités en imposent aussi, sauf si ça passe par un service externe.
* en effet ça semble être limité à 50 Mio, mais de toute façon la limite de gmail étant apparemment 25 Mio, mon MTA n'a pas été concerné.
Okay, donc avec XMPP aussi, si je comprends bien, ça marche dans un cas idéal, à savoir le cas où l'expéditeur et le récepteur sont connectés au même moment.
Euh non, ça marche dans le cas normal, et si jamais tu as un quota sur le serveur de fichiers, tu peux passer par un autre, ou faire un envoi P2P, qui est aussi un cas normal mais qui demande à ce que l'autre soit en ligne.
2 personnes en ligne en même temps c'est beaucoup moins rare que de te retrouver dans un cas où tout le monde gère sa propre chaîne de courriel, et que tout soit configuré sans limite.
Base64 : ça dépend du MUA (si son auteur a décidé de forcer à encoder en base64) car ça doit faire 15 ans que les MTA sont capables de passer du 8-bits sans accroc.
ok pour le coup de la taille, si toute la chaîne accepte du 8 bits ça fonctionne.
Stockage intermédiaire : si tu n'es pas dans le cas idéal en XMPP, il faut bien que ça soit stocké sur un serveur. Donc même raison pour mettre des quotas qu'en SMTP.
Oui il faut que ça soit stocké, mais une seule fois, pas à chaque MTA.
Reprise de transfert : bien, mais ça implique que les serveurs stockent pendant un certain délai les morceaux de fichiers dont le transfert est inachevé. Devrait influer négativement sur les quotas.
Les quotas tu es dépendant du serveur de fichiers que tu choisis. En SMTP tu es dépendant de tes MUA/MTA que tu peux maîtriser, mais aussi de ceux de ton correspondant.
Si Thunderbird stocke les gros fichiers sur des services externes et envoi le lien dans le message, c'est qu'il y a une raison…
Si je suis mon propre MTA/MDA et que mon destinataire est son propre MTA/MDA, il n'y a pas d'intermédiaire imposant ses propres règles non plus, quelle est la différence ?
Oui c'est sûr, si t'as un cas idéal où tout le monde laisse tout passer, et si t'acceptes tout le bordel qui va avec (base64, stockage du fichier à chaque étape, transfert à recommencer depuis le debut si ça foire, et y'en a sûrement d'autres que j'ai pas en tête), ça peut marchoter. Mais en pratique ça n'arrive pas, j'ai eu le cas hier avec le fichier de ~ 70 Mio qu'on a essayé de m'envoyer depuis un compte gmail, et comme déjà dit je gère mes propres serveurs, c'est pas de mon côté que ça coinçait (enfin j'ai pas vérifié, mais a priori je n'ai rien mis dans ma conf pour bloquer quoi que ce soit).
Avec XMPP le fichier passe par un canal dédié, peut être stocké ailleurs que le reste du message, y'a pas d'augmentation de taille, et même si y'a un quota au milieu tu peux toujours faire un P2P. Et je passe tous les autres problèmes de SMTP.
Je ne dis pas que XMPP est un protocole parfait, il a ses défauts, mais je dis qu'il est un excellent candidat pour remplacer SMTP, et probablement le meilleur candidat actuel.
Je dis que les pièces jointes sont un bricolage par dessus SMTP (qui est MIME), et que SMTP n'étant pas adapté au transfert de fichiers, on a de nombreux problèmes avec à cause de ça.
La taille des pièces jointes n'est effectivement pas limitée par SMTP ou MIME je n'ai jamais dis le contraire, mais l'architecture du réseau, son historique, le fait que les messages soient stockés par chaque MTA fait qu'en pratique c'est limité, soit au niveau du MUA, soit d'un MTA.
Et le protocol est tout à fait lié à ces limites, outre son historique, le fait que les messages soient stockées par les MTA, et que la taille des fichiers soit beaucoup augmentée à cause de base64 fait qu'en pratique on limite les tailles à des valeurs ridicules de nos jours.
XMPP envoit le fichier par un canal séparé, rendant ces limites inutiles. Il est toujours possible de mettre des quotas, ça personne n'a dit le contraire, mais rien n'empêche que si je m'auto-héberge on m'envoit un fichier de 3 Go. Essaye de faire pareil avec juste du SMTP. En plus de ça, XMPP gère le P2P, et la plus question de quota.
P.-S.: ohhh un nouveau dessin, c'est lié au nombre de commentaires dans un fil ? Rigolo :)
Tu as listé 7 "services", et tu as mentionné que 5 ne sont pas aboutis.
Euh non, j'ai repris une liste de 7 « services », et j'ai dis que XMPP répondait déjà à 4 d'entre eux (email, audio/vidéo, chat et partage - même si pour ce dernier il y a effectivement encore du boulot -).
Je ne vais pas reprendre la liste, mais par exemple: Linphone/Jitsi
Attention j'ai cité Linphone pour l'audio/vidéo, mais Linphone n'utilise pas XMPP ! Ça utilise SIP. Jitsi lui utilise les 2, et effectivement j'ai eu des soucis avec mes essais, maintenant je teste assez peu ça, il y a probablement des implémentations qui tournent très bien. La vidéo conférence est quand même un cas très particulier et très complexe, et même en sortant de XMPP, il y a peu voire pas de logiciels libres qui sont très bons là dedans (pour l'audio il y a mumble qui s'en tire bien je crois, et avec l'audio uniquement j'ai de bon résultats avec Linphone).
Bon y'a Tox qui est à la mode alors qu'il ne fait… que du chat pour le moment (et encore, même pas sur qu'il le fasse bien).
combien de temps s'est-il écoulé entre l'implémentation première de Jingle par Google (en VoIP à l'époque) et la publication des specs Jingle?
Il s'est passé 4 ans!
Ce n'est pas choquant du tout pour l'élaboration d'un standard. Ça n'empêchait pas les implémentations avant, juste qu'il y avait des risques de devoir les modifier avant la spécification finale. Au contraire, ça serait même plutôt mauvais signe que ça aille trop vite (il faut du temps pour discuter et tester les implémentations).
Si au lieu de passer ces 4 années à chercher à écrire la RFC parfaite le projet avait bossé sur les autres sujets dont tu parles, XMPP serait peut-être encore dans la course, et les hautes instances de Google auraient sûrement été plus réticentes à l'idée d'abandonner XMPP pour Hangout.
Les standard c'est une chose, les implémentations une autre. XMPP est toujours dans la course et de toute façon ça ne m'intéresse pas de courrir derrière les modes du moment, ni d'avoir des « gros » (quel intérêt de la décentralisation et de la fédération si tout le monde est chez Google ?). On ne sait pas les raisons internes de l'abandon (pas tout à fait effectif d'ailleurs) de XMPP pour Gtalk, mais c'est peut-être pour de basses raisons anti-concurrence (Microsoft commençait à inclure le support XMPP pour pouvoir communiquer avec GMail, notamment dans Skype et il me semble qu'il y avait une histoire avec Outlook aussi).
XMPP est peut-être un super protocole, mais il est surtout suicidé par la lenteur de la XSF!
Je reproche surtout à la XSF de ne pas mettre les priorités au bon endroit (il s'intéressent plus à l'internet des objets qu'à corriger pubsub en ce moment), mais en même temps je n'ai pas encore pris le temps de travailler moi-même sur les XEP ni de participer en dehors de quelques messages sur les listes. Donc je critiquerai vraiment quand j'aurai tenté des trucs si la XSF me bloque, mais je n'en suis pas là.
Après tous les effets de mode, c'est plus ça qui tue les projets dans l'œuf à mon avis. Tout le monde s'est rué sur Diaspora à une époque parce qu'on en parlait, oubliant les projets qui existaient et dont plusieurs existent toujours maintenant. Diaspora est toujours actif depuis que c'est vraiment communautaire (j'ai discuté avec un dév récemment entré dans l'équipe aux JDLL), mais on n'en parle plus parce que c'est plus à la mode. Aujourd'hui la mode est à bitmessage ou twister (bitmessage c'est peut-être intéressant sur le plan technique/théorique, mais j'ai franchement du mal à imaginer un truc sérieux qui tourne avec), demain ça sera oublié pour autre chose. Enfin bref, faudrait peut-être passe un peu moins de temps à s'esclaffer sur twitter sur les trucs à la mode, et plus à aider les projets qui manquent de bras…
ça peut être le MUA ou le MTA (en pratique la limite vient souvent du MTA parce qu'il doit stocker la pièce jointe, mais elle peut être mise dans le MUA en prévision), mais peut importe. Le truc est que le courrier électronique n'est pas fait pour transférer des pièces jointes, c'est un bricolage qui a été ajouté dessus (MIME) et on se retrouve avec plein de problèmes: en particulier cette fameuse limite, et l'augmentation énorme de la taille du fichier. Tu as peut-être pu envoyer 50 Mio à quelqu'un, mais rien ne garantie que ça se passera aussi bien avec une autre personne.
XMPP lui a des XEPs dédiées au transfert de fichier, même s'il n'y en pas qui définissent une pièce jointe, il suffit d'en ajouter une, il a ce qu'il faut pour créer une canal dédié et faire un transfert efficace. Bref, on a une séparation propre de la pièce jointe, et pas un plat de spaghettis à la sauce MIME.
Tu peux avoir des quotas, c'est une chose. Mais la plupart des MUA t'empêchent d'envoyer une pièce jointe supérieure à 5, 10 ou 15 Mio, alors que de nos jours c'est quand même pas énorme. Moi j'ai mon propre serveur de courriel, je n'ai pas de quota, et pourtant on n'a pas pu m'envoyer un fichier de ~70Mio tout à l'heure.
En plus de ça XMPP est capable de faire un transfert en P2P (bon là faut les 2 machines allumées en même temps bien sûr, donc on s'éloigne du courrier électronique).
Edit: et sans oublier la perte due au passage en base64
Oui, mais SMTP a de nombreux problèmes, et XMPP en règle beaucoup. XMPP est unicode de base, il n'est pas possible (théoriquement) d'usurper une adresse alors qu'avec qu'SMTP il suffit de la changer, pas de limite pour les pièces jointes (enfin il faut définir comment les envoyer, mais c'est juste une XEP à ajouter), liste de contacts (roster) déjà intégré, etc. Et avec passerelle + le jid qui ressemble à une adresse courriel, la transition est facile.
Un des buts de SàT est de fournir ce qu'il faut pour remplacer le courrier électronique par XMPP.
XMPP est capable de faire du P2P. Il utilise certes un serveur pour négocier une session (ce qui peut être un atout), mais il est envisageable qu'il soit possible de s'en passer. Du coup pour reprendre ta liste:
audio/vidéo : XMPP (Jitsi par exemple, même si perso j'ai toujours eu des soucis avec). Linphone bouge beaucoup et est dispo sous de nombreuses plateformes (web, GNU/Linux, Android, etc)
chat : du jabber en pair à pair ? ==> C'est déjà le cas: soit avec une négociation de session passant par le serveur (jingle), soit en local (http://xmpp.org/extensions/xep-0174.html). Pourquoi pas un jour se passer de serveur même en dehors du réseau local ?
partage : XMPP (jingle), même si y'a encore du boulot de ce côté
podcast pair à pair: Du streaming ? Là encore je dirais jingle à la rescousse, mais à voir je ne me suis pas encore intéressé à ce problème.
annuaire sur DHT: plus facile sur le papier qu'en pratique. Nous avons commencé un mini annuaire XMPP qu'on espère pouvoir rendre distribué…
Bref il y a des tas de projets qui demandent du temps et/ou des améliorations.
Google Wave avait quelques idées intéressantes, c'était repris par la fondation Apache et y'avait un truc libre qui avait l'air pas mal du tout dont on avait parlé il y a un an ou 2. Là encore j'ai oublié le nom, je vais essayer de retrouver ça.
Ça me ferait beaucoup rire de voir G+ disparaître (on n'en est pas -encore ?- là), après l'arrêt de leur truc de flux (j'ai oublié le nom) et l'arrêt progressif du support XMPP. Ça me ferait rire parce qu'un des arguments principaux pour ces services par rapport aux outils libres c'est « mais c'est G/FB/etc c'est solide et pérenne, ça au moins ça marche ». Je passe tous les autres problèmes (vie privée, toussa toussa), rien que ça c'est suffisamment drôle.
Je ne comprends pas ton 1er point ? Sous chaque billet tu as le lien vers l'article original.
ben le lien pointe sur l'article à travers planet libre, ce qui permet de tracer. Par exemple là j'ai un article de tuxicoman dans mon flux: « Lister et tuer les processus en cours sous Linux ». Le liens vers l'article original est « http://www.planet-libre.org/index.php?post_id=16695&go=external » (passe par planet libre), alors qu'il devrait être « http://tuxicoman.jesuislibre.net/2014/04/lister-et-tuer-les-processus-en-cours-sous-linux.html » . Alors oui vous vous en servez pour afficher l'article le plus populaire etc, mais pour moi c'est bloquant, je ne veux pas proposer mon blog à cause de ça, alors qu'une agrégation de blogs sur le libre m'intéresse.
Les boutons sociaux ça prenait trop de place à un moment dans le flux par rapport au contenu ça devenait intenable. Si tu as d'autres idées…
bon passons pour ça, c'était pas le point qui me gênait le plus
Ça ne me choque pas de demander un lien vers le PL qui vit de bénévoles et n'a pas l'ambition de monétiser son travail ni de dominer le monde. Le PL est là pour promouvoir le libre donc promouvoir le PL lui-même semble cohérent.
Demander ça ne me dérange pas, forcer à le faire oui. Je suis sur les planètes jabberfr et jabber anglophone, aucune chose de ce style n'est demandée.
Il y a aura toujours des contraintes sur le PL (à commencer par respecter la thématique) explicités par une Charte qui sert de support à la modération. C'est dans l'intérêt des utilisateurs. Idem sur LinuxFR.org etc.
Respecter la thématique ça me semble une contrainte logique. Forcer à afficher un logo non. Mais bon la point qui me bloque vraiment c'est surtout le 1er.
Bon faut pas voir ça comme une attaque frontale hein, je le lis tout de même (sans cliquer sur les liens) comme j'ai dis dans mon premier commentaire. Maintenant je ne peux pas décemment demander à inclure mon blog sur un site qui a les mêmes pratiques que je critique chez d'autres.
Tu indiques que les comtpes bidons sont en lecture seule.
euh, non. J'indique qu'on peut faire un compte bidon, et que de toute façon on peut l'utiliser en lecture seule même si on n'a pas de compte. Ce coup-ci c'est le point de fin de phrase que tu as loupé.
[^] # Re: SMTP
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Sortie de Twisted 14.0.0. Évalué à 3.
Oui tout à fait:
https://twistedmatrix.com/trac/wiki/TwistedMail
https://twistedmatrix.com/documents/current/_downloads/emailserver.tac
http://pepijndevos.nl/twsited-smtp-server-with-authentication/index.html
[^] # Re: OTR
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Le chiffrement, c'est maintenant. Évalué à 3.
OTR n'a rien à voir avec XMPP, c'est un bricolage de l'utiliser avec, dont l'intérêt principal est à mon sens est d'être utilisable avec les passerelles (c.-à-d. quand on sort de XMPP). Ce n'est certainement pas la méthode qui va être standardisée (pas plus que PGP qui était un usage historique maintenant obsolète). Le journal est d'ailleurs faux sur ce point.
La méthode propre passe par jingle et est en cours de travail: http://xmpp.org/internet-drafts/draft-meyer-xmpp-e2e-encryption-02.html . Il y aussi quelques XEPs par ci par là mais je ne les connais pas encore, je ne sais pas ce qu'elle valent (XEP-0200 par exemple).
OTR est censé être utilisé sur l'instant, comme un journaliste parlerait à une de ses source: sur le moment il sait à qui il parle, mais après coup on ne peut plus le prouver. Ça n'est pas fait pour laisser des messages hors ligne, ni même pour quoi que ce soit d'autre que de la discussion instantanée (pas de mise en forme, pas d'état de discussion, pas de correction de message, etc. Les clients qui font de la mise en forme font aussi un bricolage, ça devient du bricolage par dessus du bricolage).
ça veut dire quoi multi resources non synchronisées sur la même adresse ? Le sysème de resources de XMPP fonctionne très bien, quel est ton problème au juste ?
[^] # Re: asyncio et Python 2 : Trollius !
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Sortie de Twisted 14.0.0. Évalué à 2.
l'inconvénient principal des inlineCallbacks est une perte de performances énorme dans pypy (de ce que j'en ai lu, je n'utilise pas -encore ?- pypy).
Pour l'écriture et le débogage, l'écriture est en effet un peu difficile, c'est une habitude à prendre, par contre pour le débogage je n'ai pas trop de soucis, surtout grâce à leur système qui permet de tracer l'origine d'un Deferred en mode debug.
Bon en tout cas faut voir les évolutions de tout ça, mais si ça peut effectivement interagir comme promis, l'avenir devrait être très intéressant.
[^] # Re: Quel problème
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Préserver nos pensées quotidiennes. Évalué à 10.
Tu vois là l'(un des) intérêt(s) d'une ligne éditoriale. Le système de notation et d'étiquettes ou encore les moteurs de recherche te donnent une certaines vue des choses, une ligne éditoriale en est une autre, subjective. Rien ne t'empèche de te faire ta propre sélection d'articles et de la mettre (ou les mettre si les articles sont redistribuables) sur un site public, voire d'associer ça avec d'autres.
En fait c'est une réflexion intéressante, peut-être que le journal est un peu confus par contre. Les articles ne sont pas « oubliés » (on peut les retrouver dans les archives), mais peu mis en valeur et ils disparaissent rapidement sous d'autres journaux/dépêches ou après « l'effet buzz ».
Il y a de toute façon un certain consumérisme de l'information qui explose depuis quelques années (surtout avec des choses comme Twitter). Ce qu'il faudrait, c'est ralentir la cadence; reste à savoir de quelle manière. Une sélection d'articles sur un site à part, me semble une piste.
[^] # Re: Planet-libre
Posté par Goffi (site web personnel, Mastodon) . En réponse au sondage Quelles sont vos sources d'information pour le logiciel libre/open source ?. Évalué à 2.
Bon ben super. Reste à voir si mon blog rentre dans le cadre (a priori je pense, mais comme je parle surtout d'un logiciel, pas sûr que ça passe), mais je n'ai plus trop de raison de râler. Merci :)
[^] # Re: Planet-libre
Posté par Goffi (site web personnel, Mastodon) . En réponse au sondage Quelles sont vos sources d'information pour le logiciel libre/open source ?. Évalué à 2.
Il y a eu des changements ?
Ah apparemment les liens vers l'article complet pour les derniers articles ne pointent plus sur planet-libre, c'était le point le plus bloquant pour moi. Tu confirmes que c'est bien que ça qui a été changé ?
Merci en tout cas, c'est appréciable de voir que les critiques sont écoutées :)
# pentadactyl
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal GNOME Web, alias Epiphany : le navigateur idéal (le jour de Pâques). Évalué à 5.
Avec pendatactyl la barre d'url n'est pas visible non plus (enfin ça se remets avec :toolbarshow Navigation Toolbar), et à l'usage c'est très pratique. Mais bon là ça triche un peu, l'url est dans la barre de statut, et il suffit d'appuyer sur o pour ouvrir une autre, ou O pour modifier celle courante.
[^] # Re: Toujours le même problème: centralisation
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Les applications "cloud" sont elles un danger pour internet?. Évalué à 1.
peu importe (j'ai un exim avec à peu de choses près le conf de base, c'est possible que ça soit limité *), ce que j'indique c'est qu'avec le courrier SMTP s'il y a un élément limitant dans la chaîne t'es marron. Je viens de tomber sur ça par exemple: http://www.outlook-apps.com/maximum-email-size/
Le tableau indique que des MUA (ici outlook et windows live mail, il n'y en a pas pour Thunderbird) imposent des limites, et tous les serveurs cités en imposent aussi, sauf si ça passe par un service externe.
* en effet ça semble être limité à 50 Mio, mais de toute façon la limite de gmail étant apparemment 25 Mio, mon MTA n'a pas été concerné.
[^] # Re: Toujours le même problème: centralisation
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Les applications "cloud" sont elles un danger pour internet?. Évalué à 2.
Euh non, ça marche dans le cas normal, et si jamais tu as un quota sur le serveur de fichiers, tu peux passer par un autre, ou faire un envoi P2P, qui est aussi un cas normal mais qui demande à ce que l'autre soit en ligne.
2 personnes en ligne en même temps c'est beaucoup moins rare que de te retrouver dans un cas où tout le monde gère sa propre chaîne de courriel, et que tout soit configuré sans limite.
ok pour le coup de la taille, si toute la chaîne accepte du 8 bits ça fonctionne.
Oui il faut que ça soit stocké, mais une seule fois, pas à chaque MTA.
Les quotas tu es dépendant du serveur de fichiers que tu choisis. En SMTP tu es dépendant de tes MUA/MTA que tu peux maîtriser, mais aussi de ceux de ton correspondant.
Si Thunderbird stocke les gros fichiers sur des services externes et envoi le lien dans le message, c'est qu'il y a une raison…
[^] # Re: Toujours le même problème: centralisation
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Les applications "cloud" sont elles un danger pour internet?. Évalué à 2.
Oui c'est sûr, si t'as un cas idéal où tout le monde laisse tout passer, et si t'acceptes tout le bordel qui va avec (base64, stockage du fichier à chaque étape, transfert à recommencer depuis le debut si ça foire, et y'en a sûrement d'autres que j'ai pas en tête), ça peut marchoter. Mais en pratique ça n'arrive pas, j'ai eu le cas hier avec le fichier de ~ 70 Mio qu'on a essayé de m'envoyer depuis un compte gmail, et comme déjà dit je gère mes propres serveurs, c'est pas de mon côté que ça coinçait (enfin j'ai pas vérifié, mais a priori je n'ai rien mis dans ma conf pour bloquer quoi que ce soit).
Avec XMPP le fichier passe par un canal dédié, peut être stocké ailleurs que le reste du message, y'a pas d'augmentation de taille, et même si y'a un quota au milieu tu peux toujours faire un P2P. Et je passe tous les autres problèmes de SMTP.
Je ne dis pas que XMPP est un protocole parfait, il a ses défauts, mais je dis qu'il est un excellent candidat pour remplacer SMTP, et probablement le meilleur candidat actuel.
[^] # Re: Toujours le même problème: centralisation
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Les applications "cloud" sont elles un danger pour internet?. Évalué à 1.
Je dis que les pièces jointes sont un bricolage par dessus SMTP (qui est MIME), et que SMTP n'étant pas adapté au transfert de fichiers, on a de nombreux problèmes avec à cause de ça.
La taille des pièces jointes n'est effectivement pas limitée par SMTP ou MIME je n'ai jamais dis le contraire, mais l'architecture du réseau, son historique, le fait que les messages soient stockés par chaque MTA fait qu'en pratique c'est limité, soit au niveau du MUA, soit d'un MTA.
Et le protocol est tout à fait lié à ces limites, outre son historique, le fait que les messages soient stockées par les MTA, et que la taille des fichiers soit beaucoup augmentée à cause de base64 fait qu'en pratique on limite les tailles à des valeurs ridicules de nos jours.
XMPP envoit le fichier par un canal séparé, rendant ces limites inutiles. Il est toujours possible de mettre des quotas, ça personne n'a dit le contraire, mais rien n'empêche que si je m'auto-héberge on m'envoit un fichier de 3 Go. Essaye de faire pareil avec juste du SMTP. En plus de ça, XMPP gère le P2P, et la plus question de quota.
P.-S.: ohhh un nouveau dessin, c'est lié au nombre de commentaires dans un fil ? Rigolo :)
[^] # Re: Toujours le même problème: centralisation
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Les applications "cloud" sont elles un danger pour internet?. Évalué à 1.
Qui a parlé de limite de taille dans MIME ?
[^] # Re: Toujours le même problème: centralisation
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Les applications "cloud" sont elles un danger pour internet?. Évalué à 3.
Euh non, j'ai repris une liste de 7 « services », et j'ai dis que XMPP répondait déjà à 4 d'entre eux (email, audio/vidéo, chat et partage - même si pour ce dernier il y a effectivement encore du boulot -).
Attention j'ai cité Linphone pour l'audio/vidéo, mais Linphone n'utilise pas XMPP ! Ça utilise SIP. Jitsi lui utilise les 2, et effectivement j'ai eu des soucis avec mes essais, maintenant je teste assez peu ça, il y a probablement des implémentations qui tournent très bien. La vidéo conférence est quand même un cas très particulier et très complexe, et même en sortant de XMPP, il y a peu voire pas de logiciels libres qui sont très bons là dedans (pour l'audio il y a mumble qui s'en tire bien je crois, et avec l'audio uniquement j'ai de bon résultats avec Linphone).
Bon y'a Tox qui est à la mode alors qu'il ne fait… que du chat pour le moment (et encore, même pas sur qu'il le fasse bien).
Ce n'est pas choquant du tout pour l'élaboration d'un standard. Ça n'empêchait pas les implémentations avant, juste qu'il y avait des risques de devoir les modifier avant la spécification finale. Au contraire, ça serait même plutôt mauvais signe que ça aille trop vite (il faut du temps pour discuter et tester les implémentations).
Les standard c'est une chose, les implémentations une autre. XMPP est toujours dans la course et de toute façon ça ne m'intéresse pas de courrir derrière les modes du moment, ni d'avoir des « gros » (quel intérêt de la décentralisation et de la fédération si tout le monde est chez Google ?). On ne sait pas les raisons internes de l'abandon (pas tout à fait effectif d'ailleurs) de XMPP pour Gtalk, mais c'est peut-être pour de basses raisons anti-concurrence (Microsoft commençait à inclure le support XMPP pour pouvoir communiquer avec GMail, notamment dans Skype et il me semble qu'il y avait une histoire avec Outlook aussi).
Je reproche surtout à la XSF de ne pas mettre les priorités au bon endroit (il s'intéressent plus à l'internet des objets qu'à corriger pubsub en ce moment), mais en même temps je n'ai pas encore pris le temps de travailler moi-même sur les XEP ni de participer en dehors de quelques messages sur les listes. Donc je critiquerai vraiment quand j'aurai tenté des trucs si la XSF me bloque, mais je n'en suis pas là.
Après tous les effets de mode, c'est plus ça qui tue les projets dans l'œuf à mon avis. Tout le monde s'est rué sur Diaspora à une époque parce qu'on en parlait, oubliant les projets qui existaient et dont plusieurs existent toujours maintenant. Diaspora est toujours actif depuis que c'est vraiment communautaire (j'ai discuté avec un dév récemment entré dans l'équipe aux JDLL), mais on n'en parle plus parce que c'est plus à la mode. Aujourd'hui la mode est à bitmessage ou twister (bitmessage c'est peut-être intéressant sur le plan technique/théorique, mais j'ai franchement du mal à imaginer un truc sérieux qui tourne avec), demain ça sera oublié pour autre chose. Enfin bref, faudrait peut-être passe un peu moins de temps à s'esclaffer sur twitter sur les trucs à la mode, et plus à aider les projets qui manquent de bras…
[^] # Re: Fait
Posté par Goffi (site web personnel, Mastodon) . En réponse à l’entrée du suivi Mettre en évidence les articles collaboratifs actifs. Évalué à 2 (+0/-0).
eh ben c'est du rapide, merci :)
[^] # Re: Toujours le même problème: centralisation
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Les applications "cloud" sont elles un danger pour internet?. Évalué à 2.
ça peut être le MUA ou le MTA (en pratique la limite vient souvent du MTA parce qu'il doit stocker la pièce jointe, mais elle peut être mise dans le MUA en prévision), mais peut importe. Le truc est que le courrier électronique n'est pas fait pour transférer des pièces jointes, c'est un bricolage qui a été ajouté dessus (MIME) et on se retrouve avec plein de problèmes: en particulier cette fameuse limite, et l'augmentation énorme de la taille du fichier. Tu as peut-être pu envoyer 50 Mio à quelqu'un, mais rien ne garantie que ça se passera aussi bien avec une autre personne.
XMPP lui a des XEPs dédiées au transfert de fichier, même s'il n'y en pas qui définissent une pièce jointe, il suffit d'en ajouter une, il a ce qu'il faut pour créer une canal dédié et faire un transfert efficace. Bref, on a une séparation propre de la pièce jointe, et pas un plat de spaghettis à la sauce MIME.
[^] # Re: Toujours le même problème: centralisation
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Les applications "cloud" sont elles un danger pour internet?. Évalué à 1. Dernière modification le 26 avril 2014 à 23:20.
Tu peux avoir des quotas, c'est une chose. Mais la plupart des MUA t'empêchent d'envoyer une pièce jointe supérieure à 5, 10 ou 15 Mio, alors que de nos jours c'est quand même pas énorme. Moi j'ai mon propre serveur de courriel, je n'ai pas de quota, et pourtant on n'a pas pu m'envoyer un fichier de ~70Mio tout à l'heure.
En plus de ça XMPP est capable de faire un transfert en P2P (bon là faut les 2 machines allumées en même temps bien sûr, donc on s'éloigne du courrier électronique).
Edit: et sans oublier la perte due au passage en base64
[^] # Re: Toujours le même problème: centralisation
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Les applications "cloud" sont elles un danger pour internet?. Évalué à 3. Dernière modification le 26 avril 2014 à 22:38.
Oui, mais SMTP a de nombreux problèmes, et XMPP en règle beaucoup. XMPP est unicode de base, il n'est pas possible (théoriquement) d'usurper une adresse alors qu'avec qu'SMTP il suffit de la changer, pas de limite pour les pièces jointes (enfin il faut définir comment les envoyer, mais c'est juste une XEP à ajouter), liste de contacts (roster) déjà intégré, etc. Et avec passerelle + le jid qui ressemble à une adresse courriel, la transition est facile.
Un des buts de SàT est de fournir ce qu'il faut pour remplacer le courrier électronique par XMPP.
[^] # Re: Toujours le même problème: centralisation
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Les applications "cloud" sont elles un danger pour internet?. Évalué à 2.
XMPP est capable de faire du P2P. Il utilise certes un serveur pour négocier une session (ce qui peut être un atout), mais il est envisageable qu'il soit possible de s'en passer. Du coup pour reprendre ta liste:
email : XMPP (cf mon biller à ce sujet)
VPN : free-lan
audio/vidéo : XMPP (Jitsi par exemple, même si perso j'ai toujours eu des soucis avec). Linphone bouge beaucoup et est dispo sous de nombreuses plateformes (web, GNU/Linux, Android, etc)
chat : du jabber en pair à pair ? ==> C'est déjà le cas: soit avec une négociation de session passant par le serveur (jingle), soit en local (http://xmpp.org/extensions/xep-0174.html). Pourquoi pas un jour se passer de serveur même en dehors du réseau local ?
partage : XMPP (jingle), même si y'a encore du boulot de ce côté
podcast pair à pair: Du streaming ? Là encore je dirais jingle à la rescousse, mais à voir je ne me suis pas encore intéressé à ce problème.
annuaire sur DHT: plus facile sur le papier qu'en pratique. Nous avons commencé un mini annuaire XMPP qu'on espère pouvoir rendre distribué…
Bref il y a des tas de projets qui demandent du temps et/ou des améliorations.
[^] # Re: api
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Google moins?. Évalué à 9.
Pourquoi voulez-vous absolument de gros acteurs pour XMPP ? Tout l'intérêt c'est justement qu'il y ait de très nombreux petits acteurs.
[^] # Re: Ça me ferait beaucoup rire
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Google moins?. Évalué à 4.
Oui c'est ça Google Reader.
Google Wave avait quelques idées intéressantes, c'était repris par la fondation Apache et y'avait un truc libre qui avait l'air pas mal du tout dont on avait parlé il y a un an ou 2. Là encore j'ai oublié le nom, je vais essayer de retrouver ça.
J'ai retrouvé, c'est Kune: https://linuxfr.org/news/sortie-de-kune-0-2-0-ostrom-un-logiciel-collaboratif-base-sur-apache-wave, ça avait l'air en bonne place pour remplacer les outils collaboratifs proprio. Y'a des gens qui ont testé ce truc ? Le blog n'a pas l'air actif (dernier billet avril 2013), mais le dépôt a l'air bien actif lui.
# Ça me ferait beaucoup rire
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Google moins?. Évalué à 10. Dernière modification le 25 avril 2014 à 19:49.
Ça me ferait beaucoup rire de voir G+ disparaître (on n'en est pas -encore ?- là), après l'arrêt de leur truc de flux (j'ai oublié le nom) et l'arrêt progressif du support XMPP. Ça me ferait rire parce qu'un des arguments principaux pour ces services par rapport aux outils libres c'est « mais c'est G/FB/etc c'est solide et pérenne, ça au moins ça marche ». Je passe tous les autres problèmes (vie privée, toussa toussa), rien que ça c'est suffisamment drôle.
[^] # Re: Planet-libre
Posté par Goffi (site web personnel, Mastodon) . En réponse au sondage Quelles sont vos sources d'information pour le logiciel libre/open source ?. Évalué à 2.
Bonne nouvelle, merci de regarder ça. J'aurais sans doute mieux fait de vous contacter directement plutôt que d'ignorer.
Bon j'attends de voir comment ça évolue du coup, ça m'intéresserait tout de même d'y ajouter mon blog.
[^] # Re: Planet-libre
Posté par Goffi (site web personnel, Mastodon) . En réponse au sondage Quelles sont vos sources d'information pour le logiciel libre/open source ?. Évalué à 2.
Si à la limite y'avait une version du site clairement indiquée sans les redirections internes, ou au minimum du flux, ça serait déjà mieux.
[^] # Re: Planet-libre
Posté par Goffi (site web personnel, Mastodon) . En réponse au sondage Quelles sont vos sources d'information pour le logiciel libre/open source ?. Évalué à 2. Dernière modification le 21 avril 2014 à 16:17.
Salut antistress,
ben le lien pointe sur l'article à travers planet libre, ce qui permet de tracer. Par exemple là j'ai un article de tuxicoman dans mon flux: « Lister et tuer les processus en cours sous Linux ». Le liens vers l'article original est « http://www.planet-libre.org/index.php?post_id=16695&go=external » (passe par planet libre), alors qu'il devrait être « http://tuxicoman.jesuislibre.net/2014/04/lister-et-tuer-les-processus-en-cours-sous-linux.html » . Alors oui vous vous en servez pour afficher l'article le plus populaire etc, mais pour moi c'est bloquant, je ne veux pas proposer mon blog à cause de ça, alors qu'une agrégation de blogs sur le libre m'intéresse.
bon passons pour ça, c'était pas le point qui me gênait le plus
Demander ça ne me dérange pas, forcer à le faire oui. Je suis sur les planètes jabberfr et jabber anglophone, aucune chose de ce style n'est demandée.
Respecter la thématique ça me semble une contrainte logique. Forcer à afficher un logo non. Mais bon la point qui me bloque vraiment c'est surtout le 1er.
Bon faut pas voir ça comme une attaque frontale hein, je le lis tout de même (sans cliquer sur les liens) comme j'ai dis dans mon premier commentaire. Maintenant je ne peux pas décemment demander à inclure mon blog sur un site qui a les mêmes pratiques que je critique chez d'autres.
[^] # Re: alternativeto.net
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal SoftwareRecommendations, le nouveau petit frère de StackOverflow. Évalué à 3.
euh, non. J'indique qu'on peut faire un compte bidon, et que de toute façon on peut l'utiliser en lecture seule même si on n'a pas de compte. Ce coup-ci c'est le point de fin de phrase que tu as loupé.