Le but étant d’ajouter le moins de couches possible, j’aimerais éviter de devoir ajouter un protocole en oignons (autre que Tor ou autre solution générique clé-en-main pour wrapper les connexions vers les datapods). D’après Tor Project | How do Onion Services work?, les hidden services n’utilisent pas de crypto magique pour l’adresse de rendez-vous, c’est juste l’utilisation de relais en masse.
Pour envoyer un message depuis une clé anonyme tout en gardant la possibilité d’un antispam basé sur les identités, on pourrait créer des clés déléguées opaques grâce aux signatures en anneau, en étendant le mécanisme de transactions anonymes.
Ainsi quand une clé veut envoyer un message, on peut vérifier qu’elle appartient bien à une identité (sans savoir laquelle), et le taux de création de clés déléguées opaques par identité peut être limité.
Le premier message peut être envoyé sur une adresse publiquement associée au destinataire. Le scan des messages reçus est alors simple. On sait juste qui a reçu un message, mais pas de qui.
Le double-ratchet utilisant déjà des secrets partagés, dès le deuxième message on peut dériver de ces secrets une adresse de rendez-vous, qui changera à chaque échange dans la conversation.
Si on veut empêcher un observateur extérieur de savoir que plusieurs messages sont dans une même conversation, on peut changer de clé déléguée opaque à chaque échange, mais le processus de signature en anneau risque de devenir un facteur limitant (c’est très coûteux à signer et à vérifier, et il faut beaucoup de participants pour avoir un bon anonymat).
Si on veut pouvoir utiliser moins de clés déléguées onchain, on peut ajouter aux datapods une sorte d’authentification fédérée : un datapod qui accepte de pinner des messages provenant de clés qu’il connaît offchain. Soit on fait confiance en l’admin de son datapod, soit le datapod a ses propres rounds de signature en anneau offchain.