Salut @pouhiou,
Merci beaucoup pour ton message et tes pistes de réflexion très intéressantes. Comme tu l’as déjà remarqué et expérimenté, les codeurs sont généralement peu enclins à s’en préoccuper, souvent par ignorance ou incompétence. Et puis, c’est ton boulot et pas le nôtre 
« Chacun son métier, et les vaches seront bien gardées » ! Nous sommes complémentaires, il faut que nous parvenions à communiquer, puis à nous comprendre, enfin à travailler ensemble. Je pense que tu as une assez bonne expérience en ce domaine, moi certainement moins, mais on devrait bien y arriver !
Comment expliquer l’importance de faire du pair à pair pour un moteur de recherche, alors que j’en ai des très bien qui plantent des z’arbres, offrent des gouttes d’eau aux assos, ou sont une réussite Française qui fait de la pub pour la vie privée sur M6…?
Ben ça, c’est ton boulot, le mien va être de traduire System.out.println(« Hello, World »); en langage C 
Mais bon, c’est vrai que c’est une question dont on doit débattre tous les deux : je peux te donner des pistes, connaissant entre autres les raisons du demi-echec du code java et ce qu’un code C peut apporter, et toi tu peux me dire ce qui peut « se vendre » et ce qui est quasiment perdu d’avance.
Pour moi, tous ces moteurs ont de réels avantages par rapport à ceux des GAFAM. Mais à part Qwant et sauf s’il y en a d’autres du genre que je ne connais pas, ils ont tous l’inconvénient d’être des métamoteurs (ce qui serait un avantage sans ce qui suit) qui ne font que reprendre les résultats des principaux moteurs, et donc ils ne sont pas vraiment libres. C’est un peu comme si je cultivais moi-même mes légumes, mais que je me procure les graines chez Monsanto ! Il est certes plus long, plus difficile, moins rentable de trouver de bonnes graines traditionnelles, de variétés non trafiquées et beaucoup plus riches en nutriments, vitamines et autres oligo-éléments, mais au final c’est quand même bien plus sain et libérateur. « Vendre » ce genre de démarche n’est pas mon boulot et je ne sais pas faire du tout… C’est là que je compte sur des gens compétents en ce domaine
Une autre chose que je ne voudrais pas trop mettre en avant tant que je n’ai pas mieux étudié la question, c’est la possibilité d’améliorer les résultats de Yacy en récupérant au plus vite, grâce à ActivityPub, les nouvelles publications comme les vidéos sur PeerTube entre autres. Si ça s’avère possible, on devrait facilement être meilleurs que GG sur toutes ces publications, et donc au moins lui être bien complémentaire. J’envisage même - toujours sous réserve d’avoir mieux étudié la question - de coupler ce moteur à un gestionnaire de favoris ou de l’utiliser comme tel, ce qui en plus du côté pratique devrait participer à un enrichissement plus rapide des résultats.
Enfin, un outil de recherche libre et ouvert depuis l’indexation du web jusqu’à l’affichage des résultats me semble quelque chose d’indispensable : tant qu’on aura ne serait-ce qu’un tout petit morceau géré de manière non libre, on restera soumis à une dépendance et donc à un contrôle inacceptables.
Expliquer ce que va apporter le pair à pair, alors qu’au départ on aura forcément des requêtes plus lentes et des résultats moins bons, et quand ça demande des ressources et réflexes différents (par exemple en utilisation mobile avec forfaits data limités), c’est un défi en plusieurs temps.
Pour le premier point, je dirais simplement que la liberté a un prix et que c’est à chacun de voir s’il veut le payer ou devenir un esclave panurgiste. Le prix de la liberté en matière de moteur de recherche, c’est d’en avoir plusieurs pour jouer sur la complémentarité et éventuellement d’accepter un peu plus de lenteur. Quoique… La lenteur est ce qu’on reproche actuellement à Yacy, mais il est écrit en Java. Ré-écrit en C, il sera forcément bien plus rapide. Bon, ce qui est moins clair, c’est le temps passé aux communications entre pairs, mais c’est quelque chose qui devrait rapidement évoluer (bien plus vite que ne le fait PeerTube, puisque les pairs sont des serveurs toujours prêts à répondre, pas des particuliers qui regardent la même vidéo en même temps, donc nécessairement peu nombreux).
Pour le second point (mobiles avec forfait data limités), je dirais que c’est un point important à ne pas oublier, et que je n’y avais effectivement pas pensé. Mais à priori, je pense qu’il y a deux approches complémentaires :
- Peut-être y a-t-il de la communication à faire sur l’effet mode de la téléphonie mobile et une réflexion sur ce qu’on veut comme informatique et comme Internet. Ce que j’ai vu de mieux jusque là, c’est cette conf aux JDLL. Si le mobile est un outil extrêmement pratique, il n’est pas nécessaire dans bien des cas, alors que les pratiques et le discours ambiant nous laissent croire qu’il l’est (je n’en ai pas, et n’en ai aucun besoin ni envie !). Il y a certaines choses qu’il vaut mieux faire avec une bonne connexion Internet, il y en a qui sont même impossibles sans ça. Pas que du P2P pour un moteur de recherche ! Et je ne parle pas de surveillance, bridage, censure…
- Il faut certainement prévoir la possibilité d’être simple client, c’est à dire pouvoir disposer d’une simple interface de recherche, située sur un pair Yacy distant (par exemple chez un CHATON) et qui se charge de retransmettre les résultats obtenus. Le forfait ne devrait dans ce cas pas être utilisé plus qu’avec Framabee ou GG.
Cependant, commencer à imaginer cette conquête des cœurs des gens, en plusieurs étapes et avec plusieurs cercles, ça peut aussi permettre de se poser la question des usages, du dessein de ce code, et donc de mieux en réfléchir et l’ergonomie et les fonctionnalités dès la refonte.
Oui, tout à fait d’accord, bien sûr ! Sauf une petite nuance : si j’envisage de convertir le java en C, à priori il ne devrait pas y avoir de fonctionnalités différentes. Bon, ça contredit ce que je mentionnais plus haut et certes, j’aimerais bien autant que possible améliorer tout ce qui peut l’être. Sauf que le mieux est l’ennemi du bien et qu’on risque rapidement de faire un fork aux fonctionnalités très différentes (ce dont je suis loin d’être sûr d’être capable) et donc un développement très long, au lieu d’une simple retranscription qui devrait (du moins j’espère !) être bien plus rapide.
Le but, dans un premier temps au moins, est de pallier aux principaux défauts de Yacy : lenteur, qui entraîne une sous-utilisation, qui empêche un apprentissage correct et donc de bons résultats., et aussi l’utilisation de Java qui pose des problèmes d’incompatibilités de versions.
Après, c’est vrai qu’il ne faudra pas négliger la communication pour ne pas passer à côté de certaines adaptations voire améliorations relativement faciles à implémenter pendant les inévitables réadaptations à faire lors de cette transcription. J’ai pensé à certaines, mentionnées plus haut, mais d’autres ont peut-être des idées intéressantes à garder à l’esprit pendant ce travail.
De quelque manière que ce soit, je vous envoie tout mon courage et tout mes vœux de réussite
Merci 
Avec un tel intérêt et de tels encouragements, ça ne risquera déjà pas de foirer au niveau motivation !
Et en creusant un peu, je découvre que le projet est en totale perte de vitesse parce que ça n’a jamais donné les résultats escomptés. Les causes invoquées sont claires :
J’avoue que tu m’as bien eu ! Je te prenais pour un de ces inconditionnels de Java ou l’un de ceux que mentionne Confucius :
Confucius
Je tiendrai au courant ici et peut-être ailleurs si nécessaire pour une bonne coordination de ceux qui prendront une part active au projet.
). Il ne faut quand même pas oublier que pour aller sur la lune, l’ordinateur de bord avait 64k de ROM contenant l’ensemble des programmes et 4k de RAM. Que fait-on aujourd’hui avec un million de fois plus de RAM ? Ah, oui, au moins on peut programmer en Java, plus en assembleur ! Quel progrès !