Fort heureusement on avait déjà calculé qu’après 4 à 10 années de développement, des personnes plus proches des utilisateurs que nous allaient se pointer. Te voilà. Tu n’as plus qu’à dialoguer avec @kimamila. 
1 Like
Quels autres termes serait plus compréhensible que “compte inactif” ?
Ou est l’erreur dans ce qui est dit ?
EDIT: d’ailleurs il y avait encore plus d’erreurs AVANT la mise ne oeuvre de ce message 
Les gens croyait etre connecté à leur compte… mais non pas simple les applications web unhosted !
on pourrait utiliser : “il semble que compte soit inactif (mais utilisable)” ?
stp ne dénigre pas ma contribution, c’est déjà un premier pas important que je fais en soumettant un “bug d’usage” (et une recommandation de solution), si tu me rabroues alors que je commence à contribuer, ça baisse ma motivation à aller plus loin en soumettant des pull requests ou des edits de wiki etc
“Il me semble que ce compte n’est pas membre, et ne peux donc pas produire de monnaie” ?
Tu soumets cette contribution (c’en est une) sur le dépôt github de Cesium, je ne rabroue pas, je l’ai déjà indiqué plus haut. Ce problème de cas utilisateur n’existe pas dans Sakia / Silkaj, quji sont d’autres clients, il ne faut donc pas mélanger un problème d’interface utilisateur d’un client particulier avec le développement de la monnaie et des autres clients.
pas sûr. Que se passe t il si on rentre des mauvais identifiants ?
Et attention, Cesium est une application web, qui a forcément une ergonomie différente, du fait de l’absence de stockage local “fiable” comme une base de données pour stocker les comptes.
Tu as une bonne vue à cette adresse : https://duniter.org/fr/wiki/
Tu as la liste des plateformes d’échanges
Tu peux utiliser un Clients (c’est en fait un logiciel permettant, entre autre, de te connecter à ton portefeuille)
Tu peux être membre ou non, il n’y a pas d’obligation. Le statut membre permet de recevoir un Dividende Universel et, si tu le souhaites, participer à la création de monnaie.
Sans être membre, tu peux “commercer” avec d’autre personnes acceptant la Ğ1.
En fait le problème des erreurs de saisie existe tout autant sur les autres clients, mais les utilisateurs n’ont pas le même profils techniques. Les développeurs n’ont donc pas eu besoin de gérer le cas d’erreur de saisie.
EDIT: d’ailleurs ont pourrait enlever le message pour le mode expert de Cesium, ce qui correspondrait aux même profils d’utilisateurs que les autres clients.
@Galuel que faut il en conclure selon toi ?
Tu définis “mauvais identifiants” (dont la signification me semble pour le moins obscure), tu notes l’utilisation de Sakia / Silkaj dans le cas précis qui te préoccuperais, et tu fais une issue github au besoin.
Personnellement je trouve que Sakia est un client parfait, précis, opérationnel, efficace et clair.
Rien. Il y a une infinité de comptes Ğ1, aucun n’est a-priori “inactif”. Il y a des comptes membres et des comptes non-membres, c’est tout.
Sakia permet de sauvegarder la liste des comptes avec lesquels ont effectue des mouvements, qu’ils soient membres ou non-membres n’a aucune sorte d’importance.
Cas d’utilisation : “l’utilisateur fait une erreur de saisie dans ses identifiants, et valide sa connection”.
L’utilisateur ne comprend pas pourquoi sa demande d’adhésion n’est pas visible, et que son solde apparait à 0, etc.
aucun rapport avec la choucroute
C’était bien le comportement de Cesium dans les premières versions : tous identifiants saisis permettant l’affichage du compte lié.
C’est pourquoi j’explique qu’une application web est forcément différente dans son ergonomie, sauf à gérer une sauvegarde de compte déléguée à un tiers, accessible par un compte login/mdp indépendant (ce qui correspondt dans le cas de Sakia/Silkaj au login/mdp de ton compte unix), afin de protéger la dite sauvegarde.
Faut-il aller vers cela : une sauvegarde (quelque part) des comptes ajoutés ?
1 Like
Le mot inactif peut avoir le sens précis ici : compte non membre avec 0 mouvements de fonds en blockchain + piscine, et 0 identités en piscine également. Tandis qu’un compte actif montre au moins l’une de ces activités, et dénote que quelqu’un en a déjà l’accès.
Compte inactif fait donc sens à mes yeux, après comme le suggère @swergas tu peux ajouter des pistes de compréhension supplémentaires.
C’est un bug utilisateur ça, pas un bug logiciel. Si j’entre dans une automobile et que je ne comprends pas que ce n’est pas la mienne, alors je peux m’étonner en effet que la couleur n’est pas la même, la clé ne marche pas, le plein d’essence a changé. C’est pas un problème lié à l’automobile.
La bonne relation avec un compte se fait avec la pubkey, certainement pas avec les passwords qui ne sont nécessaires que pour faire des certifications / mouvements.
Ca me semble une bonne piste en effet.
En visant le plein contrôle de l’utilisateur = sauvegarde locale protégée par un password local, dans un dossier local visible et choisi par l’utilisateur.
impossible (il me semble) en web. Peut-être dans certain navigateur, via des plugins ?
Livrer un petit serveur web contenant une application de gestion est tout à fait possible. Une sorte de keypass web/Cesium
Si bien sûr tu peux, tu stockes en JSON par exemple (on a pas 50Mo de données non plus) et tu le chiffres avec un mot de passe.
Personnellement j’aurais bien aimé avoir cette solution, par contre niveau sécurité ce n’est pas top si le flux JSON chiffré est compromis et que le mot de passe est léger.
tu veux dire qu’après ouverture tu n’aurais pas besoin de d’authentifier ? tu inclus la clef secrete dans le truc ?
A priori, si seule la clef publique (et les paramètres de compte) sont présents dans ces données, il n’y a pas de risque de sécurité.
Oui je pensais à inclure la clé secrète dans le truc, pour éviter d’avoir à retaper mes identifiants secrets super longs.
Mais sans stocker la clé privée, aucun risque ni besoin de chiffrement.
ok je vois.
Bah j’avais en tête effectivemt un “code pin”, comme on avait fait dans Duniter App.
Cependant je penses que le cas d’utilisation n’est pas le même que celui évoqué plus haut.