séparations des certifications en attente / validées.
Ces dernières évolutions sont très utiles (voir indispensable) pour une monnaie avec des paramètres de production, par exemple lorsqu’un délai de plusieurs jours est fixé entre deux certifications sucessives, et que celles-ci ont une durée de vie limité à quelques semaines/mois. Les tests actuels sur le Sou nous aident bien à défricher ce terrain (impossible de s’en rendre compte sur test-net).
Bref, ca avance, mais sur Test-Net vous ne verrez quasiment pas de différence !
Bons tests !
##La suite ?
Les tests du Sou montrent également le besoin de nouvelles fonctionnalités, du type :
pouvoir envoyer des demandes de certifications, aux membres que l’on connait, y compris par email si renseigné dans le profil (et activation dans les paramètres) ;
pouvoir suggérer des postulants à des membres que nous connaissons (idem : avec envoi de mail si activé)
Et plus tard (plus technique à réaliser - nécessitera des fonctions de requetage de la BlockChain) :
faire de suggestion : “Connaissez vous (…)” à partir des personnes postulantes certifié par des gens qui nous ont certifiés.
Il y a encore et toujours un lien intégré vers une application économique spécifique, qui fait de la publicité pour une offre économique parfaitement indépendante de la monnaie. C’est incorrect de lier la gestion d’une monnaie libre à une valeur économique donnée.
Oui, je sais bien que le lien vers les annonces te dérange. Inutile de le redire à chaque fois, puisque j’ai déjà dit que j’allais découper en deux applications.
Je fais de mon mieux pour stabiliser Cesium le plus possible (la partie paiement et gestion de comptes) avant d’effectuer le découpage. je prends le temps qu’il faut, tant pis pour les impatients. Par exemple, je me rends compte que la partie “gestion de profil” doit rester (en option) dans Cesium. Elle remplace l’utilisation d’un forum pour déclarer son identité plus précisément. Idem pour les messages. Sortir ces fonctionnalités trop hativement m’aurait obligé à revenir en arrière.
Les tests sur le Sou me permettent d’affiner le périmètre du futur Cesium : ce qui est indispensable à la constitution de la toile de confiance, ou non. Pour moi, définir un périmètre clair n’est pas si simple.
On pourrait par exemple imaginer d’avoir une gestion de profil à part, style “gravatar”. Et des applications clientes qui utilise ou non, via une API, ces données de profil. Mais cela nécessite de définir une API précise pour communiquer avec. Avoir une seule application me permet de travailler sur le besoin, en premier lieu, puis de pouvoir définir une API.
Mais peut-etre existe-il déjà des API compatibles ? genre open-ID & Co.
(Par contre, au passage : il ne s’agit pas d’une “offre économique”, mais d’une application pour gérer des offres économiques. l’application en elle même ne vend strictement rien.)
Tout application permettant des échanges économiques devient de facto une valeur économique. Ainsi Ğchange pourra tout à fait proposer des investissements en monnaie libre (ou autre valeur économique), pour payer des développements spécifiques.
“Libre” ne signifie pas “gratuit” et “libre” ne signifie certainement pas non plus “non-valeur économique”.
Bien sûr qu’il faut une API VERS Cesium. Tout comme quand on est sur une plateforme d’échange quelconque sur le net, centralisée ou pas, la fonction de paiement se fait toujours via un prestataire de paiement extérieur, qui reçoit les données nécessaires à la transactions, qui s’effectue sur un n° de compte (ou de CB) quelconque vers le vendeur, et ensuite retour au magasin…
De sorte que Cesium pourrait intégrer une API toute simple, qui serait de la forme http://cesium.glibre.org?clédelemetteur=x&clédureceveur=y&monnaie=z&montant=m . Une application externe de vérification d’identité pourrait avoir aussi une API qui permette la vérification via http://verifid.glibre.org?monnaie=m&verifID=clépublique permettant d’avoir des informations enrichies qui aident au contrôle du receveur, et tout ceci sans rapport avec cesium, portefeuille de base, qui n’a pas à connaître ces applications extérieures, qui ne sont qu’un exemple parmis une infinité de créations possibles par les membres d’une monnaie libre.
Tu peux entièrement désactiver les extensions sur ton cesium.glibre.org, simplement en éditant le fichier config.js, et en supprimant la partie plugins.
Ca c’est ta définition de Cesium, mais je ne sais pas où tu l’as trouvé. Ce n’est pas la mienne et c’est pourquoi ces échanges sont infinis et ne convergeront jamais.
Rien ne t’empêche de faire une application de portefeuille de base, avec juste des accès à l’API BMA de Cesium. Moi cela ne m’intéresse pas, car l’API BMA a de nombreuses limites qui nécessitent d’avoir des API complémentaires (pour des accès plus rapides, des informations plus détailées comme le profil, etc) donc de facto d’autres lieux de stockage (type ES ou autre).
De même, rien ne t’empêche d’utiliser une autre moyen que ce forum pour connaitre les utilisateurs qui attendent des certifications dans TestNet. Le forum duniter.org n’est pas obligatoire pour faire fonctionner la monnaie (d’ailleurs il est centralisé, donc à terme c’est un point de faiblesse s’il est nécessaire !).
Toutes ces API connexes exploitées par Cesium sont pour moi très importantes : un client web pourra difficilement s’en passer, pour un utilisateur qui souhaite les meilleurs performances et fonctionnalités possibles.
Je développe l’outil qui ME sera utile, en premier lieu. Je ne cherche pas à faire ce que tu as en tête (même si c’est surement très bien pour toi). Les développeurs sont souvent les premiers usagers de leur outil. C’est ainsi qu’il sont motivés pour que cela avance.
C’était au moins la définition du prototype que j’avais fait à l’époque, et qui s’appelait Cesium. Si tu fais autre chose, le mieux serait de changer de nom pour éviter la confusion, non ?
Ce serait honnête en effet de ne pas appeler du même nom une version dépréciée du portefeuille de base qui fait l’intégration d’applications tierces qui n’ont pas de rapport avec la gestion de sa monnaie, et qui oriente de facto l’utilisateur vers des utilisations spécifiques.
En terme de développement et d’intérêt pour des développeurs en sus, isoler les fonctionnalités indépendantes est le fondement même de toute approche objet.
En tout état de cause le nom “Cesium” ne peut pas être utilisé sans l’accord de son fondateur quel que soit son avis sur la question (tout comme Ğmarché est l’initiative de kimamila, son utilisation lui revenant).
Franchement, vous me fatiguez avec ces discussions…
Je parle bien d’utiliser des API annexes, ce que Galuel juge hors portefeuille de base, donc hors Cesium.
Alors que tu dis toi même (@cgeek) que c’est aux clients d’utiliser des API annexes pour être plus efficaces.
Ca se mord la queue…
Par exemple, je travailles sur les certiications, et m’apercois que les temps de réponse ne seront vite plus bons, si je veux afficher la date/heure des certiications (il me faut, à partir du numéro de bloc, récupérer tout le bloc juste pour avoir l’info “médianTime”). Il me faudra bien utilier un noeud ES qui me donnerait l’info d’un seul coup, et non bloc par bloc, non ?
Tu pourrais simplement différencier Cesium et Cesium+ ou Cesiumplus, ou un truc du genre, mais isoler la gestion du portefeuille de tout ajout de fonctionnalités tierces (Ğmarché, identitié enrichie)… C’est juste ça !
[quote=“kimamila, post:10, topic:1390”]
Tu parles donc de retirer toutes utilisation d’indexations annexes à celle des noeuds ?
Toute gestion de profils ou envoi de message ?[/quote]
Tout à fait, tout ce qui ne concerne pas Duniter de base. De manière à bien différencier “je gère ma monnaie Duniter” avec “j’ai des applis enrichies tierces”.
Si c’est isolé c’est très bien. Ca me paraît le mieux dans tous les cas. Mais créer un “Cesium+” en le différenciant par le nom et la forme irait bien aussi (moins bien à mon sens, car moins orienté objet dans l’idée).
C’est bien de cela dont je parle, ainsi que les données de profil. Ce sont des données qui ne font pas partie du protocole Duniter, mais d’un autre que tu as toi-même défini. Et donc ça n’a pas à faire partie de Cesium, mais pourquoi pas partie de gchange, gprofil, l’un, l’autre, ou les deux.
Car les utilisateurs pourraient très bien utiliser d’autres outils encore pour réaliser leurs annonces, donner des informations de profil, etc.
Non Galuel parle des annonces et données de profil hors protocole Duniter. Utiliser une API tierce comme ES pour récupérer les données de la blockchain est très bien oui, mais si c’est pour aller chercher des informations tierces, alors ce n’est plus la même chose : on parle bien des données communes à tous les utilisateurs. Or tous n’ont pas à remplir un profil dans Cesium pour utiliser la monnaie.
Pour aller récupérer des données tierces, alors autant utiliser une application dédiée à ces données tierces. C’est important de pouvoir discerner le commun du tiers dans le cadre d’un outil commun.
Maintenant, Cesium masque complètement les certifications « en attente » qui ne seront jamais inscrites, car redondantes avec une certification déjà écrite et valide (ET valide jusqu’à la certification de validité de celle qui est en attente d’écriture).
J’ai aussi revu l’affichage du nombre de certifications, pour rendre visible celles en attente :
Merci Kimamila pour avoir réglé mon problème de certifications. Je n’ai pas été assez attentif, du coup je n’ai pas bien compris la bourde que j’ai faite et pas pu te faire un retour correct. Bon travail !
@Mententon_03 non, rassures toi tu n’avais pas fait de “bourde” C’est juste que certaines certifications affichaient de mauvaises dates, lorsqu’une même personne (Jean) t’avait certifié plusieurs fois…
Par ailleurs tout cela m’a aider à améliorer nettement le code qui récupère ces certifications.
Mais il reste encore du boulot, car je me suis apercu hier que je dois aussi tester lesquelles sont invalides, car émises à partir d’un bloc qui n’existe plus (=une page du grand livre de compte de la blockchain) car annulé par le réseau de noeuds… Bref, je vais essayer de détecter ces certifications et de proposer à l’utilisateur de les resoumettre, sur un bloc valid, en 1 clic.
C’est fait (pour la prochaine version de Cesium) : la détection des certifications invalides apparaitra dans “Certifications en erreur”. Il faudra en revanche attendre la prise en compte de la demande d’évolution #708 dans Duniter.
C’est juste que certaines certifications affichaient de mauvaises dates, lorsqu’une même personne (Jean) t’avait certifié plusieurs fois…