De mon côté, j’ai beaucoup avancé dans ma réflexion sur les “datapods” et ai utilisé l’exemple de gchange pour être sûr de me poser les bonnes questions. Je voulais attendre d’avoir suffisamment avancé pour présenter quelque chose de complet et fonctionnel, mais au vu de l’avancée des autres projets, je me dis qu’il est important de quand même montrer la direction que j’ai prise jusqu’à présent.
Vous pouvez télécharger un exécutable “geopod” depuis la page de release pour avoir un aperçu :
Attention, c’est en chantier, ce n’est pas prêt pour utilisation, le but est surtout d’alimenter la discussion. Quelques points en vrac :
J’aime faire des prototypes, mais je ne suis pas bon pour faire un vrai produit utilisable. Pour ça je fais bien plus confiance à @elois et @poka.
“Ǧeopod” je cherchais un nom qui fait penser à la Ğ1, aux datapods, à Ğchange, et aux données geolocalisées. Mais le nom est déjà pris donc c’est juste une appellation temporaire.
“p2p” : j’ai suivi une vraie philosophie p2p en “local first”, j’expliquerai pourquoi c’est important pour moi, mais il me semble que elois a raison et que c’est peu pragmatique par rapport aux usages actuels.
Données historiques : j’ai repris les données Ğchange v1 et Cesium+, mais n’ai pas encore travaillé à optimiser leur exploration, elles ne sont donc utilisables qu’au terme d’une looongue synchronisation (que je pense pouvoir réduire à quelques secondes au vu de mes choix d’architecture, mais ça reste à prouver).
Ceux qui sont connectés et ont envie de passer du temps derrière un ordinateur pendant ce mois d’août peuvent essayer, pour ma part je raccrocherai plutôt en septembre.
J’approuve 1000 fois l’approche local first, que je trouve bien plus robuste et pérenne.
A voir cependant si ton système d’index partiel fonctionne correctement, on verra à l’usage.
Enfin du vrai p2p.
En plus je trouve que l’interface permet de facilement comprendre ce qu’il se passe au niveau p2p.
En théorie il fonctionne comme une plage contiguë d’un prolly tree dont les clés ont été choisies dans ce but précis. En pratique, j’ai quelques benchmarks sur le stream de requêtes SQL depuis un index distant (les résultats viennent en fur et à mesure que l’arbre est récupéré), mais c’est pas encore bien intégré et il faut tester avec des requêtes plus complexes. Mais ma priorité est d’abord la récupération rapide d’un index complet, parce que ça reste assez léger donc il n’y a pas encore vraiment de raison de privilégier la récupération partielle.
Oui, j’en avais marre de la blockchain qui est un “faux” p2p, j’avais besoin de m’éloigner un peu de la Ǧ1 pour ça.
C’est mon objectif, et j’ai même plus travaillé cet aspect sur l’explorateur générique, mais je ne l’ai pas testé depuis un moment et je n’ai pas fait le build pour macOS.
Sur Mx-linux, ça s’installe parfaitement.
Je ne vois pas les annonces, même après la longue synchronisation. Sur la carte je vois les pages et les profils, pas les annonces !
Ce qui serait top, ce serait de pouvoir mettre des annonces de type “rencontres” !
[EDIT]
par contre sur debian ca passe
la phrase doit etre en anglais en français ça ne passe pas
et code local j’ai mis un petit moment a comprendre qu’il fallait le créer
j’ai un soucis avec mon avatar ou c’est quasiment noir ou c’est blanc a la place de ma photo .png
par contre je ne sais pas si c’est du a geopod mais cela a freezer ma fenetre emulation linux chose que je n’avais jamais eu
Surprenant, ça. Mais bon, c’est pas encore stabilisé donc pourquoi pas.
J’ai pas pu tester pour l’instant et j’ai aucune expérience sur le packaging windows. Mais à un moment il faudra que je m’en occupe !
Merci pour les retours, je note ça et le règlerai dans les prochaines versions même si le gros chantier reste la synchro rapide, les requêtes streamées, le parcours d’invitation la modération, et plein d’autres bêtises.
Bon, je redémarre aujourd’hui, et je vois toutes les annonces.
Toutefois sur la carte offre et demande sont mélangées.
Mais, je trouve cela prometteur !
Même quand tu utilises les filtres ? C’est une question que je me suis posé à la construction de l’index, il y a plusieurs choix :
un index uniquement géographique, il faut ensuite un full scan pour filtrer sur les types
un index par type puis géographique, il faut donc plusieurs requêtes pour assembler plusieurs types dans une même requête géographique
deux index pour permettre les deux approches, mais plus lourd et plus de calcul à l’insertion
Si je reformule, il s’agit de choisir parmi ces requêtes laquelle sera la plus rapide :
sélectionne toutes les données de cette zone, quel que soit leur type (profil, page, offre, demande…)
sélectionne toutes les offres (ou autre type) de telle zone (à répéter plusieurs fois si on veut superposer plusieurs types)
Mon idée était surtout de répondre à la question “qu’y a-t-il dans cette zone”. Ensuite on zoome sur la zone qui nous intéresse, puis on joue avec les filtres si on n’est intéressé que par les commerces par exemple, ce qui est peu coûteux quand on considère une zone restreinte.
Moi aussi, mais j’aimerais quand même réfléchir à brancher ça sur les Dunipod plutôt que sur mon datapod pour plusieurs raisons :
Il faudra y ajouter des fonctionnalités de la Ğ1 pour les financements participatifs, votes, toile de confiance, rencontres, etc. Donc c’est mieux si c’est correctement intégré la Ǧ1, ce qui sera forcément mieux le cas avec Dunipod qu’avec un connecteur custom.
C’est essentiellement une PoC qui m’a permis de me poser les questions, je ne suis pas sûr de vouloir le maintenir sur le long terme, je préfère coller à un outil qui fait consensus pour la communauté Ğ1.
J’ai envie de faire évoluer mon Datapod avec des changements cassants sans me soucier de gérer des migrations ou une rétro-compatibilité.
Le public de la Ǧ1 n’est pas forcément prêt à s’intéresser au “vrai p2p” et à accepter les compromis en connaissance de cause, je préfère trouver un public plus adapté pour inaugurer les datapods.
À terme, on pourrait intégrer les fonctionnalité de paiement, certification, et rebaptiser ça “Cesium” si c’est ok pour Benoit et que la stack technique a plus de sens (même avec IA et la stack mise à jour je trouve ça compliqué et peu efficace de bosser sur Cesium v2). Ce serait une jolie boucle vu que Cesium 1 intégrait Ğchange au début, alors si Ğchange 2 intègre Cesium
Tout dépend du niveau de zoom. Les données géolocalisées individuelles sont colorées et filtrables. Mais les données agrégées ne sont disponibles que tous types confondus car je n’ai pas fait d’index par type. Les options que je propose plus haut dépendent de choix d’architecture et d’expérience utilisateur que je n’ai pas encore fait.
Dans l’absolu et je vais sortir un truisme du type la pluie ça mouille, je pense que mis à part la lenteur de césium 2 que des gens pourraient regretter , ce qui est demandé est quelque chose qui ressemble à césium 2. 2.1 et v1, ça n’empêche pas l’évolution, et la technique derrière presque personne s’en soucie.
