프로토콜 랩스와 이갈리아(Igalia)는 웹과 브라우저에 더 많은 확장성과 사용자 에이전시를 제공하기 위한 노력의 주요 이정표를 발표하게 된 것을 기쁘게 생각한다.
크로미움에서 미리 정의된 사용자 지정 프로토콜 처리기를 지원!
그게 무슨 뜻일까? 왜 관심을 둬야 할까?
즉, 몇 줄의 코드를 변경하여 'ipfs://' 주소를 지원하는 크로미움(크롬, 브레이브, 엣지, 오페라 등에 사용되는 오픈 소스 브라우저 코드)을 구축할 수 있다.
왜 이것이 상호 운용 가능한 코어를 유지하면서 더 다양한 사용자 요구사항을 충족할 수 있는 브라우저를 향한 핵심 단계인 이유를 알아보십시오.
이갈리아와 프로토콜 랩스
이갈리아는 20년 이상 웹을 개선하기 위해 노력했다. 이갈리아는 오픈소스 컨설팅 회사로 웹 표준에 참여하고 세 개의 주요 웹 플랫폼 렌더링 엔진인 크로미움, 웹킷(Webkit) 및 게코(Gecko)에서 작업한다.
2019년에 우리는 브라우저가 같은 컴퓨터에 있는 서비스와 상호 작용하는 분산형 웹 프로젝트 및 토폴로지(네트워크 레이아웃) 배포를 더 쉽게 만들고 웹 플랫폼 기능 및 호환성 수정 작업을 위해 이갈리아와 계약했다.
이 공동 작업은 이아나(IANA) 부터 WHAT-WG, W3C, LETF, 애플(Apple), 구글(Google) 및 모질라(Mozilla)와의 협상 및 조정에 이르기까지 많은 영역을 다루었다. 2021년의 이 블로그 게시글은 결과로 나온 많은 변화를 보여준다.
IPFS에만 국한된 변경 사항은 없었다. 여러 작업이 브라우저와 웹 플랫폼을 로컬호스트 지향의 어플리케이션 토폴로지 및 비HTTP 프로토콜 작업에 더욱 잘 적응하게 하고 있다. 호환성 문제를 해결하고 엔진 간 보안모델 조정 및 먼지 쌓인 구석 청소를 통해 조금 나아졌다.
하지만 더 큰 목표는 오늘날 웹이 잘 작동하지 않는 곳에 웹을 제공하고 대체 프로토콜이 있는 웹이 어떤 모습인지 실험할 수 있다. 이는 모범적인 변화이므로 표면적인 수정 이상의 작업이 필요했다.
현재까지의 IPFS 브라우저 통합
IPFS는 다양한 수준의 브레이브 및 오페라의 기본 제공 지원 확장부터 모바일 운영 시스템 실험에 이르기까지 여러 브라우저에서 다양한 방식으로 상당한 양의 지원을 달성했다. 2019년 IPFS 브라우저 업데이트를 되돌아보면, 많이 달라졌다.
- IPFS 컴패니온(Companion) 브라우저 확장은 파이어폭스 및 크로미움 기반 브라우저에서 사용 가능하며 IPFS 데스크탑과 같은 로컬 IPFS 노드와 호환된다.
- 오페라(Opera) 브라우저는 https://dweb.link 게이트웨이로 리디렉션(redirecting)시켜 안드로이드, iOS 및 데스크탑 브라우저에서 ipfs와 ipns 구성표를 지원한다.
- 브레이브(Brave) 브라우저는 IPFS 컴패니온을 묶으며 ipfs와 ipns 구성표도 지원한다. 브라우저를 IPFS 공용 네트워크에 완전한 참가자로 만들기 위해 쿠보 IPFS 노드를 설치하고 관리하며 또한 게이트웨이로 리디렉션할 수 있다.
- 카필룬(Capyloon)은 카이 운영체제(KaiOS) 및 파이어폭스 운영체제(Firefox OS) 기반의 웹 기반 모바일 운영 체제이며 파이어폭스의 게코 렌더링 엔진을 사용하여 구축했다. 숫자 0에서 IPFS의 러스트(Rust) 구현인 Iroh(아이로)가 지원하는 ipfs와 ipns 구성표도 지원한다.
다양한 브라우저에 관심, 기회 및 도전이 있다. 많은 성과가 있지만, 아직 알아내야 할 부분이 많다.
다음은 위 표에 대한 몇 가지 참고 사항이다.
- 기본 파이어폭스 부분은 프로토콜 처리기를 통해 IPFS를 통합하고 아이로의 러스트에서 모질라의 핵심 저장소가 아닌 카필론의 분할인 게코로 IPFS 구성 요소를 번들링하기 위해 카필룬이 수행하는 작업이다. 파이어폭스에서 IPFS 지원을 위한 추적 버그가 개방되어 있지만 현시점에서 모질라에서 시행할 계획은 없다.
- 브레이브에서 파일코인 지원은 기본 지갑(파일코인의 기본 토큰을 관리하고 거래 승인을 위한 키 저장)에 있다. 또한, NFT 피닝(대체불가토큰을 파일에 지정) 지원은 2023년에 제공될 예정이며 NFT 자산 및 메타데이터를 로컬 IPFS 노드 및/또는 nft.storage에 저장한다.
기본 통합
ipfs와 ipns를 HTTP 게이트웨이로 리디렉션 하는 것은 IPFS를 웹 플랫폼에 진정으로 기본 통합하는 과정의 한 단계에 불과하다. 하지만 몇 가지 이유로 이상적이지는 않지만, 오늘날 웹의 HTTP 중심 특성과 일치하므로 비교적 간단한 통합이 가능하다. 그러나 웹 브라우저 코어에서 비HTTP 프로토콜을 지원하지 않는 오페라와 브레이브는 둘 다 이러한 수준의 통합을 추가하기 위해 제품에서 사용자 설정을 해야 했다. 이는 비용이 많이 들고 복잡하다.
기본 엔진인 크로미움이 비 HTTP 프로토콜을 기본 제공 기능으로서 더 잘 지원한다면 임베더(embedder)(크로미움 기반 제품을 위한 용어)는 더 쉽게 실험하고 통합될 수 있으며 HTTP 게이트웨이로 단순히 리디렉션 하기보단 웹 플랫폼에서의 진정한 기본 IPFS 지원이 어떤 모습인지 더 많은 시간을 할애하여 알아볼 수 있다. 이갈리아는 위 내용이 가치 있는 목표라고 동의했으며 작업과 관련한 크로미움 커뮤니티에서의 피드백이 긍정적이었으므로 우리는 작업에 착수했다.
주요 크로미움 구조 재조정(Refactor)
이갈리아의 자비 페르난데즈(Javi Fernandez)는 이 대규모 어플리케이션의 다중 프로세스 아키텍처에서 비HTTP 주소를 지원하기 위해 작년 대부분을 매우 크고 민감한 크로미움 코드베이스 조정에 소모했다. 크로미움 커뮤니티의 수많은 엔지니어의 코드 검토를 포함한 여러 단계의 작업을 거친 후 자비는 사전정의 처리 접근을 매우 간단하게 만들어 임베더들이 이제 크롬콘텐츠클라이언트(ChromeContentClient) 또는 에드에디셔널스킴 메서드(AddAdditionalSchemes method)에 추가된 두 줄의 코드에 IPFS의 단순한 리디렉션 통합을 추가할 수 있다.
schemes->predefined_handler_schemes.emplace_back(
"ipfs", "https://dweb.link/ipfs/?uri=%s");
schemes->predefined_handler_schemes.emplace_back(
"ipns", "https://dweb.link/ipns/?uri=%s");
자비는 몇 개의 게시글에서 새로운 아키텍처에 대해 자세히 설명했다.
그리고 최근 포르투갈 리스본의 IPFS 캠프에서 자비가 해당 작업에 관해 다음 영상에서 강연했다.
더 알아보고 싶다면 파일코인 슬랙의 #browsers-and-platforms 채널에 가입하십시오. 이는 매트릭스(Matrix)의 #browsers-and-standards와 IPFS 디스코드로도 연결된다.
보다 다양한 정보 및 방송 관련 소식은
공식 SNS 채널을 통해 확인할 수 있습니다.
