El equipo de desarrollo de MeshCore se separa por disputa de marca registrada y problemas con código generado por IA

 (blog.meshcore.io)
1 puntos por GN⁺ 6 일 전 | 1 comentarios | Compartir por WhatsApp
  • En el proyecto de redes mesh de rápido crecimiento, se superpusieron los problemas de la solicitud de marca registrada y el uso de código generado por IA, lo que terminó separando al core team de Andy Kirby
  • Andy Kirby usó Claude Code de forma extensiva para expandir el trabajo hacia un dispositivo standalone, una app móvil, un web flasher y una herramienta de configuración web; el equipo afirma que gran parte de ese trabajo fue vibe coded y que esto se ocultó
  • El detonante directo de la separación fue que Andy solicitó la marca MeshCore el 29 de marzo sin informar al equipo; después, las conversaciones sobre sus intenciones fracasaron y actualmente ya no hay comunicación
  • El core team dejó claro que el MeshCore oficial es la única source of truth definida por el repositorio de GitHub, y continúa el desarrollo de firmware, los lanzamientos de apps, la documentación técnica y las discusiones de desarrolladores alrededor de meshcore.io
  • Desde su inicio en enero de 2025, el proyecto ya consiguió más de 38,000 nodos en el Map oficial y más de 100,000 usuarios activos en la App oficial, por lo que se volvió aún más importante dejar en claro cuál es el espacio oficial de información y quién lo opera

Contexto de la separación

  • Desde el inicio del proyecto, el equipo de desarrollo de MeshCore ha lanzado más de 85 versiones de MeshCore Companion, Repeater y firmware de Room Server, además de dar soporte a más de 75 variantes de hardware
  • El equipo siempre mantuvo una postura cautelosa frente al código generado por IA, pero Andy Kirby empezó a trabajar de forma cada vez más independiente usando Claude Code extensivamente, ampliando el alcance hacia un dispositivo standalone, una app móvil, un web flasher y una herramienta de configuración web en todo el ecosistema de MeshCore
  • Se indica que Andy Kirby ocultó al equipo que la mayor parte de ese trabajo había sido realizada en formato vibe coded
  • El equipo realizó una encuesta en el Discord de MeshCore sobre IA y confianza, pero el texto no presenta cifras ni resultados detallados de esa encuesta
  • Como punto de inflexión del conflicto, se indica que Andy solicitó la marca MeshCore con fecha del 29 de marzo y no se lo comunicó al equipo
    • El equipo intentó discutir sus intenciones, pero las conversaciones fracasaron y actualmente no hay comunicación con Andy
  • El equipo afirma que en los últimos meses intentó resolver este problema y que, para quienes habían trabajado durante mucho tiempo en el proyecto, el impacto fue tan fuerte que se sintió como si alguien de adentro se hubiera aliado con robots y abogados

MeshCore oficial

  • El eje actual de la disputa es el derecho a usar la etiqueta ‘official’; Andy sostiene con firmeza que él es dueño de la marca y está usando activamente esa expresión en la línea MeshOS
  • El equipo define que el único MeshCore oficial es el repositorio de GitHub
    • Ese repositorio funciona como la source of truth que determina qué es MeshCore
    • Andy nunca ha contribuido a ese repositorio
  • Tras la separación interna, el equipo abrió meshcore.io, ya que Andy controla meshcore.co.uk y el servidor original de Discord, por lo que prácticamente no había otra alternativa
  • Después de abrir el nuevo sitio, Andy usó Claude incluso para copiar su look and feel, y tampoco aceptó la petición de dejar de hacerlo

Crecimiento del proyecto

  • MeshCore comenzó en enero de 2025 y desde entonces ha crecido muy rápido
  • Al momento de este texto, el MeshCore Map oficial muestra más de 38,000 nodos en todo el mundo, y la MeshCore App oficial tiene más de 100,000 usuarios activos en Android e iOS
  • A medida que crece la escala del proyecto, también crece la importancia del espacio oficial de información que ofrece el core team
  • Recientemente ha continuado la expansión de sitios web de MeshCore por país y por comunidades mesh regionales, y el texto enumera directamente los siguientes ejemplos
  • Andy Kirby tuvo un papel importante en la promoción de MeshCore en su canal personal de YouTube, pero ahora está enfocado en promocionar sus propios productos

Dirección operativa a futuro

  • El core team seguirá trabajando desde meshcore.io en el desarrollo de funciones de firmware, corrección de errores, gestión de PR y discusiones de desarrolladores
  • Los cambios de nuevas versiones de firmware y apps, las entradas del blog y la documentación técnica ahora se distribuyen a través de los siguientes canales
  • También se presentan las personas que participan en el blog y sus funciones
    • Scott es el fundador del proyecto y lead firmware engineer, además de desarrollador del firmware Ripple
    • Recrof es el desarrollador del MeshCore Map oficial y responsable de Firmware Flasher, y también compartirá ideas sobre el desarrollo inicial de MeshCore Map
    • Liam Cottle es el desarrollador de la MeshCore App oficial y publicará una guía de inicio de MeshCore App
    • FDLamotte trabaja en herramientas Python para MeshCore y en variantes de firmware STM32
    • Oltaco está a cargo del nuevo OTA Fix bootloader para mejorar la confiabilidad de las actualizaciones de firmware

Core team

  • Actualmente, el equipo de MeshCore está compuesto por Scott, Liam, Recrof, FDLamotte y Oltaco
  • Este equipo planea seguir diseñando y desarrollando software de alta calidad basado en software escrito directamente por personas

Nueva base

Lecturas relacionadas

1 comentarios

 
GN⁺ 6 일 전
Comentarios en Hacker News

  • Si aún no lo has probado, de verdad recomiendo echarle un vistazo a Reticulum
    El proyecto base parece necesitar un nuevo mantenedor ahora mismo, y el desarrollador principal sí tiene posturas bastante firmes, pero el diseño de la capa de protocolo de red distribuida está realmente muy bien pulido
    La app de escritorio funciona por Internet (IP) o por conexión USB con placas LoRa existentes, y hace poco compré una https://lilygo.cc/products/t-echo-lilygo, le cargué firmware open source y la usé; la experiencia de conectarla por USB al escritorio o por Bluetooth con https://github.com/torlando-tech/columba fue muy buena
    Gracias a esta app, Reticulum se siente realmente como un ciudadano de primera clase en cuanto a soporte de mensajería, y aunque con limitaciones, también se pueden enviar archivos o imágenes
    Como funciona a nivel de red, también puedes crear tus propias apps directamente sobre Reticulum

    • Ya funciona bien sobre LoRa, pero como es un protocolo no dependiente del medio de transporte, creo que también encajará bien en el futuro con otros métodos de transmisión como halow, óptico o wifi
      La gente probablemente terminará dándose cuenta de que LoRa jamás podrá seguirle el ritmo a los requisitos de ancho de banda y velocidad más allá de la mensajería de texto simple
      Aun así, probé una llamada de voz en tiempo real en un solo salto de Reticulum LoRa y funcionó bastante mejor de lo que esperaba
      Aquí está la wiki para empezar: https://reticulum.miraheze.org/wiki/Welcome
    • Pasé un mes tratando de construir algo con Reticulum, pero el tooling para trabajar con el protocolo era demasiado pobre
      Desde la perspectiva de alguien que solo quiere hacer una app, la experiencia de desarrollo fue bastante frustrante, y aunque el concepto está padre, tenía demasiadas trampas que te frenan como para que el arranque pareciera sostenible
      En particular, intenté portar el stack en Rust no-std para correrlo en un dispositivo nrf52 LoRA y transportar paquetes de reticulum por una red MeshCore existente, pero hasta verificar si mis paquetes estaban bien construidos fue una pesadilla
    • Nunca he visto una red Reticulum funcional en un entorno real
      Siempre he visto solo testbeds muy pequeños
    • Tengo curiosidad por saber qué banda de frecuencia te asignan
      También me pregunto si eso realmente importa
    • Ojalá nomadnet fuera reescrito en Go

  • No entiendo por qué los proyectos mesh son tan estrictos con la aplicación de marcas registradas
    Meshtastic es parecido, y una de las razones por las que me interesó MeshCore fue que leí la política de marca de Meshtastic y me pareció demasiado exagerada

    • Me da la impresión de que la cultura de la radio es bastante distinta de la cultura open source en general
      Compartir libremente y sin restricciones no es el valor por defecto del mundo; más bien es algo raro
    • No conozco bien a las personas involucradas, pero probablemente varios tengan licencia de radioaficionado
    • A estas alturas, no creo que sea justo comparar MeshCore con casos de aplicación como los de MeshTastic
      Por ahora, parece más bien el caso de una persona en Reino Unido que registró la marca sin la aprobación de los demás miembros del equipo, y todavía no está atacando realmente a nadie
    • La razón es simple: huele a dinero
      MeshCore ya tiene más de 100 mil usuarios y los repetidores están creciendo por todo el mundo como maleza, así que el incentivo para monetizar esto es muy fuerte
      Sobre todo porque la persona que quiere monetizarlo aquí no era alguien del lado del firmware o la app, sino del lado del marketing
    • El protocolo es CC y tengo entendido que Mark dijo que cualquiera podía usarlo
      Solo que al parecer no quiere que su trabajo termine contribuyendo a una red de matanza con IA imparable

  • 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.
    Sin más contexto, este encuadre se ve bastante sospechoso

    1. Que alguien “tome control” del ecosistema es un problema totalmente distinto del uso de IA. No sé exactamente qué significa eso; quizá solo quiere decir que esa persona publicó algo y la gente quiere usarlo
    2. Lo más importante es si el código realmente es malo. El hecho de que el equipo no supiera que estaba usando IA suena, al menos, a que el código en sí no tenía problemas obvios a simple vista. Entonces no entiendo por qué no juzgarlo por la calidad del código mismo
      Si la solicitud de marca es real, claramente es un acto hostil y malo, pero no me voy a indignar solo porque alguien usó Claude Code
    • De acuerdo
      Yo sí uso MeshCore de verdad y opero varios repetidores, pero no me molesta el coding asistido por IA en sí
      Eso sí, creo que debe revelarse, sobre todo si además es closed source
      El intento de adueñarse del ecosistema por medio de la marca registrada sí parece una locura, y también me preocupa que Andy no contribuyera al proyecto en GitHub como tal, sino solo hiciera extras comerciales por su cuenta
      Al mismo tiempo, también parece cierto que el equipo central de MeshCore intentó fortalecer su narrativa metiéndole un sesgo anti-IA
    • No estoy de acuerdo
      De hecho, apoyo que lo hayan señalado públicamente así
      Quien diga que revisó correctamente las 1000 líneas flojas que escupió la IA o se está engañando a sí mismo o está engañando a otros, y probablemente nunca ha hecho una revisión de código grande de verdad
      Leer 1000 líneas de texto y analizar el impacto de complejidad del código y los edge cases son cosas totalmente distintas, y una revisión integral de ese tipo puede llevar días
      Hasta un PR de 100 líneas puede tomar horas, y por esa actitud de “sí, ya revisé todo” creo que cada vez vemos más 0-day y filtraciones
      Por eso nunca podría confiar en salidas del tipo "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 has usado IA aunque sea un poco, sabes que en la práctica no funciona así
      La salida de IA es extremadamente buena para producir resultados que parecen plausibles pero son incorrectos, y como está optimizada justo para parecer convincente, a veces acierta, pero cuando falla produce código que se ve bien y por eso es más difícil de evaluar
      El código escrito por personas suele ser relativamente más fácil de olfatear para ver si es bueno o no
      Claro, hay excepciones como cuando tienes un oráculo tipo AddressSanitizer o puedes clonar un proyecto existente y comparar el comportamiento directamente, pero normalmente no se tiene ese lujo

  • He probado un poco MeshCore y Meshtastic, y aunque son divertidos, siento que en general están bastante sobrevalorados
    El concepto mismo se diluye un poco por la gente con mentalidad SHTF que se mete aquí
    Me interesaban para redes de sensores, pero la mayoría de las conversaciones reales son de gente obsesionada con intercambiar texto tipo Hello World, y no parece que estén viendo lo mal que funcionarían estas redes en una situación SHTF real

    • Yo siento casi lo mismo
      Las dos apps móviles están bastante hechas con las patas, y Meshtastic me desespera más porque parece que los equipos de UI de Android y Apple ni se hablan entre sí
      Si usas plataformas distintas, el onboarding de usuarios nuevos y responder preguntas se vuelve demasiado difícil
      Fue barato y divertido de montar, pero al menos me gustaría que hubiera una persistencia de mensajes mejor para no perder mensajes tan fácilmente
    • Participé en un juego de conquistar zonas caminando por un gran campamento usando Meshtastic y GPS, y para algo así la verdad sí quedó muy bien y estuvo bastante divertido
      Pero si mi vida dependiera de esta red mesh en una situación seria, me sentiría muy intranquilo
      Todavía es demasiado inestable como para considerarlo un medio confiable, aunque probablemente siga siendo mejor que no tener nada
      La configuración del dispositivo también es un problema: intenté instalar todo el entorno de desarrollo en una raspberry pi 3 para poder trabajar en un solo lugar sin Internet, pero la memoria se agotó antes de terminar de compilar la enorme web app que sirve como interfaz cliente principal
    • En general estoy de acuerdo, y agregaría una cosa más
      La falta de estándares también parece que perjudicaría mucho la usabilidad en una situación SHTF real
      Por ejemplo, ni siquiera está claro por qué deberías usar meshcore en vez de meshstastic, y tampoco creo que LoRa fuera a estar muy arriba en mis prioridades en ese tipo de situación
    • Si quieres construir algo del lado de sensores, mejor mira LoRaWAN
      Puedes usar un backend Chirpstack con una estación base de Mikrotik, y esa combinación está muy probada en entornos comerciales
    • No sé qué significa SHTF

  • ¿Esta app cliente sigue siendo closed source?
    Para mí eso sería descarte automático desde ese momento, y para nada me sorprende que haya pasado algo así
    Y no creo que esto termine aquí

    • https://github.com/zjs81/meshcore-open
      Ya no hace falta el cliente cerrado
    • Estoy desarrollando mi propio cliente open source y self-hosted, muy amigable para móvil, para usar con un base-station radio desde cualquier lugar
      También soporta MQTT, community observers, bots, webhooks, etc.; lo empecé porque necesitaba un cliente de uso diario que no dependiera de la radio, y ahora ya está bastante pulido como cliente complementario para power users
      La API de radio y el firmware son abiertos, hay muchísimas alternativas y a veces incluso son funcionalmente mejores que las opciones closed source, así que no tengo mucha aversión a la decisión de cerrar parte del software para ganar dinero
      https://github.com/jkingsman/Remote-Terminal-for-MeshCore
    • Me sorprendió bastante enterarme de que sigue siendo closed source, y probablemente no vaya a cambiar
      La red mesh de mi zona también estaba probando meshcore la semana pasada, pero con esto se me fueron casi todas las ganas

  • He visto a Andy Kirby en YouTube, y sus videos me parecieron demasiado sensacionalistas, exagerados y clickbait, así que terminé asociándolo con la operación del proyecto y desde entonces le perdí simpatía a meshcore
    Esto me da la impresión de que aquella intuición estaba en lo correcto

  • Viendo la situación actual, el sitio .io tiene el logo “MESHCORE” y el sitio .co.uk muestra el logo “MESHCORE(tm)”
    [1]: https://meshcore.io
    [2]: https://meshcore.co.uk

  • Nunca he usado este proyecto ni conozco a nadie involucrado
    Pero me parece interesante que cada vez que alguien sale con eso de “voy a reescribirlo todo con IA”, muy seguido termina resultando ser un enorme problemático
    Claro, puede que esta persona no sea así y yo tampoco conozco todo el trasfondo, así que no puedo juzgar si se puede confiar en todo este post
    Aun así, en mi pequeña muestra el ratio señal/ruido me parece bastante bueno

  • Would you trust AI generated mesh firmware?
    Me parece ridículo que les preocupe la confiabilidad del código generado por IA cuando la calidad de su propio código ya es tan baja
    No tienen pruebas automatizadas y han ignorado intentos de agregarlas
    [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 última vez que revisé, casi no había validación de entradas, así que podías transmitir valores absurdos como coordenadas GPS fuera del rango de la Tierra y el código simplemente los aceptaba
    Entiendo que un proyecto nuevo ande batallando, pero me molesta que sermoneen a otros por ese tema mientras no invierten en calidad de código
    Quiero que me guste MeshCore, pero la dirección del proyecto siempre termina metiéndole el pie, y además los dos operadores principales que conozco, Scott Powell y Liam Cottle, también están intentando montar un negocio closed source encima del firmware, así que los incentivos se ven torcidos
    No quiero decir que el modelo open core sea un problema en sí, pero en este caso podría llevar a aplastar alternativas open source para empujar su producto de pago closed source
    Encima, la configuración de broadcast de MeshCore recomendada para EE. UU. es ilegal, y hace unos meses le mandé correo a Liam y Scott y me ignoraron
    [4] https://github.com/meshcore-dev/MeshCore/issues/945

    • El #4 sí es realmente molesto
      Yo también soy ham, pero no soy del tipo que corre a denunciar a la FCC por una sola infracción; aun así, me preocupa esa actitud de no saber o no preocuparse por por qué existen esas reglas
      Primero, no estoy seguro de que la interpretación de la norma sea correcta, pero suponiendo que lo sea, la mayoría de la gente en el hilo parecía partir también de que sí lo era
      A mí me sonó como si a “estamos violando la norma y hay que cambiarlo” le respondieran “en Seattle sería incómodo, así que no”, “en Boston tampoco funciona bien, así que no se puede”
      No es como si esas regulaciones fueran opcionales
      La gente que usa espectro radioeléctrico compartido en general sí cumple la ley, y si el proyecto rinde peor usándolo legalmente, entonces el problema lo tiene el proyecto y debe corregirse
      Por razones así entiendo por qué los hams mayores se ponen cada vez más sensibles con esto

    • Would you trust AI generated mesh firmware?
      La pregunta misma también está cargada
      Hasta ahora, el único hecho concreto que se ha presentado es que él simplemente usó Claude Code
      Así que lo más importante es si pasa las pruebas, si introdujo fallas de seguridad o si metió regresiones sin probar

    • Me da curiosidad qué valores concretos significan coordenadas GPS fuera del rango de la Tierra
    • Tampoco entiendo bien por qué el protocolo necesita transmisión y recepción de GPS en primer lugar

    • It's ridiculous to me that they're concerned about the trustworthiness of AI-generated code when their code quality is so low.
      Estoy de acuerdo, pero aun así el código actual al menos tiene una estructura más o menos razonable
      Si entra la IA, hay muchas probabilidades de que se vuelva auténtico slopaghetti
      Que no acepten pruebas automatizadas también tiene cierta lógica si ahorita tienen 540 issues y 270 PR abiertos y solo dos personas revisando
      Con este drama encima, quizá desconfíen todavía más de las contribuciones externas
      Si de verdad quieres que tu código se mergee, quizá te convenga más ir con la gente del fork Evo, y según tengo entendido la única manera de lograr que te acepten un PR de interés es reunir suficientes likes en un issue de GitHub o entrar a Discord y pedirlo directamente
      [1] https://github.com/mattzzw/MeshCore-Evo

  • Me gusta usar IA en desarrollo y también creo que es importante en el desarrollo moderno
    Pero sí hay una diferencia clara entre código de IA y código escrito directamente por una persona, así que eso debe revelarse siempre

    • Y no solo eso
      Si grandes partes del proyecto se hicieron con vibe coding, entonces también queda en duda si esa persona realmente tiene derecho a aceptar el DCO, y si tiene derecho a distribuir ese código bajo la LICENSE de ese codebase
    • Totalmente cierto
      Ya de por sí no es fácil entender qué hace un programa, pero en código escrito por personas al menos puedes asumir que había alguna intención detrás
      Con código hecho por IA ni siquiera sabes por qué eso está ahí
      Se ve muchísimo a gente subiendo proyectos vibe coded por todo Internet, ocultando al principio ese detalle y diciendo simplemente “yo lo hice” mientras se lleva todo el crédito
      Luego más tarde sale a decir que en realidad no escribió nada y que ni entiende cómo funciona, y recién ahí intenta normalizarlo con un “usar IA no tiene nada de malo”
      Pero usar la IA como herramienta y copiar-pegar sin entender nada mientras lo empaquetas como si todo fuera mérito propio son cosas totalmente distintas