je suis une personne pour laquelle la notoriété / visibilité est essentielle : être sur Twitter ou Mastodon ou Gmail.com ou Wanadoo.fr ou n'importe quel autre endroit où l'entité administratrice peut me fermer mon compte, renommer son service ou fermer le service, c'est un risque pour la pérennité de mon image. Une solution serait d'utiliser mon propre nom de domaine. Mais Twitter par exemple ne voudra pas que j'utilise mon nom de domaine pour microbloguer. À ma connaissance, Mastodon non plus, à moins d'avoir ma propre instance. Avoir la capacité (comme pour le courriel) de déléguer la gestion de son domaine à un prestataire technique permettrait cela.
comme pour tout moyen de communication (en particulier communication publique), il y a ce qui n'est pas autorisé en entrée du système (pour des bonnes ou des mauvaises raisons, ça peut être le spam, le SEO, le harcèlement, le DDoS, le porno, les amateurs de fruits, âge/sexe/religion/nationalité/langue/..., peu importe, une catégorie qui sera bloquée par l'entité administratrice). Et il y a ce que la personne utilisatrice finale ne veut pas voir (pour des bonnes ou des mauvaises raisons, ça peut être ce qui précédait, ou le camp adverse selon elle sur n'importe quel sujet, ou son ennemi héréditaire, une personne/entité avec laquelle elle a eu un conflit, un grand pénible, un amoureux éconduit, que sais-je...). Plus il y a d'entités administratrices, plus il peut y avoir du filtrage/de la censure localisée. Et les possibilités techniques offertes par le code jouent énormément, comme bloquer une instance complète par exemple.
les conditions générales d'utilisation ou les règles de l'entité utilisée : l'entité administratrice (Twitter ou instance Mastodon ou ...) peut changer ses CGU, et décider que maintenant il est interdit de crossposter/(co|re)publier ailleurs, de parler métaphysique ou de publier des photos montrant trop de peau humaine. On peut bien choisir son instance initialement. Et elle peut changer ses règles ultérieurement, ce qui peut impliquer de devoir bouger (et reposer la question de la perte de notoriété/visibilité du compte par exemple).
le respect des lois : plus il y a d'entités, plus elles sont soumises à des législations différentes d'une part, et ont un respect variable des législations (par choix, pensez ultra-militants par exemple, ou par capacité/disponibilité, microgroupe de bénévoles débordés ou ayant laissé l'instance à l'abandon). Dans le respect des lois il y a « gérer le signalement d'un contenu manifestement illégal » par exemple, mais il y a aussi « RGPD veuillez effacer mes données perso » (et ça va devenir compliqué en multi-instances si chacun a gardé des copies (genre les métadonnées de relations par exemple) et si rien n'est techniquement en place). Ou bloquer du cyberharcèlement qui peut sauter d'une instance à l'autre pour harceler un compte donner.
l'interopérabilité et la fragmentation des protocoles : même problématique que pour le courriel par exemple, chaque instance va implémenter ou pas les évolutions des protocoles, et au final on a un mélange de grands anciens (on dirait ASCII 7 bits en clair pour du courriel) et de modernes (par exemple TLS 1.3 UTF-8 DNSSEC SPF DKIM DMARC pour du courriel). Ça sera vrai entre Mastodon 2042 et Mastodon 2063, mais aussi entre Mastodon 2031 et Pleroma 2037. Sans parler de ce qui n'est pas basé sur ActivityPub, cf https://blog.castopod.org/content/images/2022/11/fediverse-branches-axbom-12-CC-BY-SA.svg ou de Twitter (qui sans intervention du législateur n'en a et n'en aura rien à carrer de l'interopérabilité).
# Autres problématiques
Posté par Benoît Sibaud (site web personnel) . En réponse au lien Mastodon, fin de (première) partie ?. Évalué à 10.