Journal salut@toto — salutation, règle éditoriale et nom sur Internet

Sommaire

• Introduction
• Nom
  • Existence sociale
    • Adresse de médiatisation
    • Adresse de conversation
  • Rivalité des noms & problème des tuteurs
  • Unicité des noms & Référents
    • Des noms universellement uniques, pour quoi faire ?
    • Des noms uniques relatifs aux contextes culturels
  • Conclusion intermédiaire
• @ salutation et règle éditoriale
  • Règle éditoriale — B.A.L.
  • Salutation — Alias
  • Le cas des inscriptions à des plateformes
• Conclusion

Introduction

Salut à tous, je publie ce texte pour partager avec vous quelques réflexions sur la gestion du nom et des relations sociales sur Internet. J'ai commencé à formaliser ces réflexions en me demandant, pour ma pratique, comment gérer le spam autrement qu'avec un filtre anti-spam qui, bien que souvent utile, peut s'avérer très gênant (surtout quand on s’auto-héberge)

Au final, cela va au delà. L'objectif est de participer à la mise en place de réseaux sociaux non-enfermant et plus décentralisés. Le point de vue n'est pas technique mais éditorial, sémantique, celui des utilisateurs ; même si cela a des effets sur les logiciels développés et les services proposés.

Cette réflexion analyse le rôle, les enjeux et le sens des différents éléments d'une adresse de la forme salut@toto.net pour le courriel et plein d'autres applications. En effet, il me semble nécessaire de remettre en cause l'acception majoritaire de la signification des éléments d'une adresse : moi@monhébergeur ou moi@mamachine (voire moi@moi).

LinuxFr me semble un bon endroit pour en discuter, pour vérifier que je ne divague pas (totalement) et que je ne fais pas (trop) d'erreurs. Je ne suis pas informaticien, mais j'ai travaillé dans l'édition numérique, cela explique mon point de vue éditorial. Vos retours, en tant que techniciens et utilisateurs avertis, sont les bienvenus !

Nom

Dans cette première partie, trop longue, il est probable que tout te semble évident pour toi, ô lecteur de LinuxFr. Je t'invite donc à lire directement sa conclusion.

Existence sociale

Adresse de médiatisation

Comme le dit Benjamin Bayart, on n'a pas accès à Internet si on ne disposes pas d'une adresse ip¹. De la même manière on n'a pas d'existence sociale autonome sur Internet si on ne dispose pas de son nom DNS lié à une adresse ip, donc à ses publications ; ce que Bayart rappelait aussi dans sa conférence "Internet Libre ou Minitel 2.0"².

Internet est un média, il permet à chaque personne d'avoir une existence médiatique potentiellement puissante. Par existence médiatique j'entends le fait que nos propos puissent être consultés par des personnes qui nous sont inconnues, à la différence des conversations où l'on sait à qui l'on s'adresse et où ces personnes peuvent directement nous répondre.

Le premier rôle d'un nom comme toto.fr est de permettre à n'importe qui de prendre connaissance de l'existence médiatique de Toto, de répondre à la question "Qu'est-ce Toto a publié sur Internet ?". Cela combine les fonctions de nommage, d'identification et de localisation, cette combinaison forme une adresse.³ J'appelle ce type d'adresse une "adresse internet de médiatisation" dans la mesure où elle ne permet que la médiatisation des publications d'une personne.

Il ne faudrait donc pas considérer que le DNS donne des noms à des machines, mais plutôt qu'il lie des noms de personnes, physiques ou morales, à d'autres noms de machines principalement gérés par les adresses IP⁴ (même si moi aussi je donne des petits noms à mes vélos). Hors actuellement presque uniquement les machines et les personnes morales disposent de noms DNS. Contre cette acception actuelle, je propose de ne plus parler de nom de domaine mais juste de nom sur Internet.

Du coup toute les applications sur Internet devraient permettre à leurs utilisateurs d'utiliser leurs propres noms de domaine. Comme vous le savez, il est tout à fait possible pour une machine de recevoir plusieurs noms DNS et de faire le trie à la réception. Wordpress, Blogger, etc. le permettent déjà.

Aujourd'hui il n'y a que 300 millions de noms de domaines de deuxième niveau⁵ or on devrait plutôt être à 4 milliards. En France, l'Afnic qui gère 17 noms de premier niveau français, dont les .fr et autres .paris .bzh & .re, ne compte qu'environ 3 millions de noms. Si on prend en compte le besoin pour une personne d'avoir plusieurs noms ou pseudos pour gérer son identité selon les contextes alors on devrait être au delà des 4 milliards.

Adresse de conversation

Cette première adresse internet de médiatisation est réutilisée, dans la partie à droite du @, pour composer l'adresse internet de conversation. Je reviendrai dans la deuxième partie sur l'utilité de l'élément à gauche du @. Mais on peut déjà dire qu'un des intérêt à avoir son nom, son username, dans la partie à droite du @ est que si mon adresse ne marche plus, mon interlocuteur peut toujours garder un contact avec moi en allant voir mes publications et éventuellement y récupérer une autre adresse de contact.

Certains hébergeurs d'applications orientées conversation comme le courriel permettent d'utiliser son propre nom (par exemple Gmail mais les meilleurs exemples étant les services Gandi Mail ou OVH). Mais bizarrement certains services plus proche du "libre" ne permettent pas d'utiliser son propre nom . Par exemple Mailoo est génial car il fourni un service gratuit d'hébergement d'email mais il oblige d'avoir une adresse de la forme moi@mailoo.org. On retrouve ce problème avec le service XMPP fourni par Duckduckgo. D'autres plateformes comme Seenthis ne donnent qu'une adresse de la forme @toto qui n'est pas reliée au DNS, elle est donc purement locale.

Si mon association, mon entreprise ou mon hébergeur veulent prendre en charge mon nom alors elles doivent me donner un nom DNS type monnom.monentreprise ; quitte à ne pas me permettre l'utilisation du DNS pour autre chose qu'une page web ou un email qu'ils maitrisent. Cela elle permet me laisser la libre gestion de la partie avant le @ ; condition nécessaire à la gestion de ses interactions.

Or l'acception moi@monhébergeur, que je considère être une erreur, est très ancienne et encore très fréquente, en particulier chez des acteurs importants d'Internet. Ainsi dans sa conférence Benjamin Bayart dit² :

Le courrier électronique, moi, quand j'ai appris le courrier électronique quand j'étais petit on m'a dit: « c'est le login de l'utilisateur at le nom de la machine ». Mon adresse mail c'est « bayartb »,ça c'est mon login « at edgard.fdn.fr » ça c'est ma machine.

On la retrouve en 2012 chez Ray Tomlinson, à l'origine de l'email et surtout de l'utilisation du @ :

Le signe @ est ce qui faisait le plus sens car les utilisateurs étaient forcément à une adresse “at”», racontera-t-il plus tard au magazine Wired.

Et aussi dans des projets récents comme Diaspora*, ils font même l'erreur consistant à utiliser une forme @nom sans utiliser la partie devant le @ et sans gérer le nom avec le DNS :

Pour vous connecter avec des gens, il vous suffit simplement de les trouver et de les ajouter à un aspect (voir plus bas plus de détails sur les aspects). Pour les trouver […] vous pouvez aussi utiliser leur identifiant diaspora* (sonnom@nom_du_pod.com) si vous le connaissez.

[…]
Vous voulez attirer l'attention de quelqu'un ? Il suffit de le @mentionner

Ou encore dans les RFC de l'IETF le RFC 805 titré "Computer Mail Meeting Notes" (publié en 1982) :

The major conclusion reached at the meeting is to extend the "username@hostname" mailbox format to "username@host.domain", where the domain itself can be further structured.

Alors que depuis longtemps l'IETF laisse dans ses RFC, qui font une bonne analyse de l'utilité des différents éléments, la porte ouverte à d'autres interprétations. Par exemple, on le voit dès le RFC 805 :

One of the interesting ideas that emerged from this discussion was that the "user@host" model of a mailbox identifier should, in principle, be replaced by a "unique-id@location-id" model, where the unique-id would be a globally unique id for this mailbox (independent of location) and the location-id would be advice about where to find
the mailbox.However, it was recognized that the "user@host" model was well established and that so many different elaborations of the "user" field were already in use that there was no point in persuing this "unique-id" idea at this time.

Mais aussi dans d'autres plus récents comme le RFC 5598 sur l'"Internet Mail Architecture" (publié en 2009) :

A mailbox is specified as an Internet Mail address <addr-spec>. It has two distinct parts, separated by an at-sign (@). The right side is a globally interpreted domain name associated with an ADministrative Management Domain (ADMD).

[…]
The portion to the left of the at-sign contains a string that is globally opaque and is called the <local-part>. It is interpreted only by the entity specified by the address's domain name.

Malheureusement, malgré ces possibilités, aucune autre sémantique n'a vraiment réussi à prendre de l'ampleur. On retrouve donc systématique des exemples reposant sur le modèle moi@monhébergeur, par exemple dans le RFC 5322

This could be called a canonical message. It has a single author, John Doe, a single recipient, Mary Smith, a subject, the date, a message identifier, and a textual message in the body.

---

From: John Doe <jdoe@machine.example>
To: Mary Smith <mary@example.net>

Rivalité des noms & problème des tuteurs

Stéphane Bortzmeyer l'explique régulièrement, le DNS est un outil hiérarchique, il ne nous permet pas d'avoir un nom sans que l'on dépende d'un tuteur, que ce soit l'Icann, l'Afnic ou wordpress, par exemple avec un nom de la forme toto.wordpress.fr. Si une de mes tutelles me rejette, et impose sa décision aux autres tutelles⁶, je perds alors l'audience et les relations sociales rattachées à ce nom - on reconnaît ici l'effet d'enfermement dans un réseau social qui rend difficile l'abandon de Facebook ou Twitter.⁷

La relation de tutelle n'est pas problématique uniquement du point de vue du pupille, c'est aussi problématique du point de vue du tuteur car il engage sa propre réputation et sa responsabilité. Si vous ne pouvez exister qu'à travers lui, à chaque fois que vous serez mentionnés il sera mentionné. Parfois il en tirera un bénéfice, mais souvent il n'aura pas envie de prendre ce risque.

Face à ces deux problèmes, une des solutions serait que les municipalités ou départements, via les 10 000 bibliothèques municipales ou la centaine de bibliothèques départementales, proposent aux citoyens une prise en charge tutélaire de leurs noms. C'est à dire leur donner des noms comme toto.paris qu'ils pourraient relier à n'importe quel service sur Internet. Alors qu'un nom au format toto@paris (ou parfois simplement @toto non-relié au DNS) enferme dans un service donné et ne permet pas d'avoir une existence autonome.

La gestion municipale permettrait d'être un peu plus neutre et plus stable que les associations, universités et entreprises et cela permettrait de gérer la rivalité des noms et le name-squatting. Mais ce n'est pas parfait car les déménagement ne sont pas rares.

Il serait sûrement judicieux que les bibliothèques municipales fournissent aussi des services d'hébergement physique et d'administration logicielle des courriels, de Mozilla Persona et d'XMPP. Bien entendu ces services devrait être dissociés du service de nommage DNS pour laisser le choix de l'hébergeur.

Une autre solution, complémentaire, serait le Gnu Name System (GNS) qui est une sous-partie du projet GnuNet. Il permet de transformer le statut des registres de noms : actuellement "tuteurs" ils deviendraient "référents". Chaque registre deviendrait contestable et contournable si besoin.

Gns, pour aller vite⁸, est basé sur deux niveaux de noms, voici une présentation qui s'appuie sur celle de Christian Grothoff⁹ (auteur du projet) et paraphrase celle de Stéphane Bortzmeyer¹⁰ :

• Le premier niveau de nommage utilise un système de clés cryptographiques, le nom étant la clé publique ou son condensat cryptographique (dans le TLD .zkey). Les noms sont uniques (car tirés au sort dans un espace immense) et très sûrs. Ce premier système sera principalement utilisé par le logiciel, et non visible par les utilisateurs, car ces noms uniques ne sont pas facilement manipulables par des humains.¹¹

• Le second niveau permet l'utilisation de noms manipulables par des humains, définis par chaque internaute pour son usage : les petnames¹². D'une certaine façon, avec GNS, tout le monde est un registre racine, nommé ".gnu". Ces noms locaux sont sécurisés par les noms cryptographiques. Ils sont relatifs et ne sont donc pas uniques. Mais on peut aussi passer par les racines-registres d'autres personnes, utilisés comme nom de deuxième niveau, qui font autorité pour une population donnée.

Un autre point important pour contourner les registres est que leurs bases de données soient publiques et facilement forkables.

Partant de là, voyons en quoi ce statut de référent est intéressant. La partie qui vient est une digression pour promouvoir une des particularité de GNS : la non-unicité des noms ; vous pouvez donc la passer en allant directement à la conclusion intermédiaire.

Unicité des noms & Référents

Des noms universellement uniques, pour quoi faire ?

Il me semble important de prendre conscience qu'il n'est pas désirable d'avoir des noms universellement uniques. La plupart des alternatives P2P au DNS essayent de dépasser le problème du triangle de Zooko qui dit qu'un nom P2P ne peut pas être à la fois unique, manipulable par les humains et sécurisé, seuls deux de ces objectifs peuvent être obtenus simultanément. Or faire sauter l'objectif d'unicité absolue est souhaitable.

D'une part l'unicité n'est pas un bon objectif car cela renforce la rivalité donc le risque de name-squatting. Avec 4 milliards de noms cela aboutirait vite :

• soit à une augmentation des tensions autour de la propriété des noms (tout le monde veut le .sex ou le .book & les vendeurs anglophones de pommes renoncent au apple.com etc.). Pensons aux michelmartin96 que l'on trouve sur facebook ou gmail.

• soit à un allongement des adresses à cause de la classification nécessaire à la résolution des conflits, les vendeurs anglophones de pomme auraient le apple.fruit.com pour se distinguer de apple.computer.com etc.

D'autre part, l'unicité universelle n'est pas nécessaire car les humains ont des bonnes capacités d'interprétation et de prise en compte d'un contexte inhabituel contrairement aux machines (par exemple la googlecar ne peut rouler que sur une route qu'elle connaît déjà très bien) qui ont donc besoin d'identifiants uniques.

Déjà actuellement, l'humanité n'utilise pas des noms uniques et cela fonctionne bien. Par exemple au niveau des noms de ville : London, Londres, لندن, 倫敦 sont des noms propres à des contextes culturels différents pour désigner une même entité. Cette multiplicité des noms est importante pour faciliter l'identification des noms par des personnes extérieures à la culture initiale de l'entité. Imaginez que vous ayez à distinguer 北京 de 上海, 深圳, 南京, 香港, 广州 et 东莞. Pour vous faire une idée vous pouvez essayer de vous repérer sur ici ou là

On peut souligner qu'il est important que ces renommages ne soient pas fait par la culture de l'entité nommé mais par les cultures extérieures qui prennent connaissance de cette entité pour l'intégrer à leurs cultures.

Des noms uniques relatifs aux contextes culturels

Face à cette multitude de noms, on vérifie l'identité soit en passant par des référents en qui on a confiance, soit par ses spécificités locales complexes : quand on y est, il est difficile d'usurper l'identité de Londres en tant que ville caractérisée par sa localisation, ses institutions, la forme de la ville, la langue qu'on y parle etc. Dans le cas du GNS, cette réalité complexe unique, c'est le nom unique qui a la forme d'une clef publique ou son condensa.

Avec GNS, Afnic & Icann restent utiles mais leur statut évolue de tuteur à référent, dans le sens où on a toujours intérêt à passer par eux, au moins dans un premier temps, pour indiquer son nom à une personne. Ici Afnic ou Icann restent important en tant que référents culturels communs à des populations données. Par exemple en France, tous les noms pourraient être exprimés en référence plus ou moins explicite à l'Afnic. On dirait "va voir mon site toto.fr" car, la plupart du temps, notre interlocuteur saurait à quel .fr on se référerait et tout le monde l'aurait déjà enregistré dans son ordinateur, de la même manière qu'on a tous des clavier adaptés au français. L'unicité des noms serait alors maintenue pour un contexte culturel donné.

GNS permet aussi de lier un même nom unique (le .zkey) dans plusieurs registres. Ainsi, si on décide de rediriger tous les .org.fr vers le .org étasunien, aux États-Unis le nom de Wikipédia serait wikipedia.org.gnu tandis qu'en France il pourrait être wikipedia.org.fr.gnu et wikipédia.fr.gnu

On le voit, plus on serait éloigné culturellement d'une personne plus son nom serait long car la chaîne d'intermédiaires serait longue. Mais plus on fréquenterait les publications de cette personne, plus on raccourcirait son nom quitte à l'intégrer à sa propre racine. Wikipédia pourrait devenir wp.gnu

Assumer le rôle des intermédiaires c'est reconnaître la nécessité d'une gestion politique des noms de domaine. Mais, en leur donnant un statut de simples référents, ce n'est pas renoncer à la possibilité, lorsque c'est nécessaire, de les contourner, de les forker.

On le voit, on peut bénéficier de leur utilité (unicité partielle et relative à une culture) tout en gardant l'autonomie des noms, des identités, c'est à dire la possibilité de se passer totalement de ces intermédiaires ou de passer par d'autres référents.

GNS est plus une extension du système actuel, il ne remplacera pas les 300 millions de noms enregistrés dans les domaines de premier niveau. Mais GNS pourrait cohabiter avec ces noms DNS si les .zkey et .gnu étaient reconnus par l'Icann, ou les intégrer (à condition que tous ces registres actuels basculent leur logiciel de DNS vers GNS).

Au passage, l'Afnic, elle aussi, deviendrait réellement indépendante de l'Icann. Les autorités de nommage mondiales travailleraient en réseau, à statut égal et sans hiérarchie, et elles garderaient leur notoriété et crédibilité déjà établies vis à vis de leur public et dans leur zone ou sphère culturelle de référence.

Mais il y a deux difficultés majeures pour passer au GNS :

• l'implémentation actuelle de GNS ne fonctionne (presque) pas et n'est pas userfriendly. Heureusement une autre implémentation en Rust est en projet et la prise en charge du projet par l'Inria ainsi que sa notoriété croissante laissent espérer de meilleurs implémentations

• la bascule totale de DNS à GNS sera au moins aussi difficile que celle d'ipv4 vers ipv6, il est plus probable qu'il y aura une cohabitation pendant longtemps. Heureusement c'est possible.

Conclusion intermédiaire

On ne doit pas considérer que le DNS ne gère que les adresses de machines ou d'hébergeurs, ça c'est principalement l'adresse ip qui s'en charge. Mais les noms des internautes, les personnes physiques ou morales qui s'expriment sur Internet, n'ont pas à être gérées par autre chose que le DNS ou ce qui peut le remplacer. Donc le DNS lie les noms des internautes aux adresses de machine ou d'hébergeurs.

Une adresse DNS de la forme nom.tuteur, par exemple toto.fr, est ce que j'appelle une "adresse internet de médiatisation". Elle répond à la question "Qu'est-ce Toto a publié sur Internet ?". Disposer d'un nom DNS permet de gérer librement son existence médiatique, c'est à dire son audience, sa notoriété, sa légitimité, sa capacité de mobilisation etc. Cela permet de stabiliser cette existence, de ne pas perdre ces éléments à chaque fois qu'on change de logiciel ou d'hébergeur.

On doit donc passer de 300 millions de noms à 4 milliards. Pour cela il faut faciliter la gestion des zones DNS, la rendre plus user-friendly qu'elle ne l'est actuellement. Et les service d'hébergement des publications, web ou autre, doivent permettre à leurs utilisateurs, Mr et Mme Dupuis-Morizeau, d'utiliser facilement leurs propres noms DNS.

Par ailleurs, comme le DNS est hiérarchique un internaute dépend toujours de tuteurs. Cette situation est oppressante et doit donc être rejetée, sans pour autant nier l'utilité des intermédiaires. Cela peut se faire partiellement en assumant le besoin d'une gestion politique des noms, mais aussi en utilisant des outils, comme le Gnu Name System, qui permettent de contourner les intermédiaires lorsque c'est nécessaire. Cela transformerait le statut des intermédiaires : actuellement "tuteurs" ils deviendraient "référents".

GNS ne permet pas l'unicité absolue des noms mais ce n'est pas grave car celle-ci n'est pas souhaitable. En effet, d'une part les internautes peuvent prendre en compte les contextes inhabituels et agir en fonction. D'autre part GNS permet la coopération entre registre et les renommages adaptés aux pratiques et aux contextes culturel des internautes : plus une adresse serait utilisée dans un contexte culturel moins les intermédiaires seraient nombreux et donc plus elle serait courte, et inversement. Enfin il semble surtout difficile de gérer plus de 4 milliards de noms dans un registre unique sans qu'émergent d'importants conflits liés à la rivalité induite et à la centralisation politique.

Les noms des internautes et les adresses de médiatisation participent aussi à la composition des "adresses internet de conversation" en étant utilisée dans la partie à droite du @. Ces adresses permettent aux internaute d'avoir des conversations, de se répondre directement. Confiner le nom dans la partie à droite du @ permet de laisser la libre gestion de la partie à gauche du @.

Mais alors à quoi sert la partie devant le @ ? C'est ce que nous allons voir dans la deuxième partie.

@ salutation et règle éditoriale

Internet n'est pas qu'un média, c'est aussi ce que j'appelle un converso (d'autre disent "réseaux sociaux" mais ce terme ne me semble pas pertinent). Un converso est un dispositif social qui organise, cadre et rend possible les conversations en mobilisant certaines techniques et groupes sociaux. Il permet aux personnes de se répondre directement. Il se réalise notamment par la constitution d'un lieu où des conversations existent selon certaines règles. Dans ce lieu la vie privée peut (plus ou moins) exister. Voici quelques exemples de conversos non-informatisés : le téléphone, le speed dating, un repas partagé autour d'une table, un entretien d'embauche etc.

Une conversation se distingue d'une médiatisation par le fait que tous les participants se perçoivent, peuvent prendre la parole et se répondre. Une discussion nécessite que chaque participant ait un nom. Mais pour être initiée elle doit aussi passer par une salutation mutuelle. Cette salutation, indique un protocole qui fixe le cadre et les modalités d'une conversation. À vos amis vous dites "wesh", à votre famille vous dites "salut", à votre patron ou à un inconnu vous dites "bonjour", à l'école on lève le doigt pour prendre la parole etc.

Évidemment les frontières entre média et converso sont floues et les deux peuvent être combinés. D'une part une discussion entre des personnes peut avoir un public important sans que celui-ci ne puisse participer à la conversation, c'est déjà le cas avec les talkshows à la télé. D'autre part sur Internet une discussion entre des milliers de personne peut avoir lieu, par exemple grâce aux listes de discussion, à XMPP ou Twitter. Toutes ces personnes ne prennent pas la parole en même temps, elles forment alors un immense public, mais elles peuvent prendre la parole.

Les nombreux "leaks" où photos sorties de leur cadre privée, pour le meilleur et pour le pire, sont une autre illustration de cette porosité accrue par Internet entre média et converso.

Nous allons voir comment l'adresse Internet de la forme salut@moi, historiquement utilisée pour le courriel, peut permettre de gérer ces conversations. j'appelle cette forme d'adresse une "adresse internet de conversation". Le mot "adresse" dit bien ce dont il est question, c'est ce qui permet de s'adresser à une personne en particulier.

La partie à gauche du @ devrait donc être utilisée pour définir les modalités qui rendent possible la conversation. Sans le @ devant le nom et sans la partie à gauche du @, la relation n'est pas d'ordre conversationnel. C'est comme allumer la télé et regarder TF1, cela ne permet pas de converser avec TF1.

Règle éditoriale — B.A.L.

La première fonction de cette partie de l'adresse est de gérer localement la réceptions de messages qui nous sont destinés, d'ailleurs les RFC sont assez clairs sur ce point. Elle doit donc définir un assemblage de règles éditoriales qui doivent être respectées pour qu'un message soit accepté et reçu. Cela permet de gérer la forme que prendra la discussion.

Chaque "boîte aux lettre" (BAL) est un assemblage de règles éditoriales. Il est donc important qu'une personne puisse créer autant de BAL que nécessaire pour gérer les formes de ses conversations selon le contexte et l'origine de la relation sociale.

Voici quelques règles éditoriales utilisées dans la vie sans ordinateur : langage soutenu, langage familier, posture corporelle, tutoiement, vouvoiement, ton humoristique, ton compatissant, ton solennel, longueur de la prise de parole sans interruption (10 secondes ou 15 minutes) etc.

Bien sûr, toutes ces règles qui existent sans les ordinateurs sont ré-utilisées dans les conversations par ordinateurs. Mais d'autres règles éditoriales sont propres aux conversos informatisés. Voici quelques exemples qui pourront être combinées pour définir les BAL :

• avec ou sans filtre spam
• avec ou sans indicateur de présence
• N'importe qui peut y écrire
• Seules les personnes autorisées peuvent y écrire (liste de contacts avec demande type XMPP)
• liste autorisée étendue (les amis d'amis peuvent m'écrire même s'ils ne sont pas dans ma liste autorisée)
• 140 caractères max dans le corps du message
• pièces jointes uniquement .jpg .png .gif ou .flif
• pas de pièce jointe
• message inférieur à xx ko
• etc.

Pour que tout le monde puisse gérer ses BAL, et donc gérer finement les règles éditoriales, il est nécessaire d'avoir un logiciel de bureau simple d'utilisation et ergonomique. Or actuellement il me semble que cela n'existe pas.

Salutation — Alias

La deuxième fonction de la partie à gauche du @ est de filtrer les conversations selon leurs origines et leurs contextes. Ainsi une même BAL peut avoir plusieurs alias. Ces alias sont des salutations qui, déjà sans Internet, permettent de gérer ses relations sociales et d'indiquer des règles éditoriales à suivre.

Voici quelques exemple d'utilisation d'alias pour la salutation dans les relations sociales classiques : Si votre patron vous interpelle en vous disant “Wesh”, il y a aura sûrement une explication/engueulade. Si vous interpellez votre patron en disant “Yo”, idem. Si vous interpellez votre ami.e en disant “Bonjour à vous Camille Delasade”, cela sera sûrement ridicule. Car ces salutations impliquent et reflètent des formes de relation sociale. Une mauvaise utilisation de la salutation empêchera d'entrer en discussion. Si vous sifflez votre amie au loin dans la rue, elle se retournera et viendra vous parler. Mais si vous sifflez une inconnue dans la rue, il est probable qu'elle ne vous réponde pas ou qu'elle vous envoie balader, voire vous mette une grosse droite.

Sur Internet, ces alias permettent notamment de gérer le spam ou la durée de vie d'une interaction. Ainsi pour publier son adresse mail sans qu'elle soit spamée, il n'est plus nécessaire d'utiliser les astuces habituelles, probablement peu efficaces : contact [at] toto ou contact+web@toto ou encore le formulaire web qui oblige à utiliser un navigateur web car il ne publie pas d'adresse.

Par exemple pour ma règle éditoriale “adresse publique” mon adresse sera contact@toto, pour une personne rencontrée dans un bar ce sera salut@toto, pour un cadre professionnel ce sera bonjour@mohameddupont et l'adresse publiée sur mon site web sera contact-T3ls8@toto ; ce dernier alias pouvant être révoqué au besoin s'il est trop utilisé par les spameurs.

Avec ce système, un des avantages est que si un alias est révoqué, la personne utilisant cette adresse pourra toujours aller voir ce que je publie sur toto.fr et y trouver une adresse ad-hoc pour me recontacter. Mais le canal de discussion ne sera plus le même car la relation sociale ne sera plus la même.

Pour qu'un internaute gère de manière autonome son audience, la forme de ses relations sociales, leur durée de vie etc. la sémantique d'une adresse internet de conversation doit donc être : salutation@nom

On peut imaginer tout un tas de noms pour ces différents contextes et règles éditoriales. Voici quelques exemples de règles éditoriales, de salutations et d'alias associés :

Pour la BAL "microblogin" (140 caract max, 2 pièces jointes max et restreintes aux formats .jpg .png .gif et .flif) :

• yo@toto ou ε@toto pour les amis
• tweet@toto pour les inconnus

Pour la BAL "texto" (pas de pièces jointes, pas de mise en forme)

• txto@toto pour les amis
• txto-banque@toto pour ma banque

Pour la BAL "adresse publiée sur le net" (filtre anti-spam, taille des message limité à 50ko, pas de pièce jointe autorisée) :

• contact-fd4Ha@toto valable de juillet à décembre 2016
• contact-js8u@toto valable de janvier à juin 2017

Pour la BAL "courriels d'amis" (pas de filtres anti-spam, pièce jointe libre, indicateur de présence) distribuée oralement à mes amis :

• Salut-à-toi@toto pour les amis fans de Bérurier noir
• Coucou@toto pour les autres amis
• sàt@toto pour les personnes rencontrées dans les bars

Pour la BAL "courriels d'entreprises" (Seules les personnes autorisées peuvent y écrire, pas de filtre anti-spam) utilisée pour les différentes entreprises qui, dans le cadre de la fourniture de leur service, me demandent une adresse contact (mais dont je résilierait les alias ad-hoc si j'arrête mon abonnement) :

• 3615@toto ou spam@toto comme adresse générique
• edf@toto pour edf
• free-fai@toto pour l'abonnement Free

L'utilisation des courriels poubelles dont les alias cessent d'être actifs au bout de 24h etc. est une autre utilisation possible.

Les logiciels de gestion des courriels doivent être adaptés à cette gestion des alias et BAL. Certains systèmes comme Yunohost et Modoboa permettent de bien gérer les alias. Mais je n'en connais aucun qui permettent de bien gérer les BAL tel que je l'ai montré.

Le cas des inscriptions à des plateformes

S'inscrire sur un service en ligne ou un média web, c'est rendre possible une éventuelle conversation. Voilà pourquoi une adresse type salutation@nom est nécessaire et exigée par ces plateformes.

Persona permet(tait) de gérer ça bien et s'inscri(vai)t dans la gestion des noms et relations sociales que je vous ai décrit. Des liens avec XMPP étaient envisagés, ce qui aurait permis d'améliorer l'existant. Malheureusement les hébergeurs de mails ne l'ont pas adopté (tout comme ils n'ont pas adopté XMPP), du coup Mozilla souhaite l'abandonner en novembre 2016. Faudrait-il le forker (avec BrowserId) pour lui redonner une nouvelle vie ? On peut aussi lire des retours d'expérience sur l'échec de Persona par Mozilla et par un hébergeur de mail (pour qui Let's Encrypt serait aujourd'hui une bonne solution).

voici comment il était présenté :

Le mécanisme le plus répandu, basé sur le couple identifiant/mot de passe, n'est pas tenable : on demande aux utilisateurs de créer et de retenir un nouveau mot de passe complexe pour chaque site ou service qu'ils utilisent, et chaque site doit stocker de son côté les mots de passe de manière sécurisée. Pourtant, des intrusions récentes montrent que même des entreprises de premier plan peuvent avoir des failles dans la sécurité de leur base de mots de passe, ce qui met en danger les informations de leurs utilisateurs.

Persona est un système de gestion des identités ouvert, distribué, adapté à l'échelle d'internet, qui remplace le système des mots de passe par site. Il répond aux limitations en termes d'ergonomie et de vie privée que peuvent rencontrer des systèmes comme OpenID, sans avoir recours à une infrastructure centralisée comme le fait Facebook Connect.

PERSONA : LA FIN DES MOTS DE PASSE PAR SITE
Au lieu d'utiliser un mot de passe pour chaque site, Persona permet aux utillisateurs de se connecter en seulement deux clics après avoir réalisé un processus simple une seule fois pour chacune de leurs identités en ligne. Le processus est totalement sécurisé et basé sur les principes de la cryptographie à clé publique. Plutôt qu'un mot de passe, le navigateur internet de l'utilisateur génère ensuite une « assertion d'identité » chiffrée, qui expire après quelques minutes et n'est valable que pour un seul site. Du fait qu'il n'y a plus de mot de passe spécifique pour chaque site, les sites utilisant Persona n'ont plus à se préoccuper du stockage sécurisé des mots de passe ou de la perte éventuelle de leur base de mots de passe.

[…]
Les adresses de courriel portent en elles l'idée une-personne@un-contexte, facilitant ainsi pour les utilisateurs la séparation de leurs identités comme @travail, @maison, @ecole, etc.
https://developer.mozilla.org/fr/Persona/Pourquoi_Persona

[…]

PERSONA EST FLEXIBLE
Avec Persona, votre identité est votre adresse électronique. Vous pouvez utiliser autant d'adresses que vous le souhaitez, mais vous n'avez toujours besoin que d'un seul mot de passe.
https://login.persona.org

Conclusion

Actuellement les internautes disposent trop rarement d'un nom DNS et les systèmes de conversation sont trop pensés avec des adresses de la forme moi@monhébergeur. Cette vielle sémantique de l'adresse de conversation rend les internautes dépendants des hébergeurs et des loueurs de services. Ils risquent, en les quittant, de perdre leurs audiences, leurs relations sociales etc. Par ailleurs cela ne leurs permet pas de bien filtrer leurs interactions. Cette sémantique doit donc être rejetée.

Pour un Internet où les internautes ont une existence médiatique plus autonome, il est nécessaire qu'ils disposent tous d'un nom géré par le DNS. Et pour qu'Internet soit un converso (réseau social) plus décentralisé, il faut utiliser cette nouvelle sémantique pour l'adresse internet de conversation : salutation@nom (même si ça ne résout pas tous les problèmes)

La salutation doit être gérée librement par l'internaute, ce qui lui permet de modeler la forme de ses conversations (BAL) et de les filtrer selon les interlocuteurs et les contextes de rencontre (alias).

Des systèmes techniques comme le courriel, XMPP et Mozilla Persona permettent déjà d'utiliser cette nouvelle sémantique, même si leurs logiciels doivent être améliorés. Les logiciels de gestion des zones DNS participent aussi à son déploiement, mais ils nécessitent d'être plus ergonomiques et faciles d'utilisation. Enfin l'utilisation du Gnu Name System à la place ou en complément du DNS permettrait de rendre le tout encore plus décentralisé.

Bien entendu il est très probable que vous utilisiez déjà cette sémantique. Mais il me semblait nécessaire de l'expliciter vu qu'elle est très peu répandue. J'espère que l'article vous a convaincu ou au moins intéressé, vos remarques sont les bienvenues.