La transaction est un lien

March 29th, 2020

Après réflexion il est préférable de traiter la transaction dans le code comme un dérivé de lien et non d’objet.

La première raison est assez simple puisque un lien est suffisant pour marquer une transaction si cela ne concerne qu’un jeton entier. C’est le mode de transaction le plus simple et il est développé en ce moment dans la bibliothèque sur le nom LNS (mode par Lien et jeton non sécable).

La seconde, c’est qu’un lien de transaction peut désigner un objet qui porte toutes les transactions unitaires. Dans ce cas on peut traiter simultanément plusieurs jetons et plusieurs parties de jetons. Mais on doit rester dans une seule monnaie.

Valeurs relatives

February 23rd, 2020

Il y a deux formes de relativités pour la valeur des jetons. La première est externe à la monnaie du jeton avec un taux de change depuis/vers un jeton d’une autre monnaie. La seconde est interne à la monnaie lorsque l’on fait varier sa valeur par rapport aux autres jetons de la monnaie.

Champ action du lien – action supplémentaire de transaction

February 16th, 2020

Il était possible de créer une nouvelle action dédiée aux transactions et non annulable, cf l’article Lien de transaction, ce qui aurait nécessité une grosse modification du code de la bibliothèque.

Finalement cette nouvelle action ne sera pas implémentée, il est possible avec la gestion des relations sociales spécifiques à une monnaie de supporter une suppression de transaction par son initiateur mais sans effet de cette suppression si la transaction a déjà été validée par ailleurs.  dans ce cas c’est comme si la transaction marqué par l’utilisateur était une demande de transaction et que celle-ci était validée par une autorité reconnue au niveau de la monnaie.

Bonne année 2020

January 5th, 2020

Aucune publication de code n’a été faite depuis le 8 mai 2017. Les différentes applications sont toujours en cours de ré-écriture avec la nouvelle partie graphique intégrée à la bibliothèque nebule. Et elles rejoignent progressivement la mise en pratique de la Réflexion sur l’évolution de l’interface web pour nebule. Cependant une publication en cours de migration avec des modifications partielles serait catastrophique pour l’utilisabilité des applications.

Gestion de la hiérarchie dans la monnaie et les jetons

December 22nd, 2019

Lorsque l’on crée une monnaie, on lui attribue une unique entité autorité AID.

Cet autorité de la monnaie délègue la gestion de la monnaie à une ou plusieurs entités gestionnaires MID.

Les gestionnaires de la monnaie forgent un ou plusieurs sac de jetons PID.

Pour chaque sac de jetons, un gestionnaire de la monnaie délègue la gestion du sac de jetons à une ou plusieurs entités gestionnaires MID.

Les gestionnaires d’un sac de jetons forgent des jetons TID.

Il est possible d’attribuer les rôles à une seule entité.

Forçage de la monnaie dans les jetons

December 7th, 2019

Jusque là dans le code on essayait de retrouver la monnaie lorsque que l’on instanciait un jeton ou un sac de jeton. Ou plutôt on injectait l’identifiant de la monnaie dans l’instance du jeton pour pouvoir récupérer des valeurs héritées essentielles.

Cette méthode pose problème parce qu’il faut justement préalablement connaître la monnaie dans laquelle le jeton est utilisé. Il est théoriquement possible de retrouver la monnaie d’un jeton que l’on souhaite utiliser en exploitant les liens du jeton qui le lie à une monnaie. Mais comme le jeton non forcé affilié à une monnaie peut être associé à plusieurs monnaies, en l’absence de l’indication de la monnaie celle-ci est déduite d’un traitement social sur les liens avec la monnaie. Et donc qui dit traitement social des liens dit aussi possibilité manipulation, et donc problème de confiance.

Pour réaliser une transaction il faudrait préciser un jeton et une monnaie, soit à peut près le lien de rattachement du jeton à la monnaie. Le but est de ne pas utiliser des liens dans les transactions mais des jetons (objets) ou des fractions de jetons (via des liens de sous-parties d’objets).
Donc l’implémentation actuelle ne convient pas.

Pour résoudre ce problème d’implémentation, la monnaie devient un paramètre obligatoirement inscrit dans l’objet du jeton. Et c’est le cas aussi pour le sac de jetons. Ainsi le champs CID doit apparaître dans l’objet du jeton en ligne 3 de la même façon que le champs AID était devenu obligatoire en ligne 3 des objets des monnaies.

Génération de monnaie fonctionnelle

November 14th, 2019

La génération et l’affichage des monnaies, sacs de jetons et jetons sont fonctionnels même si pas encore complètement terminés.

Le travail continue maintenant sur les portefeuilles et les transactions.

Un portefeuille est un dérivé des entités. C’est le portefeuille qui sera l’élément actif des transactions vers d’autres portefeuilles.

Entité autorité forcée dans les monnaies

November 2nd, 2019

Aujourd’hui, le code force déjà l’écriture d’un objet pour une monnaie, c’est à dire que le paramètre HCT est forcé à true lors de la création d’une monnaie. Et c’est pareil lors de la lecture des paramètres d’une monnaie, on va aujourd’hui essayer de lire l’objet même si là le code est plus tolérant.

Pour les monnaies, les jetons et sacs de jetons, seuls les paramètres TYP et SID étaient obligatoirement écrits dans l’objet. Pour la monnaie on impose maintenant aussi l’écriture du paramètre AID, c’est à dire l’entité autorité de la monnaie générée.

Sans le forçage de l’AID, lors de la recherche des monnaies disponibles, pour un même CID ou SID nous pouvons avoir plusieurs entités qui se déclarent AID. Cela se traduit par des monnaies différentes sans qu’il n’y ai de conflit mais l’affichage peut être ambiguë. Donc pour éviter toute ambiguïté, on force par défaut l’AID.

Le code pourra évoluer plus tard pour permettre de lever cette ambiguïté et le forçage correspondant.

Désactivation de paramètres d’une monnaie

November 1st, 2019

Le travail sur la génération d’une monnaie et de ces composants se poursuit.

Il apparaît un problème potentiel au niveau de la monnaie qui ne se manifeste pas sur ses composants.

Un jeton va voir certaines propriétés imposées par la monnaie dans laquelle il est utilisé puisqu’il peut être utilisé par plusieurs monnaies avec des caractéristiques et buts différents. Dans ce cas un paramètre forcé sur un jeton n’est pas remplaçable par la monnaie, mais après tout si on utilise les jetons de quelqu’un d’autre on en assume les effets secondaires. Sinon lors de l’utilisation du jeton on remonte à a monnaie associée pour voir les paramètres à utiliser. Si on force le CID d’un jeton on le réduit donc à un usage strict dans la monnaie d’émission.

Cependant si on peut forcer un paramètre dans une monnaie il n’est pas possible aujourd’hui de le forcer vide, c’est à dire de ne pas l’utiliser et d’en interdire un usage ultérieur. Il va falloir voir comment implémenter ça.

Nouveau logo

October 27th, 2019

L’application qantion a maintenant un nouveau logo :

qantion_logo_256