(pour lire les épisodes précédents, suivez l'étiquette correspondante)
Bien que déjà répété un certain nombre de fois, je le redis : XMPP fait bien plus que de la messagerie instantanée. Une des fonctionnalités qui est apparue rapidement est la copie de fichiers, voyons cela de plus près
Le problème : XMPP étant du XML, il n'est pas vraiment adapté aux données purement binaires comme des fichiers. La solution est de passer par l'extérieur, c'est-à-dire une autre connexion non XML, et d'utiliser le flux XML pour la gérer, on parle de connexion « out-band ». Malheureusement, parfois il n'est pas possible d'établir cette connexion, alors on passe tout par le flux XML : c'est lent, peu efficace, mais ça fonctionne presque toujours, on parle de connexion « in-band » (qu'on pourrait traduire par « interne »).
Il y a aussi des cas où il est plus simple et efficace de rester « in-band », enfin surtout un : si on envoie très peu de données, comme une petite image (un avatar par exemple).
Comme souvent dans le monde XMPP, plusieurs solutions ont été proposées, expérimentées, parfois adoptées puis dépréciées, jusqu'à ce qu'on trouve et garde celle qui semble convenir le mieux, et qui est a priori la meilleure techniquement.
Commençons par la solution courante, appelée « Stream Initiation » (initiation de flux), elle est définie par la XEP-0095, et la copie de fichier l'utilise via la XEP-0096.
La copie de fichiers est la seule application qui utilise la XEP-0095. Nous avons 2 personnes en jeu : celle qui veut envoyer le fichier, qu'on appellera « l'expéditeur » (« sender » en anglais) et celui qui veut le recevoir, qu'on appellera « le destinataire » (« receiver » en anglais).
La XEP-0096 définit ce qu'on appelle un « profil » pour l'initiation de flux, le profil « transfert de fichier ». Elle sert principalement à transmettre les métadonnées du fichier : une description, sa taille, son nom, sa date de dernière modification, et un « hash », c'est à dire une somme de contrôle pour vérifier que le fichier a été correctement copié. C'est l'algorithme MD5 qui est utilisé ici, pourtant connu pour avoir des failles, même si elles ne sont pas dramatiques dans le cadre d'un transfert de fichier (l'expéditeur étant déjà validé par ailleurs).
Il est également possible d'indiquer une fourchette (« range ») à copier, c'est-à-dire un point de départ (« offset ») dans le fichier et une longueur (« length »), pratique si un transfert a été interrompu en plein milieu, par une coupure de courant par exemple.
Le reste, c'est la XEP-0095 qui s'en occupe, il s'agit juste de négocier la méthode à utiliser, le destinataire accepte ou non le flux, et choisi une des méthodes. Il y a 2 méthodes principales : la première est le transfert en interne (« In-Band Bytestreams », XEP-0047) qui se contente de transcoder les données en base64.
La deuxième (la XEP-0065, « SOCKS5 Bytestreams ») est plus intéressante, elle utilise SOCKS v5 pour établir une connexion externe (« out-band ») et tenter une connexion directe ou via un « proxy » qui est un élément externe relayant les données. L'utilisation d'un proxy est moins efficace qu'une connexion directe bien entendu (les données passent par un 3ᵉ point), mais est parfois nécessaire si une connexion directe est impossible à cause d'un pare-feu ou d'un NAT par exemple. XMPP permet, grâce à disco (la XEP-0030) de savoir automatiquement si votre serveur propose un proxy.
C'est donc la XEP-0065 qui est à l'origine du nom « proxy65 » couramment utilisé.
Petit détail qui a son importance : dans le cas du transfert direct, la connexion se fait du destinataire vers l'expéditeur (qui a ouvert un port pour l'occasion), aussi la connexion peut échouer dans beaucoup de cas (par exemple l'expéditeur est derrière un NAT). Une méthode a été faite pour améliorer la situation, mais elle n'a jamais été standardisée, vous pouvez la trouver ici : http://delta.affinix.com/specs/stream.html.
Voilà pour la méthode actuelle. Elle pose de nombreux problèmes : c'est uniquement l'expéditeur qui doit proposer et le destinataire accepte ou refuse, il n'y a pas de vraie méthode de secours (appelée « fallback » en anglais), c.-à-d. de méthode pour passer de SOCKS5 (ou « s5b ») au transfert « in-band » (ou « ibb »), et il y a souvent des difficultés pour établir une connexion directe comme expliqué au paragraphe précédent. Bref, ça n'est pas satisfaisant. Mais le problème est assez complexe, il n'est pas si simple de faire une connexion directe, c'est à dire pair à pair (ou « peer to peer » en anglais).
Heureusement, une nouvelle méthode est apparue, et elle est beaucoup plus souple et efficace : Jingle. Mais cet article étant déjà long, j'en parlerai la prochaine fois.
J'en profite pour annoncer que je vais commencer une série d'articles pour expliquer l'architecture et ce qu'on peut faire concrètement avec « Salut à Toi ». Je vais la faire sur mon blog pour éviter de spammer DLFP.
Je vous rappelle aussi que nous avons une campagne de financement participatif en cours pour porter « Salut à Toi » sur Android et faire une version de bureau, et que nous avons bien besoin de soutien ! http://www.arizuka.com/fr/projects/libervia
Merci :)
# correction
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
Est-ce qu'un modo peut corriger ça:
s/et d'essayer d'établie une connexion directe/et tenter une connexion directe/
Merci !
[^] # Re: correction
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# "éviter de spammer DLFP"
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 10.
Continue à spammer DLFP, s'il-te-plaît. Tes articles sont bons, intéressants, formateurs et informatifs.
Si je recevais du spam de cette qualité-là, j'aurais moins de filtres.
Proverbe Alien : Sauvez la terre ? Mangez des humains !
[^] # Re: "éviter de spammer DLFP"
Posté par Goffi (site web personnel, Mastodon) . Évalué à 5.
Merci :)
Je dis ça par rapport à SàT: ici je parle de XMPP c'est général, utilisé par de nombreux logiciels, et tout à fait dans le cadre de DLFP, du coup ça me semblait logique de publier ici.
Pour SàT on fait déjà des dépêches de temps en temps, si je fais disons 1 article par semaine pour ne parler que du logiciel sur lequel on bosse, ça me semble un peu lourd, même si j'ai beaucoup de choses à dire :).
[^] # Re: "éviter de spammer DLFP"
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Sinon, et bien tu fais un article sur ton blog et tu poste icitte un journal bookmark avec un lien vers ton billet (et une nimage qui n’a rien à voir).
^_^ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: "éviter de spammer DLFP"
Posté par Goffi (site web personnel, Mastodon) . Évalué à 4.
le premier article est en ligne, un peu technique celui là: http://www.goffi.org/post/2015/11/09/S%C3%A0T%3A-Comment-%C3%A7a-marche
# pas user friendly mais...
Posté par Psychofox (Mastodon) . Évalué à 3.
…uuencode/uudecode ça doit pouvoir le faire non, éventuellement avec en splittant les fichiers ?
D'ailleurs y'a t-il une limite de taille de message via xmpp ?
[^] # Re: pas user friendly mais...
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
uuencode pourrait être utilisé, mais base64 est standardisé (je ne pense pas que ça soit le cas pour uuencode, mais peut-être que je me trompe), et a priori plus portable. Bref, ça n'apporterait pas grand chose.
Pas définie dans la RFC, par contre il est explicitement indiqué que l'administrateur devrait pouvoir configurer une taille maximum (pour éviter les attaques par déni de service principalement), mais celle si doit être supérieure à 10000 octets. C'est expliqué dans la RFC 6120 § 13.12 point 4.
[^] # Re: pas user friendly mais...
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
ouch
s/celle si/celle-ci/
Je précise pas toujours les typos que je vois en relisant, mais celle-ci faut pas exagérer :)
[^] # Re: pas user friendly mais...
Posté par Mildred (site web personnel) . Évalué à 2.
Si: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/uuencode.html
Mais uuencode permet aussi de faire du base64 :)
# Sécurisation des données
Posté par tuxicoman (site web personnel) . Évalué à 2.
Salut,
La connexion XML jusqu'au serveur Jabber est à priori chiffrée (suivant les paramètres du client et du serveur).
Qu'en est-il du traffic qui transporte le binaire du fichier?
Je vois trois cas : Jingle, transfert direct (client to client) et lorsque l'on passe par un proxy (si les 2 utiliseurs sont derrière un NAT).
Merci !
[^] # Re: Sécurisation des données
Posté par Goffi (site web personnel, Mastodon) . Évalué à 7. Dernière modification le 05 novembre 2015 à 12:47.
Salut,
oui les connexions sont chiffrées entre client et serveur et entre serveurs, c'est même obligatoire depuis l'année dernière (cf cette annonce et les précédentes).
Dans le cas présenté dans cet article, le chiffrement n'est pas prévu. Aussi ton fichier passera en clair. Par contre en IBB (avec la XEP-0047), tu utilises le flux XML déjà en place, donc tu profiteras du chiffrement de celui-ci.
Avec Jingle par contre, le chiffrement est explicitement prévu, j'expliquerai comment dans le prochain article. Mais en gros tu peux demander une « pré-condition » de sécurité, c'est à dire une exigence pour le flux qui peut être du chiffrement de bout en bout. Là peu importe si tu passes par un proxy ou pas, c'est chiffré au départ et déchiffré à l'arrivée.
Par contre, il n'y a pas encore de méthode officielle pour les fichiers, pour la visioconférence il y a ZRTP (XEP-0262), mais je n'ai pas encore touché à ce domaine, donc je ne vais pas trop m'avancer dessus.
Il y a eu très récemment une proposition de XEP pour OMEMO/Axolotl, et une autre pour l'utiliser pour le transfert de fichiers. C'est une nouvelle méthode de chiffrement qui cherche à corriger les défauts d'OTR (qui est un gros bricolage avec XMPP). La XEP pour l'utiliser avec Jingle m'a paru mal employer ce dernier, j'ai remonté ça sur le chat et on va probablement en discuter sur la liste de diffusion. Mais en tout cas ça bouge et je pense qu'on va voir des solutions à moyenne échéance.
Un autre point à voir, en dehors des fichiers, est que Jingle est aussi intéressant pour de la messagerie chiffrée: en ayant une communication P2P tu évites le serveur, et donc un potentiel homme au milieu.
Enfin bref, le chiffrement évolue beaucoup en ce moment sur XMPP, je songe à faire un article dessus, peut-être après Jingle.
[^] # Re: Sécurisation des données
Posté par tuxicoman (site web personnel) . Évalué à 3.
Merci Goffi.
J'utilise Conversations sur Android que je trouve assez bien fait pour remplacer le SMS. On peut facilement envoyer des photos.
Apparement il utilise Jingle. Du coup je me demandais si les photos passaient en clair sur le réseau ou pas.
J'ai regardé un peu son code mais je ne trouve pas de traces de chiffrement.
Je crois que c'est important d'expliquer que les utilisateurs aient conscience si la confidentialité qui est entendue sur les messages texte s'appliquent aussi aux contenus multimédias ou pas…
[^] # Re: Sécurisation des données
Posté par Goffi (site web personnel, Mastodon) . Évalué à 6.
Oui je connais, c'est un qui a la côte en ce moment. J'ai rapidement testé mais je ne suis pas super fan: déjà leur suppression de la présence ne me plaît pas (d'après leur FAQ ils trouvent que c'est une fonctionnalité du passé, je ne suis pas du tout d'accord), ensuite conversations s'est permis de mettre un de mes salons en autojoin sans me demander mon avis (si je ne l'ai pas fait c'est que j'avais une raison), et je n'ai pas accroché avec l'interface.
Je crois qu'il implémente jingle oui, mais pour envoyer des fichiers sur un salon, c'est HTTP upload qu'ils utilisent, c'est même eux qui ont proposé la XEP. Tu peux utiliser HTTPS avec cette XEP, donc ça peut être chiffré au moins pour la transmission (mais ça sera en clair sur le serveur).
Après c'est aussi eux qui sont à l'origine des XEPs OMEMO et OMEMO/Jingle File Transfer, donc c'est fort possible que l'on puisse ou puisse bientôt envoyer un fichier en chiffré. En tout cas c'est une bonne chose de voir de l'avancement dans ce domaine qui reste un des parents faibles de XMPP.
C'est une des raisons qui m'ont fait commencer cette série d'article: comprendre ce qu'il se passe derrière, pourquoi certains trucs marchent bien et d'autres sont plus difficiles, où sont stockés les fichiers, à quel moment c'est chiffré, etc. Il faudrait aussi faire de la documentation accessible à un public moins technique, mais j'ai déjà beaucoup de choses sur les bras.
Ce sont des choses qui peuvent (voire devraient) apparaître dans l'interface. On essaye un peu de notre côté (par exemple on a une bannière de couleur différente si on écrit en public, à un groupe ou à une seule personne, on a un cadenas fermé si la communication est chiffrée de bout en bout, un message au début des passerelles pour indiquer que ça passe par des réseaux extérieurs, etc). D'autres font des choses similaires (par exemple Movim a une pastille de couleur équivalente à notre bannière). Il ne faut pas hésiter à suggérer plus sur les outil de rapport de bogue, des fois y'a des choses simples qu'on peut mettre auxquelles on n'a pas forcément pensé.
# Bibinaire
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Pourquoi le transfert de données binaires n'a pas été prise en compte dès le début?
Si je devais concevoir un protocole, je prévoirais dès le début de pouvoir transférer des données textuelles ou binaires via un même canal.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bibinaire
Posté par Jehan (site web personnel, Mastodon) . Évalué à 7.
Aucun protocole moderne digne de ce nom ne prévoirait d'utiliser le canal principal pour l'échange binaire! Un échange binaire sur le même canal implique de bloquer la connexion le temps du transfert. Même le vieux ftp, qui est un protocole à la base fait pour transférer des fichiers (donc on pourrait naïvement penser "autant tout faire dans la même connexion: contrôles et transferts!") ouvre une connexion de données séparées, ce qui permet de continuer à naviguer dans l'arborescence et d'exécuter diverses commandes de contrôle.
Bien sûr, on peut aménager le protocole pour ne pas bloquer la connexion, par exemple en coupant en petits bouts le fichier (permettant pleins de petits transferts entre lesquelles des commandes peuvent se placer). Néanmoins cela a pour conséquence de donner une sensation de ralentissement à la fois du transfert (envoyer pleins de petits bouts avec des caractères de contrôle à chaque fois est plus lent qu'envoyer en un bloc) mais aussi le flux non binaire (si on doit constamment attendre le chargement d'un bout binaire, même les messages textes pourraient se mettre à prendre quelques secondes le temps que le bout en cours se termine).
Et c'est sans compter que ça oblige en général de réencoder (par ex avec base64 dans XMPP) parce qu'on ne contrôle pas le contenu d'un binaire et que le mettre direct dans le flux cassera ce dernier chaque fois qu'un contenu de fichier utilise un caractère de contrôle du protocole. Donc le fichier à envoyer est plus gros (de l'ordre du tiers avec base64, de mémoire, ce qui n'est pas rien si on envoie de très gros fichiers!). Ça rallonge d'autant la durée du transfert.
Tout ça, c'est vraiment se faire chier pour rien alors que les connexions, de nos jours, sont tout à fait capables d'encaisser même plusieurs transferts de fichiers en parallèle à pleine vitesse chacune sur leur canal, tout en gardant un canal de contrôle non-encombré, parfaitement fluide et rapide aussi.
Donc non, franchement un protocole qui commencerait avec l'idée de tout faire dans le même canal, j'aurais pas confiance. Ça ne peut pas monter en charge notamment.
Par contre oui, comme solution de secours si on n'arrive pas à initier un canal binaire, ça ok, en bridant si besoin le transfert pour pas qu'il gêne trop le reste de l'expérience utilisateurs. C'est d'ailleurs ce que fait XMPP.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bibinaire
Posté par devnewton 🍺 (site web personnel) . Évalué à 4. Dernière modification le 05 novembre 2015 à 17:46.
Question de couche: pour moi le protocole doit être indépendant de la manière de le transporter.
Par exemple dans Mumble, les paquets peuvent être transférés sur deux connexions TCP+UDP ou sur une seule connexion TCP:
En séparant protocole et transport, on permets des optimisations selon le type d'accès: plusieurs connexions avec un serveur sur la fibre, une seule depuis un smartphone en 3G derrière un NAT…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bibinaire
Posté par Goffi (site web personnel, Mastodon) . Évalué à 5.
Jingle permet de donner des priorités aux interfaces, ainsi tu peux favoriser une connexion Wifi par rapport à de la 3G (qui peut être payante ou limitée). Ceci ne serait pas possible avec une seule connexion.
[^] # Re: Bibinaire
Posté par Jehan (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 05 novembre 2015 à 18:03.
Je comprends pas de quoi tu parles et le rapport avec la discussion. XMPP est indépendant de la couche de transport, qui est en effet TCP par défaut, mais peut-être ce que tu veux d'autre. Par exemple, y a du XMPP over BOSH (cad HTTP).
C'est même explicitement décrit dans la RFC 6120:
Si tu parles de la couche de transport pour les données, ben c'est aussi exactement ce que fait XMPP avec Jingle! Le protocole permet de définir divers transports, avec des connexions directs TCP, UDP, ou ce que tu veux, en passant par des intermédiaires ou en direct, etc. Et avec du transport inline dans XMPP en dernier recours.
Bon je peux dire une connerie car je connais pas Mumble et j'ai pas le temps ni l'envie de regarder en détail, mais la citation que tu fais… ben c'est exactement ce que fait XMPP et ce que je dis plus haut (bon sauf que XMPP fait bien plus que juste ces deux cas). Là ils semblent dire que la connexion UDP est le comportement par défaut, mais qu'elle peut être remplacée par la connexion TCP existante (j'imagine si l'établissement de la seconde connexion échoue). Ben c'est ce que fait XMPP avec son fallback inline.
Mais au final dans Mumble aussi, ils sont donc probablement conscients que si possible, ils préfèrent utiliser une connexion séparée.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bibinaire
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Sauf que Mumble étant orienté message binaire, le fallback (comment on dit en french?) reste optimisé par rapport au flux xml avec base64 de XMPP.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Bibinaire
Posté par Jehan (site web personnel, Mastodon) . Évalué à 2.
Ah ça c'est fort probable. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Pièce jointe
Posté par jnanar (site web personnel) . Évalué à 6.
Est-ce qu'un support des pièces jointes est prévu? Si je ne me trompe pas, le transfert de fichier présenté ici nécessite que le destinataire accepte le fichier et donc qu'il soit connecté.
Est-il possible d'envoyer un fichier à un destinataire non connecté? Il existe des mécanismes afin qu'un utilisateur récupère les messages qui lui ont été envoyé lorsqu'il était déconnecté. Si un tel mécanisme existe pour le transfert de fichier, alors il n'y a virtuellement plus de différence entre l'utilisation d'XMPP et du mail. On peut penser à l'ajout d'un champs XML d'un message donné où le fichier serait codé en base64 (ça existe peut-être ou cette une approche est peut-être trop naïve). Quoiqu'on pense de l'usage des pièces jointes, elles sont indispensables si on veut concurrencer les emails.
Encore merci pour tes articles de qualité et le temps que tu passes à vulgariser XMPP, SàT ainsi que tout l'écosystème autour.
[^] # Re: Pièce jointe
Posté par Jehan (site web personnel, Mastodon) . Évalué à 3.
Salut,
Je sais pas si ça existe, mais le problème est qu'un fichier, ça prend de la place. Quand tu transfères d'un compte à l'autre, ça n'utilise que de la bande passante. Si tu te mets à joindre des fichiers "en attente de connexion", faut bien le stocker quelque part, c'est à dire sur un des serveurs du fournisseur de service (sur celui de l'envoyeur ou du destinataire d'ailleurs?!).
En plus, beaucoup d'utilisateurs sur n'importe quel service sont des fantômes (ils s'inscrivent, utilisent — ou non — un temps, puis un jour ne reviennent jamais), donc ça peut entraîner des quantités phénoménales de données stockées qui ne désemplissent jamais avec le temps quand les destinataires ne se re-connectent jamais.
Donc au final, les fournisseurs de service en viennent rapidement à limiter. Va envoyer un fichier de 100 Go par email! Peu de services email (probablement aucun dans les services commerciaux) n'autoriseront. Prenons gmail par exemple, ils limitent à 25 Mo. Et même si votre fournisseur autorisait de grosses tailles, il n'est pas dit que le fournisseur du destinataire accepte l'email s'il a une limite inférieure! Tout de suite, ça limite.
Au final, le concept de pièce jointe reste intéressant mais très limité comparé à du transfert direct où on peut envoyer n'importe quelle taille. Ce ne sera jamais le protocole qui limitera sur le sujet, mais les implémentations car c'est un nid à problème.
Mais sinon oui, pour des petits fichiers, ce serait une fonctionnalité intéressante (si ça n'existe pas déjà), mais je préfèrerais voir le transfert de fichier direct marcher de façon fiable d'abord. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Pièce jointe
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Avec la XEP-0096, il y a un schéma d'URI qui est spécifié (dans la section 6.2), qui permet d'envoyer ou demander un fichier. Par contre il faut que l'entité soit connectée.
Avec Jingle, tu as un système pour demander un fichier explicitement, mais pas encore d'URI.
Alors il faut là encore que l'entité soit connectée, mais pour du transfert hors ligne, il suffit que l'entité en question soit ton serveur (exactement comme pour le web ou le courrier électronique). Un système d'URI est d'autant plus puissant que tu peux choisir de mettre des fichiers sur ton serveur (par exemple un album photo), ou d'envoyer directement en P2P si nécessaire/préférable.
Il y a aussi eu une XEP récente, HTTP upload (la XEP-0363) qui est très simple: elle consiste à spécifier l'envoi de 2 liens HTTP(S): 1 pour l'upload, 1 pour le download.
Je préfère personnellement utiliser Jingle qui est beaucoup plus puissant, mais il faut reconnaître que cette option a la simplicité pour elle, et elle peut-être adapté à un service externe.
Pour résumer donc: pour l'envoi de type pièce jointe il y a des URI, mais ça n'est pas encore spécifié pour le transfert de fichier via Jingle, ou HTTP Upload. Pour que ça soit dispo hors ligne, il suffit que ton autre pair soit un serveur.
Il manque éventuellement une XEP pour dire « ces URI sont des pièces jointes », mais c'est trivial à écrire ça.
XMPP est un excellent candidat pour remplacer le courriel, comme j'en parlais déjà en janvier 2011. D'autant plus qu'avec les passerelles, cela peut se faire de manière relativement transparente.
Merci. Il y a une grosse activité sur XMPP qui peut donner quelque chose (on pourrait même parler d'une nouvelle vague), faut pas qu'on loupe le virage…
[^] # Re: Pièce jointe
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
À la réflexion, c'est plus ou moins ce que fait la XEP-0066
[^] # Re: Pièce jointe
Posté par jnanar (site web personnel) . Évalué à 1.
Merci beaucoup pour vos réponses détaillées. Si je condense les réponses de Jehan et de Goffi, on peut donc imaginer le mécanisme suivant:
1° On envoie directement le fichier au destinataire s'il est connecté (sans quota de taille).
2° Si le destinataire est déconnecté, le programme spécifie que l'autre pair est le serveur (du destinataire si il est disponible ou celui de l'émetteur dans l'autre cas voir un serveur externe HTTP ou autre à paramétrer). Il y aurait alors des quotas de taille de fichier dépendant du serveur qui héberge le fichier.
3° Si le destinataire était non connecté lorsque le fichier a été envoyé, il a la possibilité de le récupérer lors de sa prochaine connexion (le serveur lui envoie un message contenant l'URI).
4° Le destinataire a le choix de laisser la pièce jointe sur le serveur pour consulter la pièce jointe depuis un autre client ou alors d'effacer le fichier du serveur après téléchargement sans possibilité de le récupérer depuis un autre client.
Je pense qu'un schéma de ce type permettrait de remplacer (et de surpasser)complètement l'usage du mail. Si on veut envoyer une grosse archive de photos, on est plus obligé d'envoyer 10 mails de 15Mo contenant chacun son lot de fichier, mais de simplement fixer un moment où le destinataire allume son client et on attend que transfert ait lieu afin de récupérer la série de fichier d'un coup. Si on veut simplement envoyer un fichier de taille raisonnable à un destinataire non connecté, on peut le faire aussi facilement qu'avec un mail.
[^] # Re: Pièce jointe
Posté par Goffi (site web personnel, Mastodon) . Évalué à 4.
Oui c'est plus ou moins ça (du moins l'idée que j'en ai, peut-être que d'autres ont une vision différente).
XMPP permet de faire tout ça, la partie difficile est de rentre ça simple et utilisable dans l'interface.
# autohébergement?
Posté par err404 (site web personnel) . Évalué à 2.
Avec jabber il est facile de s'autohéberger (chez soi, ou en datacenter), donc on pourrait très bien avoir un fonctionnement comme les emails.
Comme recevoir les fichiers même si on n'est pas en ligne.
C'est une fonctionnalité qui manque à se généraliser dans jabber, pour avoir enfin une vraie alternative aux emails (avec les emails, si on souhaite s'autohéberger, il est compliqué de bien configurer les paramètres pour pas se faire considérer comme SPAM par les gros.)
[^] # Re: autohébergement?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
Ça avance en ce moment avec HTTP upload, et le transfert de fichier via Jingle qui se développe. Après il faut aussi des projets derrière qui utilisent ces XEPS, et des gens qui utilisent ces projets.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.