1 points par GN⁺ 5 일 전 | 1 commentaires | Partager sur WhatsApp
  • Dans ce projet de réseau maillé à la croissance rapide, des problèmes de dépôt de marque et d’utilisation de code généré par l’IA se sont superposés, provoquant la rupture entre la core team et Andy Kirby
  • Andy Kirby a largement utilisé Claude Code pour étendre le projet à un appareil autonome, une application mobile, un web flasher et un outil de configuration web, et l’équipe affirme qu’une part importante de ce travail relevait du vibe coded et que cela a été dissimulé
  • L’élément déclencheur direct de la séparation a été le dépôt de la marque MeshCore par Andy le 29 mars sans en informer l’équipe ; ensuite, les discussions sur ses intentions ont échoué et la communication est désormais rompue
  • La core team a affirmé que le MeshCore officiel était l’unique source de vérité définie par le dépôt GitHub, et poursuit le développement du firmware, les releases de l’application, la documentation technique et les discussions entre développeurs autour de son nouveau point d’ancrage, meshcore.io
  • Depuis son lancement en janvier 2025, le projet a atteint plus de 38 000 nœuds sur la Map officielle et plus de 100 000 utilisateurs actifs sur l’App officielle, ce qui rend encore plus important d’identifier clairement les espaces d’information officiels et l’entité qui les exploite

Contexte de la séparation

  • Depuis le lancement du projet, l’équipe de développement de MeshCore a publié plus de 85 releases pour MeshCore Companion, le Repeater et le firmware Room Server, avec la prise en charge de plus de 75 variantes matérielles
  • L’équipe dit avoir toujours fait preuve de prudence vis-à-vis du code généré par l’IA, mais Andy Kirby a commencé à avancer de manière autonome en utilisant massivement Claude Code, élargissant progressivement son champ d’action à l’ensemble de l’écosystème MeshCore, jusqu’à l’appareil autonome, l’application mobile, le web flasher et l’outil de configuration web
  • Il est indiqué qu’Andy Kirby a caché à l’équipe que l’essentiel de ce travail relevait du vibe coded
  • L’équipe a mené un sondage sur le thème IA et confiance sur le Discord de MeshCore, mais le texte ne fournit ni chiffres ni résultats détaillés
  • Le conflit se serait véritablement envenimé lorsqu’Andy a déposé la marque MeshCore à la date du 29 mars sans en informer l’équipe
    • L’équipe a tenté de discuter de ses intentions, mais les échanges ont échoué et toute communication avec Andy est désormais interrompue
  • L’équipe explique avoir essayé de résoudre ce problème ces derniers mois et, pour des membres qui travaillaient depuis longtemps sur le projet, le choc a été tel qu’ils ont eu l’impression qu’une personne de l’intérieur s’était alliée à des robots et à des avocats

MeshCore officiel

  • Le cœur du différend actuel concerne le droit d’utiliser la mention « officiel » ; Andy affirme avec force qu’il possède la marque et utilise activement cette expression pour la ligne MeshOS
  • L’équipe définit le seul MeshCore officiel comme étant le dépôt GitHub
    • Ce dépôt sert de source of truth pour déterminer ce qu’est MeshCore
    • Andy n’a jamais contribué à ce dépôt
  • Après la séparation interne, l’équipe a lancé meshcore.io, car Andy contrôlait meshcore.co.uk et le serveur Discord d’origine, laissant très peu d’alternatives
  • Après l’ouverture du nouveau site, Andy aurait utilisé Claude pour en copier jusqu’au look and feel, et une demande de ne pas le faire n’a pas été respectée

Croissance du projet

  • MeshCore a connu une croissance très rapide après son lancement en janvier 2025
  • Au moment de la publication, la MeshCore Map officielle affiche plus de 38 000 nœuds dans le monde, et l’App MeshCore officielle compte plus de 100 000 utilisateurs actifs sur Android et iOS
  • Plus le projet grandit, plus l’importance d’un espace d’information officiel géré par la core team augmente
  • Récemment, la diffusion des sites web MeshCore s’est poursuivie autour de sites nationaux et de communautés mesh locales, avec les exemples suivants listés dans le texte
  • Andy Kirby a joué un rôle important dans la promotion de MeshCore sur sa chaîne YouTube personnelle, mais se concentre désormais sur la promotion de ses propres produits

Orientation pour la suite

  • La core team poursuit autour de meshcore.io le développement des fonctionnalités du firmware, les corrections de bugs, la gestion des PR et les discussions entre développeurs
  • Les journaux de modifications des nouveaux firmwares et releases d’application, les billets de blog et la documentation technique sont désormais diffusés via les canaux ci-dessous
  • Les personnes impliquées dans le blog et leurs rôles sont également présentés
    • Scott est le fondateur du projet et le lead firmware engineer ; il est aussi le développeur du firmware Ripple
    • Recrof est le développeur de la MeshCore Map officielle et responsable du Firmware Flasher ; il partage également des retours sur les débuts du développement de la MeshCore Map
    • Liam Cottle est le développeur de l’App MeshCore officielle et prévoit de publier un guide de démarrage de l’App MeshCore
    • FDLamotte travaille sur les outils Python pour MeshCore et sur des variantes du firmware STM32
    • Oltaco travaille sur un nouveau bootloader OTA Fix destiné à améliorer la fiabilité des mises à jour du firmware

La core team

  • L’équipe MeshCore se compose actuellement de Scott, Liam, Recrof, FDLamotte et Oltaco
  • Cette équipe prévoit de poursuivre à l’avenir une conception et un développement de haute qualité fondés sur des logiciels écrits directement par des humains

Nouveau point d’ancrage

1 commentaires

 
GN⁺ 5 일 전
Commentaires sur Hacker News
  • Si vous ne l’avez pas encore essayé, je recommande vivement de jeter un œil à Reticulum
    Le projet de base semble avoir besoin d’un nouveau mainteneur en ce moment, et le développeur principal a aussi des positions assez tranchées, mais la conception de la couche de protocole de réseau distribué est vraiment très aboutie
    L’application desktop fonctionne via Internet (IP) ou via une connexion USB à des cartes LoRA existantes, et j’ai récemment acheté un https://lilygo.cc/products/t-echo-lilygo sur lequel j’ai installé le firmware open source ; l’expérience en le branchant en USB sur un desktop ou en le connectant en Bluetooth à https://github.com/torlando-tech/columba a été excellente
    Grâce à cette appli, Reticulum donne vraiment l’impression d’être un citoyen de première classe pour la messagerie, et on peut aussi envoyer des fichiers ou des images, avec certaines limites
    Comme ça fonctionne au niveau réseau, on peut aussi créer ses propres applis directement au-dessus de Reticulum

    • Ça tourne déjà bien sur LoRa, mais comme c’est un protocole indépendant du support de transmission, je pense qu’il s’adaptera aussi très bien à d’autres moyens de transport à l’avenir, comme halow, l’optique ou le wifi
      Les gens finiront probablement par se rendre compte que LoRa ne pourra jamais suivre les besoins en bande passante et en débit au-delà de la simple messagerie texte
      Cela dit, j’ai testé un appel vocal en temps réel sur un seul saut LoRa avec Reticulum, et ça a étonnamment plutôt bien fonctionné
      Le wiki de démarrage est ici : https://reticulum.miraheze.org/wiki/Welcome
    • J’ai passé un mois à essayer de construire quelque chose avec Reticulum, mais le tooling autour du protocole était vraiment trop pauvre
      Quand on veut seulement développer une appli, l’expérience de dev devient franchement pénible, et même si le concept est excellent, il y a trop de pièges bloquants pour que le bootstrap soit soutenable
      En particulier, j’essayais de porter la stack en Rust no-std pour la faire tourner sur un appareil LoRA nrf52 et transporter des paquets reticulum sur un réseau MeshCore existant, mais c’était un cauchemar rien que pour vérifier si mes paquets étaient correctement formés
    • Je n’ai encore jamais vu de réseau Reticulum fonctionnel dans des conditions réelles
      Je n’ai vu que de tout petits bancs d’essai
    • Je me demande quelle bande de fréquence on obtient
      Et je me demande aussi si c’est réellement important
    • J’aimerais que nomadnet soit réécrit en Go
  • Je ne comprends pas pourquoi les projets mesh sont si souvent excessivement stricts dans l’application de leurs marques
    Meshtastic est pareil, et l’une des raisons qui m’avaient poussé à m’intéresser à MeshCore était justement qu’en lisant les règles de marque de Meshtastic, je les avais trouvées exagérées

    • J’ai l’impression que la culture radio est assez différente de la culture open source classique
      Le partage libre et sans restrictions n’est pas la norme du monde ; c’est plutôt l’exception
    • Je ne connais pas bien les personnes concernées, mais il est probable qu’elles aient des licences de radioamateur
    • Je ne pense pas qu’il soit juste, à ce stade, de comparer MeshCore à MeshTastic comme s’il s’agissait du même niveau d’application
      Pour l’instant, cela ressemble surtout à une personne qui a déposé la marque au Royaume-Uni sans l’accord des autres membres de l’équipe, pas encore à quelqu’un qui attaque réellement d’autres personnes
    • La raison est simple : ça sent l’argent
      MeshCore a plus de 100 000 utilisateurs et les relais poussent partout dans le monde comme des mauvaises herbes, donc l’incitation à monétiser tout ça est énorme
      Et en particulier, la personne qui cherche à monétiser n’était pas du côté firmware ou app, mais du côté marketing
    • Le protocole est sous CC et j’ai entendu dire que Mark avait dit qu’on pouvait l’utiliser librement
      En revanche, il ne semble pas vouloir que son travail contribue à un réseau de mise à mort IA impossible à arrêter
  • We have always been wary of AI generated code, but felt everyone is free to do what they want and experiment, etc. But, one of our own, Andy Kirby, decided to branch out and extensively use Claude Code, and has decided to aggressively take over all of the components of the MeshCore ecosystem: standalone devices, mobile app, web flasher and web config tools.
    And, he’s kept that small detail a secret - that it’s all majority vibe coded.
    Sans plus de contexte, ce cadrage paraît assez douteux

    1. Qu’une personne « prenne le contrôle » de l’écosystème n’a rien à voir avec l’usage de l’IA. Je ne sais pas exactement ce que cela veut dire ; peut-être simplement qu’il a publié quelque chose que les gens ont envie d’utiliser
    2. La vraie question est de savoir si le code est mauvais. Le fait que l’équipe ne savait même pas qu’il utilisait l’IA semble indiquer qu’au moins, à première vue, il n’y avait pas de problème évident avec le code lui-même. Dans ce cas, pourquoi ne pas le juger sur la qualité du code elle-même
      Le dépôt de marque, si c’est vrai, est clairement un comportement hostile et problématique, mais je ne vais pas m’indigner juste parce que quelqu’un a utilisé Claude Code
    • D’accord
      J’utilise réellement MeshCore et j’exploite plusieurs relais, mais le codage assisté par IA en soi m’importe peu
      En revanche, surtout si c’est closed source, je pense qu’il faut le divulguer
      La tentative de s’approprier l’écosystème via la marque semble délirante, et le fait qu’Andy n’ait pas contribué au projet GitHub lui-même mais seulement construit des extensions commerciales personnelles me gêne aussi
      En même temps, il semble bien que l’équipe centrale de MeshCore ait aussi ajouté un biais anti-IA pour renforcer son récit
    • Pas d’accord
      Au contraire, je soutiens le fait d’avoir soulevé publiquement le problème
      Quiconque prétend avoir correctement relu les 1000 lignes bancales produites par l’IA se trompe lui-même ou trompe les autres, et il est probable qu’il n’ait jamais vraiment fait de revue de code à grande échelle
      Lire 1000 lignes de texte et analyser l’impact en complexité du code ainsi que les edge cases sont deux choses complètement différentes, et une revue globale de ce type peut prendre plusieurs jours
      Même une PR de 100 lignes peut prendre des heures, et si on laisse passer ça avec une attitude du genre « j’ai tout vérifié », il n’est pas étonnant qu’on voie de plus en plus de 0-day et de fuites
      C’est pourquoi je ne pourrai jamais faire confiance à des sorties du type « You are absolutely correct, apologies for the oversight, here's a revised version: »
    • Is the code bad? It sounds like they had no idea he was using AI. That seems to imply there was nothing wrong with the code as-is. Why not judge it on it's merits?
      Si vous avez un peu utilisé l’IA, vous savez que, dans la réalité, ça ne se passe pas comme ça
      Les sorties d’IA sont très douées pour produire des résultats plausibles mais faux, et comme elles sont optimisées pour la plausibilité, elles tombent parfois juste ; mais quand elles se trompent, elles produisent un code qui a l’air bon, ce qui rend le jugement encore plus difficile
      Avec du code écrit par un humain, il est relativement plus facile de se faire une idée de sa qualité
      Bien sûr, il existe des exceptions lorsqu’on a un oracle comme AddressSanitizer ou qu’on peut cloner un projet existant et comparer directement le comportement, mais le plus souvent on n’a pas ce luxe

  • J’ai un peu touché à MeshCore et Meshtastic ; c’est amusant, mais j’ai l’impression que, globalement, c’est très surévalué
    Le concept lui-même devient un peu flou à cause des gens au profil SHTF qui gravitent autour
    Je m’intéressais à ces outils pour des usages de réseau de capteurs, mais en pratique l’essentiel des conversations vient de personnes obsédées par l’échange de messages texte façon Hello World, sans vraiment voir à quel point ces réseaux fonctionneraient mal dans une vraie situation SHTF

    • J’ai à peu près le même ressenti
      Les deux applis mobiles sont assez bancales, et Meshtastic est encore plus agaçant parce qu’on dirait que les équipes UI Android et Apple ne se parlent même pas
      Si on utilise des plateformes différentes, c’est très difficile d’intégrer de nouveaux utilisateurs ou de répondre à leurs questions
      C’était peu coûteux et amusant à mettre en place, mais j’aimerais au moins une meilleure persistance des messages pour éviter de les perdre sans arrêt
    • J’ai participé à un jeu de conquête de zone dans un grand camping en utilisant Meshtastic et le GPS, et pour cet usage c’était vraiment bien adapté et assez amusant
      Mais si ma vie dépendait de ce réseau mesh dans une situation sérieuse, je serais très inquiet
      C’est encore bien trop instable pour être considéré comme un moyen fiable, même si ça peut toujours être mieux que rien
      La configuration des appareils pose aussi problème : j’ai essayé d’installer tout l’environnement de développement sur un raspberry pi 3 pour pouvoir travailler quelque part sans Internet, mais la mémoire s’est épuisée avant même de finir la compilation de l’énorme application web qui sert d’interface client principale
    • Je suis globalement d’accord, et j’ajouterais un point
      L’absence de standards risque aussi de fortement nuire à l’utilisabilité dans une vraie situation SHTF
      Par exemple, il n’est même pas clair pourquoi on devrait utiliser meshstastic plutôt que meshcore, et dans ce genre de situation je ne pense pas non plus que LoRa serait ma priorité mentale
    • Si vous voulez faire quelque chose côté capteurs, mieux vaut regarder LoRaWAN
      Il suffit d’un backend Chirpstack derrière une station de base Mikrotik, et cette combinaison a été largement validée en environnement commercial
    • Je ne sais pas ce que veut dire SHTF
  • Cette application cliente est-elle encore closed source ?
    Pour moi, ce serait éliminatoire à ce stade, et je ne suis pas du tout surpris que ce genre de choses arrive
    Et j’ai l’impression que ce ne sera pas la dernière fois

    • https://github.com/zjs81/meshcore-open
      On n’a plus besoin désormais du client fermé
    • Je développe moi-même un client open source self-hosted, très orienté mobile, pour un base-station radio qu’on puisse utiliser partout
      Il prend aussi en charge MQTT, community observers, bots, webhooks, etc., et je l’ai démarré parce qu’il me fallait un client du quotidien non lié à une radio ; aujourd’hui, c’est devenu un client compagnon assez abouti pour les power users
      L’API radio et le firmware sont ouverts, il existe énormément d’autres options et elles sont parfois même plus riches fonctionnellement que les alternatives closed source, donc je n’ai pas spécialement de ressentiment envers le fait de fermer une partie du logiciel pour gagner de l’argent
      https://github.com/jkingsman/Remote-Terminal-for-MeshCore
    • J’ai été assez surpris d’apprendre que c’était encore closed source, et je doute que cela change
      Notre mesh local testait aussi meshcore la semaine dernière, mais là mon intérêt a pratiquement disparu
  • J’ai déjà vu Andy Kirby sur YouTube, et ses vidéos m’avaient semblé tellement sensationnalistes, exagérées et clickbait que j’en étais venu à l’associer à la gestion du projet ; c’est à partir de là que meshcore a commencé à me rebuter
    Cet épisode me donne l’impression que mon intuition de l’époque était la bonne

  • Vu la situation actuelle, le site en .io affiche un logo « MESHCORE » et le site en .co.uk affiche un logo « MESHCORE(tm) »
    [1]: https://meshcore.io
    [2]: https://meshcore.co.uk

  • Je n’ai jamais utilisé ce projet et je ne connais personne impliquée
    Mais je trouve intéressant de voir à quelle fréquence, chaque fois que quelqu’un arrive avec un discours du type « je vais tout réécrire avec l’IA », cela finit par révéler un énorme cas social
    Bien sûr, ce n’est peut-être pas le cas de cette personne, et je ne connais pas tous les dessous de l’histoire, donc je ne peux pas dire si ce texte est entièrement fiable
    Mais dans mon petit échantillon, le rapport signal/bruit me semble assez bon

  • Would you trust AI generated mesh firmware?
    Je trouve absurde de s’inquiéter de la fiabilité du code généré par IA alors que la qualité de leur propre code est déjà si faible
    Il n’y a aucun test automatisé, et les tentatives d’en ajouter ont été ignorées jusqu’ici
    [0] https://github.com/meshcore-dev/MeshCore/pull/925
    [1] https://github.com/meshcore-dev/MeshCore/issues/1059
    [2] https://github.com/meshcore-dev/MeshCore/pull/1065
    [3] https://github.com/meshcore-dev/meshcore.js/pull/11
    La dernière fois que j’ai regardé, il n’y avait quasiment aucune validation d’entrée, si bien qu’on pouvait diffuser des valeurs absurdes comme des coordonnées GPS hors des limites de la Terre, et le code les acceptait telles quelles
    Je comprends qu’un jeune projet soit en difficulté, mais il est irritant de faire la leçon aux autres sur ce sujet sans investir soi-même dans la qualité du code
    J’aimerais aimer MeshCore, mais son orientation de gestion lui met sans cesse des bâtons dans les roues, et les deux principaux opérateurs que je connais, Scott Powell et Liam Cottle, semblent eux aussi vouloir bâtir une couche métier closed source au-dessus du firmware, ce qui crée des incitations perverses
    Je ne dis pas que le modèle open core est mauvais en soi, mais dans ce cas précis il peut pousser à freiner les alternatives open source pour favoriser leur propre produit payant et closed source
    En plus, les paramètres de diffusion MeshCore recommandés pour les États-Unis sont illégaux, et lorsque j’ai écrit à Liam et Scott il y a quelques mois, ils m’ont ignoré
    [4] https://github.com/meshcore-dev/MeshCore/issues/945

    • Le point #4 est vraiment pénible
      Je suis moi aussi radioamateur, mais pas du genre à signaler immédiatement quelqu’un à la FCC pour une simple entorse au règlement ; en revanche, l’attitude consistant à ne pas savoir ou à ne pas se soucier des règles m’inquiète
      D’abord, je ne suis pas certain que l’interprétation de la réglementation soit correcte, mais à supposer qu’elle le soit, les autres personnes du fil semblaient elles aussi partir du principe qu’elle l’était
      À mes yeux, on lit quelque chose comme « nous enfreignons les règles donc il faut changer ça », auquel on répond « ce n’est pas pratique à Seattle donc on ne le fera pas », ou « ça marche mal à Boston donc ce n’est pas possible »
      Il ne s’agit pas de règles optionnelles
      Les gens qui utilisent des ressources radio publiques respectent généralement la loi, et si le projet fonctionne moins bien lorsqu’il est utilisé légalement, alors c’est au projet d’être corrigé
      C’est pour ce genre de raison que je comprends pourquoi les vieux radioamateurs deviennent de plus en plus sensibles sur ces sujets
    • Would you trust AI generated mesh firmware?
      Cette question elle-même est une question orientée
      Pour l’instant, le seul fait concret présenté est qu’il a simplement utilisé Claude Code
      Ce qui compte davantage, c’est donc de savoir si les tests passent, si cela a introduit des failles de sécurité, ou si des régressions non testées sont apparues

    • Je me demande quelles valeurs précises désignent des coordonnées GPS hors des limites de la Terre
    • Je ne comprends même pas bien pourquoi le protocole a besoin d’envoyer et recevoir du GPS
    • It's ridiculous to me that they're concerned about the trustworthiness of AI-generated code when their code quality is so low.
      Je suis d’accord, mais au moins le code actuel garde encore une structure à peu près cohérente
      Avec l’IA, cela risque vraiment de devenir du slopaghetti
      Le refus d’accepter des tests automatisés se comprend aussi un peu si l’on considère qu’il y a déjà 540 issues et 270 PR ouvertes, avec seulement deux personnes pour faire la revue
      Avec tout ce drama en plus, ils risquent d’avoir encore moins confiance dans les contributions externes
      Si vous voulez vraiment faire merger du code, il vaudrait peut-être mieux vous tourner vers les gens du fork Evo ; de ce que j’ai entendu, pour faire merger une PR qui vous intéresse, il faut soit obtenir assez de likes sur une issue GitHub, soit aller sur Discord et le demander directement
      [1] https://github.com/mattzzw/MeshCore-Evo

  • J’aime utiliser l’IA pour le développement, et je pense aussi que c’est important dans le développement moderne
    Mais il y a clairement une différence entre du code écrit par une IA et du code écrit directement par un humain, et cela doit donc impérativement être divulgué

    • Ce n’est pas tout
      Si une grande partie d’un projet a été construite en vibe coding, il devient aussi flou de savoir si cette personne a réellement le droit d’accepter le DCO, et si elle a le droit de distribuer ce code sous la LICENSE de cette base de code
    • Tout à fait
      Comprendre ce qu’un programme fait n’est déjà pas simple, mais avec du code écrit par un humain, on peut au moins supposer qu’il y avait une certaine intention
      Avec du code produit par IA, on ne sait même pas pourquoi tel élément est là
      Il y a trop de gens qui publient partout sur Internet des projets vibe coded, en cachant d’abord ce fait et en disant simplement « c’est moi qui l’ai fait », tout en récupérant tous les compliments
      Puis plus tard, lorsqu’ils admettent qu’ils n’ont rien écrit eux-mêmes et qu’ils ne savent même pas comment cela fonctionne, ils veulent alors faire passer ça comme si « utiliser l’IA ne posait aucun problème »
      Mais utiliser l’IA comme outil et faire du copier-coller sans compréhension tout en présentant l’ensemble comme son propre mérite sont deux choses totalement différentes