Skip to content

IPFS mất đội maintainer cốt lõi — web phi tập trung đi về đâu?

Karify98 & Amy 🌸·
Cover Image for IPFS mất đội maintainer cốt lõi — web phi tập trung đi về đâu?

Ngày 24/8, Shipyard — đội kỹ sư đứng sau phần lớn hạ tầng cốt lõi của IPFS — thông báo sẽ dừng toàn bộ công việc vào 30/9/2026, sau khi Protocol Labs quyết định không gia hạn tài trợ. IPFS không biến mất, nhưng thông báo này đặt một câu hỏi khó: một giao thức phi tập trung sẽ sống ra sao khi đội ngũ duy nhất bảo trì nó rời đi?

IPFS là giao thức lưu trữ định địa chỉ theo nội dung: một file được tìm theo hash của chính nó, không theo máy chủ nào lưu nó. Protocol Labs tạo ra IPFS, còn Shipyard là đội thực tế bảo trì các implementation và gateway công cộng mà cộng đồng dùng hằng ngày. Toàn bộ tầng này chạy trên libp2p.

Chuyện gì đang xảy ra

Theo blog chính thức, Shipyard sẽ ngừng "engineering, maintenance và infrastructure operations" cho IPFS từ 30/9. Cụ thể:

  • Các project mất người bảo trì chuyên trách: Kubo (implementation Go), Helia (JavaScript), Boxo, Rainbow, IPFS Desktop, IPFS Companion, Service Worker Gateway, IPFS Check và một số dự án khác.
  • Shipyard ngừng đóng góp cho các project upstream go-libp2p và js-libp2p.
  • Shipyard dừng vận hành hạ tầng công cộng: ipfs.io, dweb.link, check.ipfs.network, delegated-ipfs.dev, các bootstrap node và cụm Wikipedia-on-IPFS.

Điều đáng chú ý: Protocol Labs — chủ sở hữu các domain và hạ tầng — mới là bên quyết định tương lai của chúng. Shipyard chỉ là người vận hành. Blog cũng nêu thành quả gần nhất của đội: tái kiến trúc gateway để chịu được lượng truy cập gấp khoảng 3 lần, trong khi giảm khoảng 80% chi phí vận hành và bảo trì.

IPFS không chết, nhưng đội cốt lõi rời đi

Trên Hacker News, nhiều người vội sửa lại tiêu đề: đây không phải "IPFS đóng cửa". IPFS là một giao thức mở, mạng lưới vẫn chạy, và theo một số bình luận, IPFS Foundation sẽ chuyển sang cấp grant cho từng maintainer cá nhân thay vì nuôi một đội tập trung.

Nhưng sự phân biệt đó không làm nhẹ vấn đề. Một maintainer đang vận hành production nêu đúng loạt câu hỏi chưa có lời đáp: sau tháng 9, ai sẽ nhận báo cáo lỗ hổng bảo mật và phát hành bản vá cho Kubo, Boxo, Helia? Ai sẽ cắt release, hay người vận hành phải đóng băng phiên bản hiện tại? Ai vận hành ipfs.io và dweb.link hằng ngày?

Một grant cho cá nhân không giống một người có commit right và quy trình release rõ ràng. Đó là khoảng trống mà thông báo này để lại — và nó lớn hơn vẻ ngoài.

Vì sao giao thức phi tập trung vẫn mong manh

Nghịch lý nằm ở chỗ: IPFS phi tập trung ở tầng dữ liệu, nhưng lại tập trung ở tầng con người. Khi một đội duy nhất nắm phần lớn implementation chính và gateway công cộng, "bus factor" của cả hệ sinh thái bằng đúng kích thước của đội đó.

Đây là bài toán cũ của open source: phần mềm miễn phí, nhưng người bảo trì phải được trả lương từ một nguồn nào đó. Khi nguồn đó là một công ty duy nhất, cả hệ sinh thái phụ thuộc vào quyết định ngân sách của công ty đó. Trên HN, người ta còn nhắc Cloudflare và Brave trước đây cũng từng rút khỏi IPFS — dấu hiệu cho thấy nhu cầu dùng IPFS chưa đủ để nuôi hạ tầng của nó.

Với developer đang build trên IPFS, hệ quả là một bài toán rủi ro: nếu ứng dụng phụ thuộc vào gateway công cộng hoặc một implementation cụ thể, bạn cần kế hoạch dự phòng trước tháng 9.

Điều cần biết

  • Đừng nhầm "Shipyard rời đi" với "IPFS chết". Mạng vẫn chạy, giao thức vẫn mở. Nhưng "mở" không đồng nghĩa "có người bảo trì" — đó là hai chuyện khác nhau.
  • Rà soát dependency của bạn. Nếu dùng gateway công cộng như ipfs.io hay dweb.link trong production, đừng coi nó là vô hạn. Chuyển sang self-host gateway hoặc chạy node riêng nếu nó nằm trong đường dẫn quan trọng.
  • Đánh giá bus factor. Hỏi thẳng: nếu nhà cung cấp chính ngừng hoạt động ngày mai, ai vá lỗi cho thư viện bạn đang dùng? Với IPFS, câu trả lời hiện chưa rõ.
  • Theo dõi alternative. Cộng đồng nhắc tới Iroh (iroh.computer), do các kỹ sư cũ của IPFS và Protocol Labs xây dựng, như một hướng peer-to-peer có mô hình kinh doanh bền vững hơn. Chưa phải drop-in replacement, nhưng đáng để mắt.

Câu chuyện Shipyard là lời nhắc về một sự thật khó chịu của hạ tầng mở: tính phi tập trung của giao thức không tự lan sang tầng vận hành. Một mạng lưới có thể sống sót khi một node rời đi, nhưng lại chao đảo khi đội duy nhất bảo trì phần mềm và gateway của nó ra đi. Trước 30/9, đội nào đang đặt cược vào IPFS nên tự trả lời câu hỏi đó — bằng kế hoạch cụ thể, không phải hy vọng.


Bài viết được hỗ trợ bởi AI (Amy 🌸). Nội dung đã được kiểm duyệt bởi tác giả.

Related Posts