이 스레드에서 Iroh 팀이 fork를 결정하는 과정을 서로 존중하며 논의하는 모습이 보기 좋았음
정말 멋진 상호작용이었음. 과거에는 유지보수자들이 fork를 적대적 행위나 “우리 코드를 훔친다”는 식으로 받아들이는 경우가 많았는데, 이번엔 달랐음
내부 변경사항을 upstream으로 다시 올리는 게 얼마나 어려운지도 잘 드러남. 그들은 자신들의 변경을 수백 개의 작은 PR로 쪼개서 리뷰받을 시간이 없다고 했음. 회사 입장에서는 너무 큰 시간 투자이기 때문임
그래도 원 프로젝트와 구현 세부사항을 가깝게 유지하길 바람. 충분히 안정화된 후에는 작은 단위가 아닌 큰 덩어리 단위 병합도 가능할 것 같음
이런 예의 바른 대화는 오픈소스 커뮤니티의 흔한 드라마와는 대조적이라 보기 좋았음
iroh는 개인용 애플리케이션을 빠르게 만드는 시대에 잘 포지셔닝된 제품처럼 보임
나는 이를 이용해 “app relay”를 만들어보고 싶었음. 사용자가 별도 설정 없이 자신의 네트워크 내 앱이나 데이터를 원격으로 접근할 수 있는 zero-config OSS 솔루션을 구상 중임. 이는 Tailscale 같은 네트워크 릴레이와는 다름
실제로 zero-config는 구현이 까다로움. 나는 mDNS 기반 디스커버리를 다양한 홈 네트워크에서 구현해봤는데, 라우터들이 멀티캐스트를 차단하거나 제한하는 경우가 많았음. 결국 여러 fallback 계층을 쌓고, 어떤 경로가 실제로 동작하는지 휴리스틱을 짜야 했음. QUIC에 multipath가 기본 내장돼 있었다면 훨씬 수월했을 것임
이런 주제에 관심 있다면 awesome-tunneling 리스트를 참고하면 좋음. 특히 OpenZiti가 앱 내부에 터널을 임베딩하는 비슷한 접근을 하고 있음
n0 팀을 정말 좋아함. 나는 그들의 sendme CLI를 자주 써서 P2P 파일 전송을 함
나도 마찬가지임. 그들의 툴킷은 빠르고 안정적이며 즐거운 개발 경험을 줌. 진짜 게임 체인저 같음
좋은 정보 고마움. 나는 보통 magic wormhole을 쓰는데, 파이썬 모듈이 너무 많아 서버에 설치하기 부담스러웠음. 그래서 Windows SQL 서버에서는 toothpyk 같은 간단한 대안을 쓰거나 wget으로 해결했음. sendme를 꼭 써봐야겠음
noq/iroh가 QUIC 패킷을 중계(relay) 하는 방식이 궁금했음. QUIC은 추적이 어려운데, relay가 어떤 패킷을 어디로 보내야 하는지 어떻게 아는지, 혹은 QUIC을 다른 프로토콜로 감싸는지 궁금했음
noq 자체는 릴레이 로직을 구현하지 않음. iroh 릴레이는 단순히 또 다른 IP 서브넷처럼 동작함
실제로는 QUIC datagram을 WebSocket으로 감싸서 전송함. 헤더에는 대상 EndpointId(ed25519 공개키)가 포함되어 있고, 핸드셰이크를 통해 송신자 EndpointId도 인증됨
즉, QUIC datagram을 HTTPS over TCP로 터널링하는 셈임. 이중 암호화이지만, UDP 차단 환경에서도 동작하고 일반 트래픽처럼 보이도록 설계했음
iroh 팀은 여전히 빠른 속도로 발전 중임
주말에 시간을 내서 iroh로 Nebula 같은 오버레이 네트워크를 만들어볼 계획임
그들의 Discord에서 언급된 관련 프로젝트로 iroh-lan과 iron을 참고하면 좋음
QUIC 같은 접근법은 여전히 연결 지속성을 전송 상태에 강하게 묶어두는 구조임
나는 세션 아이덴티티를 전송 계층과 완전히 분리해, 전송 실패가 단순한 복구 가능한 이벤트가 되게 할 수 있을지 고민 중임. QUIC보다 더 나아간 실용적 시스템을 본 사람이 있는지 궁금함
Hacker News 의견들
이 스레드에서 Iroh 팀이 fork를 결정하는 과정을 서로 존중하며 논의하는 모습이 보기 좋았음
내부 변경사항을 upstream으로 다시 올리는 게 얼마나 어려운지도 잘 드러남. 그들은 자신들의 변경을 수백 개의 작은 PR로 쪼개서 리뷰받을 시간이 없다고 했음. 회사 입장에서는 너무 큰 시간 투자이기 때문임
그래도 원 프로젝트와 구현 세부사항을 가깝게 유지하길 바람. 충분히 안정화된 후에는 작은 단위가 아닌 큰 덩어리 단위 병합도 가능할 것 같음
iroh는 개인용 애플리케이션을 빠르게 만드는 시대에 잘 포지셔닝된 제품처럼 보임
나는 이를 이용해 “app relay”를 만들어보고 싶었음. 사용자가 별도 설정 없이 자신의 네트워크 내 앱이나 데이터를 원격으로 접근할 수 있는 zero-config OSS 솔루션을 구상 중임. 이는 Tailscale 같은 네트워크 릴레이와는 다름
n0 팀을 정말 좋아함. 나는 그들의 sendme CLI를 자주 써서 P2P 파일 전송을 함
noq/iroh가 QUIC 패킷을 중계(relay) 하는 방식이 궁금했음. QUIC은 추적이 어려운데, relay가 어떤 패킷을 어디로 보내야 하는지 어떻게 아는지, 혹은 QUIC을 다른 프로토콜로 감싸는지 궁금했음
실제로는 QUIC datagram을 WebSocket으로 감싸서 전송함. 헤더에는 대상 EndpointId(ed25519 공개키)가 포함되어 있고, 핸드셰이크를 통해 송신자 EndpointId도 인증됨
즉, QUIC datagram을 HTTPS over TCP로 터널링하는 셈임. 이중 암호화이지만, UDP 차단 환경에서도 동작하고 일반 트래픽처럼 보이도록 설계했음
iroh 팀은 여전히 빠른 속도로 발전 중임
주말에 시간을 내서 iroh로 Nebula 같은 오버레이 네트워크를 만들어볼 계획임
QUIC 같은 접근법은 여전히 연결 지속성을 전송 상태에 강하게 묶어두는 구조임
나는 세션 아이덴티티를 전송 계층과 완전히 분리해, 전송 실패가 단순한 복구 가능한 이벤트가 되게 할 수 있을지 고민 중임. QUIC보다 더 나아간 실용적 시스템을 본 사람이 있는지 궁금함
noq 코드 스니펫을 참고함
최근 발표된 iroh의 커스텀 트랜스포트 기능 관련 소식도 흥미로움
iroh 0.97.0 블로그 포스트에서 자세히 볼 수 있음
혹시 nQUIC을 확인해봤는지? Noise를 Noq에 통합하면 흥미로울 것 같음
noq(그리고 그 기반인 Quinn)는 자체 “Session” 트레이트를 구현할 수 있어서, TLS나 nQUIC 중 원하는 걸 선택할 수 있음
tsoding의 Noq와 혼동하지 말아야 함. 그건 “Not Coq”에서 따온 이름임