L'auteur d'une œuvre peut en changer la licence, mais la licence d'origine peut évidemment toujours s'appliquer évidemment aux copies effectuées avant le changement de licence.
Ça c'est la théorie. En pratique il peut s'avérer difficile de prouver que la copie qu'on utilise a été faite AVANT le changement de licence.
C'est ainsi qu'on voit de temps en temps fleurir des forks libres issus d'anciennes versions de logiciels dont la nouvelle version est devenue propriétaire.
Je n'y connais rien alors ma question est peut-être idiote mais une photo libre est définitivement libre ou bien son auteur peut en changer la licence ?
Si oui, on n'éviterait pas la problématique que tu soulèves : comment prouver que la photo que nous utilisons est sous l’ancienne licence ?
Les photos en question sont classées dans une arborescence de type année/mois, ce qui représente au moins 60 répertoires. J'aimerais donc pouvoir lancer le script à la racine des répertoires d'années. D'un autre coté, j'imagine qu'on ne peut pas charger la barque de tblDng avec des milliers de noms de fichiers ?
La centralisation pose, entre autres, le problème de la confiance. Ce n'est pas parce que c'est libre que je fais confiance aux administrateurs.
Je ne vois pas le rapport avec la décentralisation : tu as toujours ton compte sur un serveur, géré par un administrateur auquel tu dois faire confiance.
Tu ne confonds pas avec solution distribuée (type Jami par exemple) ?
Je partage ton point de vue sur Matrix vs XMPP. Cependant, force est de reconnaître que le processus "idéal" de standardisation de XMPP induit une grande lenteur. L'alternative qui consiste à ré-inventer un protocole qui contient tout ce dont on a besoin (et une implémentation de référence pour un serveur et un client) puis à le proposer "out of the box" comme un nouveau standard ouvert va beaucoup plus vite. D'ailleurs, preuve pour moi que ce ne sont pas les bases techniques de XMPP qui seraient vieillissantes, c'est que certaines messageries propriétaires d'aujourd'hui sont parties d'une base XMPP et ça ne les a pas empêché d'avoir des fonctionnalités complètes et de conquérir une grosse part d'utilisateurs.
Comme le noyau Linux ? Je croyais que faire des monolithes, c'était mal :)
On parle d'un protocole, pas d'une implémentation, hein… Je n'ai rien contre la découpe en XEP, c'est le fait qu'elles soient optionnelles qui me paraît dommageable pour le succès de XMPP.
Pour avoir monté un serveur XMPP […] j'étais déjà à plus de 80% des tests de compliance.
Je parlais du protocole pas des implémentations et de leur configuration par défaut (dont tu confirmes toi-même qu'il manque quand même 20% dans une d'entre-elle et dont rien ne garantit que c'est celle qui va être choisie par l'administrateur du service).
Je persiste à penser que si le core du protocole XMPP incluait obligatoirement tout ce qu'on s'attend à trouver dans une messagerie moderne, on aurait moins d'implémentations (serveurs et clients) différentes formant la fédération et il y aurait moins de déceptions* de la part des utilisateurs qui pensaient trouver la solution pour un "whatsapp" plus respectueux de leurs données personnelles et qui marche "out of the box".
* même si celles-ci tendent à diminuer grâce aux nombreuses initiatives telles que joinjabber, snikket, quicksy, …
NB. C'est dommage mais le fait est que c'est souvent bien plus rapide de créer un protocole et l'implémentation de référence qui va avec, puis de proposer d'en faire un standard ou a minima de le rendre libre, que de construire ce protocole à plusieurs avec la nécessité d'un consensus à chaque étape. Et si en plus on rend optionnelle l'implémentation de ces étapes… C'est peut-être ce qui va faire que Matrix voire Jami vont réussir là où XMPP, pourtant parti bien avant et plein de qualités, ne va peut-être pas décoller.
Savoir que tes interlocuteurs ne sont pas capables de faire de l'A/V c'est bien mais ça ne résout pas mon problème si je veux communiquer avec eux. On en revient toujours au même point : comment convaincre quelqu'un de quitter whatsapp (ou consorts) si on n'est pas capable de lui assurer que la solution proposée inclut par défaut les services considérés comme le minimum requis pour faire de la messagerie ? Des initiatives comme joinjabber citée plus haut peuvent aider mais est-ce que ça sera suffisant pour compenser ce "défaut" (stratégique, pas technique) originel de XMPP : un core obligatoire minimaliste et une multitude d'options ?
Oui on peut avoir plusieurs terminaux avec le même compte , perso c'est sur smartphone Android, client lourd Linux et aussi client web (app.element.io).
Matrix peer to peer est présenté comme un Matrix "normal" du point de vue du client, c'est juste que le serveur est local sur le device. J'imagine donc que ton compte est sur ce serveur local. Si tu as plusieurs devices, avec chacun leur serveur local, comment ça peut être le même compte ?
Je me suis posé la même question mais j'ai tendance à rejeter "idéologiquement" Matrix pour avoir voulu ré-inventer ce qui existait déjà au lieu de contribuer à l'améliorer (y a t-il des raisons techniques empêchant d'implémenter des passerelles dans le cadre de XMPP ?).
Bon en fait j'attends la version swarm de jami ;-)
Moi aussi !
Je ne sais pas si Jami est mieux ou moins bien que XMPP, ni même si ça recouvre tout le domaine fonctionnel de XMPP (notamment des salons publics avec beaucoup de personnes) ou celui de Matrix (passerelles) mais au moins ils ne réinventent pas un énième standard qui fait la même chose que le précédent.
Ce serait formidablement utile d'avoir un lien vers des clients qui couvrent les principales plateformes utilisées, et garantissant entre eux texte, audio, vidéo […]
Il ne suffit pas qu'un client implémente les fonctionnalités souhaitées (texte, fichiers, appel A/V, …) il faut aussi que les serveurs concernés (le tien et ceux de tes contacts) les implémentent aussi.
Par ailleurs, il est vrai que XMMP permet de changer de client et/ou de serveur. Mais dans le cas d'un changement de serveur, comment ça se passe pour les données (conversations, fichiers), il y a une XEP qui décrit comment un serveur doit permettre de les exporter puis les réimporter ?
Peut-être une confusion avec l'anglicisme «cryptage» ?
Je dirais plutôt une confusion avec un autre sens de chiffrage assez courant (mais peut-être incorrect), par exemple : "chiffre-moi cet appel d'offres" = "dis-moi à quel prix on va proposer notre offre".
mais un autre moyen pour que la rencontre physique des correspondants apporte une précaution supplémentaire à l'avenir.
Jami est multi-devices pour un même compte et, d'un point de vue fonctionnel, ne permet pas à un contact de choisir/savoir à quel device de son correspondant il s'adresse (son correspondant peut lui en donner la possibilité s'il le souhaite en créant plusieurs comptes dédiés chacun à un device mais ils ne seront pas synchronisés entre eux).
Pour en revenir à l'aspect sécurité que tu évoques, il y a deux façons d'installer un compte déjà existant sur un nouveau device :
1) soit en le "reliant" (avec échange d'un code PIN) à un autre device ayant déjà le compte en question ; on est dans ce cas en principe sûr que cette nouvelle instance du compte est aussi "authentique" que l'autre (désolé si je n'ai pas le bon vocabulaire, je ne suis pas un spécialiste), C'est peut-être ça que tu as vu mais les contacts ne sont pas impliqués dans cette opération et une fois le compte installé sur le nouveau device, rien ne permet (au niveau de l'UI, du moins) aux contacts de les distinguer.
2) soit en "restaurant" une copie du compte (volée sur un des devices ayant ce compte installé ou bien sur une sauvegarde) => si cette copie est non chiffrée, on peut alors usurper l'identité, et le correspondant n'a aucun moyen de savoir que ce nouveau device est "illégitime". D'où la nécessité de protéger le fichier de compte sur chaque device via l'option "mot de passe" de Jami (ou via un chiffrement du système de fichiers sous-jacent). Ceci dit, il n'y a rien de spécifique à Jami si ce n'est que comme il n'y a pas de serveur central, il semble difficile d'avertir le titulaire qu'un nouveau device s'est connecté sur le compte comme le font de nombreux services cloud.
Si mes souvenirs sont bons le QR code dans Jami, représente l'adresse mais aussi certifie un équipement pour cette adresse.
Pour autant que je puisse en juger à l’œil, les QR codes sur mon PC et de mon smartphone sont identiques. Fort heureusement d'ailleurs, car je me verrais mal d'avoir à donner autant d'identifiants que d'appareils sur lesquels j'utilise un même compte Jami !
Pour les autres problèmes évoqués sur Jami, je n'ai pas cette mauvaise expérience mais mon utilisation est pour le moment très restreinte ; un seul correspondant. Ceci dit, même si je considère que Jami fonctionne bien pour mon usage limité, ça reste un projet en plein développement avec une nouveauté importante (les groupes) qui induit de nombreux changements, notamment sur la synchronisation des messages (y compris sur les conversations 1-1 puisque ces dernières s'effectueront aussi dans le cadre technique d'un groupe).
Un point important avec Jami : c'est du distribué, pas du décentralisé => il n'y a pas de serveur intermédiaire => il est impossible pour Jami d'envoyer un message si le destinataire n'est pas connecté ; il le prend en compte localement et je suppose qu'il réessaie périodiquement mais il est possible que dans le cas d'un fichier, il se contente de refuser immédiatement, d'où peut-être le "pair injoignable". Par ailleurs, à l'arrivée, la version Android de Jami utilise le système de push de Google, ce qui n'est pas le cas de la version F-Droid, ça peut aussi expliquer des différences de comportement (un bug sur une version et pas sur l'autre).
Bref, pour moi, Jami reste la cible "idéale" mais pour ceux qui veulent une solution aujourd'hui et maintenant, il vaut mieux faire un autre choix (XMPP a ma préférence idéologique sur Matrix).
Mais une autre conséquence moins intéressante est que si tu lourdes ton mot de passe, il n'y a aucun moyen de le récupérer.
Non, ça n'a rien à voir. En fait ni la création d'un identifiant "lisible", ni le mot de passe du compte ne sont obligatoires. L'identifiant "lisible", c'est juste parce que c'est plus rassurant/facile de donner à tes contacts un identifiant qu'une UID telle que 0a13d5f52cc003c0gfc37297e52dfxd3678eb8ef. Le mot de passe, c'est pour chiffrer ton compte (c'est-à-dire, principalement, ta clé privée) sur ton device. Si ton device est déjà chiffré (c'est le cas pour un smartphone, en général), ce n'est pas forcément nécessaire.
Mais même si tu perds le mot de passe d'un compte chiffré sur un device, rien n'est perdu : il suffit de conserver une version non chiffrée du compte dans un endroit sûr et de restaurer le compte sur le device à partir de cette version non chiffrée.
ils ne peuvent pas vérifier ton identité autrement qu'en te voyant connecté.
Il n'y a pas de "ils" : aucun serveur ne vérifie ton identité. Celle-ci est assurée par l'UID, statistiquement unique, que tu as communiqué à tes contacts (soit directement, soit via l'identifiant "lisible" qui lui a été optionnellement associé dans la blockchain Euthereum). Et personne ne peut usurper cette identité sans être en possession d'une copie du compte qui correspond à cet UID (d'où l'intérêt de le protéger en le chiffrant sur les devices non sûr).
[^] # Re: libre un jour, libre toujours ?
Posté par mahikeulbody . En réponse à la dépêche Tour d'horizon des images libres (et pas libres). Évalué à 6.
Ça c'est la théorie. En pratique il peut s'avérer difficile de prouver que la copie qu'on utilise a été faite AVANT le changement de licence.
Tu forkes une photo comment ?
# libre un jour, libre toujours ?
Posté par mahikeulbody . En réponse à la dépêche Tour d'horizon des images libres (et pas libres). Évalué à 9.
Je n'y connais rien alors ma question est peut-être idiote mais une photo libre est définitivement libre ou bien son auteur peut en changer la licence ?
Si oui, on n'éviterait pas la problématique que tu soulèves : comment prouver que la photo que nous utilisons est sous l’ancienne licence ?
[^] # Re: Pour ajouter un grain de shell dash (sh)
Posté par mahikeulbody . En réponse au message Suppression d'un fichier raw si et seulement si le fichier jpg de même préfixe existe. Évalué à 2.
Je dois avoir les deux shells installés car les deux commandes marchent (je suis Manjaro/KDE).
[^] # Re: avec le shell bash
Posté par mahikeulbody . En réponse au message Suppression d'un fichier raw si et seulement si le fichier jpg de même préfixe existe. Évalué à 2.
Merci !
[^] # Re: avec le shell bash
Posté par mahikeulbody . En réponse au message Suppression d'un fichier raw si et seulement si le fichier jpg de même préfixe existe. Évalué à 3.
Merci !
[^] # Re: bashisme
Posté par mahikeulbody . En réponse au message Suppression d'un fichier raw si et seulement si le fichier jpg de même préfixe existe. Évalué à 2.
Ça marche, merci !
[^] # Re: avec le shell bash
Posté par mahikeulbody . En réponse au message Suppression d'un fichier raw si et seulement si le fichier jpg de même préfixe existe. Évalué à 2.
Il y a un moyen de rendre ça récursif ?
Les photos en question sont classées dans une arborescence de type année/mois, ce qui représente au moins 60 répertoires. J'aimerais donc pouvoir lancer le script à la racine des répertoires d'années. D'un autre coté, j'imagine qu'on ne peut pas charger la barque de
tblDngavec des milliers de noms de fichiers ?[^] # Re: avec le shell bash
Posté par mahikeulbody . En réponse au message Suppression d'un fichier raw si et seulement si le fichier jpg de même préfixe existe. Évalué à 2. Dernière modification le 18 février 2021 à 15:51.
Ça marche, merci !
Merci également aux autres pour leurs variantes.
[^] # Re: bashisme
Posté par mahikeulbody . En réponse au message Suppression d'un fichier raw si et seulement si le fichier jpg de même préfixe existe. Évalué à 2.
(J'ai ajouté un " manquant dans la ligne
echo "pas de fichier jpg pour ${FICHIER})Ça me dit :
pas de fichier jpg pour ./a.raw
pas de fichier jpg pour ./b.raw
pas de fichier jpg pour ./c.raw
ce qui n'est vrai que pour c.raw.
[^] # Re: À décomposer
Posté par mahikeulbody . En réponse au message Suppression d'un fichier raw si et seulement si le fichier jpg de même préfixe existe. Évalué à 2.
Merci d'avoir pris la peine de répondre.
J'ai essayé ton script sur cet exemple :
a.jpg a.raw b.jpg b.raw c.rawj'obtiens cette liste de fichiers à supprimer :
./a.jpg
./b.jpg
./c.jpg
alors que dans cet exemple, il ne faut supprimer que a.raw et b.raw (mais pas c.raw car il n'existe pas de c/jpg).
J'ai raté quelque chose ?
[^] # Re: Configuration serveur et écosystème de clients
Posté par mahikeulbody . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 2.
Je ne vois pas le rapport avec la décentralisation : tu as toujours ton compte sur un serveur, géré par un administrateur auquel tu dois faire confiance.
Tu ne confonds pas avec solution distribuée (type Jami par exemple) ?
[^] # Re: Configuration serveur et écosystème de clients
Posté par mahikeulbody . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 3.
Je partage ton point de vue sur Matrix vs XMPP. Cependant, force est de reconnaître que le processus "idéal" de standardisation de XMPP induit une grande lenteur. L'alternative qui consiste à ré-inventer un protocole qui contient tout ce dont on a besoin (et une implémentation de référence pour un serveur et un client) puis à le proposer "out of the box" comme un nouveau standard ouvert va beaucoup plus vite. D'ailleurs, preuve pour moi que ce ne sont pas les bases techniques de XMPP qui seraient vieillissantes, c'est que certaines messageries propriétaires d'aujourd'hui sont parties d'une base XMPP et ça ne les a pas empêché d'avoir des fonctionnalités complètes et de conquérir une grosse part d'utilisateurs.
[^] # Re: EDF n'est pas un industriel
Posté par mahikeulbody . En réponse au journal Hercule démantèlera-t-il l'électricité de France. Évalué à 4.
Le palier N4 est de conception "purement française", selon wikipedia (soit 4 x 1450 MW).
[^] # Re: Matrix vs XMPP
Posté par mahikeulbody . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 3. Dernière modification le 02 février 2021 à 10:28.
On parle d'un protocole, pas d'une implémentation, hein… Je n'ai rien contre la découpe en XEP, c'est le fait qu'elles soient optionnelles qui me paraît dommageable pour le succès de XMPP.
Je parlais du protocole pas des implémentations et de leur configuration par défaut (dont tu confirmes toi-même qu'il manque quand même 20% dans une d'entre-elle et dont rien ne garantit que c'est celle qui va être choisie par l'administrateur du service).
Je persiste à penser que si le core du protocole XMPP incluait obligatoirement tout ce qu'on s'attend à trouver dans une messagerie moderne, on aurait moins d'implémentations (serveurs et clients) différentes formant la fédération et il y aurait moins de déceptions* de la part des utilisateurs qui pensaient trouver la solution pour un "whatsapp" plus respectueux de leurs données personnelles et qui marche "out of the box".
* même si celles-ci tendent à diminuer grâce aux nombreuses initiatives telles que joinjabber, snikket, quicksy, …
NB. C'est dommage mais le fait est que c'est souvent bien plus rapide de créer un protocole et l'implémentation de référence qui va avec, puis de proposer d'en faire un standard ou a minima de le rendre libre, que de construire ce protocole à plusieurs avec la nécessité d'un consensus à chaque étape. Et si en plus on rend optionnelle l'implémentation de ces étapes… C'est peut-être ce qui va faire que Matrix voire Jami vont réussir là où XMPP, pourtant parti bien avant et plein de qualités, ne va peut-être pas décoller.
[^] # Re: Matrix vs XMPP
Posté par mahikeulbody . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 4. Dernière modification le 01 février 2021 à 20:56.
Savoir que tes interlocuteurs ne sont pas capables de faire de l'A/V c'est bien mais ça ne résout pas mon problème si je veux communiquer avec eux. On en revient toujours au même point : comment convaincre quelqu'un de quitter whatsapp (ou consorts) si on n'est pas capable de lui assurer que la solution proposée inclut par défaut les services considérés comme le minimum requis pour faire de la messagerie ? Des initiatives comme joinjabber citée plus haut peuvent aider mais est-ce que ça sera suffisant pour compenser ce "défaut" (stratégique, pas technique) originel de XMPP : un core obligatoire minimaliste et une multitude d'options ?
[^] # Re: Mauvaise question...
Posté par mahikeulbody . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 2.
Les analogies, c'est bien pour aider à faire comprendre, mais ça a de sérieuses limites quand il s'agit de s'en servir pour démontrer.
[^] # Re: XMPP ou Matrix ?
Posté par mahikeulbody . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 2.
Matrix peer to peer est présenté comme un Matrix "normal" du point de vue du client, c'est juste que le serveur est local sur le device. J'imagine donc que ton compte est sur ce serveur local. Si tu as plusieurs devices, avec chacun leur serveur local, comment ça peut être le même compte ?
[^] # Re: XMPP ou Matrix ?
Posté par mahikeulbody . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 4.
Le serveur de référence de Matrix est réputé super consommateur de ressources, ça va le faire sur un smartphone ?
De plus, est-ce que cette solution permettra d'avoir plusieurs devices reliés au même compte (comme le permet Jami) ?
[^] # Re: XMPP ou Matrix ?
Posté par mahikeulbody . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 7.
Je me suis posé la même question mais j'ai tendance à rejeter "idéologiquement" Matrix pour avoir voulu ré-inventer ce qui existait déjà au lieu de contribuer à l'améliorer (y a t-il des raisons techniques empêchant d'implémenter des passerelles dans le cadre de XMPP ?).
Moi aussi !
Je ne sais pas si Jami est mieux ou moins bien que XMPP, ni même si ça recouvre tout le domaine fonctionnel de XMPP (notamment des salons publics avec beaucoup de personnes) ou celui de Matrix (passerelles) mais au moins ils ne réinventent pas un énième standard qui fait la même chose que le précédent.
[^] # Re: Configuration serveur et écosystème de clients
Posté par mahikeulbody . En réponse à la dépêche Messagerie instantanée : ce n’est pas une question d’applications. Évalué à 4.
Il ne suffit pas qu'un client implémente les fonctionnalités souhaitées (texte, fichiers, appel A/V, …) il faut aussi que les serveurs concernés (le tien et ceux de tes contacts) les implémentent aussi.
Par ailleurs, il est vrai que XMMP permet de changer de client et/ou de serveur. Mais dans le cas d'un changement de serveur, comment ça se passe pour les données (conversations, fichiers), il y a une XEP qui décrit comment un serveur doit permettre de les exporter puis les réimporter ?
[^] # Re: Vous avez oublié movim !
Posté par mahikeulbody . En réponse au sondage Quel est selon vous le client XMPP à l'interface la plus adaptée pour une équipe soudée de gens inconnus?. Évalué à 3.
Je dirais plutôt une confusion avec un autre sens de chiffrage assez courant (mais peut-être incorrect), par exemple : "chiffre-moi cet appel d'offres" = "dis-moi à quel prix on va proposer notre offre".
[^] # Re: Pourquoi ne pas passer sur un vrai réseau décentralisé éprouvé ?
Posté par mahikeulbody . En réponse au journal Signal la bonne alternative à Whatsapp ?. Évalué à 3.
Jami est multi-devices pour un même compte et, d'un point de vue fonctionnel, ne permet pas à un contact de choisir/savoir à quel device de son correspondant il s'adresse (son correspondant peut lui en donner la possibilité s'il le souhaite en créant plusieurs comptes dédiés chacun à un device mais ils ne seront pas synchronisés entre eux).
Pour en revenir à l'aspect sécurité que tu évoques, il y a deux façons d'installer un compte déjà existant sur un nouveau device :
1) soit en le "reliant" (avec échange d'un code PIN) à un autre device ayant déjà le compte en question ; on est dans ce cas en principe sûr que cette nouvelle instance du compte est aussi "authentique" que l'autre (désolé si je n'ai pas le bon vocabulaire, je ne suis pas un spécialiste), C'est peut-être ça que tu as vu mais les contacts ne sont pas impliqués dans cette opération et une fois le compte installé sur le nouveau device, rien ne permet (au niveau de l'UI, du moins) aux contacts de les distinguer.
2) soit en "restaurant" une copie du compte (volée sur un des devices ayant ce compte installé ou bien sur une sauvegarde) => si cette copie est non chiffrée, on peut alors usurper l'identité, et le correspondant n'a aucun moyen de savoir que ce nouveau device est "illégitime". D'où la nécessité de protéger le fichier de compte sur chaque device via l'option "mot de passe" de Jami (ou via un chiffrement du système de fichiers sous-jacent). Ceci dit, il n'y a rien de spécifique à Jami si ce n'est que comme il n'y a pas de serveur central, il semble difficile d'avertir le titulaire qu'un nouveau device s'est connecté sur le compte comme le font de nombreux services cloud.
[^] # Re: Pourquoi ne pas passer sur un vrai réseau décentralisé éprouvé ?
Posté par mahikeulbody . En réponse au journal Signal la bonne alternative à Whatsapp ?. Évalué à 4. Dernière modification le 27 janvier 2021 à 09:49.
Pour autant que je puisse en juger à l’œil, les QR codes sur mon PC et de mon smartphone sont identiques. Fort heureusement d'ailleurs, car je me verrais mal d'avoir à donner autant d'identifiants que d'appareils sur lesquels j'utilise un même compte Jami !
Pour les autres problèmes évoqués sur Jami, je n'ai pas cette mauvaise expérience mais mon utilisation est pour le moment très restreinte ; un seul correspondant. Ceci dit, même si je considère que Jami fonctionne bien pour mon usage limité, ça reste un projet en plein développement avec une nouveauté importante (les groupes) qui induit de nombreux changements, notamment sur la synchronisation des messages (y compris sur les conversations 1-1 puisque ces dernières s'effectueront aussi dans le cadre technique d'un groupe).
Un point important avec Jami : c'est du distribué, pas du décentralisé => il n'y a pas de serveur intermédiaire => il est impossible pour Jami d'envoyer un message si le destinataire n'est pas connecté ; il le prend en compte localement et je suppose qu'il réessaie périodiquement mais il est possible que dans le cas d'un fichier, il se contente de refuser immédiatement, d'où peut-être le "pair injoignable". Par ailleurs, à l'arrivée, la version Android de Jami utilise le système de push de Google, ce qui n'est pas le cas de la version F-Droid, ça peut aussi expliquer des différences de comportement (un bug sur une version et pas sur l'autre).
Bref, pour moi, Jami reste la cible "idéale" mais pour ceux qui veulent une solution aujourd'hui et maintenant, il vaut mieux faire un autre choix (XMPP a ma préférence idéologique sur Matrix).
[^] # Re: Amidon
Posté par mahikeulbody . En réponse au journal de l'art et la manière de faire du gratin dauphinois. Évalué à 6.
Je suis grenoblois depuis 40 ans mais il aura fallu que je fréquente linuxfr pour enfin prendre conscience de cette évidence toute simple !
[^] # Re: Alternatives
Posté par mahikeulbody . En réponse au journal Signal la bonne alternative à Whatsapp ?. Évalué à 3. Dernière modification le 22 janvier 2021 à 08:08.
Non, ça n'a rien à voir. En fait ni la création d'un identifiant "lisible", ni le mot de passe du compte ne sont obligatoires. L'identifiant "lisible", c'est juste parce que c'est plus rassurant/facile de donner à tes contacts un identifiant qu'une UID telle que 0a13d5f52cc003c0gfc37297e52dfxd3678eb8ef. Le mot de passe, c'est pour chiffrer ton compte (c'est-à-dire, principalement, ta clé privée) sur ton device. Si ton device est déjà chiffré (c'est le cas pour un smartphone, en général), ce n'est pas forcément nécessaire.
Mais même si tu perds le mot de passe d'un compte chiffré sur un device, rien n'est perdu : il suffit de conserver une version non chiffrée du compte dans un endroit sûr et de restaurer le compte sur le device à partir de cette version non chiffrée.
Il n'y a pas de "ils" : aucun serveur ne vérifie ton identité. Celle-ci est assurée par l'UID, statistiquement unique, que tu as communiqué à tes contacts (soit directement, soit via l'identifiant "lisible" qui lui a été optionnellement associé dans la blockchain Euthereum). Et personne ne peut usurper cette identité sans être en possession d'une copie du compte qui correspond à cet UID (d'où l'intérêt de le protéger en le chiffrant sur les devices non sûr).