Dans le premier cas, il reste un "centre" qui échappe à l'utilisateur. Dans le second, le poids de la mise en place et de l'entretien de ce "centre" lui incombe. Aucun de ces horizons ne me semble désirable au point de ne pas investiguer celui des services distribués, pour justement, entre autre, envisager leurs limitations. C'est de la prospective.
Oui il y a plusieurs questions à prendre en compte. Pour ma part je ne suis pas gêné d'avoir un serveur géré par une entité si j'ai confiance en elle (une assoce que je connais bien par exemple), mais même dans ce cas je chiffrerai de bout en bout les infos très sensibles (par exemple un mot de passe que je donne à quelqu'un). Pour faire un parallèle, j'ai très souvent laissé les clefs de chez moi à des inconnus (je suis sur des sites d'hospitalité comme BeWelcome).
Il y a aussi des questions écologiques (mutualiser les ressources sera toujours mieux de ce point de vue), d'entretien (en dehors du serveur pour ton logiciel lui même, la gestion des sauvegardes ou des risques d'intrusion ne vont a priori pas être géré par ton logiciel final, même s'il est entièrement P2P). Bref, c'est pas mal si une ou plusieurs personnes s'en occupent sérieusement. Je pense que le mieux est de permettre les 2 : mutualiser et si voulu autohébergement facile.
Je vois Tox, ring.cx et ricochet comme outsiders. Si tu as le temps, je serais ravi - et probablement pas que moi - d'avoir ton avis sur ces derniers.
Tox j'ai essayé mais il y a plus d'un an, avec un des frontaux les plus communs (je ne sais plus lequel, peut-être Venom). J'avais apprécié la simplicité (en dehors du hash quasi inévitable, on lance est c'est OK), mais impossible d'avoir une vidéo fonctionnelle, et c'est pour ça que je voulais l'utiliser. À vrai dire même avec Jitsi j'ai pas eu des résultats très probants (pas essayé non plus depuis longtemps), et c'est encore Mumble qui me donne les meilleurs résultats, mais c'est audio uniquement. Il faut dire que je suis souvent dans des conditions mauvaises (pas de connexion directe, mauvais débit, etc).
Ring et Ricochet pas essayé, Ricochet leur technique pour couvrir le bruit semble intéressante, mais c'est un cas d'utilisation particulier, pour des messages très sensibles, pas sûr que ça soit viable pour de la conversation de tous les jours (encore une fois, question de ressources).
Dans tous les cas ces projets vont accuser un énorme retard sur XMPP, car il y a beaucoup de problèmes qui sont déjà réglés dans ce dernier, et qu'ils vont avoir. Et c'est souvent plus difficile quand il n'y a pas de serveur intermédiaire. Sans parler des fonctionnalités à implémenter (des trucs comme la correction du dernier message, l'état de discussion, la gestion des archives, des appareils multiples connectés en même temps, etc).
Tiens d'ailleurs XMPP est un cas particulier : c'est un réseau décentralisé « hybride », c'est à dire qu'il y a des serveurs intermédiaires mais il est capable de faire du P2P (j'ai un article à publier sur Jingle à ce sujet). On est aussi plusieurs à envisager à terme d'en faire un réseau entièrement pair à pair en regroupant serveur et client (optionnellement), ça ne se fera peut-être jamais, mais c'est techniquement possible (on peut déjà se passer de serveur en local).
[^] # Re: Ne pas jeter le bébé avec l'eau du bain
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Partage: de ownCloud (décentralisé) à Syncthing (distribué). Évalué à 5.
Oui il y a plusieurs questions à prendre en compte. Pour ma part je ne suis pas gêné d'avoir un serveur géré par une entité si j'ai confiance en elle (une assoce que je connais bien par exemple), mais même dans ce cas je chiffrerai de bout en bout les infos très sensibles (par exemple un mot de passe que je donne à quelqu'un). Pour faire un parallèle, j'ai très souvent laissé les clefs de chez moi à des inconnus (je suis sur des sites d'hospitalité comme BeWelcome).
Il y a aussi des questions écologiques (mutualiser les ressources sera toujours mieux de ce point de vue), d'entretien (en dehors du serveur pour ton logiciel lui même, la gestion des sauvegardes ou des risques d'intrusion ne vont a priori pas être géré par ton logiciel final, même s'il est entièrement P2P). Bref, c'est pas mal si une ou plusieurs personnes s'en occupent sérieusement. Je pense que le mieux est de permettre les 2 : mutualiser et si voulu autohébergement facile.
Tox j'ai essayé mais il y a plus d'un an, avec un des frontaux les plus communs (je ne sais plus lequel, peut-être Venom). J'avais apprécié la simplicité (en dehors du hash quasi inévitable, on lance est c'est OK), mais impossible d'avoir une vidéo fonctionnelle, et c'est pour ça que je voulais l'utiliser. À vrai dire même avec Jitsi j'ai pas eu des résultats très probants (pas essayé non plus depuis longtemps), et c'est encore Mumble qui me donne les meilleurs résultats, mais c'est audio uniquement. Il faut dire que je suis souvent dans des conditions mauvaises (pas de connexion directe, mauvais débit, etc).
Ring et Ricochet pas essayé, Ricochet leur technique pour couvrir le bruit semble intéressante, mais c'est un cas d'utilisation particulier, pour des messages très sensibles, pas sûr que ça soit viable pour de la conversation de tous les jours (encore une fois, question de ressources).
Dans tous les cas ces projets vont accuser un énorme retard sur XMPP, car il y a beaucoup de problèmes qui sont déjà réglés dans ce dernier, et qu'ils vont avoir. Et c'est souvent plus difficile quand il n'y a pas de serveur intermédiaire. Sans parler des fonctionnalités à implémenter (des trucs comme la correction du dernier message, l'état de discussion, la gestion des archives, des appareils multiples connectés en même temps, etc).
Tiens d'ailleurs XMPP est un cas particulier : c'est un réseau décentralisé « hybride », c'est à dire qu'il y a des serveurs intermédiaires mais il est capable de faire du P2P (j'ai un article à publier sur Jingle à ce sujet). On est aussi plusieurs à envisager à terme d'en faire un réseau entièrement pair à pair en regroupant serveur et client (optionnellement), ça ne se fera peut-être jamais, mais c'est techniquement possible (on peut déjà se passer de serveur en local).