Je tiens à vous présenter mes excuses pour le manque de nouvelles concernant le développement de Cesium v2.
Voici les principales avancées réalisées :
Mode Dégradé : L’application fonctionne désormais en mode dégradé si le datapod est absent, assurant ainsi une continuité de service.
Vérification des Réseaux : Une fonctionnalité de vérification de la disponibilité des réseaux a été implémentée, évitant ainsi l’utilisation de réseaux inactifs.
Affichage des URLs : Les URLs utilisées sont maintenant affichées clairement dans les paramètres, remplaçant l’affichage du premier élément de la liste.
Écrans de Pré-certification : Les écrans de “Vérifications avant certifications” ont été ajoutés, améliorant le processus de certification.
Moi j’aime bien l’approche de Gecko, bouton absent si on n’est pas membre, bouton grisé si la certif est impossible : délai entre 2 certif émise, déja certifié, ou invitation pas encore acceptée.
Si c’est pour renouvellement de certification pourquoi pas, à savoir combien de temps après la fin de validité de la certification ce bouton est encore affiché.
Si c’est pour le renouvellement d’adhésion, je n’ai pas l’impression que ce bouton soit à sa place dans l’annuaire, mais plutôt sur la page du compte concerné.
J’espère que le contrôle de la règle de distance se fait pour le certificateur.
Car si c’est pour le certifié, ça n’a pas de sens, si l’on considère que c’est la somme des certifications qui lui permettra de respecter la règle de distance.
Dans les paramètres, il est maintenant possible de définir une période afin de récupérer automatiquement le dividende universel pour les membres.
Les périodes disponibles sont “Quotidien”, “Hebdomadaire” et “Mensuel”
Il me semble qu’il serait plus simple que les utilisateurs ne s’occupe pas du tout de cette récupération de DU, cela devrait se faire sans intervention de l’utilisateur.
Oui, la réclamation des DU doit être transparente et intégrée automatiquement dans un batch lorsque l’utilisateur effectue une transaction.
Le fait que les DU soient réclamés manuellement est une optimisation purement technique. Cette notion ne doit pas apparaître dans les wallets grand public ; à la limite, en mode expert, pourquoi pas.
@zoltounet, pour faire simple, tu peux commencer par batcher un appel claimUds à chaque transaction de l’utilisateur. S’il n’y a pas de DU à réclamer, l’appel se terminera dès le début, donc le surcoût d’exécution est négligeable.
Mais il n’y a pas un risque de recevoir des amendes si l’utilisation fait trop de transaction ? Egalement, si le nombre d’utilisateurs grossi sur le moyen/long termes, l’impact risque de ne plus être négligeable?
Egalement par défaut, le paramètre est défini en “hebdomadaire”.
La version qui est disponible en release(qui date de 3semaines) sur le git ne contient pas les correctifs que j’ai implémenté récemment.
Je vais voir avec @kimamila pour faire une release dès que possible.
Si c’est dans un batch, ça compte pour une seule transaction. L’overhead reste négligeable. Sinon, compare juste le CurrentUdIndex avec le firstEligibleUd de l’utilisateur. Tu peux demander à @poka comment il a fait dans Gecko.
Non, les calculs du call claimUds ne dépendent pas du nombre d’utilisateurs.
il faut vraiment masquer cette histoire de réclamation des DUs par défaut dès le début.
Si 10 000 utilisateurs réclament une fois par jour, ça fait environ 1 extrinsic par bloc.
Les extrinsics sont gratuits tant que les blocs ne sont pas près d’être saturés. Il serait possible de vérifier le quota actuel avant de soumettre des extrinsics automatiques mais avec le nombre d’utilisateurs actuel ce n’est pas urgent.
J’ai reboucler avec @kimamila pour le claim de l’UD, on va ajouter le mode expert et cette configuration sera uniquement présent dans ce mode. Sinon elle sera masqué et le claim ne sera effectué qu’au moment du chargement du compte.
Egalement, j’ai commencé à réaliser l’équivalent de la page “Réseau” pour Cesium v2.
