WebDAV를 통한 IPFS

WebDAV는 HTTP 프로토콜을 확장하는 프로토콜이다. HTTP의 목적은 웹서버가 파일서버로의 역할을 하도록 하는 것이다. 사용자는 기본 파일 브라우저 및 기타 로컬에서 실행 중인 애플리케이션에서 WebDAV 지원 웹 서버에 액세스 할 수 있다. 파일 익스플로러에서 바로 웹서버의 파일을 마치 로컬 파일인 것처럼 관리할 수 있게 해준다. 이 기술은 시간이 지남에 따라 모든 주요 운영 체재에 적용되었다. WebDAV가 여기서 달성한 것은 IPFS가 필요한 곳이다. 파일 브라우저에서 쉽게 액세스 할 수 있다. 이러한 과거 프로토콜이 IPFS목적에 적합한 이유를 살펴보겠다.

크로스 플랫폼

WebDAV는 매우 오랜 역사가 있다. 기존 HTTP프로토콜 위에 구현된 개방형 표준이다. 이는 그것에 대한 지원구축이 너무 복잡하지 않아 매우 광범위한 WebDAV 지원이 이루어졌음을 의미한다.

윈도우

윈도우는 윈도우98부터 WebDAV를 지원해, 최근까지 지속해서 지원 중이다.

▲ 윈도우 탐색기에서 WebDAV를 통한 IPFS의 스크린샷

맥

맥은 오랫동안 다양한 측면에서 WebDAV를 지원해왔다. 맥 운영체제 X 10.4 타이거(Mac OS X 10.4 Tiger)는 WebDAV에 대한 보안 액세스를 추가했다.

리눅스

리눅스에는 다양한 데스크탑 환경이 있다. 구글 놈(Gnome, Gvfs-구글 놈 가상 파일 시스템-는 IO 계층임)과 K 데스크톱 환경(KDE, KIO-KDE 인풋/아웃풋-는 IO계층임)을 비교해 보겠다.

• 구글 놈은 2000년에 WebDAV 지원을 받았다.
• KDE는 2002년에 WebDAV지원을 받았다.

▲ 돌핀(KDE와 플라즈마의 기본 파일 브라우저)에서 WebDAV를 통한 IPFS의 스크린샷

iOS 및 안드로이드

모바일에서는 이야기가 조금 다르다. 모바일에 있는 스톡 파일 브라우저는 상당히 제한적이며, 특별한 기능 제공이 제한적이다. 타사 파일 브라우저는 앱 스토어에서 더 많은 기능을 제공한다.

• 안드로이드의 경우 우수한 WebDAV 지원을 제공하는 솔리드 익스플로러(Solid Explorer)가 있으며 또는 Cx 파일 익스플로러(Cx File Explorer)도 있다.
• iOS의 경우 WebDAV 네비게이터(WebDAV Navigator)가 있다. 두 플랫폼 모두 WebDAV를 지원하는 더 많은 앱을 제공한다.

아래는 안드로이드의 Cx 파일 익스플로러에서 WebDAV를 통한 IPFS의 스크린샷이다.

▲ 안드로이드의 Cx 파일 탐색기에서 WebDAV를 통한 IPFS의 스크린샷

WebDAV는 어디에나 있다!

위의 내용은 WebDAV를 모든 주요 플랫폼에서 사용 가능하다는 것을 보여준다. 우리는 WebDAV를 통한 IPFS를 실험을 하고 싶었다. 우리가 아는 한, WebDAV는 IPFS를 더 광범위하고 쉽게 사용할 수 있게 만드는 최적의 프로토콜일 수 있다.

하지만 우리는 이 프로젝트가 얼마나 실현 가능한지 평가해야 했다. 이 글은 그 질문에 대한 답을 해주고 WebDAV 실험의 결과물을 다룬다.

누가 WebDAV를 사용할까?

가장 먼저 알아야 할 것은 (웹)스토리지 세계에서 WebDAV의 현재 사용량이다. 이것은 그 인기를 알려주는 지표가 될 것이며 IPFS목적으로 어떻게 사용할 수 있는지에 대한 몇 가지 아이디어와 통찰력을 제공할 수 있다.

표는 훨씬 나은 이야기를 해준다. 밑 표는 WebDAV를 지원하는 10개의 상위 클라우드 스토리지 공급자(이 사이트에 의하면)이다.

이 표는 몇 가지를 분명하게 보여준다.

1. 스토리지 공급자는 WebDAV 지원을 즉시 제공하지 않는 경우가 많다.
2. 위의 10개 중 절반 이상이 WebDAV를 가능하게 하는 타사 도구를 적어도 1개 가지고 있기 때문에 여전히 WebDAV 지원에 대한 몇가지 요구가 있다.

즉, WebDAV가 전성기를 지난 것처럼 보인다. 암호화된 스토리지에 대한 요구가 점점 더 대중화되면서 WebDAV를 지원이 불가능하진 않지만 어려워 지고 있다.

이를 암시하는 다른 단서는 깃허브(Github)에서 찾을 수 있는 상당히 적은 수의 프로젝트이다. WebDAV 검색 시 모든 클라이언트와 서버 구현으로 찾으면 살짝 다른 결과가 나온다. 이를 WebDAV 서버 시행으로만 범위를 좁히면, 결과는 거의 없다. (이마저도 "로컬 파일 및 디렉토리를 WebDAV 서버에 동기화"에 일치하므로 여전히 일치하지 않는다.)

IPFS는 WebDAV와 어떻게 연관되는가?

오늘날, WebDAV는 원격 폴더를 로컬 폴더와 동기화하는 도구로서 더 많이 사용된다. 하지만 이것은 의도의 일부분이다다.

WebDAV는 웹 서버가 같은 웹 프로토콜에서 파일서버로서 역할을 하도록 설계됐다. 파일 익스플로러를 사용하여 WebDAV를 활성화한 상태에서 웹 서버에 연결할 수 있으며, 익스플로러에서 로컬 파일과 폴더를 찾는 것처럼 파일과 폴더를 보여준다.

또 다른 방법은 웹 서버 내부에 FTP(파일 전송용 프로토콜)기능을 통합하여 FTP가 아예 필요 없다고 상상하는 것이다. 이 경우 웹 서버만 있으면 충분하다.

이러한 기능의 요구사항 중 하나는 파일과 폴더를 탐색하는 기능이다. 이 기능은 WebDAV가 네트워크에 있는 파일과 폴더에 쉽게 액세스할 수 있는 방법을 IPFS에 제공할 수 있다. 사용자는 IPFS가 내부에서 사용된다는 사실을 모른채 데이터를 검색할 수 있다.

잠재적인 WebDAV 이점

WebDAV는 표준으로서 HTTP 방법을 필요에 맞춰 확장한다. 이 표준화가 IPFS를 더 쉽게 사용할 수 있는 경우, 일부를 지원하는 것을 고려하는 데 도움이 된다. 또한 다음과 같은 새로운 사용 사례들도 제공한다.

1. 쓸 수 있는 게이트웨이. MFS(IPFS 내부의 파일 변환을 쉽게 하기 위해 만들어진 도구)를 생각해보십시오.
2. 현재 WebDAV를 이미 지원하는 애플리케이션의 IPFS 통합.
3. WebDAV를 통한 윈도우, 맥, 리눅스에서의 IPFS 즉시 지원.
4. 많은 앱 중 하나를 통해 안드로이드와 iOS 지원.

더 많은 잠재적인 이점이 있지만, 이 짧은 리스트는 WebDAV 지원이 무엇을 가져올 수 있는지에 대해 이미 엄청난 것을 보여준다.

WebDAV 및 Go 언어

IPFS를 참고하여 시행된 KUBO(4세에서 10세의 아이들에게 초점을 맞추어 설계된 교육 목적의 코딩 솔루션)는 Go언어로 작성됐다. Go에는 완전한 WebDAV 서버 패키지가 있는 것처럼 보인다. 기술적인 차원에서는 이 패키지는 적어도 KUBO에서 WebDAV 지원 실행을 고려할 수 있도록 한다.

개념 증명: 노드JS(NodeJS, 자바 스크립트를 사용한 오픈소스 서버환경)에서 WebDAV 서버 분리

몇 달 전 마크 게이저(Mark Gaiser)는 노드JS에서 개념 증명(POC) 프로젝트를 만들기 시작했다. 이 언어가 선택된 이유는 빠른 개발의 용이성과 이미 완벽하게 작동하는 WebDAV 서버 패키지의 가용성이다.

"여기서 취하고 싶었던 접근 방식은 가능한 한 많은 기존 구성 요소를 사용하는 것이었다. 예를 들어 해당 WebDAV 서버에 이러한 서버를 시작하기 위해 몇 가지 방법이 있다. 가장 쉬운 방법은 특정 폴더를 해당 서버 패키지가 제공할 'WebDAV 폴더'로 설정하는 것이다."-마크 게이저

또 다른 방법은 해당 패키지 논리를 따르고 사용자 지정 파일시스템(custom filesystem)을 만드는 것이다.

많은 테스트 후에 마크는 어떤 형태로든 가상 파일 시스템을 구현해야 한다는 결론에 도달했다. WebDAV가 바라던 대로 나오지 않더라도 가상 파일 시스템을 사용하면 도움이 될 것으로 생각했다.

예를 들어 이 가상 파일 시스템이 존재한다면 사용자는 노드JS 파일 시스템 기능을 이용하여 IPFS에서 파일을 읽을 수 있다. 사실상 필요한 것은 노드JS의 파일시스템 API(응용 프로그램 인터페이스)와 호환되는 라이브러리였다.

개념적으로 이는 이제 다른 클라우드 스토리지 공급자를 위한 가상 파일 시스템과 같은 수준이 됐다. 한 가지의 예로 드롭박스(Dropbox) 대신 이 패키지가 원하는 효과를 달성하는 것이다.

이와 같은 패키지가 더 많이 있으며, 이를 통해 파일 시스템을 효과적으로 구현할 수 있다. 각 구현이 다르므로 이와 관련해서 기존 프로젝트를 재사용할 방법이 없었다. 하지만 그 개념 중 일부를 검토하고 부분적으로 재사용할 수 있다.

가상 파일 시스템 접근 방식은 WebDAV 서버 포크(블록체인이 여러 갈래로 나뉘면서 기존과는 다른 방식의 새로운 버전이 생기는 것)로 이어진다.

WebDAV 서버 패키지는 기본 파일시스템 경로를 정의할 수 있었던 반면, 사용자 정의 파일시스템 구현 개체를 제공할 방법이 없었다. 해당 패키지의 개발자는 적절한 테스트가 수반된다면 해당 패치가 환영받을 것이라고 말했다.

마크는 ‘미래의 언젠가’ PR(불특정 다수의 일반 대중을 대상으로 이미지의 제고나 제품의 홍보)을 만들 목적으로 저장소를 나눴다. 하지만 당분간은 자체 저장소에 저장된다. 시간이 지나 이를 수용할 수 있도록 추가적인 시간이 투입되면 다시 통합할 것이다.

이 포크를 사용하면 노드의 파일시스템 기능을 구현하는 어떤 가상 파일 시스템 개체든지 WebDAV 디렉토리로 사용할 수 있다. 이 접근은 약간의 수정으로 드롭박스 가상 파일시스템 패키지(dropbox virtual filesystem package)에서 작동했다. 이것은 가상 파일 시스템 접근 방식이 작동 가능함을 입증했다.

노드JS의 IPFS 지원 가상 파일 시스템

고지 사항:

1. 이 라이브러리는 진행 중인 작업이다.
2. 품질은 테스트 목적으로만 제공된다.
3. 재사용하기 위해서는 더 많은 작업이 필요하다.
4. 이것을 재사용하지 마십시오!

위의 조항들을 제외하고는 IPFS가 지원하는 가상 파일 시스템을 만들 수 있다. 하지만 이 라이브러리는 WebDAV 지원을 게이트웨이 코드에 추가해야 하는지 알아내기 위한 목적으로 만들어졌다.

그러므로 이 라이브러리는 게이트웨이를 사용하지 않고(게이트웨이 콘텍트 내에서는 의미 없음) 포트 5001의 내부 IPFS HTTP API를 사용한다. 즉, 이 라이브러리가 로컬 노드를 실행하는 경우에만 실제로 유용하다.

이 라이브러리는 시간이 지남에 따라 더욱 유용해질 것이다. 마크의 계획은 다음과 같다.

1. 내부 HTTP API 혹은 게이트웨이 API를 사용하는 것과 같은 백엔드 처리 선택
2. 지원 작성
3. 결정될 이름으로 npmjs(노드 패키지 매니저 자바 스크립트)에 추가

아이디어는 빌더들이 해당 라이브러리에서 '기본적으로 보이는' 노드JS 파일 시스템 함수를 실행할 수 있어야 한다는 것이다. 다음은 그에 대한 예시이다.

▲ 빌더들이 실행할 수 있어야 하는 함수의 예시

WebDAV 결과를 통한 IPFS

IPFS가 지원하는 가상 파일 시스템을 사용함으로 WebDAV 애플리케이션을 통한 작동하는 IPFS가 생긴다. 이제 마침내 "IPFS가 WebDAV 보다 얼마나 더 실현 가능한가?"에 대해 대답할 능력을 갖춘다.

이에 답하기 위해 마크는 다양한 플랫폼과 두 가지 WebDAV 구현에서 여러 테스트를 실행했다. 표는 다음과 같이 읽어야 한다.

• 각 열의 첫 번째 그림 이모티콘은 노드JS에서의 내 구현을 나타낸다.
• 각 열의 두 번째 그림 이모티콘은 rclone에서의 WebDAV 구현을 나타낸다.(이 구현은 Go 언어로 작성되고 잘 지원되는 것 같으므로 선택되었다.)

참고사항:
😠 = 아예 작동하지 않음. 고치기 위한 명확한 경로 또한 없음
😢 = 특정 조건에서만 작동 혹은 수동 단계가 필요. 특정 앱을 위한 메모 확인.
😄 = 전체적으로 좋음.
🦄 = 누군가의 추측. 적절하게 테스트가 불가능하지만 잘 작동하는 것으로 보임.

파일 오픈(File opens)
😄은 모든 파일이 일반적으로 여느 파일처럼 파일 브라우저에서 열리는 것이다.

윈도우랑 리눅스에서는 적용되지 않았다. 윈도우는 WebDAV에서 모든 파일에 대해 50MB 제한이 있었다. 그 밑 용량의 파일을 열면 'ok'ish.'가 작동한다. 50MB 이상의 파일을 열면 어떠한 오류나 경고 없이 실패한다.

리눅스(적어도 KDE의 Dolphin)은 크기 제한이 없다. 둘 다 열려있는 각 파일이 먼저 다운로드 되고(이에 대해 피드백은 얻지 못함) 다운로드 완료 후에 열린다. 이것은 시간이 오래 걸릴 수 있다.

스트리밍(Streaming)
스트리밍은 파일 열기와 많은 관련이 있다. 윈도우나 리눅스는 재생을 시작하기 전에 데이터를 전체적으로 다운로드 해야 하므로 스트리밍을 하지 않는다.

안드로이드(Solid Explorer)는 백그라운드에서 실행되는 일종의 '스트리밍 서비스(streaming service)'가 있다. 파일을 부분적으로 다운로드 하고 그 부분에서도 처리를 하는 것으로 보인다. 이것은 파일의 크기에 상관하지 않고 즉시 재생되는 경험을 제공한다. 이 부분에서 솔리드 익스플로러(Solid Explorer)와의 경험은 기본 파일 시스템처럼 느껴질 것이다.

브라우징(Browsing)
KDE에서 돌핀 파일 브라우저(Dolphin file browser)를 사용할 때 유저들이 /ipfs/로 탐색할 것으로 기대된다. 하지만 안드로이드나 윈도우는 이런 방식으로 작동하지 않는다. 이유는 복잡하다.

윈도우에서 /ipfs/로 탐색하고 싶다고 가정하자. 만약 /ipfs 폴더가 를 하위 폴더로 가지고 있다면 가능하다. 하지만 없다. 따라서 /ipfs 에서 어떤 네트워크 인덱서(CID)를 탐색할지 모르기 때문에 윈도우(그리고 안드로이드의 솔리드 익스플로러)에서 작동하지 않는다.

그들은 주어진 주 프로세스의 하위 프로세스를 모른다. KDE의 돌핀은 이 경우에 신경 쓰지 않고 열려고 시도한다. 이것이 바로 여기에서 작동하는 이유다. 윈도우 및 안드로이드(솔리드 익스플로러)의 경우 WebDAV 연결을 만드는 순간 탐색하려는 정확한 지점을 지정해야 한다. 따라서 /ipfs/로 연결을 만들고 /ipfs/로 탐색하고 싶으면 찾아보려는 새 네트워크 인덱서에 대한 WebDAV 연결을 편집해야 한다.

메타데이터 작동(Metadata works)
파일 브라우저가 항복을 표시하는 방법을 정의하는 파일 속성이다. 예를 들어 폴더 유형이 있는 항목은 json 파일이 아닌 폴더로 표시되어야 합니다. 이는 테스트 된 모든 환경에서 잘 작동합니다.

쓰기 방지(Write prevents)
쓰기 방지는 특별히 강조되어야 한다. WebDAV 자체에는 명시적인 읽기 전용 모드가 없다. 따라서 여기서 시도하는 것은 처음부터 WebDAV에서 완전히 지원되지 않는다.

여기에 "버그가 많은 것이다!"라는 적용되는 면책 조항이 있다. 이를 정상적으로 처리하는 것은 앞으로 구현 세부 사항일 뿐이다.

복사(Copy)
윈도우에서는 50MB 제한 내에 있는 파일만이 상호 작용이 가능하므로 이 환경은 좋지 않다. 더 큰 용량(복사본 포함)과 상호 작용하면 작동하지 않는다. 다른 테스트 환경은 여기에서 잘 작동한다.

플레이스홀더 리드미(Placeholder readme)
플레이스홀더 리드미는 /ipfs와 /ipns에서 볼 수 있는 마법 같은 파일이다. 이러한 리드미 파일은 수행할 수 있음을 보여주는 스텁 싱글라인 파일이다(stub single-line files). 윈도우 또는 안드로이드를 사용할 경우 /ipfs/에 직접 매핑(mapping)해야 하므로 절대 볼 수 없을 것이다.

WebDAV 미래를 통한 IPFS

우리는 여러 의견을 찾고 있다. 이러한 결과에 대해 어떻게 생각하는지, 잠재적인 WebDAV 지원 게이트웨이로 어떤 종류의 사용 사례를 상상할 수 있는지 궁금하다. 이에 대한 의견이 있다면 생각을 공유하고 WebDAV를 통해 앞으로 나아가는 길을 선택하는 데에 도움을 주길 바란다.

슬랙, 디스코드, 매트릭스 또는 포럼에서 직접 연락할 수 있다.

도와주세요!

IPFS를 보다 광범위하게 액세스할 수 있게 하는 것은 항상 염두에 두어야 할 훌륭한 목표다. 이 프로젝트에 관심이 있고 개선하고 싶다면 자유롭게 코드를 해킹하십시오.

더 큰 변화를 염두에 두고 있다면 오픈 그랜트(Open Grant)를 살펴볼 가치가 있다. 옵션을 선택하고 사용해 보십시오.

WebDAV는 지원되지만 IPFS는 지원되지 않는 흥미로운 프로젝트를 알고 있다면 여기에 Github 이슈로 보내십시오.

이것을 실행할 수 있을까?

물론이다! 이 저장소는 전체 실험을 직접 실행하는 방법에 대한 세부 정보를 제공한다.

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

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