GN⁺: 블로그를 IPFS에서 서버로 이전한 이유

• 본인은 IPFS(InterPlanetary File System)와 ENS(Ethereum Name Service)를 사용한 웹사이트의 선구자였음을 자부함
• 2019년 3월 첫 ENS+IPFS 웹사이트를 설정했을 때, 유사한 웹사이트는 15개 미만이었음
• 2019년부터 2022년까지 IPFS+ENS 브라우저 확장 프로그램(Almonit), IPFS+ENS 검색 엔진(Esteroids)을 공동 개발하고, 개인 블로그도 IPFS+ENS를 통해서만 접근 가능했음
• 그러나 오늘, 블로그를 다시 서버로 옮기기로 결정하고 그 이유를 논의하고자 함

P2P 웹사이트에 대한 흥분

• P2P 웹사이트인 IPFS에 대해 흥분했던 이유는 이론적으로 웹사이트 방문자가 많을수록 더 강력하고, 검열에 저항력이 있으며, 확장성이 높아진다는 점이었음.
• 토렌트 파일이 영원히 살아남는 것처럼, 웹사이트도 그러길 원했음.
• 방문자가 많을수록 사용하기 더 빠르고, 일부 방문자가 콘텐츠를 퍼뜨리는 데 도움을 줄 수 있는 웹사이트를 상상했음.

실제로는 효과가 없었던 이유들

• 대부분의 IPFS 사용자는 자체 노드나 소프트웨어를 실행하지 않고 게이트웨이를 사용함.
• 자체 IPFS 노드를 운영한다 해도 웹사이트에 접근한다고 해서 자동으로 그 내용을 고정하는 것은 아님.
• BitTorrent와 달리 IPFS에서는 콘텐츠를 받으면서 기본적으로 공유하는 것이 아님.
• 웹사이트는 동적 객체이며 내용이 지속적으로 업데이트됨.
• 대부분의 IPFS 웹사이트는 IPNS(내부 이름 시스템) 또는 ENS(Ethereum Name System)를 사용하여 최신 버전의 콘텐츠를 가리킴.
• IPFS에는 아직 IPNS의 최신 콘텐츠를 항상 고정하는 간단한 명령이 없으며, ENS를 사용하는 경우 이더리움 블록체인 이벤트를 수신해야 함.

브라우저에서 IPFS 콘텐츠 접근의 어려움

• IPFS 블로그를 모든 주요 게이트웨이, 모든 IPFS 노드, Brave 브라우저(기본적으로 IPFS 지원), js-libp2p & helia(IPFS의 js 라이브러리)에서 접근 가능하게 하고 싶었으나 신뢰할 수 있는 방법을 찾지 못함.
• cid.contact라는 "콘텐츠 라우팅" 서비스를 발견했으나, 이 서비스를 통해 콘텐츠를 색인하는 방법을 알아내지 못함.
• cid.contact에 의존하면 중앙 집중식 서비스에 대한 의존성이 생김.

간단하고 전통적인 솔루션으로의 복귀

• IPFS 블로그를 잘 운영하기 위한 지속적인 노력에 지쳐, 단순하고 전통적인 작동 솔루션을 원함.
• 현재 읽고 있는 블로그는 Jekyll로 구축되었으며 자체 10달러 서버에서 호스팅됨.
• 여전히 IPFS의 팬이지만, 개인 블로그의 요구 사항에는 아직 부합하지 않음.

GN⁺의 의견

• IPFS는 분산형 웹을 위한 혁신적인 기술이지만, 개인 블로그와 같은 동적이고 빈번한 업데이트가 필요한 콘텐츠에는 아직 적합하지 않음.
• 기술의 복잡성과 유지 관리의 어려움은 사용자가 전통적인 서버 기반 솔루션으로 돌아가는 주된 이유임.
• 이 글은 기술 애호가들에게 IPFS와 같은 분산형 기술의 현실적인 한계와 개선이 필요한 영역을 보여주며, 기술 발전에 대한 지속적인 관심과 참여를 촉구함.