L’un des axes de développement d’Horizen est la sécurisation des communications. Cet article décrit en détail les fonctions de messagerie initiales mises en œuvre et esquisse la voie à suivre pour les développer dans l’avenir. Afin de garantir la compatibilité inter-applications, nous basons la messagerie ZenChat sur un protocole bien défini afin que les futures applications (portefeuilles/clients de chat, etc.) soient compatibles entre elles. Une fonctionnalité de messagerie s’exécutant sur une blockchain semble contre-intuitive à première vue, compte tenu des limitations du débit des transactions. Mais nous pensons que nos efforts en matière de scalabilité permettront de rendre possible la diffusion de messages sur la blockchain dans un avenir proche.

La valeur de notre protocole de messagerie ne repose pas seulement sur la communication entre les utilisateurs, mais aussi sur la communication entre les différents nœuds et/ou applications au niveau du protocole.

Exemples de scénarios de messagerie :

1 à 1 et en messagerie de groupe - dans le premier cas, deux personnes discutent l’une avec l’autre (cas classique de tchat). Dans le deuxième cas, de nombreux utilisateurs envoient des messages à un “canal” commun. De nouveaux utilisateurs peuvent être ajoutés au canal ; messages avec expéditeurs identifiables et messages anonymes - dans certains cas, les utilisateurs souhaitent prouver leur identité aux destinataires. Dans d’autres cas, les utilisateurs souhaitent rester anonymes.

Sur la base de ce qui précède, nous obtenons quatre combinaisons de cas d’utilisation majeurs : (1-à-1 / groupe) combinés avec (expéditeurs anonymes / identifiables). Le terme utilisateur ne doit pas être strictement compris comme un utilisateur humain. Nous pourrions facilement imaginer des scénarios où des robots/intelligences artificielles, etc. utiliseraient le protocole de messagerie.

Utilisateurs

Un utilisateur peut avoir plusieurs identités sur la messagerie ZEN qu’il présente à d’autres utilisateurs (comme information publique). Le client/wallet/GUI de messagerie est responsable du maintien de ces identités. Une identité de messagerie doit contenir les informations suivantes :

  • Un surnom qui est arbitrairement choisi et donné par l’utilisateur ;
  • Une adresse d’envoi et de réception spécialement créées ou dédiées pour l’identité de la messagerie. Elles sont utilisées pour envoyer et recevoir des messages grâce à des transactions ;
  • Une adresse T-ID (ID pour indentifiant) de l’expéditeur utilisée pour signer les messages avant leur envoi (spécifique à l’identité de la messagerie).

En option, un utilisateur est libre d’inclure d’autres détails, tels que son nom et prénom et ses contacts comme son email, son numéro de téléphone ou son identifiant Twitter. La façon dont les utilisateurs partagent leur identité afin d’établir un contact n’est pas strictement définie. Vous pouvez l’implémenter de différentes manières :

Comme implémentation initiale, les GUI (General User Interface : Interface Graphique) des portefeuilles/messageries permettent aux utilisateurs d’importer/exporter/copier/coller leur identité ZEN ou l’identité d’un contact tel un objet JSON. Les utilisateurs partagent leur identité ZEN soit en privé (via d’autres canaux), soit par commodité sur un canal slack dédié à ZEN.

Une fois que l’utilisateur A importe l’identité de l’utilisateur B, le client GUI peut demander à l’utilisateur A s’il souhaite envoyer son identité à l’utilisateur B comme message spécial ZEN. Ceci n’est possible que si le message peut tenir dans une transaction Z→Z (pour la version 1 du protocole de messagerie ZEN). Ensuite, le client GUI de l’utilisateur B lui demandera d’importer l’identité de l’utilisateur A à partir du message.

Plus tard, un nouveau “serveur de messagerie ZEN” (malheureusement centralisé) pourrait être implémenté où les utilisateurs pourraient publier leur identité ZEN. Les clients de GUI de messagerie accèderont au serveur via une interface standardisée. Les utilisateurs pourront publier ou rechercher des identités sur le serveur.

La solution à long terme souhaitée est un registre décentralisé des identités ZenChat sur la blockchain Horizen !

Protocole de messagerie

Les messages “ZEN” des utilisateurs sont acheminés dans le cadre des transactions ZEN T→Z et Z→Z dans le champ mémo. Le champ mémo a une longueur maximale de 512 octets et, lorsqu’il est spécifié sur une ligne de commande, doit être au format HEX. Il y a actuellement quelques limitations dans les transactions JoinSplits/→Z qui compliquent quelque peu la conception du protocole :

Lorsqu’une adresse Z réceptionne une transaction (elle en est donc le destinataire), elle voit la date/le montant/le memo mais ne voit pas l’adresse T/Z d’envoi. C’est le cas pour les transactions ZEN T→Z et Z→Z. Lorsqu’une transaction est envoyée à partir d’une adresse Z, elle n’est pas enregistrée dans le fichier “wallet.dat” de l’expéditeur.

Les limitations exigent que l’identité de l’expéditeur soit établie au niveau du protocole de messagerie (en signant le message avec une adresse T). Chaque expéditeur d’un message (qui utilise la messagerie ZEN) doit avoir deux adresses :

  • Une adresse Z pour l’envoi et la réception de la transaction de messagerie (utilisée uniquement pour le “transport”) ;
  • Une adresse T pour signer le message envoyé et prouver l’identité de l’expéditeur (pour le cas d’utilisation d’un utilisateur qui n’est pas anonyme). Un expéditeur (humain) peut (potentiellement) avoir plusieurs identités de messagerie/détails de contact, mais pour chaque identité/détails de contact, une paire d’adresses Z+T doit être créée/dédiée pour l’utilisation. Chaque message ZEN est envoyé comme une seule transaction Z→Z d’un expéditeur à un destinataire dans la première version du protocole.

Un message (“zenmsg”) dans ZenChat se compose d’un champ de données indiquant la version (“ver”) du protocole exécuté par le programme, de l’adresse de l’expéditeur (“from”), du message lui-même et d’une signature (“sign”). Avec ce format de message, la longueur maximale effective d’un message utilisateur (“message”) est d’environ 340 caractères. Les futures versions du protocole pourront permettre des messages plus volumineux en envoyant un message divisé en plusieurs transactions. Lorsqu’un utilisateur envoie un message, l’adresse T signe le message texte de l’expéditeur et inclut la signature dans le message. Il n’est pas nécessaire d’inclure un destinataire parce que les renseignements le concernant sont inclus dans la signature.

{
   "zenmsg":
   { "ver": 1,
     "from": "znn9wRVAkgNnKCYJvsHu9nm4Q7c6AxLE2qR",
     "message": "Le message est ici",
     "sign": "H5L3vhCQ+3EAz7BRrpNqy2x42VF+oY1WowGxCwEJkMlcbfX+GLU3PWOzPwJK+BUBY5YoDk/hAkF4GwtqyWWOngI="
   }
}

Les messages anonymes

Lorsqu’un utilisateur envoie un message de manière anonyme, la structure est légèrement différente. Lorsque l’utilisateur A envoie le tout premier message à l’utilisateur B - le client GUI génère un ID unique pour la direction de la messagerie (utilisateur A → utilisateur B), et le stocke en permanence. Tous les messages non signés suivants (Utilisateur A → Utilisateur B) auront le même ID unique. Le client de l’interface graphique présentera tous les messages anonymes qu’il reçoit avec le même identifiant, comme provenant du même expéditeur anonyme. Un message anonyme ne contient aucun expéditeur.

{
   "zenmsg":
   {
     "ver": 1,
     "message": "Le message est ici",
     "threadid": "123e4567-e89b-12d3-a456-426655440000"
   }
}

La différence entre les fils de discussion anonymes et les fils de discussion avec des utilisateurs identifiés est qu’un ID unique remplace la signature et l’expéditeur. Comme l’expéditeur est anonyme (et n’apparaît pas dans la transaction), le destinataire ne sera pas en mesure de répondre au message lors d’une conversation 1-à-1. Cependant, le message peut inclure l’adresse Z de l’expéditeur dans le premier (seulement le premier) message envoyé (dans la direction Utilisateur A → Utilisateur B). Dans ce cas,l’utilisateur B peut alors répondre, toutes les réponses utiliseront alors le même ID unique.

Le nouveau champ, “returnaddress” (adresse de retour), peut révéler l’identité d’un utilisateur (indirectement ou non) et affaiblir l’anonymat. De plus, l’ID de thread n’est pas fiable à 100% pour indiquer que les messages proviennent du même utilisateur, en particulier dans les scénarios de messagerie de groupe (d’autres utilisateurs peuvent le voir et le falsifier).

{
   "zenmsg":
   {
     "ver": 1,
     "message": "Le message est ici",
     "threadid": "123e4567-e89b-12d3-a456-426655440000",
     "returnaddress": "zcZLZ6hjYYCqZEg64aHpvCpaX7yQyvAedjhHkP2e1LWVSNmxhj6CUYJqAsPGXzxB5prMppyv2jsJxbGbw4JDvdxpPUbNNUa"
   }
}

Un message est soit signé avec une adresse T, ou est anonyme et a un ID unique, mais jamais les deux.

Message spécial

Un type de message spécial contient les détails d’une identité de messagerie dans le premier message. L’expéditeur utilise ce message afin d’informer le destinataire de l’identité de l’expéditeur, de sorte que le destinataire n’aurait pas besoin d’importer ces données d’une autre manière. Dans ce type particulier de transaction, le message contient les informations d’identification de l’utilisateur.

Messages de groupe

La messagerie de groupe implique que plusieurs utilisateurs envoient des messages à un seul canal/groupe. Les messages sont visibles pour tous les utilisateurs concernés. Le canal possède une adresse Z vers laquelle tous les utilisateurs envoient des messages. Les expéditeurs de ces messages peuvent être identifiables ou anonymes. Afin de faire connaître aux autres utilisateurs ses données d’identité, tout utilisateur peut envoyer au canal le message spécial mentionné ci-dessus contenant ses données d’identité. Si un utilisateur n’envoie pas ce message spécial, les autres utilisateurs connaîtront son adresse T mais ne sauront pas qui est derrière elle.

L’obtention d’une adresse Z pour un canal de messagerie est spécifique à l’implémentation de la plateforme de messagerie. La meilleure façon d’obtenir l’adresse Z simplement est de permettre aux utilisateurs d’utiliser une expression commune, telle qu’un #hashtag. Chaque utilisateur convertit individuellement cette phrase en une adresse Z et l’importe dans son portefeuille/client GUI.

Résumé

Une messagerie est un ajout appréciable à la pile de fonctionnalités de notre plateforme blockchain. Elle permet non seulement aux utilisateurs de communiquer d’une personne à une autre ou en groupes/canaux mais aussi par le biais de différents logiciels clients, portefeuilles et applications. Les utilisateurs peuvent créer autant d’identités de messagerie qu’ils le souhaitent et peuvent choisir de communiquer anonymement ou ouvertement. Un message dans l’application ZenChat est une transaction avec un message joint dans un champ de données. Les messages via notre application ZenChat peuvent contenir environ 340 caractères.

Alors que les utilisateurs doivent actuellement échanger leurs identités de messagerie en dehors de l’application, il est souhaitable à long terme d’avoir un registre distribué des identités de messagerie sur la blockchain Horizen. Afin de créer un canal de messagerie, une phrase commune ou #hashtag peut être convertie en adresse Z.

Envie d’essayer notre messagerie ZenChat ? Pour ce faire, téléchargez notre application phare Sphere by Horizen, activez le Full Mode (mode complet en français) dans les paramètres et envoyez votre premier message. Si vous ne possédez pas encore de ZEN, visitez notre faucet où vous recevrez une petite quantité de ZEN gratuitement et pourrez commencer à explorer notre application de messagerie.