Développement de wotmap

#136

L’interface est super comme ça ! Par contre c’est dur de lire les pseudos des petits nœuds, il faudrait une taille minimale pour le texte. Et aussi pouvoir zoomer avec +/- en plus de la molette ça serait pratique.

Pour info pour les autres : mon script trouve trop d’identités (un peu plus de 2000) alors qu’il est sensé ne prendre que les membres.

Edit: En fait c’est à cause des identités qui ont été membres mais qui ne le sont plus. Le problème : si on les met, il ça signifie que la wotmap ne liste pas que les membres ; si on ne les met pas, ça pose des problèmes puisque leurs certifications sont encore valides et doivent être représentées.

Re2·edit: wot_json.py qui prend toutes les identités, avec [“attributes”][“member”] qui indique si il est membre ou pas. Dans stats.json, total_nodes liste toutes les ids, total_members seulement les membres. total_noreferents ne compte que les membres non référents. Du coup il faudrait ajouter un figuré pour les non-membres dans l’interface, par exemple grisé ou hachuré.

3 J'aimes
#137

Avant les vacances, je vous livre une nouvelle version de la wotmap grâce aux contributions de @tuxmain et de moi-même :wink: N’hésitez pas si vous avez des retours (bugs, améliorations). Je n’ai pas encore implémenté les demandes ci-dessus. Je verrai ça plus tard :wink:

2 J'aimes
#143

Pour sa première version officielle, la wotmap passe en v0.10 sur l’adresse https://wotmap.duniter.org

Au programme :

  • Possibilités de survoler les certifications et de cliquer dessus pour voir les détails
  • Filtrage de communautés par double click sur un noeud
  • Un clic droit sur un noeud masque la communauté
  • Utilisation des touches du clavier pour déplacer la wotmap et zoomer dessus
  • Aide en ligne
  • Affichage de statistiques
  • Meilleure gestion des temps d’attentes

N’hésitez pas à remonter les éventuels bugs que vous pouvez rencontrer ou vos idées d’amélioration. Le nouveau dépôt se trouve sur https://git.duniter.org/paidge/wotmap

3 J'aimes
#146

Je cherche à automatiser le déploiement de la wotmap avec un fichier .gitlab-ci.yml inspiré de celui qu’avait fait @1000i100 :

.gitlab-ci.yml 
stages:
  - build
  - publish

update-data:
  stage: build
  image: python:3.6.8-alpine3.9
  script:
    - wget http://g1.1000i100.fr/duniter.db
    - mkdir -p /var/lib/duniter/.config/duniter/duniter_default/
    - mv duniter.db /var/lib/duniter/.config/duniter/duniter_default/

    - mkdir -p /var/www/wotmap/
    - cp -r ./ /var/www/wotmap/

    - python3 /var/www/wotmap/script/wot_json.py -d

    - mv /var/www/wotmap ./release
  artifacts:
    untracked: true
    paths:
      - release/
  only:
    - master

pages:
  stage: publish
  image: python:3.6.8-alpine3.9
  script:
    - mv release public
  artifacts:
    untracked: true
    paths:
      - public
  only:
    - master

La méthode utilisée par @1000i100 ne permet pas d’avoir les données à jour puisque le script ne se lance que lors du git push. De plus, vu que la BDD de Duniter a changé de format, je ne vois pas trop comment faire pour importer les données dans le conteneur Docker. L’idée la plus pertinente qui me vient à l’esprit est de monter directement le dossier de la machine hôte (/var/lib/duniter/.config/duniter/duniter_default/data/leveldb/) dans le conteneur mais cette discussion sur Stackoverflow dit que ce n’est pas possible…

Est-ce que quelqu’un aurait une idée ?

EDIT :serait-ce une piste ?

#147

Si, puisque le script se lance au git push ET peut être lancé sous forme de CI récurente, comme un cron, quotidiennement par exemple.

En revanche, effectivement, pour reprendre le principe que j’utiliser avec la nouvelle BDD, il faudrait exposer cette nouvelle BDD qui n’est plus en un seul fichier, en télécharger les éléments puis en extraire les info souhaitées.

Autre possibilité, maintenant que le sync est rapide : créer un noeud et faire une sync dans la CI.

1 J'aime
#148

@Pierre_Jean_CHANCELL ce serait amusant de pouvoir jouer une animation avec l’évolution de la toile du premier bloc jusqu’à son état actuel, un peu dans ce genre là.

Par ailleurs, je me demandais pourquoi ton programme n’enregistrait pas la position des nœuds directement côté serveur pour éviter de calculer le layout à chaque chargement de la page.

2 J'aimes
#149

En fait le programme côté serveur qui génère la liste des nœuds calcule déjà les positions, mais il n’est pas assez efficace. Du coup on recommence côté client avec une bibliothèque plus efficace. Le prépositionnement côté serveur permet tout de même de raccourcir la durée de calcul côté client.

2 J'aimes
#150

Oui j’y ai pensé :wink: D’autant que le premier outil de visualisation web de la WOT montrait l’évolution de la toile au cours du temps. C’était écrit en PERL si je ne me trompe pas.

EDIT : Bah tiens, je viens de retrouver le code source.

Je pourrais ptet me pencher un peu plus sur la question mais est-ce vraiment d’une grande utilité ?

1 J'aime
#151

La vue en 3D (espace-temps) est forcément utile, mais reste encore a voir ce qu’on veut montrer :slight_smile:

#152

j’y vois surtout le côté artistique. ça peut montrer l’évolution de la toile, son accélération, son ralentissement… Après je vois pas trop

2 J'aimes
#153

C’est donc une question d’outils ? Ça doit être possible de faire tourner les outils clients côté serveur pour récupérer les positions une fois pour toutes, du moment qu’elles sont calculées à un endroit. Mais c’est vrai que je suis le premier à vouloir éviter de faire tourner du javascript côté serveur.

Utile, non, amusant, si ! Ta wotmap aide beaucoup à la compréhension de la wot pendant les présentations, une version animée aiderait à raconter son histoire.

1 J'aime
#154

@Pierre_Jean_CHANCELL Si tu veux l’intégrer dans la wotmap, ça m’intéresserait d’adapter le script Python pour faire ça. Par contre il faudrait pouvoir lire la blockchain afin de construire l’index pour un bloc donné.

Et puis on ne peut pas stocker les positions de tous les nœuds pour chaque bloc, donc il faudra choisir la fréquence. Pour éviter de recalculer plusieurs fois les graphes passés on peut les archiver.

#155

SigmaJS permet de rajouter des noeuds dynamiquement au graphe. En remettant le layout dynamique tel que je l’avais fait au début, on verrait la toile évoluer mais le CPU va prendre cher :stuck_out_tongue: Pour faire ça, il faudrait tout l’historique des dates d’entrée et de sortie des membres.

#156

Voilà. Mais le seul historique qu’on a est la blockchain, et on ne peut pas demander ces calculs au client, donc mon idée est de calculer le graphe côté serveur pour tous les instants voulus.

Actuellement le JSON fait 3 Mo, donc même avec seulement 1 graphe archivé par mois, on arrive à 72 Mo pour 2 ans, ce qui fait trop…

Tout ça m’amène à la réflexion que la toile, comme tout système distribué dont chaque nœud agit indépendamment, n’est pas nécessairement représentable entièrement. Par exemple, l’univers, pris à une grande échelle, forme des filaments de superamas de galaxies. Mais on ne peut jamais représenter en réduit l’univers entier, parce que premièrement ça reviendrait à réduire les actions indépendantes de 10^beaucoup objets à l’action d’un seul (un processeur informatique) ; deuxièmement parce que nous ne voyons pas l’intégralité de l’univers, pourtant nous sommes quasi-sûrs qu’il s’étend au-delà de notre champ de vision. (ce dernier point d’approche du concept d’Holochain)

1 J'aime
#157

Il reste toujours la possibilité de rendre certains nœuds mobiles sélectivement. Par exemple, lors de l’ajout d’un nouveau nœud on rend celui-ci mobile ainsi que ses voisins, et on les fixe à nouveau une fois la position d’équilibre atteinte. Ou alors on rend mobile seulement le nœud en focus et ses voisins. Comme ça, on évite les calculs gourmands impliquant tous les nœuds.

#158

Une source d’inspiration pour la wotmap : https://galaxy.opensyllabus.org/

#159

Merci @HugoTrentesaux. Il y a en effet qqes idées à prendre :wink: Quelles sont les fonctionnalités qui t’intéressent sur ce site ?

1 J'aime
#160
  • le temps de chargement est très rapide
  • le graphe est extrêmement lisible
  • le jeu de couleur est agréable à l’œil

mais il manque plein de fonctionnalités par rapport à la wotmap actuelle (représentation des liens, changement de point de vue…)

#161

Là pour le coup, c’est parce qu’on ne peut pas calculer la position des nœuds côté serveur. La bibliothèque python-igraph n’implémente l’algorithme de position des noeuds qui m’intéresse. C’est pour ça que le navigateur (via SigmaJS) est obligé de le faire…

Oui je suis d’accord. Sûrement du à l’algorithme de positionnement des nœuds qui doit être différent de celui que j’utilise (force-atlas). J’avais modifier un paramètre de la wotmap pour améliorer ce côté-là déjà mais y’a ptet encore des choses à faire.

Pour le moment les couleurs sont générées à la volée en fonction du nombre de communautés dans le script Python de @tuxmain . Il est sûrement améliorable mais je ne suis pas très calé pour ça. Voici le bout de code si qqun veut s’y coller :

for i in range(nb_nodes):
	outdata_wot["nodes"][i]["my_community"] = membership[i]
	(r, g, b) = colorsys.hsv_to_rgb(float(membership[i]) / nb_communities, 1, 1)
	R, G, B = int(255 * r), int(255 * g), int(255 * b)
	outdata_wot["nodes"][i]["color"] = "rgba(" + str(R) + "," + str(G) + "," + str(B) + ",1)"
#162

On peut essayer de faire tourner le code SigmaJS côté serveur. Je n’aime pas faire tourner du JS côté serveur, mais il y a plein de gens que ça ne dérange pas :smiley: par contre, je ne saurais pas faire.

Je parlais surtout du choix des couleurs : des couleurs pastel transparentes sans bordure sur fond blanc. Ça permet de voir les régions où plusieurs disques se superposent, et ça sature moins l’œil !

2 J'aimes