La vue en 3D (espace-temps) est forcément utile, mais reste encore a voir ce qu’on veut montrer 
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 Likes
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 Like
@Paidge 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.
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 
Pour faire ça, il faudrait tout l’historique des dates d’entrée et de sortie des membres.
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 Like
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.
Merci @HugoTrentesaux. Il y a en effet qqes idées à prendre 
Quelles sont les fonctionnalités qui t’intéressent sur ce site ?
1 Like
- 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…)
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)"
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 
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 Likes
Fait amusant : 7GqVqKGayGRJWZ apparait en dehors de la Wotmap sur https://wotmap.duniter.org/
(non connexe au reste de la toile)
Si tu zoome tu verra qu’il sont 4 en réalité, et tous non-membres pour cause d’expiration de certifs, c’est un bug de wotmap qui affiche des identitiés qui ne sont plus membres @Paidge
2 Likes
J’ai lancé le script sur un noeud synchronisé et je n’ai plus ce « bug ». Je pense que c’est parce que mon noeud n’était plus synchronisé… A surveiller. Merci @HugoTrentesaux pour le signalement 
2 Likes
As tu essayé avec un calcul coté serveur, via nodeJS par exemple, pour générer un fichier de position ?
1 Like
Malheureusement, je n’ai jamais codé en nodeJS. Ça fait au moins 2 ans que j’essaie de trouver le temps de me former, notamment pour contribuer à Duniter/Cesium… En vain 
Je fais surtout du front maintenant (HTML/CSS/JS/Jquery/Bootstrap)
Hello
depuis quelques jours la wotmap semble ne plus se mettre à jour.
Elle reste au bloc n° 290299 .
Je dis ça juste au cas ou l’un d’entre vous aurait un peu de temps pour voir…
1 Like
c’est mon noeud qui est désynchronisé. Je vais le synchro dès que possible.
1 Like