IPFS 유지보수팀, 운영 종료 발표
IPFS Maintainers Winding Down
Protocol Labs가 IPFS 생태계의 핵심 유지보수 조직인 Shipyard에 대한 자금 지원을 중단함에 따라, Shipyard는 2026년 9월 30일부로 IPFS 관련 엔지니어링, 유지보수, 인프라 운영을 종료한다. 이로 인해 Kubo, Helia, Boxo, IPFS Desktop 등 주요 프로젝트의 전담 관리자가 사라지고, ipfs.io, dweb.link, IPFS 부트스트랩 노드 등 공공 인프라 운영도 중단된다. Shipyard는 지난 3년간 IPFS 게이트웨이 트래픽을 약 3배 늘리면서 운영 비용을 80% 절감하는 등의 성과를 냈지만, 다음 단계의 혁신을 실현할 기회를 잃게 됐다.
우리는 콘텐츠가 있는 위치가 아닌 그 내용에 따라 주소가 지정되어야 한다는 믿음을 가진 모든 분들께 감사드립니다.
HN 토론
199- momack2
여기 게시물은 꽤 혼란스럽습니다 (그래서 이걸 'IPFS 프로젝트'가 종료되는 것으로 읽는 사람을 탓할 수는 없어요, 완전히 오해의 소지가 있죠) - 하지만 이건 사실 단지 _Shipyard_ - IPFS 구현체를 유지보수하는 여러 팀 중 하나 - 의 종료 발표일 뿐입니다.
*IPFS 프로젝트는 종료되거나 문을 닫지 않습니다* - 단지 중앙화된 구현 지원 대신 개별 유지보수자에게 보조금을 지급하는 방식으로 전환할 뿐입니다.
- devttyeu
몇 년 전 유지보수자로 있었던 사람으로서 사라지는 걸 보니 슬프네요.
궁금해하시는 분들을 위해 말씀드리면, p2p를 할 수 있는 더 지속 가능한 (실현 가능하고 집중된 비즈니스가 프로젝트를 뒷받침하는) 옵션이 있습니다. 바로 Iroh입니다 - https://www.iroh.computer/ - 전 IPFS, 전 Protocol Labs 개발자들이 만들었죠 (저는 그 팀과 예전에 함께 일한 것 외에는 아무 관련이 없습니다).
안타깝게도 Protocol Labs는 지금 뭐.. 뭐라고 해야 할지, 그냥 VC/암호화폐 자금을 받은 프로젝트들을 지원하는 것 외에는 별로 하는 일이 없는 것 같아요.
- rhodey
정말 안타까운 일입니다. Cloudflare가 IPFS를 버렸을 때 이 다음 단계가 이미 진행 중이라고 말할 수 있었죠. 제가 편향되어 있을 수도 있지만, IPFS가 몇 년 전 비정적 웹앱을 지원하기 위해 'IPNS'에 너무 많은 시간을 쏟기로 결정했을 때 그들이 만든 것은 요구를 충족시키지 못했다고 생각합니다. 그리고 IPFS 위에 웹앱이 없으면 아무데도 갈 수 없었죠.
약 1년 전에 저는 IPFS-boot를 작성했습니다. 이는 IPFS에서 웹앱을 제공하면서도 업데이트 경로를 제공하고 콘텐츠 해싱을 깨지 않는 도구입니다:
https://github.com/rhodey/IPFS-boot
하지만 지금 IPFS를 사용하지 않고 안전한 웹앱을 제공하려면, 제 생각에 유일한 옵션은 사용자에게 Tailscale을 설치하라고 하고 웹앱을 직접 호스팅한 다음 모든 기기에 Tailscale을 설치하라고 하는 것입니다.
- JuniperMesos
> Shipyard와 함께한 좋은 기억이나 IPFS가 결국 이루길 바랐던 아이디어가 있다면, Google Form으로 알려주세요.
제가 IPFS 또는 유사한 분산 웹 기술이 이루길 바라는 중요한 것 중 하나는, Shipyard 사람들에게 IPFS 유지보수에 대한 내 생각을 알리기 위해 Google 양식을 작성해야 하는 필요성을 없애는 것입니다.
진지하게, 분산 또는 프라이버시 기술에 관심이 있는 사람들이 거대 기술 회사가 호스팅하는 중앙 집중식 서비스를 사용하여 (이미 계정이 있으니) 편리하다는 이유로 작업을 수행하고, 분산 버전을 제공하려고도 하지 않는 것이 저를 짜증나게 합니다. 그냥 사람들에게 이메일을 보내라고 초대하는 것이 더 나았을 것입니다.
- scirob
저는 몇 가지 비암호화폐 분산 앱을 구축하려고 시도했습니다. 문제는 브라우저 내에서 항상 안정적으로 전달되는 것이었습니다. https://inbrowser.link/ 는 유용성을 크게 향상시켰지만 너무 늦었고 ipfs.js는 결코 일관되게 작동하지 않았습니다. 결국 사용자에게 좋은 경험을 제공하는 유일한 방법은 모든 콘텐츠에 대해 IPFS를 HTTP 게이트웨이로 제공하는 것이었지만, 그러면 그냥 분산 연극일 뿐입니다.
2015년에 IPFS 개념이 제 마음을 사로잡았던 것을 기억합니다. 정말로 누군가가 현재 주류 패러다임과는 확연히 다른 무언가를 설계했다는 느낌이 들었던 그런 기억에 남는 순간이었죠.
하지만 결국 그것은 여전히 실제 문제를 해결하지 못하고 사용 사례를 찾는 멋진 기술에 불과했던 것 같습니다.
- 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.
파일 배포의 AWS나 Azure 같은 느낌이네요. 너무 많은 것이 너무 혼란스럽습니다. 그리고 Protocol Labs가 그 여러 가지를 운영하지 않음에도 불구하고 소유하고 있는 것 같기도 하고요?
아이러니하게도 꽤 취약한 구조로 보입니다.
어쨌든 매우 슬픈 소식입니다.
- mikert89
IPFS에 실제 사용자가 있나요? 그들이 2억 7천만 달러를 모금하고 그곳의 많은 사람들이 엄청나게 부자가 되었던 때를 기억합니다.
- gritzko
IPFS가 나쁜 아이디어였다고 말할 수는 없습니다. GitHub를 생각해 보세요: 그것은 미소가 붙어 있는 거대한 콘텐츠 주소 저장소입니다. Tailscale과 같은 매우 뜨거운 P2P 제품들도 있었습니다. Protocol Labs는 ICO 기간/이후에 정점을 찍었지만, 장기적으로 (1) 그들은 특정 사용자층에 집중하지 않았고 (2) 네트워크 성능이 좋지 않았습니다. 개인적으로 그들이 DHT에 건 것은 올바른 선택이 아니었다고 생각합니다 (저는 IPFS보다 훨씬 전에 이 분야에서 일했습니다). 뭐, 돌이켜보면 우리 모두 현명하죠.