iroh 1.0까지의 여정 - IPFS 구현에서 공개 키 기반 연결 라이브러리로

공개 키만으로 상대를 지정해 인증되고 암호화된 연결을 만드는 Rust 라이브러리 iroh가 4년간의 개발 끝에 1.0 출시. 여러 차례 방향을 바꾸며 핵심 연결 기능에 집중 처음에는 모바일 기기를 위한 IPFS 구현이었지만, Delta Chat의 채팅 기록 전송조차 성능과 의존성 제약을 충족하기 어려웠음. IPFS 호환성을 포기하고 QUIC와 BLAKE3 기반 전송으로 단순화 서로 다른 네트워크의 기기도 연결하도록 홀 펀칭과 릴레이, 공개 키 기반 주소 조회를 도입. 직접 연결이 어려운 환경에서는 보조 서버를 활용하며 연결의 신뢰성을 우선 문서와 데이터 동기화까지 갖춘 통합 개발 도구로 확장했지만, 커진 API 전체의 품질을 유지하기 어려워짐. 모든 사용자에게 공통으로 필요한 연결만 남기고 나머지는 별도 크레이트로 분리 1.0은 통신 형식과 API의 안정화를 의미하며 내부 개선은 계속됨. 네트워크 경로를 끊김 없이 전환하기 위한 멀티패스 지원은 quinn을 포크한 자체 QUIC 구현 noq로 발전 IPFS 구현에서 출발한 전송 실험 초기 iroh는 휴대전화처럼 자원이 제한된 기기를 목표로 한 Rust 기반 IPFS 구현이었으며, 여러 IPFS 프로토콜을 구현하고 기존 구현과의 상호운용도 지원함 기존 블롭 전송 프로토콜에 만족하지 못해 IPFS 커뮤니티 안에 move the bytes 워킹 그룹을 만들고 새 프로토콜을 추진함 실험용 라이브러리 krakensync는 콘텐츠 주소 지정에 BLAKE3 만 사용함. 대용량 블롭을 점진적으로 스트리밍하면서 검증할 수 있기 때문임 기본 알고리듬을 만든 뒤 다음 회의까지 이틀 안에 네트워킹을 붙여야 했으나, 당시 rust-libp2p로는 어렵다고 판단함 quinn-noise를 통해 알게 된 quinn은 수정하기 쉽고 Rust다운 간결한 API를 제공해, QUIC 기반 데모를 만드는 데 적합했음 이 실험은 LLM 코딩 도우미가 등장하기 전 진행됨 Delta Chat의 요구와 IPFS 호환성 포기 병행하던 프로젝트는 Delta Chat의 새 기기 설정 과정에서 채팅 기록 백업 하나를 전송하는 기능이었음 디스크와 네트워크 사용량에 엄격한 제약이 있었고, 중단된 전송을 재개할 수 있어야 했음 IPFS 기반 iroh로는 이 좁은 요구조차 충족하기 어려웠으며, 네트워크 성능이 충분하지 않고 의존성 트리도 너무 커졌음 별도의 경량 동기화 라이브러리를 처음부터 만들면서 QUIC 네트워킹과 ...