Sur le principe, voilà qui serait fort intéressant : obliger les compagnies à pratiquer une interopérabilité minimale. Dans la pratique, ce genre de législation a-t-il vraiment une chance de fonctionner ? Nonobstant même les réticences d'opérateurs intéressés à l'enfermement de leurs utilisateurs, n'y aurait-il pas des difficultés techniques majeures à résoudre pour produire une réelle interopérabilité ?
Posté par inkey .
Évalué à 3.
Dernière modification le 26 mars 2022 à 08:35.
Pour connaître un peu un protocole comme XMPP et le principe de passerelle, j'ai pas l'impression qu'il y ai de grosses contraintes techniques pour faire transiter la messagerie simple.Exemple: https://spectrum.im/documentation/about.html. Et je ne crois pas qu'un gros service de messagerie ai une architecture spécialement distruptive (genre du p2p systématique). Là ou ça peut vraiment devenir vraiment coûteux voir impossible à rendre interopérable, je pense, c'est pour le chiffrement bout en bout ou l'audio/vidéo vu les histoire de codecs, etc.
Mais c'est que mon impression, il est fort possible que quelque-chose m'échappe et que ça soit infiniment plus compliqué.
Feux Facebook Messenger (je présume vu que l'entreprise tente plutôt de pousser Whatsapp mais peut-être que ça survivra) et Google Talk (qui a fait place à Hangout qui est en train de virer à autre chose) par exemple (et il y en a plein d'autres comme ça) ont bien utilisé XMPP à un moment, preuve que ça marche ou peut marcher… Mais une fois qu'ils estiment avoir assez de poids (de compte dans leur réseau, chez eux) ça commence à saboter l'interopérabilité puis par la supprimer. Assurément le problème n'est pas technique (au pire il leur suffirait d'ouvrir les specs de leur proto qui est si bien et mieux pour que d'autres puissent se joindre à eux pour un monde meilleur.) Il faut arrêter de gober ou servir l'excuse technique alors qu'il s'agit purement de choix idéologiques et financiers.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Je vois une différence assez nette entre avoir un protocole ouvert et pouvoir s'interconnecté avec d'autres protocoles conçu différemment de façon convenable. Du coup, je ne pense pas que rendre le protocole ouvert suffit forcément, des ajustements du protocole même peuvent être nécessaire. Cela dit c'est peut être l'occasion rêver pour avoir une réelle standardisation.
Ce n'est pas faux. Je pointais surtout du doigt le fait qu'au lieu d'aller dans le sens de la standardisation, la tendance était plutôt de s'enfermer et de rompre l'interopérabilité de trucs ouverts (puis de crier que ça marche pas…)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Je vois une différence assez nette entre avoir un protocole ouvert et pouvoir s'interconnecté avec d'autres protocoles conçu différemment de façon convenable.
Justement, l'interconnexion peut tout à fait se passer avec le protocole ouvert. En fait XMPP a une partie qui concerne la connexion serveur-client et une partie serveur-serveur. Un réseau propriétaire peut tout à fait se contenter d'implémenter la partie serveur-serveur (ce ne serait même pas une réimplémentation puisque cette partie n'existe en général pas, comme il n'y a pas encore d'intéropérabilité pour l'instant).
Donc en gros, on s'en fiche comment (cad avec quel protocole) Facebook ou iMessage envoie un message à un usager du-dit service. Et on leur demande pas de changer cela, ni à utiliser XMPP. Par contre, si l'usager de Facebook veut envoyer un message à un autre sur iMessage ou sur un serveur XMPP, ou tout autre service, la connexion entre le serveur du service 1 et 2 pourrait se faire dans un protocole standardisé (par exemple donc XMPP).
Soit:
Alice—[communication proprio] --> Serveur d'Alice—[XMPP] --> Serveur de Bob—[communication proprio] --> Bob
En fait à la belle époque de XMPP, celle où j'étais moi-même membre de la XSF et qu'on croyait que c'était la bonne (y a plus de 10 ans), plusieurs services proprios avaient fait des expériences de telles interconnexions en XMPP. De mémoire (dites moi si je me plante), y avait AIM, ICQ qui testaient l'intéropérabilité avec XMPP, et je crois même qu'à un moment Microsoft avait testé une intéropérabilité sur MSN. Je me souviens que c'était l'époque marrante où certains geeks s'amusaient à scanner des ports sur des domaines de grosses entreprises IT qui avaient leur propre réseau de messagerie puis venaient annoncer joyeusement sur une liste de la XSF "j'ai trouvé un serveur qui répond avec un en-tête XMPP!". On ne s'attendait pas forcément à ce qu'aucun de ces services propriétaires (surtout ceux qui étaient les plus anciens) utilisent XMPP en protocole client-serveur. Mais avoir un unique protocole de communication en serveur-serveur suffirait pour une vraie intéropérabilité.
À l'époque, on y a vraiment cru, on a failli l'avoir notre intéropérabilité. Puis soudain, tout s'est effondré super rapidement, tout le monde s'est retiré du jeu, a arrêté ses expérimentations, ceux qui utilisaient XMPP (même en client-serveur pour le coup, et déjà en serveur-serveur) ont décidé de se refermer sur eux-même parce qu'ils étaient sûr d'y gagner (les idiots! Quand on voit le succès inexistant qu'ils ont eu en faisant cela… on pense à toi, Google, notamment! Où en sont-ils maintenant dans l'usage de leur solution? Ils sont surtout tous là à se faire la guerre).
Donc si cette intéropérabilité peut être forcée par une loi européenne, oui, 100 fois oui. De même heureusement que les téléphones ne sont pas limités par opérateurs, ou internet par fournisseur d'accès (on a failli l'avoir celui-là pour qui se rappelle les débuts de l'internet commercial!). Et pour ça, ça veut dire clairement avoir un protocole ouvert et unique imposé pour la partie serveur-serveur au moins (client-serveur, ce serait mieux, car ça permettrait de pouvoir utiliser le client de son choix quel que soit l'opérateur, de même qu'on peut utiliser le client email de son choix; mais à la limite si certains services veulent se tirer des balles dans le pied, tant que moi, je peux contacter les clients de ces services, ça me va!). Et bien entendu, je pense que XMPP serait le bon choix si on voulait choisir un tel protocole unique.
Par contre si ça en vient juste à ce que chaque service fournisse une spec semi-ouverte, semi-complète pour son protocole propriétaire, ou pire des APIs quelconques (probablement avec des "tokens" de connexion à réclamer au cas par cas), imposant que chaque service fasse du développement spécifique pour chaque autre service, alors franchement c'est juste une impasse de plus.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je te confirme que tu as bonne mémoire pour AIM d'AOL, je ne sais plus pour ICQ de Mirabilis.
Je confirme aussi que Google a été moteur (probablement ce qui a motivé d'autres à faire des expérimentations ?) et a contribué Jingle (si j'ai bonne mémoire) puis s'est effectivement suicidé. Bizarrement, les autres ne veulent pas en tirer les bonnes leçons…
Pour le dernier point (sur les specs des autres services) tu soulèves un point crucial que je n'avais pas anticipé. En tout cas, pour la partie technique, XMPP permet déjà d'être concrètement et réellement interopérable et le reste n'est qu'excuses…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Posté par Krunch (site web personnel) .
Évalué à 4.
Dernière modification le 27 mars 2022 à 13:42.
D'un point de vue technique, il y a quand même l'aspect gestion du spam qui est quand même vachement plus facile sur un réseau fermé. De manière générale, je suis d'accord que c'est pas une excuse suffisante mais c'est pas trivial non plus.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Je ne comprends pas ton propos, peux-tu l'expliciter ?
S'il y a plusieurs réseaux "fermés" (sur inscription, c'est comme cela que je comprends le terme ?) interconnectés, chacun modérant ses inscrits, en quoi est-ce plus compliqué ? Je dirais l'inverse pour ma part ?
Si Facebook a un problème de spam avec ses utilisateurs, ils peuvent facilement fermer les comptes concernés et mettre en place des restrictions plus ou moins adéquates pour les nouveaux comptes. Si Facebook a un problème de spam avec des utilisateurs de « petits » opérateurs tiers, c'est plus compliqué/délicat à gérer puisqu'ils n'ont pas de contrôle à l'inscription, peu de visibilité sur les comptes eux-mêmes et plus de risque de faux positifs lors du bloquage.
Suffit de voir le nombre de petits opérateurs qui ont des problèmes pour envoyer des mails à des adresses gmail. C'est pas juste parce que Google veut pas faire d'effort. Dans ce cas c'est plutôt dans leur intérêt que les e-mails circulent bien tant que leurs utilisateurs sont pas spammés. C'est surtout que techniquement c'est compliqué d'atteindre ces deux buts à la fois.
Encore une fois, je pense pas que ça soit une raison suffisante pour éviter l'interopérabilité mais c'est pas techniquement trivial.
Le documentaire que tu mentionnes semble plus parler de groupes d'incitation à la haine, ce qui est un problème différent du spam et les solutions / motivations de l'un ne sont pas forcément les solutions / motivations de l'autre.
Je travaille chez Google mais pas sur gmail ou autre système de messagerie. Je ne représente pas la société sur ce site. Ce message n'engage que moi.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Pourtant l'expérience montre que les grandes plateformes ne parviennent à modérer efficacement (trop ou pas assez), dépassés qu'ils sont par leur taille probablement ?
Alors que la question de la modération d'un réseau fédéré à grande échelle, avec de multiples autorités, reste à expérimenter.
Il est étrange de mettre en balance un risque potentiel avec un risque avéré, et de faire primer le 1er, non ?
J'ajoute que j'aurais plus confiance d'être sur un réseau fédéré modéré par une entité dont les valeurs me conviennent que sur celui d'un géant dont l'objet est de faire des profits quitte à promouvoir les contenus agressifs, polémiques ou plus généralement violents
Le risque de spam me semble tout à fait avéré. De ce que j'en vois, la modération du spam et du contenu incitant à la haine sont des problème très différents.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Alors que la question de la modération d'un réseau fédéré à grande échelle, avec de multiples autorités, reste à expérimenter.
Ça a été testé avec Mastodon (et encore, pour une définition de grande échelle pas trop grande), je ne dirais pas que ça c'est bien passé, puise que la solution a été de banir certains serveur depuis d'autres serveur. C'est aussi ce qui se passe avec le mail, n'importe qui peut en envoyer, au final, tu ne peux faire confiance à aucun serveur et tu te retrouve avec des règles arbitraires et débiles.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Note que si ton service centralisé est suffisamment grand, tu te retrouves aussi avec des règles arbitraires et débiles. Mais peut-être un peu moins et il est relativement plus facile de les corriger (mais aucun utilisateur ne peut les éviter).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
La gestion du spam est fondamentalement plus compliquée sur un réseau fédéré mais il y a aussi tout l'aspect évolution qui est fortement ralenti comme expliqué ici : https://lwn.net/Articles/687294/
Je pense pas que ça soit non plus une excuse suffisante pour éviter la fédération des grands réseaux de messagerie mais ça démontre que c'est pas anodin non plus comme changement.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
n'y aurait-il pas des difficultés techniques majeures à résoudre pour produire une réelle interopérabilité ?
Si j'étais fournisseur du service de messagerie Fesseboob à plusieurs millions d'abonnés, je me dépêcherais de fournir une API :
à Alice de générer un jeton qui donne le droit de lui envoyer des messages ;
Alice donne le jeton à Bob ;
Bob entre le jeton dans son autre messagerie Buttslap ;
Lors que Bob veut envoyer un message à Alice, Buttslap appelle https://fesseboob.ie/sendMessage avec le jeton, le message et la photo de son chat en paramètre.
Une fois cette API devenue un standard de fait, je mettrais en place la fondation OpenAssMessaging qui définit les appels http avec une RFC de 42000 pages et vends des certifications à 8000€ la semaine.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Et techniquement ?
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 3.
Sur le principe, voilà qui serait fort intéressant : obliger les compagnies à pratiquer une interopérabilité minimale. Dans la pratique, ce genre de législation a-t-il vraiment une chance de fonctionner ? Nonobstant même les réticences d'opérateurs intéressés à l'enfermement de leurs utilisateurs, n'y aurait-il pas des difficultés techniques majeures à résoudre pour produire une réelle interopérabilité ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Et techniquement ?
Posté par inkey . Évalué à 3. Dernière modification le 26 mars 2022 à 08:35.
Pour connaître un peu un protocole comme XMPP et le principe de passerelle, j'ai pas l'impression qu'il y ai de grosses contraintes techniques pour faire transiter la messagerie simple.Exemple: https://spectrum.im/documentation/about.html. Et je ne crois pas qu'un gros service de messagerie ai une architecture spécialement distruptive (genre du p2p systématique). Là ou ça peut vraiment devenir vraiment coûteux voir impossible à rendre interopérable, je pense, c'est pour le chiffrement bout en bout ou l'audio/vidéo vu les histoire de codecs, etc.
Mais c'est que mon impression, il est fort possible que quelque-chose m'échappe et que ça soit infiniment plus compliqué.
[^] # Re: Et techniquement ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 10.
Feux Facebook Messenger (je présume vu que l'entreprise tente plutôt de pousser Whatsapp mais peut-être que ça survivra) et Google Talk (qui a fait place à Hangout qui est en train de virer à autre chose) par exemple (et il y en a plein d'autres comme ça) ont bien utilisé XMPP à un moment, preuve que ça marche ou peut marcher… Mais une fois qu'ils estiment avoir assez de poids (de compte dans leur réseau, chez eux) ça commence à saboter l'interopérabilité puis par la supprimer. Assurément le problème n'est pas technique (au pire il leur suffirait d'ouvrir les specs de leur proto qui est si bien et mieux pour que d'autres puissent se joindre à eux pour un monde meilleur.) Il faut arrêter de gober ou servir l'excuse technique alors qu'il s'agit purement de choix idéologiques et financiers.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Et techniquement ?
Posté par inkey . Évalué à 3.
Je vois une différence assez nette entre avoir un protocole ouvert et pouvoir s'interconnecté avec d'autres protocoles conçu différemment de façon convenable. Du coup, je ne pense pas que rendre le protocole ouvert suffit forcément, des ajustements du protocole même peuvent être nécessaire. Cela dit c'est peut être l'occasion rêver pour avoir une réelle standardisation.
[^] # Re: Et techniquement ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
Ce n'est pas faux. Je pointais surtout du doigt le fait qu'au lieu d'aller dans le sens de la standardisation, la tendance était plutôt de s'enfermer et de rompre l'interopérabilité de trucs ouverts (puis de crier que ça marche pas…)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Et techniquement ?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 26 mars 2022 à 15:58.
Justement, l'interconnexion peut tout à fait se passer avec le protocole ouvert. En fait XMPP a une partie qui concerne la connexion serveur-client et une partie serveur-serveur. Un réseau propriétaire peut tout à fait se contenter d'implémenter la partie serveur-serveur (ce ne serait même pas une réimplémentation puisque cette partie n'existe en général pas, comme il n'y a pas encore d'intéropérabilité pour l'instant).
Donc en gros, on s'en fiche comment (cad avec quel protocole) Facebook ou iMessage envoie un message à un usager du-dit service. Et on leur demande pas de changer cela, ni à utiliser XMPP. Par contre, si l'usager de Facebook veut envoyer un message à un autre sur iMessage ou sur un serveur XMPP, ou tout autre service, la connexion entre le serveur du service 1 et 2 pourrait se faire dans un protocole standardisé (par exemple donc XMPP).
Soit:
Alice—[communication proprio] --> Serveur d'Alice—[XMPP] --> Serveur de Bob—[communication proprio] --> Bob
En fait à la belle époque de XMPP, celle où j'étais moi-même membre de la XSF et qu'on croyait que c'était la bonne (y a plus de 10 ans), plusieurs services proprios avaient fait des expériences de telles interconnexions en XMPP. De mémoire (dites moi si je me plante), y avait AIM, ICQ qui testaient l'intéropérabilité avec XMPP, et je crois même qu'à un moment Microsoft avait testé une intéropérabilité sur MSN. Je me souviens que c'était l'époque marrante où certains geeks s'amusaient à scanner des ports sur des domaines de grosses entreprises IT qui avaient leur propre réseau de messagerie puis venaient annoncer joyeusement sur une liste de la XSF "j'ai trouvé un serveur qui répond avec un en-tête XMPP!". On ne s'attendait pas forcément à ce qu'aucun de ces services propriétaires (surtout ceux qui étaient les plus anciens) utilisent XMPP en protocole client-serveur. Mais avoir un unique protocole de communication en serveur-serveur suffirait pour une vraie intéropérabilité.
À l'époque, on y a vraiment cru, on a failli l'avoir notre intéropérabilité. Puis soudain, tout s'est effondré super rapidement, tout le monde s'est retiré du jeu, a arrêté ses expérimentations, ceux qui utilisaient XMPP (même en client-serveur pour le coup, et déjà en serveur-serveur) ont décidé de se refermer sur eux-même parce qu'ils étaient sûr d'y gagner (les idiots! Quand on voit le succès inexistant qu'ils ont eu en faisant cela… on pense à toi, Google, notamment! Où en sont-ils maintenant dans l'usage de leur solution? Ils sont surtout tous là à se faire la guerre).
Donc si cette intéropérabilité peut être forcée par une loi européenne, oui, 100 fois oui. De même heureusement que les téléphones ne sont pas limités par opérateurs, ou internet par fournisseur d'accès (on a failli l'avoir celui-là pour qui se rappelle les débuts de l'internet commercial!). Et pour ça, ça veut dire clairement avoir un protocole ouvert et unique imposé pour la partie serveur-serveur au moins (client-serveur, ce serait mieux, car ça permettrait de pouvoir utiliser le client de son choix quel que soit l'opérateur, de même qu'on peut utiliser le client email de son choix; mais à la limite si certains services veulent se tirer des balles dans le pied, tant que moi, je peux contacter les clients de ces services, ça me va!). Et bien entendu, je pense que XMPP serait le bon choix si on voulait choisir un tel protocole unique.
Par contre si ça en vient juste à ce que chaque service fournisse une spec semi-ouverte, semi-complète pour son protocole propriétaire, ou pire des APIs quelconques (probablement avec des "tokens" de connexion à réclamer au cas par cas), imposant que chaque service fasse du développement spécifique pour chaque autre service, alors franchement c'est juste une impasse de plus.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Et techniquement ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 5.
Je te confirme que tu as bonne mémoire pour AIM d'AOL, je ne sais plus pour ICQ de Mirabilis.
Je confirme aussi que Google a été moteur (probablement ce qui a motivé d'autres à faire des expérimentations ?) et a contribué Jingle (si j'ai bonne mémoire) puis s'est effectivement suicidé. Bizarrement, les autres ne veulent pas en tirer les bonnes leçons…
Pour le dernier point (sur les specs des autres services) tu soulèves un point crucial que je n'avais pas anticipé. En tout cas, pour la partie technique, XMPP permet déjà d'être concrètement et réellement interopérable et le reste n'est qu'excuses…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Et techniquement ?
Posté par Krunch (site web personnel) . Évalué à 4. Dernière modification le 27 mars 2022 à 13:42.
D'un point de vue technique, il y a quand même l'aspect gestion du spam qui est quand même vachement plus facile sur un réseau fermé. De manière générale, je suis d'accord que c'est pas une excuse suffisante mais c'est pas trivial non plus.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Et techniquement ?
Posté par antistress (site web personnel) . Évalué à 4. Dernière modification le 27 mars 2022 à 14:14.
Je ne comprends pas ton propos, peux-tu l'expliciter ?
S'il y a plusieurs réseaux "fermés" (sur inscription, c'est comme cela que je comprends le terme ?) interconnectés, chacun modérant ses inscrits, en quoi est-ce plus compliqué ? Je dirais l'inverse pour ma part ?
Cf le lien donné ci-dessous : https://www.laquadrature.net/2019/06/12/interoperabilite-contre-haine/ et le documentaire cité
[^] # Re: Et techniquement ?
Posté par Krunch (site web personnel) . Évalué à 4.
Si Facebook a un problème de spam avec ses utilisateurs, ils peuvent facilement fermer les comptes concernés et mettre en place des restrictions plus ou moins adéquates pour les nouveaux comptes. Si Facebook a un problème de spam avec des utilisateurs de « petits » opérateurs tiers, c'est plus compliqué/délicat à gérer puisqu'ils n'ont pas de contrôle à l'inscription, peu de visibilité sur les comptes eux-mêmes et plus de risque de faux positifs lors du bloquage.
Suffit de voir le nombre de petits opérateurs qui ont des problèmes pour envoyer des mails à des adresses gmail. C'est pas juste parce que Google veut pas faire d'effort. Dans ce cas c'est plutôt dans leur intérêt que les e-mails circulent bien tant que leurs utilisateurs sont pas spammés. C'est surtout que techniquement c'est compliqué d'atteindre ces deux buts à la fois.
Encore une fois, je pense pas que ça soit une raison suffisante pour éviter l'interopérabilité mais c'est pas techniquement trivial.
Le documentaire que tu mentionnes semble plus parler de groupes d'incitation à la haine, ce qui est un problème différent du spam et les solutions / motivations de l'un ne sont pas forcément les solutions / motivations de l'autre.
Je travaille chez Google mais pas sur gmail ou autre système de messagerie. Je ne représente pas la société sur ce site. Ce message n'engage que moi.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Et techniquement ?
Posté par antistress (site web personnel) . Évalué à 4. Dernière modification le 27 mars 2022 à 16:13.
Pourtant l'expérience montre que les grandes plateformes ne parviennent à modérer efficacement (trop ou pas assez), dépassés qu'ils sont par leur taille probablement ?
Alors que la question de la modération d'un réseau fédéré à grande échelle, avec de multiples autorités, reste à expérimenter.
Il est étrange de mettre en balance un risque potentiel avec un risque avéré, et de faire primer le 1er, non ?
[^] # Re: Et techniquement ?
Posté par antistress (site web personnel) . Évalué à 5.
J'ajoute que j'aurais plus confiance d'être sur un réseau fédéré modéré par une entité dont les valeurs me conviennent que sur celui d'un géant dont l'objet est de faire des profits quitte à promouvoir les contenus agressifs, polémiques ou plus généralement violents
[^] # Re: Et techniquement ?
Posté par Krunch (site web personnel) . Évalué à 3. Dernière modification le 27 mars 2022 à 16:27.
C'est cool mais ça a rien à voir avec l'aspect technique dont est le sujet de ce fil.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Et techniquement ?
Posté par Krunch (site web personnel) . Évalué à 2.
Le risque de spam me semble tout à fait avéré. De ce que j'en vois, la modération du spam et du contenu incitant à la haine sont des problème très différents.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Et techniquement ?
Posté par antistress (site web personnel) . Évalué à 3.
Ha, justement, c'est la question que je me posais
[^] # Re: Et techniquement ?
Posté par claudex . Évalué à 4.
Ça a été testé avec Mastodon (et encore, pour une définition de grande échelle pas trop grande), je ne dirais pas que ça c'est bien passé, puise que la solution a été de banir certains serveur depuis d'autres serveur. C'est aussi ce qui se passe avec le mail, n'importe qui peut en envoyer, au final, tu ne peux faire confiance à aucun serveur et tu te retrouve avec des règles arbitraires et débiles.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et techniquement ?
Posté par Krunch (site web personnel) . Évalué à 3.
Note que si ton service centralisé est suffisamment grand, tu te retrouves aussi avec des règles arbitraires et débiles. Mais peut-être un peu moins et il est relativement plus facile de les corriger (mais aucun utilisateur ne peut les éviter).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Et techniquement ?
Posté par claudex . Évalué à 3.
C'est vrai. Je voulais parler du point de vue de l'opérateur de service, mais je n'avais pas pensé à l'utilisateur.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et techniquement ?
Posté par Krunch (site web personnel) . Évalué à 2.
La gestion du spam est fondamentalement plus compliquée sur un réseau fédéré mais il y a aussi tout l'aspect évolution qui est fortement ralenti comme expliqué ici : https://lwn.net/Articles/687294/
Je pense pas que ça soit non plus une excuse suffisante pour éviter la fédération des grands réseaux de messagerie mais ça démontre que c'est pas anodin non plus comme changement.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Et techniquement ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Si j'étais fournisseur du service de messagerie Fesseboob à plusieurs millions d'abonnés, je me dépêcherais de fournir une API :
Une fois cette API devenue un standard de fait, je mettrais en place la fondation OpenAssMessaging qui définit les appels http avec une RFC de 42000 pages et vends des certifications à 8000€ la semaine.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Et techniquement ?
Posté par claudex . Évalué à 3.
Comment Alice donne le jeton à Bob vu qu'elle ne peut pas encore communiquer avec lui ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et techniquement ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Toutes les belles rencontres commencent dans un bar.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Et techniquement ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
on pourra parler d'Open Bar ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Contexte
Posté par antistress (site web personnel) . Évalué à 5. Dernière modification le 26 mars 2022 à 11:49.
Pour rappel :
https://www.laquadrature.net/2019/05/21/pour-linteroperabilite-des-geants-du-web-lettre-commune-de-45-organisations/
https://www.laquadrature.net/2019/06/12/interoperabilite-contre-haine/
et aussi cette question (celle de multiplier les "autorités" pour éviter la censure centralisée lorsqu'un seul acteur détient le réseau) est abordée dans le docu Disparaitre sous les radars des algorithmes (ARTE TV) https://linuxfr.org/users/nico4nicolas/liens/disparaitre-sous-les-radars-des-algorithmes-arte-tv
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.