#🧘‍♀️목적

JS(그리고 변형 타입 스크립트)는 가장 큰 개발자 커뮤니티를 가진 가장 흔히 볼 수 있는 프로그래밍 언어이다. 우리의 목표는 해당 개발자들이 IPFS의 이점을 활용하여 생산성을 높이는 것에 초점을 맞춘다.

이 항목는 JS 내의 IPFS 개발에 대한 업데이트를 제공한다. 시간이 좀 지났기 때문에, 다루어야 할 내용이 많다. 이것은 향후 나올 내용들의 첫 번째 업데이트이다. 완전한 로드맵은 아니지만, JS의 IPFS 개발 이력, 앞으로의 대처에 관한 일부 유지 관리자에 의한 결정 그리고 고객이 도움을 줄 수 있는 것들에 대해 명확성을 부여하고자 한다.

📇 이름 및 용어
⏳ IPFS JS 개발 이력
🔀 과거 IPFS JS 사용 패턴

쿠보의 원격 제어

노드.js(Node.js) 컨텍스트의 js-ipfs

브라우저 컨텍스트의 js-ipfs

🧑‍💻 지난 18개월간의 JS에서의 IPFS 개발
💡 2022년, 2023년 JS에서의 IPFS 개발의 미래

Go와 JS 개발의 분리

브라우저 친화적인 새로운 P2P 트랜스포트(Browser-Friendly P2P Transports) 포착 및 활용

완전 사양의 위임된 라우팅 프로토콜(Fully Sepced Delegated Routing Protocols)과 엔드포인트 (Endpoints) 지원

프로토콜 랩스 위임 및 프리로드 노드(Preload Nodes) 셧다운

2023년 포미그래닛(Pomegranate) 출시

포미그래닛이 출시되면 js-ipfs 유지 보수 일시 중지

새로운 이름 등장

다량의 문서 업데이트

🗺 타임라인
🤝 도울 수 있는 방법

#📇이름 및 용어

보다 명확한 이해를 위해 다음의 이름과 용어를 사용한다:

• 쿠보(Kubo) - 이 프로젝트는 이전에 go-ipfs로 알려졌다. 여기에서 자세한 내용 참조
• js-ipfs - 자바 스크립트로 쓰인 오래된 ipfs 구현이다. 밑에서 설명한 것처럼 포미그래닛이 출시되면 사용하지 않는다. 현재 수명 제한 탓에 쿠보에서 했던 것처럼 구현의 이름을 변경할 계획은 없다.
• 포미그래닛 - 포미그래닛은 곧 만들어질 JS에서의 IPFS 구현이며 밑에서 설명한다. 최종 이름은 TBD(확정 예정)며 여기에서 과정을 볼 수 있다. js-ipfs의 기본 라이브러리(예시로 js-libp2p, js-ipfs-bitswap)를 많이 사용하지만 다른 API를 사용하는 별도의 프로젝트다.
• IPFS-in-JS - JS에서의 IPFS 자바스크립트와 타입스크립트 언어를 사용한 IPFS 개발이다. 'js-ipfs' 프로젝트나 '포미그래닛'과는 다르다.
• 위임 노드(Delegate nodes) - 해당 노드들은 위임된 라우팅을 위해 쿠보 RPC(원격 절차 호출) API의 엔드포인트(/api/v0/dht/*)를 보여준다. js-ipfs 노드에는 기본적으로 DHT(분산 해시 테이블)가 활성화되어 있지 않고 브라우저에서도 양호한 DHT 서버가 생성되지 않으므로 DHT 문제를 해결하려면 위임 노드의 도움이 필요하다.
• 프리로드 노드(Preload nodes) - 이 노드들은 쿠보 RPC API의 엔드포인트(/api/v1/refs)를 리모트 노드가 CID를 가져오도록 호출할 수 있다. 브라우저에 추가된 블록이 네트워크의 나머지 부분에서 사용할 수 있도록 장시간 실행되는 IPFS 노드에 미리 로드되도록 하는 데 필요하다. 프리로드 노드는 일정 기간이 지나면 해당 블록들을 수집한다.

#⏳IPFS JS 개발 이력

js-ipfs 프로젝트는 2014년에 시작되었으며 쿠보(당시 go-ipfs)의 기능과 API를 반영하고자 했다. 이는 JS 코어(Core) API의 개념에서 나타나며 쿠보 RPC API를 효과적으로 JS로 변환한 개념이다. 이 인터페이스에는 다음과 같은 여러 가지 구현이 있었다.

• ​ipfs-코어: IPFS의 기능의 JS 기본 구현
• ipfs-http-클라이언트: RPC HTTP콜을 사용하여 위임하는 구현이다. 따라서 쿠보 데몬(daemon)(멀티태스킹 운영 시스템에서 백그라운드로 지속 실행되는 프로그램) 또는 js-ipfs 데몬과 제어 및 소통할 수 있다.

이것은 쿠보와 js-ipfs의 개발을 어색하게 연결했다. js-ipfs에서는 지원되지 않았던 기능을 쿠보에서는 지원하는 것을 볼 수 있다. 그리고 쿠보에서 구현되지 않으면 수정사항이 JS 코어 API에 추가되지 않기 때문에 종종 기능 실험에 방해되는 경우가 있었다.

쿠보의 API 및 디자인 선택과 연계하여 최상위 js-ipfs 프로젝트의 구조는 쿠보와 유사하였으며, 상호 작용 옵션의 키친 싱크(kitchen sink)(더는 취할 조치가 없을 정도로 모든 것을 시도한 상태)가 되었다.

1. js-ipfs를 독립 프로세스로 실행할 수 있는 데몬
2. 핵심 구현에 대한 CLI(커맨드라인 인터페이스)
3. 2개의 RPC 클라이언트와 서버의 구현:\
   1. 쿠보에 맞는 HTTP를 통한 RPC API
   2. 양방향 스트리밍을 위한 웹소켓을 통한 gRPC(구글이 개발한 원격 절차 호출) API
4. HTTP 게이트웨이 서버(쿠보에 비해 뒤처지고 서브도메인 분리 및 검증 가능한 블록/CAR(자체 주소를 가진 컨텐츠 아카이브)응답 등의 최근 사양을 지원하지 않음)

이러한 키친 싱크 측면은 희박하고 'JS방식'과는 반대였다. 예를 들어 js-ipfs를 가져오면 사용하지 않더라도 항상 MFS, IPNS 등등을 얻을 수 있으므로 번들이 커지고 공격 벡터가 많아지는 의존성이 증가합니다.

"...바나나를 원했지만 받은 건 바나나를 들고 있는 고릴라와 전체 정글이었다."-조 암스트롱(Joe Armstrong), 엘랑(Erlang) 프로그래밍 언어 창시자

추가 모듈을 설정하여 노드의 기능을 확장시킬 수 있는 더 유연한 js-libp2p 모델과는 다르다.

#🔀과거 IPFS JS 사용 패턴

JS의 유연한 특성과 여러 런타임 지원을 고려할 때, 몇 년 동안 여러 가지 사용 패턴이 있었다. 위의 개발 기록에서 IPFS 네트워크와 프로토콜은 주로 다음과 같은 방식으로 JS를 사용하여 접근했다.

#쿠보의 원격 제어

이 방법에서는 장기간 실행되는 쿠보 노드가 쿠보의 RPC API를 거쳐 ipfs-http-클라이언트에 의해 제어된다.

nvm(노드 버전 매니저) 다운로드 지표에 의하면, 10배 이상의 npm 다운로드로 지금까지 가장 인기 있는 방법이다.

👍장점

• 쿠보의 모든 기능을 갖춘 IPFS 구현에 대한 액세스와 적극적인 유지보수 및 기능 개발을 제공한다.

👎단점

• 장기 실행 중인 쿠보 데몬을 아키텍처로 가져와 TLS(전송 계층 보안) 종료를 위해 엔진X(nginx)와 같은 리버스 프록시가 필요할 수 있다.
• 공용 인터넷에 노출되는 쿠보 RPC API 엔드포인트를 보호하려면 적절한 보안이 필요하다.

#노드js 컨텍스트의 js-ipfs

이 방법에서는 IPFS 개체를 임포트 및 인스턴스화하거나 공유 js-ipfs 데몬에 액세스하여 응용 프로그램에 직접 ipfs-코어를 포함한다. 전자의 방법에서 애플리케이션의 노드js 프로세스에서도 IPFS p2p 접속이 열린다.

👍장점

•​ JS에 풀 애플리케이션 스택이 있으면 아키텍처가 단순해지고 디버깅이 쉬워진다.

👎단점

•​ DHT 클라이언트 및 서버와 같이 최근에 추가된 일부 기능이 과거에 부족했다.
•​ API가 크고 파악이 어렵다. 쿠보 CLI에서 직접 번역된 많은 메서드를 포함하고 있으며 입력은 빠르지만 자주 중복되는 경우가 생긴다.

#브라우저 컨텍스트에서 js-ipfs

브라우저가 열려있는 네트워크 연결과 각 브라우저 탭에서 사용되는 스토리지 공간에 제약을 가하기 때문에, 믿을 수 있는 IPFS 노드를 만들지 않는다. 따라서 라우팅, 검색 그리고 제공을 포함한 IPFS 노드의 많은 책임은 브라우저에서 위임된 방식으로 처리된다.

안타깝게도 현제 js-ipfs의 기본 위임 설정은 매우 복잡하며 제대로 설계되지 않았다. 특히 브라우저가 안전하고 안정적으로 연결할 수 있는 안전한 웹소켓(WSS)을 지원하는 프로토콜 랩스에서 호스팅하는 프리로드 및 위임 노드를 통해 이 문제가 발생한다.

위임된 라우팅/검색은 js-ipfs는 위임 노드에 쿠보 RPC API(/v0/dht/*)를 사용하여 DHT 조작을 대신 실행하도록 요구한다. 위임 노드는 DHT에 사용자와 컨텐츠 제공자를 조회한 후 연결된 브라우저 노드에 제공되는 컨텐츠를 가져온다.

브라우저에서 위임된 제공을 위해 js-ipfs는 브라우저에서 전체 대그(dag, 암호화폐에서 데이터 모델링)를 프리로드 하기 위해 쿠보 RPC API(/v0/refs)를 사용하여 프리로드 노드에 접속한다. 프리로드 노드는 빗스왑(Bitswap)을 통해 브라우저에서 데이터를 가져온 후 DHT에 공개한다.

주의: 프리로드는 에피메랄 피닝(ephemeral pinning, 지속적인 해쉬를 사용한 메타데이터 분산 기법)으로 이해될 수 있다. CID의 데이터는 IPFS 네트워크에서 사용할 수 있는 짧은 시간 동안 프리로드 노드에 의해 옮겨지며 그 후 가비지가 수집된다.

브라우저에서 실행 중인 js-ipfs 노드는 웹RTC(웹 실시간 소통) 스타 트랜스포트(WebRTC Star transport)을 통해 다른 js-ipfs 노드에 연결할 수 있지만, 초기 접촉을 수행하기 위해 중앙집중형 시그널링 서버가 필요하며 이 트랜스포트에 대한 지원이 아직 실현되지 않았기 때문에 쿠보 노드에 연결하는 데 사용할 수 없다.

👍장점

•​ 이 기능은 유용하며 실시간으로 전송되는 일시적인 데이터의 양이 적은 다중 사용자 앱에서 작동한다.
•​ 웹RTC를 사용하는 js-ipfs는 집중형 시그널링 서버를 필요로 하고 이상적인 장기 솔루션이 아님에도 직접적인 브라우저 간의 소통이 가능하다(초기 SDP 매니페스트가 시그널링 서버를 통해 교환된 후).

👎단점

• 가용성과 성능은 중앙 집중식 인프라에 크게 좌우된다.

• 프로토콜 랩스(PL)가 하드코딩된 HTTP 엔드포인트를 셧다운 했을 경우, 다른 사용자가 HTTPS용 TLS 증명서를 사용하여 클라우드 내 어딘가에서 자신의 쿠보 인스턴스를 실행하여 js-ipfs 설정에서 프리로드로 변경설정 하지 않는 한 js-ipfs 위임은 정지된다. 이는 채택에서의 가파른 장벽이며 중대한 요구다.
• 적절한 libp2p 프로토클을 예상하는 일시적은 '핵(hack)'으로 설계되었다. 아쉽게도 몇 년이 지난 지금도 기존 쿠보 RPC /v0/refs 해킹을 하고 있다.

• 비효율적인 설계
• ​이전 js-ipfs 버전의 하드 코딩으로 일부 프리로드 노드가 불균형한 트래픽을 수신하기 때문에 확장성이 좋지 않다.
• /v0/refs를 통한 프리로드는 매우 낭비적이다.

• 다른 구현에서 지정 또는 채택되지 않음: 웹RTC 스타 트랜스포트는 js-libp2p에서만 구현되며 웹RTC나 위임/프리로드 API가 지정되지 않는다.

#🧑‍💻지난 18개월간의 JS에서의 IPFS 개발

지난 18개월 동안 JS 전선에서 다음과 같은 작업을 수행했다.

1. JS 코어 API와 쿠보의 공정성을 주로 유지하는 것을 포함한 프로젝트의 전반적인 유지보수
2. js-ipfs 및 js-libp2p를 타입스크립트 및 ESM(통합보안 관리 시스템)으로만 현대화 😅
3. js-libp2p의 이더리움 로드스타(Ethereum Lodestar)와 같은 IPFS 외의 다른 프로젝트에 대한 중요도를 고려하여 js-libp2p의 보안 및 성능 개선. 예를 들어 도스와 이클립스(DoS and eclipse) 공격 완화가 추가되었다.
4. js-libp2p에 DHT 클라이언트/서버 구현 추가(노드JS에서는 공용 IPFS DHT에서 컨텐츠를 읽고 쓰는것이 가능하다.)
5. JS에서의 IPFS 구현의 연결옵션 확장. 특히 웹트랜스포트(WebTansport)를 도입하여 브라우저 기반의 IPFS 노드와 브라우저 간 접속을 모두 집적 다이얼하기 위해 중앙 집중식 시그널링 서버를 필요로 하지 않는 새로운 웹RTC 트랜스포트를 추가하고 있다. (이것에 대해서는 밑에 자세하게 설명한다.)

이 시점에서 js-libp2p에는 견고한 p2p 라이브러리가 구축되어 있으며, 여러 IPFS 구현 환경에서 JS/타입스크립트를 사용하여 더 나아가는 방법을 알았다.

#💡2022년, 2023년 JS에서의 IPFS 미래

지금까지 다루었던 JS에서의 IPFS에 대한 배경을 통해 이 섹션은 2022년과 2023년의 실천 계획으로 이동한다.

#고(Go)와 JS 개발의 분리

우리는 쿠보와 js-ipfs에서 완전한 호환성을 가져본 적이 없으며 앞으로 더 투자할 가치가 없다고 생각한다. 프로토콜 랩스의 EngRes(엔지니어링&리서치) 그룹에 의해 유지된 구현은 고 및 JS 구현은 각각의 사용자 기반에 적합한 API를 분산 및 개발할 것이다.

이는 실질적으로 다음과 같이 해석된다.

1. ipfs-http-클라이언트는 js-ipfs를 제어하기 위해 HTTP를 통한 RPC API로 유지된다(웹소켓을 통한 ipfs-grpc-클라이언트도 사용할 수 있다).
2. 포미그래닛 투자로 새로운 포미그래닛용 RPC API가 등장할 예정이다.
3. ipfs-http-클라이언트와 쿠보의 최신 버전에 대한 호환성 테스트는 하지 않을 예정이다.
4. JS를 통해 쿠보 노드를 제어하고 싶다면 쿠보 고유의 라이브러리 js-쿠보-rpc-클라이언트(api)를 사용한다.

#브라우저 친화적인 새로운 P2P 트랜스포트(Transport) 포착 및 활용

웹트랜스포트나 웹RTC 등의 새로운 트랜스포트 덕분에 브라우저가 중앙 권한 TLS 증명서(Central Authority TLS certs) 없이도 다른 libp2p 노드(다른 브라우저 포함)에 접속할 수 있는 환경으로 변하고 있다. 더욱 자세한 내용을 알려면 connectivity.libp2p.io를 보십시오.

즉, 브라우저 노드는 라우팅, 검색 및 제공을 위임하는 장기 실행 IPFS 노드에 더 많은 옵션을 갖게 된다. 예를 들어 네트워크상의 다른 노드에 DHT 또는 Bitswap 요구를 할 수 있게 되었다.

주의: 사용자가 탭을 닫거나 노트북을 절전 상태로 만들 때 브라우저 노드가 네트워크에서 사라지는 것을 막을 수 없으므로 브라우저 노드는 더 긴 수명을 가진 노드에 컨텐츠 제공을 위임한다.

이러한 비약적인 발전을 실현하고 브라우저 컨텍스트에서 js-ipfs에서 논의된 쿠보 RPC API와 프리로드 노드에 의존했던 과거의 더 복잡한 매커니즘을 제거한다.

#완전 사양 위임 라우팅 프로토콜 및 엔드포인트 지원

접속 면에서는 브라우저에서 DHT 쿼리(DHT queries)를 작성할 수 있지만, 다양한 어플리케이션에서 여전히 루팅을 위임하고 싶어할 것으로 예상한다. 리프레임(Reframe)은 쿠보와 같은 다른 IPFS 구현이 구현한 위임 라우팅 프로토콜이다. 현재 HTTP를 트랜스포트로 사용하고 있지만, 쿠보 RPC API에 얽메이지 않는다. libp2p가 제공하는 '제한된 위임 라우터'의 주변 검색을 위한 특정 프로토콜이 있는 경우, 그것 또한 지원한다.

#프로토콜 랩스 위임 및 프리로드 노드 셧다운

위에서 설명했던 브라우저 친화적인 새로운 p2p 트랜스포트를 고려하여 브라우저 컨텍스트의 js-ipfs에 설명된 기존 위임/프리로드 노드와 쿠보 RPC API를 사용한 복잡한 '이야기'를 중지한다. 결과적으로 어플리케이션의 설정이 간단해지게 되며 중앙 집중식 인프라를 제거한다.

위임된 라우팅은 리프레임 엔드포인트를 구성할 수 있다. 브라우저 노드에서 컨텐츠를 제공하는 경우 탭이나 노트북 커버를 닫는 등의 행동을 설명하는 것은 개발자에게 달려 있다. 일반적으로 개인 프리로드 노드를 직접 실행하거나 핀 접속 서비스에 컨텐츠를 명시적으로 업로드하여 제공하는 것이 좋다.

#2023년 포미그래닛 출시

포미그래닛은 JS 런타임에서 이용할 수 있는 것을 활용하면서 지난 8년간 배운 모든 것을 바탕으로 개발될 IPFS 구현이다.

정의되는 속성은 다음을 포함한다.

1. 웹 최초 동형 API - 브라우저, 전자, 노드, 디노(Deno), 번(bun) 등에서 실행 - 노드js API 없음, 표준 JS(예를 들어 노드 스트림이 아닌 웹 스트림, 버퍼가 아닌 유닛8Arrays). 노드 API는 mDNS(멀티캐스트 도메인 네임 서비스)와 같은 특수한 경우에만 고려된다.
2. 레거시 '코어 API' 개념에 얽매이지 않는 리너API(Leaner API) - 포미그래닛은 js-ipfs와의 API 호환성이 없다. 쿠보의 영향을 많이 받은 js-ipfs '코어 API'에 비해 인체공학적 JS 개발자 API가 공개된다(js-ipfs의 ipfs-코어를 사용하여 포미그래닛을 기존 어플리케이션에서 사용하고 싶다면 '코어 API'에서 포미그래닛 API로 어댑터를 만들 수도 있다).
3. ESM(JS 모듈)과 TypeScript만 해당 - JS 개발을 위한 이들 유틸리티에 대한 논의는 더는 없다. 첫날부터 채택할 예정이다.
4. 기존 라이브러리 활용 - js-ipfs의 인터페이스 및 구성에서 벗어나면서도 js-libp2p, js-bitswap 등의 기본 계층을 유지한다. 이러한 라이브러리는 지난 18개월 동안 많은 유지보수(TypeScript 및 ESM 업데이트 포함)를 받아 실제 가동 환경에서 테스트 중이다.우리는 포미그래닛에서도 의지할 예정이다.
5. Unified File API - 파일 시스템처럼 동작하여 CID를 반환하는 고수준 명령어. 예를 들어 다음과 같다.
   
6. 낮은 수준의 IPLD(자체 주소를 가진 컨텐츠 웹의 데이터 모델) 작업을 위해 블록 API를 노출한다.
7. 브라우저 사용 사례에 초점을 맞춘다. 노드에서의 조작을 방해하는 것은 일절 하지 않는다. JS 또는 클라우드 서비스 작업자는 브라우저 기능을 더 빨리 제공하는 제공 경로에 우선순위를 부여한다. 이는 브라우저 런타임은 고유한 런타임으로 다른 구현에서는 포미그래닛 IPFS 구현을 사용할 수 없기 때문입니다. 따라서 HTTP 게이트웨이 사양의 JS 구현과 같은 것에 투자할 계획이 없다. 쿠보, Iroh(클라우드, 모바일&데스크탑 플랫폼을 위한 IPFS의 차세대 구현) 등과 같은 다른 구현이 이 사용 사례를 추구하도록 할 예정이다.
8. 구성 가능한 위임 수준을 사용하도록 설정한다. 라우팅, 검색 및 제공에서는 없음(모두 로컬 포미그래닛 노드에 의해 처리됨)에서 완전(모두 HTTP 게이트웨이 및 피닝 서비스로 처리됨)까지 다양한 수준의 위임이 이루어진다.

#포미그래닛이 출시되면 js-ipfs 유지 보수 일시 중지

포미그래닛을 사용하여 네트워크를 통해 파일을 추가하고 저장할 수 있는 직후 PL EngRes는 js-ipfs의 유지보수를 중지할 것이다. js-ipfs를 인수할 신뢰할 수 있는 실적이 있는 그룹이 없는 경우 커뮤니티는 js-ipfs를 분할 후 유지한다(무심코 저작 권한을 양도할 때 발생할 수 있는 문제를 피하고 싶다).

앞서 논의한 바와 같이, 우리는 js-libp2p 및 js-bitswap과 같이 js-ipfs가 의존하는 많은 라이브러리의 지원과 개발을 중단하지 않을 것이다. 사업은 포미그래닛 등의 핵심 의존관계로 적극 유지된다.

#새로운 이름 등장

여기서 설명한 바와 같이 프로토콜 랩스는 JS를 포함한 추가 IPFS 구현을 위한 공간을 확보하려고 한다. js-ipfs는 IPFS가 아니며 js-ipfs는 JS의 IPFS 구현이 아님을 명확히 하고 싶다. go-ipfs는 2022년에 쿠보로 최소한의 이름을 바꾸면서 이 전환을 성공적으로 수행했다. 포미그래닛과 같은 새로운 구현에서는 반드시 같은 네임스쿼팅(name-squatting)(악의적인 의도를 가진 특정 사용자 이름 또는 계정 조작의 등록) 하는 실수를 하지 않을 것이다. 상세 및 계획은 여기 및 IPFS포럼에서 공유된다.

#다량의 문서 업데이트

전용 웹사이트, 예시, 공식 문서 및 과정까지 많은 곳에서 새 이름과 구현을 고려한 업데이트가 필요하다. 아직 계획되지 않은 대규모 사업이 될 것이다. 여기서 추적할 수 있다.

#🗺타임라인

위의 모든 것을 포함하는 스케줄은 아직 적극 책정되고 있다. 제안된 로드맵을 갱신할 예정이다.

#🤝도움을 줄 방법

1. 🗳 새로운 '포미그래닛' JS 라이브러리의 이름을 제안하고 투표한다.
2. 🗣 포미그래닛 로드맵에 대한 피드백을 제공한다. 현재 js-ipfs를 어떻게 사용하고 있는지 알려주면 앞으로 포미그래닛에서 귀사의 사용 사례가 어떻게 지원될지 알 수 있다.
3. 팀에 합류 - 우리는 이상을 실현하고자 하는 JS와 타입스크립트 개발자를 더 고용하고 있다. 프로토콜/바이트/스트림 수준에서 작업한 경험이 있다면 이상적이다. 자세한 내용은 여기를 참조하십시오.
4. ✋ 기여 - 오픈 소스 기여를 환영한다. 좋은 아이디어가 있고 자금이 필요하십니까? 보조금 요청을 고려하십시오.

JS 런타임에서 IPFS를 탁월하게 만들기 위해 이 여정에 참여해 주어서 감사를 표한다.

보다 다양한 정보 및 방송 관련 소식은

공식 SNS 채널을 통해 확인할 수 있습니다.