Cesium² : top départ!

kimamila · 2 September 2022 21:50

Bonjour à tous,

Je suis content de vous annoncer que Cesium² est maintenant en phase active de développement. Il tourne déjà, pour le moment en version web et Android.

La création de compte commence à fonctionner pas trop mal : « compte v2 » bien sûr (avec phrase de récupération et code secret), mais aussi v1 (salt+mot de passe). Le processus de migration d’un compte v1 reste encore à faire, mais j’ai les idées claires (enfin je crois) pour y arriver avec l’aide des autres développeurs (merci @poka, @tuxmail, @vit, etc.).

En plus de création de compte (et consultation), les paiements fonctionnent : Youpi !

Pour le moment, le contenu afficher dans l’annuaire est bidon. En gros il affiche les comptes de tests (Alice, Bob, Fredie, etc.).

Les interfaces sont pour le moment très restreintes et simpliste. Le but était surtout de poser les bases du logiciel. La gestion des clefs notamment, et les entrées du menu, etc.

Reste maintenant a intégrer la gestion de la toile de confiance (certifications, adhésion), et à gérer la partie graphQL pour récupérer les données indexées (historiques des transactions, etc.)

Tout n’est pas encore traduit, notamment pour la partie création de compte V2.
Pour le reste je bénéficie des anciennes traductions, donc ca couvre pas mal de cas de figure.

« Mais pourquoi faire Cesium² ?! »

Mon objectif avec Cesium², est de proposer une migration en douceur, pour les utilisateurs de Cesium v1. C’est à dire qu’ils ne soient pas trop perdus dans la navigation et les menus, et qu’ils montent en niveau presque sans s’en apercevoir (sur la sécurité notamment)

Par ailleurs, il est bon que plusieurs logiciels de paiement soit opérationnel, pour gérer d’autre approche ou cibler d’autres usagers, matériels, etc.

Et puis, coder un logiciel client permet aussi d’échanger sur les fonctionnalités, entre développeurs, et à partir de choses concrètes. On peut ainsi explorer des pistes, au niveau ergonomique, revenir en arrière, repartir, s’inspirer de ce que font les autres logiciels client, etc.

Bref, cela me semble utile.

Technologies

Les technologies utilisées sont :

Angular 14, Ionic 5 : pour la gestion des composants, écran et style; En gros c’est de l’HTML, avec des services écrit en TS;
, Capacitor : pour le dialogue avec le matériel (Android, iOS),
polkadot-js et polkadot-ui : pour la gestion des clefs de compte, connexion à l’API Duniter V2. Les typages de l’API, en typescript, fonctionnent parfaitement. Donc manipuler l’API de Duniter v2 est assez aisé. Exemple [ici pour le paiement(src/app/wallet/account.service.ts · master · clients / Cesium-grp / cesium2s · GitLab) et la pour la création de compte V1
Apollo (GraphQL) pour se connecter aux indexeurs (à venir)

Globalement, le code est (et restera) beaucoup plus allégé que dans Cesium v1.

Voila, pour aller plus loin, et voir le code (libre), ça se passe ici : clients / Cesium-grp / cesium2s · GitLab

La procédure pour lancer Cesium2 dans un navigateur y est détaillé.

Je mettrait bientôt un site avec un déploiement régulier dessus et l’APK pour Android téléchargement depuis ce site.

voilou

Allez zou, dodo ! Demain j’enmène mon fils s’installer pour ses études

tuxmain · 2 September 2022 22:09

Il faudra appeler la version stable « Cesium 133 » ! (puisque c’est le seul isotope stable)

HugoTrentesaux · 3 September 2022 07:20

Totalement d’accord avec toi ! Je suis convaincu qu’il est indispensable de conserver un Cesium semblable à ce à quoi se sont habitué les utilisateurs. Je craignais juste que tu ne trouves pas le temps de t’y atteler.

Merci beaucoup pour ce travail, en plus si le code est beaucoup plus léger que Cesium v1, on arrivera à associer d’autres contributeurs

poka · 3 September 2022 16:37

Compilé en lancé en local en suivant le readme sans problème, en moins de 5 minutes

En effet la stack semble infiniment plus légère que Cesium1 !
Bravo!

HugoTrentesaux · 7 November 2023 15:50

J’ai l’impression qu’il y a deux catégories de personnes : ceux chez qui javascript fonctionne (comme @poka ci-dessus) et ceux chez qui ça ne marche pas. Je fais très clairement partie de la deuxième et après avoir scrupuleusement suivi le readme pourtant très simple, je me retrouve avec des milliers d’erreurs de modules manquants, types non trouvés, ou types incompatibles. Et je ne parle même pas des milliers de paquets dépréciés WARN deprecated à l’installation des dépendances.

Oui j’ai bien fait nvm use 14 pour utiliser la bonne version de node, npm install pour installer les dépendances, et je voudrais bien copier des logs d’erreur de npm run start si leur longueur ne dépassait pas la limite de 10000 lignes que j’ai configuré pour mon terminal vscode.

Est-ce que @flodef @ManUtopiK ou une autre personne chez qui javascript fonctionne peut faire une branche sur laquelle exécuter

nvm use 14
npm install -g @ionic/cli @angular/cli @capacitor/cli
npm install
npm run start

fonctionne ? Ça me permettrait d’avoir un point de départ pour améliorer Cesium v2 et pouvoir montrer une POC en vidéo pour montrer que la v2 avance autrement qu’avec Ğcli en terminal.

[edit] peut-être que tout ce qu’il manque c’est un lock file pour la résolution de dépendances

vit · 7 November 2023 16:53

Je suis comme toi , autant c’est réglé depuis longtemps en Python avec les environnements virtuels, autant en NodeJS, c’est le Bronx (je m’énerve pas contre NodeJS, j’explique…).

Moi j’avais résolu le problème avec Devbox, qui te crée un environnement système isolé où tu peux installer tout ce qu’il te faut, isolément de ton système :

cgeek · 7 November 2023 17:50

Ça fonctionne ici : Commits · demo-cgeek · clients / Cesium-grp / cesium2s · GitLab, à condition de lancer un nœud local qui écoute sur ws://127.0.0.1:9944/ws.

Mais effectivement c’est un coup de chance, il n’y avait pas de package-lock.json.

HugoTrentesaux · 8 November 2023 10:31

Super, ça marche ! Merci @cgeek

Cesium connecté avec le compte Alice sur un réseau local

Maintenant, au boulot ^^

HugoTrentesaux · 8 November 2023 12:28

Ce n’est pas propre pour l’instant parce que je ne me suis pas approprié la structure du projet, mais j’ai ajouté l’affichage de la clé publique v1 et de l’adresse ss58 dans le formulaire de login v1 :

C’est sur ma branche hugo-dev. Je continue à expérimenter, on verra ce qu’on en fait après.

HugoTrentesaux · 8 November 2023 19:02

J’ai aussi ajouté une POC pour se connecter à l’aide d’un mnemonic (à essayer par exemple avec le compte Alice (bottom drive obey lake curtain smoke basket hold race lonely fit walk//Alice) et ai quelques observations :

j’ai beaucoup de warnings de lint et de formatage, ce serait bien de préciser lesquels utiliser pour faciliter le boulot à plusieurs
je comprends l’idée de séparer login et register au niveau de l’interface utilisateur, mais pas au niveau du account.service.ts.
il y a de la répétition de code entre createAddress et register, et je manque de docstring pour pouvoir refactorer ça en restant dans l’esprit du account.service.
je ne comprends pas bien la structure du code : pourquoi le account.service utilise à la fois RegisterData, un type du module register et AuthData, un type du module auth ? Est-ce que ce ne serait pas mieux de se mettre d’accord sur un type unique et une API claire pour faciliter la gestion ?

En fait je me retrouve comme sur Ğcli au départ : devant un design que je ne comprends pas et avec une conception personnelle de ce à quoi ça pourrait/devrait ressembler. Pour Ğcli j’ai fini par complètement transformer l’architecture, en prenant soin de mettre des docstrings partout pour dire comment s’en servir, et je l’ai fait en sachant que je serai dispo pour assurer le support et la formation de futurs devs sur Ğcli.

Sur Cesium v2 je pourrais aussi entreprendre une grosse refacto pour me sentir plus à l’aise pour développer dessus, mais :

je ne connais pas du tout Angular, ce que je ferais ne serait probablement pas idiomatique
ça risque de me prendre un peu de temps, je ne suis pas sûr que ce soit une bonne utilisation
je préfère me concentrer sur Duniter v2s, l’indexeur, et Ğcli, et ne pas occuper une position centrale sur une trop grande partie de l’écosystème

Au vu des avancés sur Duniter et l’indexeur, j’ai l’impression que Cesium v2 pourrait devenir le facteur limitant pour une migration de la Ğ1. D’un point de vue gestion du projet, j’aimerais avoir une idée de la date à laquelle on pourrait avoir un MVP pour Cesium v2, d’où mes expérimentations ci-dessus. Tant que le projet n’avance pas, difficile de se faire une idée, mais il suffirait d’une ou deux personnes qui y travaillent petit-à-petit dessus pour être rassuré de ce côté et concentrer mes efforts sur le futur live network afin de débugger, tester, et consolider le coeur (il reste des gros bugs comme #129 par exemple).

cgeek · 9 November 2023 08:01

Peut-être parce que dans les deux cas on a un compte à la fin, et que tout l’application repose sur l’utilisation d’un compte. Par contre je trouve le service account.service.ts bizarrement positionné dans la hiérarchie du code. Je l’aurais plutôt vu dans shared/services/.

Moi non plus, mais comme tu dis Cesium v2 va bientôt devenir le facteur limitant. Et si @kimamila n’a plus de temps ou de motivation, nous serons bien obligés de le faire. En mode MVP dans un 1er temps bien sûr.

Mais c’est d’ailleurs un bon exercice de développer un client pour s’assurer que l’on a rien loupé côté Duniter.

kalimheros · 12 November 2023 18:45

Une idée comme ça: Pourquoi ne pas développer un client à partir de rien? Tout propre, il se servirait des paramètres et des variables de la V2 et serait optimisé. Au mieux, cela ferait un client performant, au pire cela ferait une concurrence loyale.

cgeek · 12 November 2023 19:10

C’est le cas de Ğecko. Effectivement peut-être vaut-il mieux soutenir ce projet d’autant que son auteur de Ğecko semble motivé et actif !

tuxmain · 12 November 2023 19:29

C’est justement une bonne chose d’avoir plusieurs clients différents : ils répondent à des besoins différents, des goûts différents, ont des failles de sécurité différentes, des bugs différents, dépendent de personnes différentes (tant leurs mainteneurs que ceux de leurs dépendances).

HugoTrentesaux · 13 November 2023 11:33

Bonne question et tu as déjà deux bonnes réponses

J’aimerais apporter quelques précisions :

Cesium v2 part “de rien” au sens où il part d’une base propre et polkadotjs pour gérer la connexion avec substrate
si Cesium v1 était “peu performant”, c’était pour beaucoup dû à ce qu’il y avait derrière (Duniter v1 et l’indexeur Cesium+ pod), ce qui n’est plus le cas en v2 car c’est Duniter-v2s et Duniter-indexer. Ensuite, Cesium v2 utilise des dépendances à la fois plus à jour et stables, ce qui est un atout pour le développement, et permet aussi de gagner en performances
bien sûr qu’il est bon d’avoir de la diversité dans les clients, mais vu la communauté Ğ1, il me paraît indispensable d’avoir une interface qui ne perturbe pas trop les habitudes, donc un Cesium v2 qui soit assez proche de Cesium v1 en matière d’interface

J’ajoute un point à ce sujet pour la prochaine visio dev.

kimamila · 18 November 2023 06:04

Super @HugoTrentesaux tes retours et réflexions sur Cs2 !

Je pourrais aider pour

paramétrer un formateur syntaxique plus propre.
Aussi pour le passage à Angular 16, puis 17 - je suis en plein dedans au boulot. Notamment la gestion des templates est (enfin) plus convivial avec des @if @else etc au lieu des “*ngIf ; else” (Google vient d’annoncer cette nouveauté ce mois ci !)
répondre à tes questions sur AuthData et account service. Ils ont effectivement besoin d’être revus. Il faut que je m’y replonge pour te répondre…

Sinon :

l’architecture peut être revue, c’est certain. Notamment j’utilise maintenant d’avantage (et mieux) RxAngular pour gérer les Input/Output des composants, et l’état des services. Nous devrions sans doute revoir cette partie.
@cgeek fais tu encore du Angular au boulot, pour aider sur la conception ?
@cgeek j’avais pensé ‘shared’ d’avantage pour des composants très bas niveau, réutilisables par exemple dans d’autres projets, en dehors de tout “métier”. J’ai déjà du code ce module qui me vient de projets pro. Je les ajoute au fil des besoins.
Je suis toujours motivé, mais effectivement en manque de temps. Si j’arrive à organiser les prochaines RML en mars ce sera déjà bien mais je sais aussi que cela me motivera aussi pour avancer sur Cs2.

Prenez soin de vous les amis et merci pour ce que vous faites !

cgeek · 18 November 2023 10:28

Non je ne fais plus d’Angular, tout juste un peu de Vue 3 (et encore). Si vous l’initiez je saurai suivre, mais pas mettre en place des fondations dans l’état de l’art pour un projet front. Et aujourd’hui ces derniers sont aussi poussés, voire plus, qu’on projet backend.

kimamila · 27 November 2023 10:03

@HugoTrentesaux j’ai commencé à intégrer les modifs de ta branche (qui reprennent celle de @cgeek)

J’ai pu avancé sur ce point la semaine dernière. Je vais pousser des modifications structurelles, qui impactent beaucoup de code.

je préfère vous prevenir, au cas où vous aviez debuter d’autres chantiers sur Cs² ? Redites moi si c’est le cas

Concernant le lancement d’une G1v2 pour les 7 an de la G1, je suis bien motivé par ce défi, vis à vis de Cs² ! D’autant que cela collerait avec les RML à Laval en mars, juste la semaine d’après (du 11 au 15 mars 2024).

voilou

HugoTrentesaux · 27 November 2023 10:41

Super si tu fais les changements structurels ! Ça permettra de contribuer plus facilement. Pas de travail en cours pour ma part, si j’en ai je le publie dans une branche. Et le dépôt n’a pas de fork, donc on dirait que personne ne travaille secrètement dessus

on avait déjà la documentation de tous les calls : Duniter | Runtime calls
on a maintenant la documentation de tous les événements : Duniter | Runtime events

Ça va évoluer avec les discussions dans API des événements, mais au moins ça fait une bonne base pratique à utiliser.

Moi aussi, très motivé par ce défi !!

gma · 27 November 2023 21:37

Salut à tous,

Je débarque ici et souhaiterai chercher à contribuer à faire avancer cette version 2, même si je ne connais pas trop angular.

J’ai lu déjà pas mal de choses à propos de duniter-v2s sur ce forum et sur duniter.org, et vu une bonne partie des vidéos de Hugo. Mais, il y a quand même pas mal de choses qui restent un peu floues pour moi pour l’instant.
J’ai la compilation et l’exécution d’un serveur duniter-v2s local fonctionnelles, ainsi que la compilation et l’exécution de cesium2s en utilisant ce serveur. J’ai exploré un peu le code de cesium et fait 2-3 petites modifications localement qui n’ajoutent pas de fonctionnalités mais améliorent un peu le code (du moins à mon avis ^^).

Y a-t-il une sorte de feuilles de route des fonctionnalités à implémenter ? Dans quel ordre ?

Bonne soirée !