IPFS pierde a sus principales mantenedores: Shipyard cierra sus operaciones

IPFS Maintainers Winding Down

IPFS pierde a sus principales mantenedores: Shipyard cierra sus operaciones

Shipyard, el equipo que mantenía el núcleo de IPFS, anuncia el cierre de sus operaciones tras la decisión de Protocol Labs de no renovar su financiación. A partir del 30 de septiembre de 2026, dejarán de mantener proyectos clave como Kubo, Helia, Boxo, Rainbow e IPFS Desktop, y cesarán su contribución a la infraestructura pública, incluidos ipfs.io y dweb.link. La compañía destaca sus logros, como la reingeniería de la puerta de enlace que triplicó el tráfico con un 80% menos de costes, y expresa su pesar por no poder implementar las próximas mejoras planificadas.

Ha sido un honor construir junto a esta comunidad; aunque este capítulo de IPFS en Shipyard llega a su fin, seguimos orgullosos de lo que hemos logrado juntos.
  1. momack2

    La publicación aquí es bastante confusa (así que no culpo a nadie que lea esto como que "IPFS el proyecto" se está cerrando en lugar de solo un equipo de mantenedores, es totalmente engañoso) - pero esto es en realidad solo un anuncio de cierre para _Shipyard_ - uno de los muchos mantenedores de implementaciones de IPFS.

    *El Proyecto IPFS no se está retirando ni cerrando* - solo se está cambiando a subvenciones individuales para mantenedores en lugar de soporte centralizado de implementación dentro de Shipyard.

  2. devttyeu

    Triste verlo ir, habiendo sido mantenedor hace algunos años.

    Para los que se pregunten, hay opciones más sostenibles (con un negocio viable y enfocado respaldando el proyecto) para hacer p2p, concretamente Iroh - https://www.iroh.computer/ - que fue construido por ex-desarrolladores de IPFS y Protocol Labs (no tengo relación con el equipo más allá de haber trabajado con ellos en el pasado).

    Lamentablemente Protocol Labs está haciendo... eh, lo que sea ahora, excepto aparentemente apoyar los proyectos de los que obtuvo su financiación de VC/cripto.

  3. rhodey

    Esto es realmente desafortunado. Cuando Cloudflare dejó IPFS se podría decir que este siguiente paso ya estaba en camino. Puede que esté sesgado, pero creo que cuando IPFS decidió dedicar tanto tiempo a "IPNS" para soportar aplicaciones web no estáticas hace años, lo que idearon no se ajustaba a la necesidad. Y sin aplicaciones web en IPFS las cosas no iban a ninguna parte.

    Hace aproximadamente un año escribí IPFS-boot que permite servir aplicaciones web en IPFS proporcionando también una ruta de actualización y sin romper el hash de contenido:

    https://github.com/rhodey/IPFS-boot

    Pero ahora si quieres servir una aplicación web segura y no usar IPFS, en mi opinión la única opción que tienes es decir a los usuarios que instalen Tailscale y que alojen la aplicación web ellos mismos y luego instalar Tailscale en todos los dispositivos.

  4. JuniperMesos

    > Si tienes un recuerdo favorito de trabajar con Shipyard, o una idea que siempre esperaste que IPFS lograra, nos encantaría escucharla. Formulario de Google

    Una cosa importante que me gustaría ver que IPFS o una tecnología web descentralizada similar lograra, es eliminar la necesidad de llenar un formulario de Google para decirle a la gente de Shipyard lo que pienso sobre su mantenimiento de IPFS.

    En serio me molesta cuando personas que aparentemente se preocupan por la tecnología descentralizada o la privacidad usan un servicio centralizado alojado por una gigantesca empresa tecnológica para realizar una tarea porque es conveniente (si ya tienes una cuenta con ellos), y ni siquiera intentan hacer disponible una versión descentralizada. Habría sido mejor si simplemente invitaran a la gente a enviarles un correo electrónico.

  5. scirob

    Intenté construir algunas aplicaciones descentralizadas no cripto. Lo que las mató fue la entrega fiable y siempre disponible dentro del navegador. https://inbrowser.link/ fue un gran salto en utilidad pero llegó demasiado tarde; ipfs.js simplemente nunca funcionó de manera consistente. Al final, la única forma de obtener una buena experiencia para tus usuarios era que tú proporcionaras la puerta de enlace IPFS a HTTP para todo el contenido, pero entonces ¿cuál es el punto? Es solo teatro de descentralización.

    Recuerdo que en 2015 el concepto de IPFS me voló la cabeza; es un momento tan memorable cuando realmente sentiste que alguien había diseñado algo significativamente diferente a los paradigmas actuales dominantes.

    Pero al final parece que fue otro caso de una tecnología genial buscando un caso de uso, no resolviendo un problema real.

  6. its-summertime

    Kubo, Helia, Boxo, Rainbow, IPFS Desktop, IPFS Companion, Someguy, Service Worker Gateway, IPFS Check, libp2p, ipfs.io, dweb.link, check.ipfs.network, delegated-ipfs.dev, Wikipedia-on-IPFS.

    Se siente un poco como el AWS o Azure de la distribución de archivos, tantas cosas tan confusas. También aparentemente Protocol Labs es dueño de varias de esas cosas a pesar de no operarlas.

    Irónicamente parece un sistema bastante frágil.

    Independientemente, muy triste noticia.

  7. mikert89

    ¿IPFS realmente tiene usuarios? Recuerdo cuando recaudaron 270 millones y un montón de gente allí se hizo extremadamente rica.

  8. gritzko

    No puedo decir que IPFS fuera una mala idea. Considera GitHub: es un almacén masivo direccionado por contenido con una sonrisa. Ha habido productos P2P muy populares, por ejemplo Tailscale. Protocol Labs tuvo su pico durante/después de la ICO, pero a largo plazo, (1) no se centraron en una audiencia particular y (2) el rendimiento de la red no era excelente. Personalmente creo que su apuesta por la DHT no fue la correcta (trabajé en esta área mucho antes de IPFS, por cierto). OK, en retrospectiva todos somos sabios.

Más de este día

2026-08-24