Est-ce que ça serait, ou pas, une bonne idée de différencier 2 types de clients ? (Pour les utilisateurs bien entendu, les deux clients peuvent être builder conjointement, à partir du même code, mais donner deux livrables ^^).
1- les clients se voulant très secure, pour la gestion du compte membre, avec répartition du DU vers des portefeuilles, et gestion des certifications (et des utilitaires à la wotwizard pour comprendre l’impact d’une nouvelle certif).
2- les clients pour la gestion de portefeuilles, et réaliser des transactions (et pourquoi pas des transactions avec conditions, un système compta, de facturation…).
Est-ce que ca a déjà été discuté ? Qu’en pensez-vous ?
On nous reproche déjà la multiplicité des clients, si en plus on divise un même client en deux applications…
Pour avoir construit mon architecture from scratch hier et avoir rencontré un problème dans celle-ci, que j’ai résolu, je ne me vois pas réfléchir sur un projet coupé en deux. C’est une contrainte de plus à gérer. Deux livrables à tester et à maintenir. Pour un développeur, c’est plus facile de faire deux projets et encore bien plus facile de n’en faire qu’un seul.
@yyy comme tu poses spécialement la question, je réponds brièvement que oui tu as entièrement raison, et que je suis un train de bosser sur un nouveau client android/ios spécialement conçu pour les paiements.
En argument pour, je me dis que ça pourrait simplifier la communication, et l’usage pour les nouveaux et les professionnels :
le client compte membre, faut y faire attention, il ne faut pas l’installer et l’utiliser n’importe où n’importe comment, c’est que le notre, on y gère son DU, la compréhension et l’acception de la licence est préalablement nécessaire, on vérifie bien de ne pas envoyer ses certifs trop vite…
le client portefeuille, n’importe qui peut l’utiliser, c’est le client des nouveaux, on se moque de la licence, c’est le client à utiliser pour gérer ses différents portefeuilles, mais aussi pour gérer les portefeuilles de ses associations/entreprises, portefeuilles également géré à plusieurs…
En argument contre, effectivement, c’est un peu plus de boulot pour les devs, c’est sûr ^^
Je ne distinguerai pas exactement les cibles ainsi mais dans l’idée oui, un client qui fait bien le taf pour un usage précis, plutôt truc trop lourd qui fait tout.
Le client de paiement sera pour … bah payer en fait ^^ faire ses achats, avec un truc simple et rapide.
La gestion de la wot demande plus de fonctions peut être, mais un client spécialisé là dessus serait une superbe idée.
J’imagine plutôt un client où les parties « membre » et « portefeuilles » sont nettement séparées dans l’UI.
Avec, pourquoi pas, un modèle de sécurité différent :
les seeds des portefeuilles sont générées par le logiciel, chiffrées et protégées par un mot de passe unique
la seed du membre est générée par le logiciel, n’est pas enregistrée mais donnée comme phrase de passe à retenir et entrer à chaque fois. (en fait, c’est le meilleur moyen pour que les membres notent la seed en clair… Pas forcément une bonne idée, donc.)
L’installation par défaut pourrait ne montrer que la partie « portefeuilles », et une action serait requise pour activer la partie « membre ».
C’est une idée.
Pour le client oui ceux qui veulent faire quelque chose de plus généraliste mais avec une UX totalement différente de Cesium ce serait top aussi.
Pour la seed je pars sur le choix N°1. Générer à partir d’un mnemonic unique, stocké et protégé par un code PIN alphanumérique à 6 caractères.
J’en discute avec Elois qui va m’aider et continuer de mon conseiller sur cette partie.
Ca permet aussi, pour un nouveau dev, de devoir se faire la main que sur une partie, sans être dérangé par l’ensemble, et sans trop de risque de sécurité : oui, des junes sont sûrement en jeu, mais c’est moins pire que le parte/vol de centaines/milliers de compte membre
Une fois cette partie maîtrisée, on peut plus sereinement s’attaquer à la partie où la sécurité est plus critique
Ou en contraire, continuer à améliorer son client de paiement sans être dérangé par d’autres considérations techniques qui concernent les compte membre
Any client MUST deal, in a secure manner, with private-key material… I don’t see that tx’s are less (or more) important to protect than identity/membership/certification/revocation.
The very first question that every new Cesium user should NEVER have to deal with is the choice between Member Account, and simple-wallet… imho, its the very first and completely unnecessary ui/ux choice/flaw offered by Cesium… because we can all convert any simple wallet into a member account once we’ve started to understand why this is important and desirable.
I too view transactions as a different use-case than member actions, so I could certainly imagine the simplest of wallets ONLY dealing with private-key creation/securization and transactions… while full-featured clients would also have a module that plugs-in for member actions.
Je trouve l’idée intéressante, cela permet d’utiliser un outil optimisé en taille de ressource pour le type d’action que l’on veut réaliser.
Par exemple sur un équipement autonome de paiement la totalité des fonctionnalités ne sont pas nécessaires.
Je trouve l’idée très bonne d’autant que ça résout le double problème des terminaux mobiles : peu fiables en termes de sécurité et technos plus restreintes pour pouvoir fonctionner sur iOS et Android.
Du coup je pense que le mieux c’est :
Un client mobile natif destiné gestion de portefeuille uniquement
Un client desktop qui fait tout.
Ainsi, pas besoin de découper e deux un même projet, comme le dit @vit c’est plus chiant à gérer. Il vaut mieux 2 projets différents maintenus par des dev différents.
Je pense qu’on va vers un bel avenir si on se dirige vers :
Un super client mobile pour la gestion de portefeuilles : @poka a commencé quelque chose et je compte l’aider
Un client desktop complet qui fait tout. Pour que ce client soit intuitif il vaudrait qu’il soit en mode «simplifié» par défaut avec uniquement les fonctionnalités de base pour gérer son compte membre. Et que toutes les fonctionnalités non-essentielles ne s’affichent qu’en mode expert.
Du coup c’est ma question @vit, quelle est ta vision pour Tikka ?
Car perso je trouvais sakia génial pour un utilisateur avancé comme moi mais beaucoup trop compliqué a utilisé pour un utilisateur lambda. Serait tu ok pour intégrer un mode «simplifié» ?
Concernant les questions de sécurité autour de la génération de la seed notamment, je vais créer un post dédié, car il y a beaucoup à dire…
Oui c’est exactement ce que je désire, une interface simple par défaut. Car un développeur est aussi un être humain, et un fainéant (il a inventé le principe KISS et DRY pour coder le moins possible, le bougre).
Mais avec des options avancées que je vais essayer de planquer le plus possible, car elle ne concerne que les testeurs ou les initiés.
Bon ça c’est sur le papier, prévoyez de belles engueulades au RML (« pourquoi t’as pas fait comme ça, moi j’aurais fait autrement… ») !
Nul besoin de les «planquées» chacune différemment. Il suffit d’avoir dans les paramètres une option «activer le mode expert» qui fasse alors apparaître toutes les fonctionnalités avancées
Cette option doit bien entendu être désactivée par défaut et être mémorisée dans la config sauvegardée, afin de ne pas avoir besoin de la réactiver a chaque démarrage).
(Naissance aujourd'hui de Tikka, un nouveau client!), me revient une réflexion :
