I2P 개발자 회의 - 2016년 3월 4일

15:00:05 <zzz> 0) 안녕 15:00:23 <zzz> 1) 이 회의의 구조 15:00:32 <zzz> 2) 로드맵 논의 15:00:37 <zzz> 0) 안녕 15:00:41 <zzz> 안녕 15:00:54 <str4d> 안녕 15:01:02 <xcps_> 안녕! 15:01:27 <orignal_> 무슨 일 있어? 15:02:18 <zzz> http://zzz.i2p/topics/2021 의 스레드와 http://i2p-projekt.i2p/en/get-involved/roadmap 의 현재 로드맵을 검토해 주세요 15:02:27 <zzz> 1) 이 회의의 구조 15:03:22 <zzz> 바로 로드맵으로 들어갈까요, 아니면 먼저 상위 수준의 우선순위에 대해 이야기할까요? 15:03:53 <str4d> 후자부터 하죠 15:04:41 <zzz> 좋아요, 스레드에서 두 가지 우선순위를 던졌습니다 - 네트워크를 성장시키기, 그리고 보안 강화 15:04:55 <zzz> 상위 원칙으로서 어떻게 들리나요? 15:05:25 <zzz> 먼저 무엇이 중요한지 결정합시다 15:05:32 <EinMByte> 예상한 대로인 것 같아요 15:05:48 <EinMByte> "네트워크를 성장시키기"는 폭넓은 의미여야 해요 15:05:57 <str4d> 그건 큰 주제로 훌륭하다고 봅니다 15:06:03 <zzz> anonimal이 스레드에 더 많이 던지긴 했는데, 제가 의도한 바는 아니었어요 15:06:13 <xcps_> 제 생각에는 보안 강화가 항상 가장 중요해야 해요 15:06:28 <zzz> 로드맵을 검토하면서 고려해야 할 다른 원칙이 있나요? 15:06:28 <str4d> 여기서 해야 할 일은, 제 생각에는, 잠재적 산출물 관점에서 그것들이 실제로 무엇을 의미하는지 파악하는 거예요 15:06:40 <EinMByte> 그러니까 "네트워크를 성장시키기"는 "연구자들의 관심 증대"도 포함해야 해요 15:07:00 <zzz> "네트워크 성장"은 매우 다양한 걸 의미해요 - 스레드를 보세요 15:07:09 <str4d> EinMByte, 맞아요, 저도 스레드에서 언급했던 것 같아요 15:07:36 <zzz> 곧 이것들이 무엇을 의미하는지 정리할게요. 지금은 뭐가 중요한지 합의하죠. 15:07:58 <str4d> 저에겐 사용성이 매우 중요하고, 제 생각에는 위 두 영역에도 기여해요 15:07:58 <zzz> 우리가 성장을 계속하면 무엇이든 가능해요. 성장이 멈추면 끝이죠 15:08:05 <zzz> 동의해요, str4d 15:08:41 <str4d> 단기적으로는 사용자 기반을 늘리는 측면에서, 장기적으로는 대외 노출 확대, 연구자들의 사용 용이성 향상 등에서요. 15:09:11 <EinMByte> 또한 성장만이 연구자들을 끌어들이는 유일한 방법이라는 점도 유념하세요 15:09:25 <zzz> 사용자가 늘면 개발자도, 연구자도, 콘텐츠도 더 많이 와요, 계속해서요 15:09:37 <EinMByte> 큰 네트워크일수록 연구 대상로 더 흥미롭죠 15:10:05 <EinMByte> 그래서 그 두 가지 우선순위에는 모두 동의할 수 있을 것 같아요 15:10:16 <zzz> 지난 1년 동안 성장의 대부분은 vuze에서 왔어요. 훌륭하지만, '자연발생적' 성장도 더 있었으면 합니다 15:10:43 <zzz> 하지만 임베디드 앱에서의 성장, 또는 전반적으로 애플리케이션에 집중하는 것이 성장의 가장 쉬운 길일 수도 있어요 15:10:48 <str4d> 맞아요 15:11:04 <EinMByte> zzz: 많은 사람들에겐 백그라운드에서 I2P가 실행되고 설정을 대신 처리해 주는 앱을 쓰는 게 더 쉬워요 15:11:12 <sadie> 안녕 - 조금 늦었네 15:11:20 <zzz> 안녕 sadie 와줘서 기뻐요 15:11:23 <str4d> 그건 제 생각에는 UI와 API 양쪽의 사용성 개선에서 나올 거예요 15:11:42 <str4d> 후자는 이미 여러 스레드에서 작업 중이에요 15:11:48 <zzz> 어떤 면에선 UI 전문가는 앱들이에요, 그들이 i2p를 번들하고 최선이라고 판단하는 방식으로 드러내거나(혹은 숨기거나) 하게 합시다 15:11:58 <str4d> 음 15:12:08 <EinMByte> str4d: 같은 문제에 대한 다른 해법이죠, 맞아요. 그리고 모든 것에 I2P를 번들하는 건 확장성이 없다고 생각해서 저는 그게 더 마음에 들어요 15:12:30 <str4d> 그게 제가 Android에서 취하던 접근이랑 비슷해요 15:13:04 <EinMByte> 사람들이 애플리케이션마다 I2P 인스턴스를 하나씩 갖지 않도록 보장하는 방법이 필요해요 15:13:12 <zzz> 좋아요, 1)과 관련해 더 있을까요, 아니면 로드맵 자체를 보러 넘어갈까요? 15:14:00 <str4d> 여기 있는 모두가 대체로 동의하는 것 같아요 15:14:08 <str4d> (적어도 반대는 없네요 :P) 15:14:14 <zzz> 스레드에서 몇 줄 복사해 올게요. 정답은 아니고 참고용으로요 15:14:25 <zzz> 네트워크 성장 15:14:25 <zzz> 포함: 마케팅, 공동 프로젝트, 더 많은 번들링, 다른 사람들이 i2p를 번들하도록 지원, 사용성, 웹사이트 개선, 더 많은 번역, 강연과 발표, 기사와 스토리, UI, Android, Android 앱, 더 나은 GFW 우회, orchid, 클라이언트 개발자를 위한 더 많은 라이브러리와 도구, 대규모 웹사이트에 대한 더 나은 지원, 대체 router 개발 지원, 연합, 속도 향상과 효율성, 용량, 한도 상향, 등록하기 15:14:25 <zzz> Debian에, ... 15:14:25 <zzz> 보안 강화 15:14:25 <zzz> 포함: 암호(crypto) 마이그레이션, 구독(subscription) 프로토콜, 새로운 전송 프로토콜, 플러그형 전송, LS2, NTCP2, 새로운 DH, 키 폐기, 키 저장, 코드 리뷰, Sybil, 버그 수정, 네이밍, SSL, ... 15:14:46 <zzz> 좋아요, 그럼 2) 로드맵 자체로 넘어가죠 15:15:10 <zzz> URL은 http://i2p-projekt.i2p/en/get-involved/roadmap 15:15:50 <zzz> .25는 거의 완료됐고 약 10일 내에 릴리스예요, 그래서 올해의 다음 4개 릴리스인 26-29를 봅시다 15:16:00 <zzz> 그걸로 ccc까지 갈 수 있을 거예요 15:16:15 <EinMByte> 예를 들어 어떤 항목이 2017 아래에 있으면, 그때부터 검토를 시작한다는 뜻인가요, 아니면 그때부터 구현을 시작한다는 뜻인가요? 15:16:41 <str4d> 우리가 *need* to do 라고 보는 것들 중에서는, crypto 마이그레이션과 Sybil 관련 작업의 우선순위가 높다고 봐요 15:16:42 <zzz> 1mb, 새로운 crypto/DH, NTCP2 같은 2017년의 큰 작업들은 지금부터 확실히 시작하고 싶어요 15:17:04 <EinMByte> 또한, 제 생각에는 지금은 eclipse 공격도 문제예요 15:17:05 <zzz> 그래서 로드맵에 그것들을 위한 준비 작업을 포함할 수 있죠 15:17:23 <str4d> EinMByte, 네, 그건 Sybil 범주에 묶어뒀어요 15:17:36 <EinMByte> 자정 회전(midnight rotation) 아이디어는 전혀 통하지 않고, 더 나은 대안이 있어야 한다고 봐요 15:17:52 <zzz> 동의해요 15:18:05 <EinMByte> str4d: 네, 같은 유형의 공격으로 분류하는 게 타당하죠 15:18:44 <str4d> EinMByte, RWC에서 몇 사람과 이걸 논의했어요 15:18:48 <str4d> 몇 가지 생각은 있는데, 여기서 바로 논의하긴 어렵네요 15:18:51 <EinMByte> zzz: 그럼 2017년까지 NTCP2/...를 시작하려면 사전 작업을 계획해야겠죠 15:18:58 <zzz> 맞아요 1mb 15:19:02 <str4d> 네 15:19:20 <str4d> 로드맵에 기획과 연구를 넣고 싶어요 :) 15:19:28 <zzz> 문제는 이거예요. 저는 지금 26 작업을 하고 있어야 하는데, 거기에 뭐가 들어가는지 몰라요 15:19:39 <orignal_> 기존 NTCP에 랜덤 패딩을 추가하는 게 가능할까요? 15:20:01 <str4d> orignal_, 제가 알기론 아니고, NTCP2 스레드를 확인해 보세요 15:20:02 <zzz> 그럼 10분 정도 26을 계획하고, 그다음 장기적인 걸로 넘어가죠 15:20:13 <str4d> ㅇㅋ 15:20:14 <zzz> 제가 오늘 뭘 해야 할지 말해 주세요 15:20:30 <EinMByte> 맞아요, 먼저 그거에 집중합시다 15:20:34 <zzz> 좋아요, .25 리스트에서 못 한 게 뭔지 봅시다 15:20:50 <zzz> wrapper는 못 했고, kytv는 잠수예요 15:20:54 <EinMByte> "crypto 향상"은 꽤 포괄적이네요 15:21:12 <zzz> crypto 향상에서 실제로 한 건 25519 속도 개선 몇 가지였어요 15:21:34 <zzz> 그래서 wrapper를 제외하면 .25 리스트의 내용은 실제로 다 들어갔어요 15:22:00 <zzz> 하지만 Sybil 관련으로 더 할 일이 있으니 26 리스트에 유지합시다 15:22:08 <str4d> 좋아요 15:22:25 <str4d> 추가 테스트가 필요해서 GMP 6는 .26으로 미뤘죠 15:22:35 <zzz> 이제 26 리스트에서 무엇을 포함시키거나 이동해야 할까요 15:23:05 <EinMByte> 결국 Sybil 방지는 아마 일이 아주 많을 테니, 장기 과제로 보여요 15:23:10 <EinMByte> (먼저 충분한 문헌 검토가 필요하다는 의미에서요) 15:23:15 <zzz> orignal, 맞아요, 패딩이 있는 ntcp는 ntcp2예요 15:23:21 <str4d> EinMByte, Sybil 탐지 도구는 아직 아무 데도 쓰이지 않고 있어요, 그 부분에 더 많은 기획이 필요해요 :) 15:23:49 <zzz> hottuna4가 한 달간 자리를 비워요, 그 한 달이 언제 끝날지 확실치 않아서 gmp6가 26에 들어갈 수도 있고 아닐 수도 있어요 15:24:02 <str4d> ㅇㅋ 15:24:37 <str4d> 주소록을 위한 구독 프로토콜 개선: 가능한 한 빨리 넣으면 아주 좋아요, 그래야 기존 Dest 소유자들이 Ed25519로 마이그레이션할 수 있거든요 15:24:37 <EinMByte> CRL에는 물음표가 굳이 필요 없다고 생각해요 15:24:47 <str4d> 그걸 실제로 하는 데 얼마나 걸릴까요? 15:25:14 <zzz> 곧 tuna로부터 상태 업데이트가 필요하고, 26에 큰 걸 올리는 마감은 3월 말/4월 첫째 주가 될 거라 봐요 15:26:10 * str4d 아직 CRL 관련 내용을 잘 이해하지 못했는데, zzz가 자세히 설명해줄 수 있을까요? 15:26:14 <zzz> .25는 디스크에서 crls를 읽는 기능이 있어서, 업데이트에 포함할 수 있어요 15:26:35 <zzz> 하지만 그건 그리 도움이 안 돼요, 업데이트에서는 그냥 cert를 제거하면 같은 효과거든요 15:26:56 <zzz> 그래서 업데이트 없이 사람들에게 crls를 배포하려면, 피드에 넣을 거예요 15:26:57 <str4d> 저는 그냥 사용 사례를 파악하려는 거예요 15:27:09 <zzz> 사용 사례는 누군가가 침해됐을 때예요 15:27:20 <str4d> 우리는 아직도 cert pinning을 안 하나요? 15:27:30 <zzz> 아니요 15:27:56 <zzz> 그래서 90%까지 작업했고, crl을 네임스페이스에 넣기만 하면 돼요 15:28:46 <zzz> pinning은 까다롭고 위험해요 15:29:05 <zzz> crypto cat이 'pinning 자살'을 했죠 15:29:17 <zzz> 핀닝을 했는데 중간 인증서가 바뀐 경우요 15:30:49 <zzz> pinning이 cls를 대체한다고는 생각하지 않아요 15:30:51 <zzz> crls 15:31:21 <zzz> crls는 ssl만 위한 게 아니고, reseed와 업데이트 키에도 쓰여요 15:31:58 <zzz> 그럼 crls를 26 리스트에 유지할 수 있을까요? 거의 끝났거든요 15:32:20 <str4d> pinning에 대해 걱정하는 건, 누가 예를 들어 Quantum Insert 같은 걸로 reseed 도메인 이름을 리다이렉트하고, 도메인 요구사항만 만족하는 유효한 SSL cert를 아무거나 올리면, router들이 그걸 받아들일 수 있다는 점이에요 15:33:05 <str4d> 그리고 CRL과 관련해서, 특정 인증서를 비활성화하는 데 그걸 쓰면, 그 인증서는 무엇으로 대체되나요? 15:33:25 <zzz> 없어요. 다음 릴리스에서 아마 대체본이 있을 거예요 15:33:45 <str4d> 이건 좀 지나치게 세부로 들어가고 있네요 15:34:07 <str4d> 제가 말하려던 건, 이걸 좀 더 고민해야 한다는 거예요 15:34:24 <zzz> 좋아요, 그럼 crls는 26에 유지하되, 세부사항은 다음 1~2주 안에 논의하죠 15:34:30 <zzz> 아직 100% 명확하지 않으니까요 15:34:38 <zzz> 넘어가죠 15:34:42 <zzz> 26 리스트에 또 뭐가 있죠 15:34:43 <str4d> ㅇㅋ 15:34:50 <EinMByte> ㅇㅋ 15:35:08 <zzz> 구독 프로토콜 15:35:28 <zzz> 이게 사이트의 crypto 마이그레이션을 위한 핵심이에요 15:35:40 <EinMByte> hosts.txt 대체를 말하는 건가요, 아니면 다른 건가요? 15:36:22 <zzz> 네, 이건 hosts.txt를 피드로 바꾸는 거예요, 예를 들면 foo.i2p=b64#sig=b64#cmd=alt ... 같은 식으로요 15:36:26 <str4d> EinMByte, 서명된 키-값 메타데이터로 주소록 구독 프로토콜을 보완하는 거예요 15:36:49 <zzz> 제안은 꽤 정리돼 있지만, 18개월 정도 보류 상태였어요 15:37:07 <EinMByte> 그렇긴 한데, hosts 파일 크기가 너무 커지지 않겠나요 15:38:02 <EinMByte> 아마 since 파라미터를 추가해서, 특정 시점 이전에 추가된 hosts는 제외하게 하면 어떨까요 15:38:07 <EinMByte> (필요 없는데도 전체 목록을 받지 않도록요) 15:38:22 <zzz> 이건 원래 crypto 마이그레이션 계획의 일부였지만 어렵고 가장 중요한 부분은 아니었어요 15:38:49 <zzz> 하지만 서명 쪽 crypto 마이그레이션에서 남은 주요 과제예요 15:39:26 <str4d> EinMByte, 그런 건 이미 etag로 어느 정도 하고 있어요 15:39:28 <zzz> 이것도 구체적으로 제안은 많지만, 합의가 충분치 않아서 시작하지 못했던 것 중 하나예요 15:39:42 <EinMByte> str4d: 그런데 실제로 쓰이나요? 15:39:46 <str4d> EinMByte, 네 15:40:00 <EinMByte> 아, 됐어요. 그렇다면요 15:40:03 <str4d> 이건 현재 셋업과 다르지 않을 거예요 15:40:20 <zzz> 그래서 이건 26 리스트에 두고 최대한 빨리 시작할게요. 26에 충분히 진척될지는 모르겠지만 노력하겠습니다. zzz.i2p의 스레드를 검토할 필요가 있어요 15:40:22 <str4d> 하지만 도메인 이름 엔트리가 한 번만 나타나는 게 아니라, 이제는 '스트림'에서 반복될 거예요 15:40:42 <EinMByte> 그런데 왜 그 이상한 포맷을 유지해야 하는 특별한 이유가 있나요? 15:41:05 <EinMByte> 표준적인 걸 쓰는 게 더 쉬워 보이거든요 15:41:06 <zzz> 그럴 수도요. 오래된 클라이언트와의 호환성 때문이죠. 하지만 그게 중요한지 확실히 검토하고 결정해야 해요 15:41:20 <zzz> 우리는 아마 1년쯤 이걸 들여다보지 않았어요 15:41:28 <zzz> 그래서 먼지를 털고 한번 살펴보죠 15:41:32 <EinMByte> zzz: 호환성은 한동안 기존 hosts.txt 파일도 함께 제공하는 방식으로 처리할 수 있죠 15:41:41 <str4d> 또 예를 들어 모든 '잃어버린' 이름들을 어떻게 할지라는 더 큰 이슈도 있어요 15:41:53 <str4d> 하지만 그건 현재 논의 범위를 벗어나요 15:41:57 <zzz> 맞아요. 다른 구현들도 참여시켜야 해요 15:42:18 <EinMByte> str4d: 그건 새로운 네이밍 시스템을 갖추게 될 때(그럴 일이 있다면) 결정할 사안이라고 생각해요 15:42:26 <str4d> 지금은, 현재 활성 도메인들이 자신의 dest를 업데이트할 수 있는 방법이 필요해요 15:42:26 <zzz> 좋아요, 일단 26 리스트에 유지합니다. 다음 항목 - Sybil 관련 15:42:45 <zzz> Sybil을 자동화할 수 있을까요? philip winter의 논문은 모두 읽었길 바라요???? 15:42:50 <str4d> 그리고 코어 코드를 빨리 넣을수록, 1년쯤 뒤에 더 빨리 활성화할 수 있어요 15:43:50 <EinMByte> zzz: 무슨 논문이요? 제가 뭔가 분명히 놓쳤네요 15:44:27 <zzz> 링크는 트위터의 @__phw를 확인하세요 15:45:02 <zzz> ccc에서 sadie의 소개로 그와 함께 작업 중이에요 15:45:03 <EinMByte> zzz: 이건가요: http://arxiv.org/pdf/1602.07787v1.pdf? 15:45:27 <zzz> 지난 몇 주 안에 발표된 거라면 그거예요 15:45:59 <EinMByte> 음, 올해 2월의 eprint예요 15:46:09 <zzz> 우리는 자동화할 준비가 안 된 것 같아요. 그쪽도 사실 그렇고요 15:46:22 <zzz> 그들은 하루에 한 번 dirauth들에게 이메일만 뿌려요 15:46:36 <zzz> 양쪽 모두 휴리스틱과 요령뿐이에요 15:46:49 <EinMByte> 그럼 아마 출판 후에 eprint를 온라인에 올린 거겠네요 15:46:57 <zzz> 그래서 자동화 쪽은 올해 후반으로 미루고 싶어요 15:47:07 <str4d> EinMByte, 제가 가진 버전은 2월 25일자예요 15:47:14 <EinMByte> zzz: 그럼 탈중앙화된 환경에서 그게 정확히 어떻게 작동하죠? 15:47:44 <str4d> 탑다운이 아니라 보텀업으로 해야 해요 15:48:06 <str4d> 즉, 각 router는 peer 프로파일에 '잠재적 Sybil 후보'를 포함해야 해요 15:48:13 <zzz> EinMByte, 모르겠어요. 어렵습니다 15:48:20 <str4d> 예를 들면 온라인 시간 등등을 기반으로요 15:48:30 <EinMByte> Sybil 공격을 탐지하는 건 가능하다고 봐요, 그 탐지에 기반해 방지하는 건 탈중앙 네트워크에선 매우 어렵고요 15:48:30 <EinMByte> 하지만 도전은 좋네요 15:48:34 <zzz> 중앙화된 방식으로 그의 셋업을 재구성 중인 gravy도 필요해요 15:48:43 <str4d> 어느 정도 더 중앙화된 셋업을 갖는 가능성도 있어요 15:48:45 <str4d> 네, 그거요 15:48:45 <EinMByte> str4d: 그 시점에는 각 router에 신뢰를 부여해야 해요 15:48:52 <EinMByte> 그 자체가 하나의 전체 anti-sybil 시스템이 되겠죠 15:49:07 <str4d> 그리고 router들이 잠재적 sybil 목록을 구독하게 하는 것 15:49:07 <zzz> 약간 dagon 제안과 비슷하네요 15:49:09 <str4d> EinMByte, 그건 기본적으로 지금의 peer 프로파일이 하는 역할이긴 해요 15:49:31 <str4d> 여기서 '신뢰'는 현재 '과거에 내게 라우팅이 잘 됐는가'로 정의돼 있어요 15:49:42 <EinMByte> str4d: 네, 그리고 지금까지 몇몇 공격을 유발하기도 했죠 :) 15:50:15 <str4d> 맞아요 15:50:23 <EinMByte> 또한 peer 프로파일은 사실 네트워크에서 어떤 피어를 배제하도록 해주지는 않아요 15:50:31 <EinMByte> Sybil 방지는 어느 정도 그걸 가능하게 할 거예요 15:50:35 <str4d> 피어 프로파일링과 피어 선택도 우선순위를 둬야 한다고 생각하는 항목이에요 15:50:46 <str4d> EinMByte, 할 수도 있어요 15:51:01 <zzz> 그래서 26의 Sybil 항목은 '지속적 개선'으로 바꾸고, '자동화' 부분은 나중으로 미루자고 제안합니다 15:51:01 <str4d> 지금은 아니죠 15:51:11 <str4d> 그런 걸 넣을 자리가 거기라는 말이었어요 15:51:34 <EinMByte> str4d: 네, 가능해요. 15:51:37 <str4d> (Sybil 탐지와 더 발전된 기법을 I2P의 개념과 아키텍처에 넣는다는 의미에서요) 15:51:53 <EinMByte> 어쨌든, 탈중앙화는 포기하지 않겠습니다. 제 생각에는 I2P의 가장 멋진 부분이거든요 15:52:14 <str4d> 네 15:52:27 <EinMByte> (그리고 중앙화는 어차피 여러 실질적 공격으로 이어지죠) 15:52:43 <zzz> 넘어가죠. 스트리밍 개선? 그게 뭔지 잘 모르겠어요, 아마 '계속 더 좋게 만들기' 항목일지도 15:52:49 <str4d> zzz, 네, 그 routerconsole 페이지 작업을 계속하고, 전략이 정해지면 peer 프로파일과 선택에 연결하면 돼요 15:53:00 <zzz> 스트리밍에서 구체적으로 뭘 해야 할지 떠오르지 않네요. 누구 있나요? 15:53:01 <EinMByte> 가끔 중앙 권한을 추가하면 보안 증명을 쉽게 만들 수 있지만, 실제로는 보안 실패를 초래할 수 있어요 15:53:20 <str4d> 연구와 최적화가 있으면 좋겠어요 15:53:28 <EinMByte> zzz: 거기서 우리가 할 수 있는 뚜렷한 개선이 있나요? 15:53:30 <str4d> 그건 외부 연구 주제로 좋을 것 같아요 15:53:46 <zzz> 더 나은 테스트 셋업이 정말 필요해요 15:53:51 <EinMByte> str4d: 동의해요. 15:53:55 <zzz> 지연/드롭 추가, 순서 바꾸기 등등 15:54:04 <EinMByte> 그거랑 다른 것들을 '열린 연구 과제' 페이지에 아마 확장해 넣어야겠어요 15:54:40 <zzz> 스트리밍 관련 제 리스트에 창의적인 항목은 많지 않아요. 테스트 결과 주도로 가야 해요 15:54:50 <EinMByte> tunnel 할당에서 더 개선할 여지가 있지 않을까요? 15:55:05 <str4d> zzz, 제 기억으로 그걸 할 수 있는 컨테이너로 'The Internet'을 시뮬레이션하는 GH 프로젝트가 있어요 15:55:08 <zzz> 그럼 이 항목을 '스트리밍 테스트 하니스'로 하죠 15:55:17 <str4d> 그게 얼마나 쉬울진 모르겠지만, 컨테이너마다 JVM을 새로 하나씩 필요로 할 거예요 :P 15:55:25 <str4d> EinMByte, 음 15:55:48 <EinMByte> str4d: shadow를 쓸 수 있을 거예요. Java와 통합이 될진 모르겠지만 kovri TODO 리스트에 있어요 15:55:52 <str4d> 그건 진짜 스트리밍은 아니고, 데이터그램 레벨이죠 15:56:22 <zzz> tunnel 할당 건은 클라이언트가 tunnel을 고르게 하자는 psi의 아이디어예요 15:56:34 <EinMByte> str4d: 네, 이걸 최적화할 부분이 더 있다고 봐요 15:56:46 <EinMByte> zzz: 저는 사용자가 최고의 최적화 알고리즘이라고는 생각하지 않는데, 그럴 수도요 15:57:10 <zzz> 그건 우리 레이어링을 심하게 훼손하는 일이고, 제가 보기엔 방법이 없어요. 하지만 psi는 그걸 제안하고 있어요 15:57:19 <EinMByte> ... 아마 'client'가 사용자라는 뜻은 아니겠죠 15:57:32 <zzz> client == i2cp의 클라이언트 측 15:57:44 <str4d> 거기서 문제는 15:57:54 <str4d> Tor는 Control Socket을 통해 이런 기능을 제공해요 15:57:58 <EinMByte> 아 그렇다면 맞네요 15:57:59 <str4d> 그리고 연구자들에게 매우 유용해요 15:58:10 <str4d> 하지만 그쪽은 아키텍처가 훨씬 평평하죠 15:58:19 <str4d> 반면 우리는 I2CP를 통해 서로 다른 클라이언트를 분리해요 15:58:31 <EinMByte> zzz: 관련 정보는 router가 더 많이 갖고 있다고 예상해요. 클라이언트는 추가 요구사항만 전달하면 되고요 15:58:41 <zzz> 연구자용 psi의 lua 훅도 있는데, (java나 kovri 어디에도) 아직 머지되진 않았지만, 여전히 옵션이에요 15:59:14 <zzz> 보세요, 지금 클라이언트 측은 tunnel 자체를 알지도 못해요, 그러니 당연히 고를 능력도 없죠 15:59:16 <str4d> RWC에서 nickm과 얘기했는데, Tor에선 플러그인 시스템보다 Control Socket 인터페이스를 유지하는 게 훨씬 쉽다고 하더군요 15:59:17 <EinMByte> shadow가 실제로 연구자들에게 쓰이고 있다는 건 알아요 15:59:22 <EinMByte> Lua는, 잘 모르겠어요 15:59:55 <EinMByte> zzz: 그럼 아마 관련 정보를 I2CP로 넘기는 방식으로 같은 걸 달성할 수 있지 않을까요? 16:00:17 <zzz> 1mb, 네, 하지만 정말 흉할 거예요 16:00:44 <str4d> 항상 -research 플래그 같은 걸로 제한할 수는 있죠 16:00:54 <str4d> (router.config에서) 16:01:06 <str4d> 그렇게 하면 대부분 사용자들은 그 흉함을 보지 않게 돼요 16:01:13 <zzz> kovri/i2pd에는 아직 client/router 사이에 그런 엄격한 API 경계가 없어서, 그들에게는 더 쉬워요 16:01:20 <zzz> *그들에게 16:01:28 <str4d> 그리고 처음부터 '.research'는 '이 API는 변경될 수 있습니다'라는 의미로 정의할 수 있어요 16:01:44 <str4d> 즉, 연구자는 특정 버전과 함께 .research 플래그를 사용해야 해요 16:01:57 <str4d> 논의의 실제 주제로 돌아가서: 16:01:59 <EinMByte> zzz: tunnel과 관련해서요. 경우에 따라 달라요. tunnel의 의도된 사용 정보는 전달하는 게 말이 된다고 봐요. 16:02:20 <zzz> (참고: 이 회의는 최대 25분 더 진행하고, 일요일에 이어서 합니다) 16:02:33 <EinMByte> zzz: shadow가 C로 작성돼서 우리에겐 주로 더 쉬운 것 같아요 16:02:42 <str4d> 이건 '추가 연구 필요' 범주로 밀어두는 게 좋겠어요 16:02:44 <zzz> 문제는 고를 게 당신의 tunnel만이 아니라, 원격 쪽의 tunnel도 있다는 거예요 16:02:48 <EinMByte> 좋아요. 그럼 넘어가죠. 16:03:08 <zzz> 좋아요, 지금 26 리스트에는 그게 전부예요. 무엇을 추가해야 할까요? 16:03:11 <EinMByte> zzz: 그건 원격 쪽에서 처리하지 않나요 16:03:36 <zzz> 아니요, 우리는 소스 라우팅을 해요(즉, 상대 inbound를 위해 그쪽의 leaseset에서 원격 lease를 고릅니다) 16:04:08 <zzz> 27-29 리스트를 보세요. 26으로 당겨야 할 게 있을까요? 16:04:44 <str4d> 새로운 LS들과 netdb를 위한 준비 작업을 시작하고 싶어요 16:04:46 <zzz> 여기가 '2017년을 위한 xxx 초기 작업'이 모여 있는 곳이지만, 2016년 것들도 많아요 16:05:23 <EinMByte> zzz: far-end 뜻을 제가 오해했네요, 신경 쓰지 마세요 16:05:31 <str4d> 그걸 빨리 정리해서 코드베이스에 넣을수록, 네트워크가 그걸 폭넓게 지원하는 시점도 앞당겨져요 16:06:42 <EinMByte> 우리는(kovri) 명세(specifications)를 원한다는 점을 유의하세요 16:06:52 <EinMByte> 그렇지 않으면 구현을 따라가기가 어려울 거예요 16:07:31 <zzz> 물론이죠. 새로운 specification은 모두 함께 작업해야 해요 16:07:36 <EinMByte> str4d: LS2가 실제로 무엇을 지원해야 하는지 목록부터 시작합시다 16:07:53 <EinMByte> (아직 안 했다면요) 16:09:40 <zzz> 기본적으로 ls2는 몇 가지뿐이에요 16:09:59 <zzz> 플래그용 공간을 좀 추가하고 16:10:09 <zzz> 미래의 crypto를 가능하게 하고요 16:10:52 <zzz> 하지만 더 나은 멀티호밍에 관한 제안들이 있고, grothoff류의 서비스 조회도 있어요 16:11:00 <zzz> anycast 16:11:01 <EinMByte> 참고할 수 있는 구체적인 목록이 어딘가 있나요? 16:11:11 <zzz> zzz에 모아놨어요, 잠시만요 16:11:23 <str4d> EinMByte, 그걸 웹사이트에 천천히 모으고 있어요 16:11:41 <zzz> 그거 좀 더 빨리 할 수 있을까요, str4d? 다음 주나 그다음 주 정도로? 16:11:47 <str4d> 그건 .26 리스트에 넣어야겠네요 16:11:50 <str4d> 흠 16:11:53 <str4d> 아마도요 16:11:59 <str4d> 더 많은 검토가 필요해요 16:11:59 <zzz> 제안들이 단순 리스트로 정리돼 있지 않으면 이건 너무 어려워요 16:12:08 <EinMByte> str4d: 좋아요. 사실 이런 것들 중 일부는 위키 기능이 유용할 거예요 16:12:24 <EinMByte> (그게 더 빨라질 거라는 생각이에요) 16:12:48 <zzz> 우선 목록이 필요해요 16:12:50 <str4d> EinMByte, 맞아요 16:12:56 <zzz> 한꺼번에 다 하려 들지 맙시다 16:13:11 <str4d> 백엔드 HTML이 필요했던 걸 (현재는) rST로 옮기려 하고 있어요 16:13:31 <str4d> 제가 가진 걸 검토해 줄 사람이 필요해요. a) 사용 가능하고 b) 현재 가진 걸 잃지 않는지 확인하려고요 16:13:39 <str4d> 현재는 명세 문서에만 적용돼 있어요 16:13:40 <zzz> 제안 관련 건을 26 리스트에 넣고, 그게 무엇을 의미하는지는 나중에 얘기하죠. 하지만 최대한 빨리 전진이 필요해요. 16:13:55 <str4d> 그게 굳어지면, 제안으로 확장하는 건 사소해요 16:13:56 <zzz> 그걸 웹사이트에 올리고 싶어요. 형식은 상관없어요. 16:14:46 <EinMByte> 제안들을 기꺼이 검토하겠지만, 가끔은 아예 텍스트를 못 찾을 때가 있어요 16:15:10 <EinMByte> (웹사이트의 어떤 것들은 좀 숨어 있는 것 같아요) 16:15:37 <zzz> 맞아요 16:16:05 <zzz> zzz.i2p의 자료를 어떤 식으로든 체계화해서 웹사이트로 옮겨야 해요 16:16:13 <EinMByte> str4d: HTML에서 여러 포맷으로 쉽게 변환 가능한 것으로 옮기는 건 좋은 일이에요 16:16:28 <EinMByte> zzz: 네, 확실히요 16:16:35 <str4d> EinMByte, 제가 검토받고 싶은 건 i2p.www.str4d에 있어요 16:16:36 <EinMByte> 모든 제안을 위한 고정된 프로세스가 있으면 좋겠어요 16:16:57 <zzz> 좋아요. 26 리스트에 넣습니다. 세부사항은 추후에. str4d, 시작하세요. 많은 피드백을 기대하진 않아요. 그냥 새 시스템을 만들어 오면 우리 모두 따를게요 16:17:02 <str4d> 그리고 http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/ 에도요 16:17:04 <str4d> EinMByte, 그걸 확정하는 데 저와 함께하고 싶다면, 어쩌면 .25 즈음에 끝낼 수 있을 거예요 16:17:23 <zzz> 26에 또 뭐가 있죠? 이제 마무리해야 해요 16:17:36 <str4d> ( EinMByte, 구체적으로 http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/spec ) 16:18:14 <zzz> 이건 아주 단기 과제예요. 월요일에 뭘 해야 할지 알아야 해요 16:18:27 <zzz> 26에 대한 마지막 호출 16:18:41 <str4d> 구독 관련 작업은 시간이 좀 걸릴 것 같아요 16:18:49 <str4d> 그래서 그게 주요 과제가 되는 걸로 저는 좋습니다 16:18:52 <zzz> 동의해요. 16:19:54 <zzz> 좋아요. 일요일 같은 시간에 회의합니다. vrp/h1부터 시작할게요. 미리 티켓 1119를 검토해 주세요. 그 후 시간되면 27-29를 논의하죠. 16:20:06 <EinMByte> str4d: 그중에서 가장 주의가 필요한 건 뭐라고 보시나요? 16:20:27 <zzz> 필요하면 일요일에 26로 잠깐 돌아올 수도 있어요 16:20:43 <str4d> EinMByte, 기본적으로 제안 작성 포맷이 사용 가능한지, 그리고 (HTML이나 TXT 형식으로) 웹사이트에 올라갈 내용을 제한하지는 않는지 결정하는 거예요 16:20:45 <zzz> 그래서 일요일 안건은 1) vrp/h1/1119; 2) 26; 3) 27-29 입니다 16:20:57 <zzz> 모두 고마워요 16:21:25 * zzz 회의 종료에 *bafs* 16:27:50 <EinMByte> str4d: 대부분 다른 포맷으로 변환만 될 수 있다면 아마 괜찮아요 :)