Mouais, toujours pas convaincu, on pourrait en discuter en vrai si tu veux. Je vois l’intérêt théorique, mais pas du tout la pertinence pratique en ce moment. Je rajoute quand même deux questions qui me sont passées par la tête entre temps :
- est-ce qu’on change le random id quand on change la owner key ? (je propose que non)
- est-ce qu’on pousse la logique jusqu’à pouvoir faire un virement / une certification vers un random id plutôt que vers une adresse (sauf dans le cas de la création de compte, bien entendu) ?
Mon impression générale est que c’est une challenge inutile d’implémenter des trucs compliqués côté serveur si on n’a pas les ressources pour le documenter, l’implémenter dans les libs, l’implémenter dans les clients, l’expliquer aux utilisateurs… Concrètement, ça ne sert à rien de se faire chier côté Duniter à implémenter le random id, d’émettre l’événement RandomIdAssigned si Ğecko / Cesium ne se sert pas du random id et que l’indexeur n’écoute pas l’événement. Vu les forces actuelles dans le projet, il vaut mieux viser un truc archi minimal mais fonctionnel qu’avoir des ambitions supérieures, mais qu’on ne peut pas réaliser. Je suis favorable à de la R&D quand ça concerne notre cœur de métier (monnaie libre, démocratie, toile de confiance) mais défavorable quand ça concerne des trucs généraux (sécurité, blockchain…). Même avec des bonnes idées, on n’a pas encore les ressources pour les développer et les diffuser assez vite pour qu’elles ne soient pas ré-inventées par Parity ou autre. Donc toute contribution est bienvenue, mais je ne bosserai pas dessus personnellement, et sachez que toute fonctionnalité présente mais non documentée me ralentit car cela nécessite de rétro-ingénierier le code et fouiller le forum à la recherche d’explications.
Qu’entends-tu par “nécessaire” ? On ne peut pas s’en passer ? Où sont les identicônes dans Duniter v1 ? As-tu une idée quantitative du nombre d’erreurs qui auraient pu être évitées par leur présence ?