Cesium+ Pod > Nouvelle version v1.5.15 (stable)

API CS+
1

L’équipe de développement de Cesium+ est heureuse de vous annoncer la nouvelle version 1.5.15 de Cesium+ Pod !

Cette version a pour objectif principal la décentralisation des données Cesium+, grâce à une synchronisation P2P enfin opérationnelle.

Quelles nouveautés ?

Voici la liste des nouveautés :

API REST

Voici les nouvelles URL disponibles (nouveaux index ElasticSearch) :

  • /g1/pending/_search : permet des recherches sur les demandes d’adhésion comme membre (en cours de validité ou non, donc ** y compris au-delà du délai des 2 mois**).
    Un traitement collecte (chaque heure) les nouvelles demandes en attente, en tirant au sort un nœud Duniter de la branche principale. Le but étant d’archiver indépendamment des fork/resync de nœuds, et de l’aboutissement réel (inscription en blockchain) de la demande d’adhésion.
    Cet index pourra servir par les clients (Cesium ou outre) pour avertir l’utilisateur après un fork, et lui proposer un renvoi de sa demande d’adhésion.

  • /wot/pending : idem que sur l’API BMA, mais en utilisant l’index précédent (pas besoin d’interrogation du noeud Duniter qu’écoute le pod) ;

  • /node/stats : renvoi l’état d’utilisation du Pod (et de son cluster ElasticSearch, si plusieurs pods locaux). Notamment, y est visible le nombre de connexion WebSocketpar par index écouté, c’est à dire la charge de sessions utilisateurs qu’ouvrent des clients comme Cesium.

  • /like/record : gestion de compteurs permettant d’envoyer des like, dislike, ou abuse (=signalement avec ou sans demande de modérations) sur n’importe quel document du Pod : un bloc, un profil utilisateur, une page, un commentaire, etc. (en dehors toutefois des messages privés).

    • Cet index permettra par exemple de signaler un profil à supprimer ou douteux, etc… Les signalements émis (compteur de type abuse) déclenchent des notifications vers l’administrateur du Pod, qui pourra les recevoir dans Cesium ou par email, pour répondre à la demande de modération;
    • Ceci devrait permettre de connaître les comptes douteux, de manière autogérée par la communauté Cesium+ pour éviter les cas de fishing comme évoqué dans cette discussion. Les logiciels clients pourront choisir de marquer, voir filtrer les profiles suivant les compteurs abuse, ou suivant une proportion via à vis des like.
    • Des URL de raccourcis permettent d’accéder directement au compteur : <index>/<type>/<docId>/likes , <index>/<type>/<docId>/_dislikes ou <index>/<type>/<docId>/_abuses
      Exemple, sur un profil utilisateur /user/profile/38MEAZN68Pz1DTvT3tqgxx4yQP6snJCQhPqEFxbDk4aE/_likes

    Attention : Cesium (logiciel client) n’exploite pas encore cette fonction de signalement (-> à venir en v1.6+).

Fonctionnement en réseau P2P

On va enfin pouvoir avoir un réseau de Pod pleinement P2P ! :slight_smile:

  • Les Pod publient maintenant une fiche de paires au réseau Duniter. Ils peuvent donc être visibles, comme vous le verrez dans la nouvelle vue réseau des Pod Cesium+ (nécessite Cesium v1.5+)

  • A chaque démarrage, une synchro différentielle se fait depuis le réseau. Utile par exemple si vous arrêter votre Pod plusieurs heures ou jours.

  • Le réseau des nœuds Duniter et des pod Cesium+ est scanné et actualisé toutes les 5 minutes (à chaque nouveau bloc) pour découvrir les nœuds, leur endpoint/API et leur dernier bloc. Cette indexation sert dans différent traitements du pod, par exemple pour connaître les nœuds Cesium+ lors des synchros de données Cesium+;

  • Nouvelles règles anti-spam : contrôle d’intégrité des documents reçus, lorsqu’ils sont liés à d’autre document (par exemple les commentaires doivent pointer vers une page existante, le destinataire d’un message privé doit avoir un profile Cesium+), etc. Après vérification, sont exclus les documents en échec.
    Ces nouvelles règles évitent la propagation de documents invalides.

  • Noter bien que le Pods n’utilisent pas de blockchain. Il peut donc exister des différences de nombre de documents indexés, entre les Pod, en fonction de leur historique et des règles de synchro (qui deviendront paramétrables, avec le temps); En revanche, chaque document est signé et ne peut donc pas être falsifier (sans connaître la clef secrète de l’émetteur).

Optimisation des performances

Il est maintenant possible de lancer plusieurs pods en parallèle, sur un même réseau local (ou en VPN), pour former un cluster ElasticSearch avec répartition de charge :

  • Lorsque plusieurs pods sont sur le même réseau (y compris sur la même machine), ils vont automatiquement répliquer leurs données d’indexation, se répartir la charge des requêtes demandés, etc. Ils communiqueront entre eux via le protocole interne natif à ElasticSearch (par défaut en HTTP, sur le port 9300).

  • Les traitements d’indexation (des blocs, des événements, etc.) et d’envoi (emails) ne s’exécute qu’une seule fois, sur le master node du cluster ES.
    (Dans les versions précédentes, chaque pod lançait les même traitements redondants, ce qui provoquait des erreurs de double indexation, et beaucoup de charge inutile).

  • Le serveur web frontal (Apache, Nginx) peut donc faire du load balancing et failover, entre les différents pod locaux.
    Théoriquement, donc, une mise à niveau de Cesium+ Pod ne devrait même plus déclencher d’interruption de service : on arrête un pod (les traitements basculent éventuellement sur le second pod) qu’on met à jour, puis on recommence sur le second, et hop, ni vu ni connu ! :slight_smile:

  • Dans les prochaines semaines, la rapidité de g1.data.duniter.fr sera donc renforcé par l’ajout de pod locaux. De la doc suivra pour expliquer comment configurer tout ça, typiquement sous Nginx.

Améliorations diverses :

  • Quand cela est possible, les notifications envoyées par emails utilisent maintenant le nom des profils Cesium+ (quand il existe) plutôt que la clef publique.

  • Les URL de partage (exemple /user/profile/<pubkey>/_share) pour les réseaux sociaux pointent vers une page HTML relookée avec bootstrap
    (Cela servira aussi pour change, puisque cette partie du code est réutilisable dans d’autres plugins ES)

  • Amélioration des messages de log, notamment à la fin des synchros (affichage d’un comptage des opérations insert/update/delete effectuées).

Corrections diverses

  • Toutes les entrées/sorties de la WoT sont maintenant bien indexés (dans /user/event). Ceci corrige le bug des DU manquants dans Cesium+, dans l’historique et les graphiques de compte, où il manquait des DU sur certains comptes.

  • /node/summary renvoi la bonne version du pod, et non plus celle de Duniter4j (une lib sous-jacente)

  • L’index /docstat/record a été migré vers un nouvel index /document/stats. Pour rappel, cet index stocke le nombre de documents du Pod, actualisé toutes les heures et exploités par les graphiques de suivi des données sur des pod Cesium+ (nécessite Cesium v1.5+).
    Les données de l’ancien index sont bien sûr migrés (dès le démarrage du pod dans la nouvelle version) : vous ne perdez donc pas les stats de votre pod.

Et après ?

Décentralisons Cesium+

Vous pouvez maintenant aider en installant votre propre Pod Cesium+, puis vérifier que tout fonctionne et que les données se répliquent bien.

Do you P2P ?

Voici les étapes rapides d’installation (la doc officielle est ici)

  • Installez les dépendances : Java JDK (8) et Libsodium;

  • Télécharger la dernière version du pod, puis dézippez :

    wget -kL https://github.com/duniter/cesium-plus-pod/releases/download/cesium-plus-pod-1.5.15/cesium-plus-pod-1.5.15-standalone.zip

  • configurez votre Pod, en éditant le fichier config/elasticsearch :

    • cluster.remote.host : le nom public permet l’accès à votre pod;
      • Si vide, votre pod ne publiera pas d’accès public (pas de “fiche de paire” envoyé au nœud Duniter) et ne pourra donc pas être contacté par les autres Pod du réseau;
    • cluster.remote.port : le port (idem que http.port, sauf si vous avez un frontal web, comme nginx ou apache, pour faire du load-balanding);
    • network.host : l’interface réseau à utiliser (locahost, l’IP locale, etc.);
    • http.port : le port ou une plage de ports, pour l’accès HTTP au Pod;
      Mettre une plage (9200-9210) si vous voulez lancer plusieurs Pods avec la même configuration;
    • duniter.host et duniter.port : le noeud Duniter à suivre;
    • etc.

  • lancer le pod :

    cd cesium-plus-pod-1.5.15/bin
./elasticsearch -d

Simple, non ? :slight_smile:

Prospections

Quelques pistes pour la suite :

  • Être indépendant du nœud Duniter sous-jacent, et basculer sur la branche majoritaire.

    • Maintenant le scan du réseau est complet (via BMA et WS2P head), le pod pourrait (en option) basculer automatiquement vers un nœud UP de la branche majoritaire;
    • Une autre idée est de basculer dans ce mode uniquement si le nœud sous-jacent est HS : par exemple s’il ne forge ou ne reçoit plus de bloc depuis M minutes (M étant configurable);

  • Ajouter d’autres URL compatible avec BMA : Les pods sont en effet de plus en plus compatibles avec cette API (/network/peers, /network/peering, /wot/pending, etc.). Donc pourquoi ne pas tenter une implémentation complète ?
    Cela pourrait résoudre les problèmes de performances que rencontrent actuellement les nœuds Duniter (notamment sur les requêtes /wot/requirements et /tx/sources).

    • L’algo pourrait aller chercher les infos quotidiennement, puis garder un cache pour répondre aux requêtes BMA.
    • A chaque interrogation, le pod pourrait aussi tenter une mise à jour (par exemple s’il y a eu un nouveau bloc) auprès du nœud Duniter, et prévenir le client de la mise à jour ?

  • d’autres idées ?

Contribuer à la contribution

Le travail qui a permis d’aboutir à cette version stable, est estimé à 13 homme-jours (entre mi-décembre et aujourd’hui).

Comme toujours, vous êtes invité à contribuer à l’effort de développement, par exemple via le compte des développeurs de Duniter.

a+ (et pensez à prendre soin de vous !)

3 Likes
2

Salut @bpresles, as tu possibilité de mettre à jour dans la dernière version ton Pod ?
J’ai republié une version 1.5.16

EDIT: en faisant un resync complete (propriété duniter.p2p.fullResyncAtStartup: true)

3

J’ai mis à jour, la synchronisation (full) est en cours. :slight_smile:

4

@kimamila
Une question par contre, j’ai remarqué que la synchro récupère bien les infos de la blockchain Duniter, mais qu’il n’y a par contre pas de synchro du profil Cesium+ (avatar, adresse, abonnements), ni des messages.

Il y a quelque chose à faire pour que les noeuds Cesium+ soient synchro entre eux sur ces fonctionnalités ?

5

Peux tu me faire passer les logs ? Logiquement, le pod aurait devrait scanner le réseau, et y récupérer les Peer compatible.
Sinon, tu peux forcer le premier peer en mettant ceci dans ton fichier /config/elasticsearch.yml :

duniter.p2p.includes.endpoints: [
  "ES_CORE_API g1.data.duniter.fr 443",
  "ES_USER_API g1.data.duniter.fr 443",
  "ES_SUBSCRIPTION_API g1.data.duniter.fr 443"
]
6

J’ai rien dis, en fait cela n’avait pas terminé toutes les synchros, maintenant tout est bon :slight_smile:

1 Like
7

Wahoo, c’est beau des pods Cesium+ synchro :

image
image726×362 40.6 KB

Je suis un peu ému, là :slight_smile:

EDIT: la différence ci dessus, de 1 document, est du sans doute à un problème de validation des signature des profiles JSON, que j’ai eu dans Cesium+ il y a longtemps. Le Pod Cesium+ de duniter.fr a toujours la même BDD ElasticSearch depuis le début de la G1.
Quand on aura vérifié que le réseau est bien stable, je pourrait faire faire un RAZ + synchro, pour nettoyer tout ca :slight_smile:

Je suis trop content !!

8

Dis donc tu commence à avoir pas mal de gens inscrit chez toi aux notifications par email :slight_smile: As tu bien vérifier que cela fonctionnait ?

9

Non, pas vraiment… Je reçois des emails de messages d’information quand le noeud démarre et s’éteint, mais j’avoue que la config email j’ai fais ça rapidement, juste avec un petit postfix local pas vraiment personnalisé.

Y’a un moyen de tester spécifiquement que les notifications fonctionnent ?

10

A priori si tu recois des emails, c’est que ca marche :slight_smile:
Il te faut paramétrer les propriété de config, pour personnaliser l’objet du mail, par exemple.

Ensuite, dès qu’un évenement (TX, Certification, etc.) arrives sur ton compte, le lendemain tu recois un email.
Tu peux aussi forcer démarrage, pour les tests.

11

Justement, j’ai constaté que je recevais juste les mails « message d’information » concernant la disponibilité du noeud Dunier (ex: « Noeud Duniter [g1.presles.fr:443] à nouveau accessible. »), mais je n’ai jamais reçu de notification pour les TX, certifications… :frowning:

Cela dit, est-ce lié au « services / abonnement » ? Car je vois que sur mon compte c’est configuré pour être notifié par ton noeud et non par le mien (« prestataire »). Je viens de changer, je vais voir si je reçois des mails de mon noeuds Cesium+ demain :slight_smile:

1 Like
12

Oui c’est ça :slight_smile:

13

Voilà une autre conséquence directe de cette version du Pod : la réutilisation pour gchange (cf annonce d’une nouvelle version : https://forum.monnaie-libre.fr/t/gchange-nouvelle-version-v1-1-2/9345) qui exploite la gestion P2P et celle des likes et signalements. :slight_smile:

1 Like
14

Salut @bpresles :slight_smile: Peux tu mettre a jour en 1.5.18 ? Les statistiques sur les documents utilisateurs étaient arretée. Suite un mauvais refactoring. Pas grand chose d’autres sinon.
a+