I2P 개발자 회의 - 2006년 9월 12일

16:06 <jrandom> 0) 안녕 16:06 <jrandom> 1) 0.6.1.25와 네트 상태 16:06 <jrandom> 2) I2PSnark 16:06 <jrandom> 3) Syndie (무엇/왜/언제) 16:06 <jrandom> 4) Syndie 암호 관련 질문 16:06 <jrandom> 5) ??? 16:06 <jrandom> 0) 안녕 16:06 * jrandom 손 흔듦 16:06 <jrandom> 주간 상태 노트를 http://dev.i2p.net/pipermail/i2p/2006-September/001307.html 에 올려뒀어 16:07 <jrandom> 그 노트가 몇 시간 전부터 올라와 있었으니, 다 읽고 메모 준비해왔지? ;) 16:07 <jrandom> 1) 0.6.1.25와 네트 상태로 넘어갈게 16:08 <vulpine> <Complication> 0.6.1.25는 여기서는 잘 동작한 것 같아, 이전에 못 본 오류가 하나만 있었어 16:08 <jrandom> 좋아, 무슨 문제야? 16:08 <vulpine> * Complication 로그를 뒤짐 16:09 <jrandom> 네트워크 규모가 전보다 더 큰 것 같아, 그래도 크기 차원은 비슷하고 16:09 <vulpine> <Complication> "Unknown error reading the net.i2p.data.i2np.GarlicMessage: wtf, fromLong got a negative? -840" 16:10 <vulpine> <Complication> 시작은 "ERROR [NTCP read 1 ] .router.tunnel.FragmentHandler: Error receiving fragmented message (corrupt?)" 16:10 <jrandom> 아 오케이 좋아, 그건 오래전부터 있던 거라 무시해도 돼 16:11 <vulpine> <Complication> 한 번만 발생 16:11 <vulpine> <frosk> 방금 그 마지막 오류는 여러 번 봤어 16:11 <vulpine> * jrandom fox를 쿡 찌름 16:12 <vulpine> <Complication> 아, 하나 더: "router.tunnel.TunnelDispatcher: wtf, took 1121 to dispatch net.i2p.data.i2np.TunnelBuildMessage@XXXX out YYYYY in net.i2p.router.tunnel.PumpedTunnelGateway@ZZZZ" 16:12 <vulpine> <Complication> (이것도 별거 아닌 듯, 단순 혼잡일지도) 16:12 <jrandom> 응, 아마도 16:13 <jrandom> irc는, 분명히, 지금은 아직 좀 거칠어 16:13 <jrandom> (하지만 이번만큼은 i2p 탓은 아냐 :) 16:14 <jrandom> 좋아, 1) 네트 상태와 0.6.1.25에 대해 다른 거 있어? 16:15 <kostya213> 그냥 덧붙이자면 .25가 지난 몇 달 동안 겪던 문제를 전부 해결했어 16:15 <jrandom> 멋지네! 16:16 <vulpine> <green> NTCP만 사용할 때 상태 계산을 바꿔줘 16:16 <jrandom> ㅇㅋ, 하지만 udp를 비활성화하는 건 권장하지 않아 (비활성화하는 방법도 알려주지 않겠다고 분명히 말했을 거야) 16:17 <jrandom> 다만 상태 표시는 udp만이 유일한 전송 수단이 아니라는 걸 고려하도록 업데이트해야 해 16:17 <jrandom> 다음 리비전에 고칠게, 고마워 16:17 <vulpine> <green> jrandom : 물론이지, 네가 말 안 해도 코드는 읽을 수 있어 ;) 16:18 <jrandom> 맞아, 하지만 내가 권장하지 않고, 시도도 말라고 하면, 표시 메시지가 헷갈리게 나오더라도 놀라지 마 ;) 16:19 <vulpine> <green> 그치, 콘솔에 그냥 "OK"만 띄울 수도 있지 :) 16:19 <jrandom> 그러게 16:21 <jrandom> 좋아, 2) I2PSnark로 넘어가자 16:21 <jrandom> zzz는 지금 자리에 없는 것 같네 16:22 <jrandom> zzz가 i2psnark의 스케줄링을 개선하기 위한 몇 가지 변경을 작업 중이야 16:23 <jrandom> (지금은... 내 기억이 맞다면 좀 단순해, 다만 zzz가 손대는 수정이 정확히 뭔지는 잘 모르겠어) 16:23 <jrandom> ((그래도 진전이 기대돼!)) 16:25 <jrandom> 좋아, 2) I2PSnark에 더 없으면 3.*) Syndie 관련으로 넘어가자 16:26 <jrandom> 다룰 게 많으니까 먼저 3.1) Syndie가 무엇인지부터 들어가자 16:27 <jrandom> 회의 전에 게시물 암호화에 관해 몇 가지 질문을 받았어 16:27 <jrandom> 기본적으로, 게시물은 대칭키 방식으로 암호화돼 - 대칭키가 있는 사람은 누구나 그 게시물을 읽을 수 있어, 즉 권한이 있는 거지 16:28 <jrandom> 채널 답글은 채널/포럼에 연결된 공개키로 비대칭 암호화돼 16:28 <jrandom> 일부 게시물은 읽기 위한 대칭키를 패스프레이즈(암호문구) 기반으로 생성할 수 있어 16:29 <jrandom> 그리고 어떤 게시물은 읽기 가능한 헤더에 대칭키를 포함할 수도 있어(그래서 누구나 읽을 수 있게) 16:29 <modulus> 마지막 방식의 의미는 뭐야? 16:29 <jrandom> 그리고 어떤 포럼 자체는 포럼 메타데이터에 대칭키를 포함할 수 있어, 그래서 채널 메타데이터만 있으면 누구나 게시물을 읽을 수 있게 16:29 <jrandom> modulus: 공개적으로 읽을 수 있는 것까지도 모든 게 항상 암호화되도록 하려는 거야 16:29 <jrandom> (즉 간단한 도청이 무의미해지도록) 16:30 <modulus> 그렇네, 이해했어. 16:31 <jrandom> 좋아, 회의 전에 들어온 암호화 질문은 그 정도로 커버된 것 같아 16:31 <jrandom> 3.1) Syndie가 무엇인지에 대해 질문 있어? 16:31 <jrandom> (물론, 배포되면 더 명확해질 거야) 16:32 <vulpine> <void> 흠 16:33 <jrandom> 어때, void? 16:33 <vulpine> <void> <void> 메시지(.zip) 아카이브에 다른 사람의 메시지, 예컨대 인용되는 메시지도 함께 포함할 수 있지? 16:34 <jrandom> 음, 맞아, .snd 파일을 첨부로 포함할 수 있어, 하지만 명시적인 네임스페이스가 있어서 표준 References: 스타일로 이전 메시지에 링크할 수 있어 16:34 <jrandom> (즉 frost 스타일의 "스레딩"을 할 필요는 없어) 16:35 <vulpine> <void> 오케이, 그렇구나 16:37 <vulpine> <Complication> Syndie에 관해, 여러 사람이 게시하는 포럼에(일반 게시판의 계정처럼) 사람들에게 접근 권한을 주되 되돌릴 수 없게 주지 않고, 권한을 철회해야 할 때(어떤 이유든) 원치 않는 혼란을 피하는 문제를 사람들이 어떻게 풀까 궁금했어 16:38 <vulpine> <Complication> 한 가지 해법은, 물론 작성자가 클라이언트가 표시해야 할 답글 작성자를 추천하도록 지정하는 거지 16:38 <jrandom> Complication: 새 공개/개인 키쌍을 만들고, (임시로) 권한을 줄 사람에게 개인키를 주고, 공개키를 "keys allowed to post" 목록에 포함해 16:38 <vulpine> <Complication> ..그리고 클라이언트는, 히스토리를 추적할 의도가 없다면, 그 추천(더 정확히는 최신 버전)을 따르는 거지 16:38 <jrandom> (그리고 더 이상 권한이 없게 되면 그 키를 "keys allowed to post" 목록에서 제거해) 16:39 <kostya213> jrandom: .snd는 오디오 앱에서 널리 쓰이는 확장자라서 다른 확장자를 쓰는 게 좋겠어, MIME이 헷갈릴 거야 16:39 <jrandom> 아, 맞아 - 모든 포럼에는 "소유자"(서명에 쓰이는 개인키)가 있어서 누가 게시할 수 있는지 목록 등을 관리할 수 있어 16:39 <vulpine> <Complication> "keys allowed to post"는 작성자의 최신 글이나 다른 메시지에 붙는 메타데이터겠지, 맞아? 16:39 <jrandom> 좋은 지적이야 kostya213, 다만 그러면 .dat에 묶일지도 ;) 16:40 <jrandom> Complication: 아 미안, 아니야, 현재/예전 Syndie처럼 포럼/채널 자체에 대해 별도의 서명된 메타데이터 게시물이 있어 16:40 <vulpine> * Complication 누군가가 .dat도 이미 뭔가로 쓴다고 주장했던 것 같다고 생각함 :) 16:40 <jrandom> 맞아, "octet-stream"이라고 불리는 application ;) 16:40 <vulpine> <void> .syn은 주목할 만한 용도가 없는 것 같네 16:41 <vulpine> <Complication> 아하, 특수 메타데이터 게시물... 그래, 그걸로 되겠다 16:41 <jrandom> 오 멋져, syn으로 가자! 16:41 <jrandom> (좋은 눈이야 void, 고마워 kostya213) 16:41 <vulpine> <void> 흠, " 16:41 <vulpine> <void> 흠, "Word Synonym File", Company: Microsoft 16:42 <jrandom> 뭐, 방법을 찾게 될 거야 16:42 <kostya213> 응 워드에서 써 16:42 <vulpine> <void> 그래도 무시해도 되겠지 :) 16:42 <kostya213> 희망 잃지 마, 널리 쓰이는 MIME 타입과 충돌하지 않을 걸 찾을 수 있을 거야 16:43 <jrandom> 좋아, 3.1) Syndie가 무엇인지에 대해 다른 거 있어? 16:43 <vulpine> <void> 그러고 보니, 왜 꼭 세 글자 확장자에 매달려야 하지? DOS 시대의 유물인데 16:43 <kostya213> 꼭 물어야지, 왜 확장자를 세 글자로 제한해? 이제 DOS 쓰는 사람 없잖아 16:44 <jrandom> ㅎㅎ 16:44 <kostya213> void랑 동시에 말했네 16:44 <kostya213> .syndie 괜찮아 보인다 16:44 <vulpine> <void> .synd도 아무하고도 충돌 안 할 듯 16:44 <kostya213> 그것도 좋고 16:45 <vulpine> <void> 망할 랙 :( 16:48 <jrandom> 좋아, 3.2) Syndie가 왜 중요한가로 넘어가자 16:48 <vulpine> <void> jrandom: 잠깐만 16:48 <cervantes> (네가 중요하다고 하니까) 16:48 * jrandom 기다림 16:48 <jrandom> !thwap cervantes ;) 16:48 <vulpine> <void> 상태 노트에 게시물에 아바타를 첨부할 수 있고, 그렇지 않으면 기본값이 사용된다고 했잖아 16:49 <vulpine> <void> 그런데 한 사람이 단일 "기본" 대신 미리 정의한 여러 아바타를 갖고 싶다면? 16:49 <jrandom> 응, 작성자는 자기 채널 메타데이터에 기본 아바타를 포함할 수 있어 16:49 <vulpine> <void> 매번 다른 걸 첨부하는 건 비효율적이야 16:49 <jrandom> 좋은 질문이야 void - 노트에 있는 스크립트 코드로 가보자 16:50 <jrandom> listauthkeys --authorizedOnly true 16:50 <jrandom> authenticate 0 16:50 <vulpine> <void> (?) 16:50 <jrandom> listauthkeys는 네가 "나야"라고 서명할 수 있는 모든 아이덴티티를 표시하고, "authenticate 0"은 서명에 사용할 아이덴티티를 고르는 거야 16:51 <jrandom> 그래서 그 아이덴티티는 자기 채널을 갖고, 그 채널은 자기 메타데이터를 갖고, 거기에 아바타가 포함될 수 있어 16:51 <vulpine> <void> 흠, 별도의 아이덴티티는 별도의 키쌍을 의미하나? 16:51 <jrandom> 응 16:51 <vulpine> <void> 한 아이덴티티에 여러 아바타를 갖고 싶다면? 16:52 <jrandom> 채널 메타데이터에 기본 아바타가 있고, 메시지별로 재정의할 수 있어 16:52 <kostya213> 가치는 애매한데 16:52 <vulpine> <void> 여러 개의 "기본" 아바타 중에서 고를 수 있게 16:52 <vulpine> <void> 아니면 내가 너무 사소한 걸 파고드는 건가? :) 16:53 <jrandom> 아, 무슨 말인지 알겠어. 처음엔 지원 안 해 16:53 <jrandom> 나중에는 가능할지도 16:53 <vulpine> <void> 맞아 kostya213, 그럼 됐어 16:53 <vulpine> <void> :) 16:53 <jrandom> (하지만 아바타는 크기가 아주 작아서 포함해도 큰 부담은 없을 거야) 16:53 <vulpine> * Complication 메시지별 아바타 추가는 충분히 쉽게 코딩할 수 있을 거라고 생각함 16:53 <vulpine> <void> 그럼, 3.1) Syndie가 무엇인지? 16:53 <vulpine> <Complication> (결국엔) 16:54 <vulpine> * cervantes irc 서버들을 본드로 붙임 16:54 <vulpine> <void> Complication: jrandom이 방금 그걸 이미 할 거라고 했잖아 :) 16:54 <jrandom> (메시지별 아바타는 기본으로 갈 거야 complication, 여기서 말한 건 아바타 자체를 포함하는 대신 메시지에서 "avatar 1을 써"라고 말해서 고를 수 있게 '기본'을 여러 개 두자는 아이디어) 16:54 <vulpine> <Complication> 지연, 지연... 16:54 <jrandom> 좋아, 3.1에 대해 더 있어? 16:54 <jrandom> 없으면 3.2로 가자 16:55 <vulpine> <void> 그게 다인 듯 16:55 <jrandom> wr0d. 16:56 <jrandom> cervantes의 빈정거림 외에, "왜"에 대한 질문/코멘트/우려 사항 있어? 16:56 <jrandom> (어, "concerns") 16:58 <vulpine> <Complication> cervantes: ircd에 본드를 바르기 전에 표면을 알코올로 닦았나? ;) 16:58 <kostya213> 내 생각엔 Syndie는 정당화가 필요 없어, 이미 익명화 네트워크에 관심 있는 사람이라면 그 가치는 자명할 거야 16:58 <kostya213> 그리고 정보 중앙집중화의 위험을 알고 있다면 16:59 <vulpine> <Complication> (재전송, 서버에 도달했다면 무시해 주세요) 16:59 <vulpine> * Complication Syndie가 중요한 이유: phpBB를 돌리는 Joe Sixpack은 너무 빨리 털릴 거고, $random_blogging_tool을 돌리는 Joe Sixpack도 털릴 거야 16:59 <vulpine> <Complication> (확률은 다를지라도) 16:59 <vulpine> <void> 그러게 16:59 <jrandom> 응, 게다가 실제 적대자를 상대하는 사람이라면 누구든지 (꼭 국가급이 아니어도) 17:00 <jrandom> 좋아, 다들 얘기해줘서 좋아 17:00 <jrandom> 3.2에 더 없으면, 3.3) Syndie를 언제 쓸 수 있나로 넘어갈까? 17:01 <vulpine> <void> 음, 본질적으로 암호학적 원리 위에 구축되고 전송 계층과 독립적인 포럼/블로깅/이메일/커뮤니케이션 도구야 17:01 <vulpine> <Complication> ...그리고 만약 Joe Sixpack의 적수가 교차 공격을 걸어온다면, 어떤 종류의 eepsite를 돌리든 결국엔 털릴 거야 (엄청 거대한 네트워크가 아닌 이상) 17:01 <kostya213> 프라이버시/익명성의 즉각적 가치를 못 느끼는 이들에게는 설득이 어려울 수도 있어 17:01 <jrandom> kostya213: 응, 그래도 몇 가지 요령을 쓸 수 있어, 예컨대 오프라인으로 안전하게 브라우징할 수 있게 한다든가 17:02 <vulpine> <Complication> 보안 자체는 누구나 좋아할 수 있지 17:02 <jrandom> (예: RSS 요약만이 아니라 참조된 전체 페이지까지 끌어오는 오프라인 RSS 리더) 17:02 <vulpine> <void> 그러니, 왜 정당화가 필요한지 모르겠어 :) 17:02 <vulpine> <void> kostya213: Syndie를 쓰기 위해 익명이 될 필요는 없어 17:02 <cervantes> Syndie를 언제 사용할 수 있는지, 아니면 Syndie가 언제 쓸 만해지는지? 17:02 <jrandom> 말 잘했어 void :) 17:03 <cervantes> 텍스트 인터페이스라면 꽤 방대한 사용 문서가 필요하겠지 17:03 <jrandom> cervantes: 지금 Syndie는 기능적으로 동작해(게시물 생성, 채널 관리, 게시물 읽기, 답글 달기 등 가능) 17:03 <kostya213> jrandom: Syndie는 중복성을 어떻게 처리해? 콘텐츠 소실에 얼마나 강해? 17:03 <cervantes> (사용 가능해지려면) 17:03 <jrandom> cervantes: 각 명령이 문서화된 인라인 메뉴가 있어(최소한으로라도) 17:04 <cervantes> 좋아, 사용 시나리오 예시 계획도 있어? 17:04 <jrandom> kostya213: Syndie는 콘텐츠 계층에서 동작해 - 중복성은 다른 것에서 처리해. 예를 들어 usenet에 올리면 usenet 전체에 복제돼 17:04 <cervantes> 아마 요령은 이 모든 걸 어떻게 스크립트로 엮는지 배우는 거겠지 17:04 <vulpine> <void> kostya213: 그건 Syndie의 영역 밖이야, 전송 메커니즘에 달렸거든 17:04 <vulpine> <void> 아쉽지만 17:04 <jrandom> 좋은 아이디어야 cervantes 17:05 <jrandom> 첫 Syndie 릴리스에는 예전/현재 Syndie처럼 HTTP 복제 시스템이 포함될 거야 17:05 <jrandom> cervantes: 아마 베타 사용자들이 자기들이 좋아하는 스크립트를 모아서 우리 배포에 포함시켜줄 수도 있지 :) 17:05 <modulus> 음, 이거 콘솔 앱이야? 17:05 <jrandom> modulus: 응, 처음엔 텍스트 기반 앱 17:06 <modulus> 훌륭해! 17:06 <cervantes> jrandom: 베타 사용자들이 어떻게 쓰는지 알아내기만 하면 말이지 ;-) 17:06 <jrandom> ㅎㅎ 17:06 * jrandom curses/기타도 고려했지만, CLI만 있는 것 대신 대화형 스크립트 가능한 텍스트 인터페이스가 아마 가장 단순하고 유용하다고 판단했어 17:07 <jrandom> (GUI 없이라는 뜻) 17:07 <cervantes> modulus: 봐, jrandom이 네 끈질긴 피드백을 들었잖아 :) 17:07 <vulpine> <Complication> 원한다면 그 위에 더 대화적인 텍스트 인터페이스를 올릴 수도 있을 거야 17:07 <jrandom> 응, 물론 17:08 <jrandom> (코드는 pircbot 같은 IRC 클라이언트와 손쉽게 통합되도록 만들어져 있어) 17:08 <modulus> cervantes: ㅋㅋ 17:09 <modulus> 상상대로라면 그 위에 GUI를 얹을 수도 있겠네 17:09 <modulus> 물론 일이 훨씬 많겠지만. 17:09 * kostya213 emacs 플러그인을 기다림 17:09 <modulus> 하하하 17:09 <jrandom> ㅎㅎ 17:09 <modulus> 사실 emacs 모드도 나쁘지 않지, 그러면 더 많은 괴짜들을 끌어들일지도 몰라. 17:10 <cervantes> 아이덴티티를 고르려면 ctrl-alt-shift-break-uparrow-num7-b를 누르시오 17:10 * jrandom 그건 elipsers에게 맡길게 ;) 17:10 <kostya213> 악의는 없지만, 이 프로젝트가 더 많은 괴짜를 끌어들일 필요가 있는지는 모르겠어 17:10 <vulpine> <Complication> 그런 부류의 괴짜들이 코딩도 할까? 17:11 <jrandom> 그러길 바라지 complication 17:11 <jrandom> 좋아, 3.3)이 앞으로 나올 것들을 어느 정도 설명해 줄 거야 17:11 <jrandom> 언제냐면, 글쎄, 지켜보자고, 하지만 "곧"이길 바래 ;) 17:12 <jrandom> 좋아, 3.3)에 대해 더 있어? 17:12 <vulpine> * Complication 그런 괴짜 무리들이 환영이긴 하겠지 :D 17:12 <cervantes> 코딩이라는 게 있고, 난독화된 perl로 해석되는 tcl을 쓰는 게 또 있지 17:12 <kostya213> FUSE 플러그인도 유용할 수 있겠다 17:13 <jrandom> 응 17:13 <jrandom> 좋아, 4) Syndie의 암호로 넘어가자 17:13 <jrandom> 그 이슈들에 대해 코멘트 있는 사람? 17:14 <vulpine> <Complication> 그러고 싶지만, 그 암호/해시/키 길이의 강도를 평가할 역량은 없어 17:15 <vulpine> <void> elgamal/rsa 서명은 얼마나 길지? 2kbit 키에 4kbit? 17:15 <vulpine> * Complication 그 얘기는 전적으로 다른 사람에게 맡김 17:15 <jrandom> 바로 떠오르진 않네 17:15 <vulpine> <void> dsa랑 비교하면? 17:16 <jrandom> (근데 ECC는 작고 좋아 보이네) 17:16 <modulus> ElGamal 서명은 다루기 어렵고 길어. gpg 팀도 그걸 겪었지. 17:16 <jrandom> 응, 다만 그 트릭들 중 일부는 키 재사용과 관련 있었어 17:16 <vulpine> <void> 아, 오케이 17:16 <vulpine> <void> 응, 그렇네 17:16 <tethra> modulus: 길고 단단하다면, 그런 건 취향 커뮤니티가 따로 있지 17:17 <jrandom> 좋아, 그 포인트는 그냥 미리 알리고, 생각나는 게 있을 때 의견 달라는 의미였어 17:17 <cervantes> 플러그형 암호 알고리즘을 구현할 수 없을까 - 더 나은 키 생성 방식이 표준화되면 Syndie에 그걸 추가하고 새 게시물부터 그걸 쓰게 하고, 오래된 게시물은 예전 방식을 계속 쓸 수 있게 17:17 <tethra> (미안) 17:17 <jrandom> cervantes: DSA: 접두사를 포함하니까, Elg: 접두사도 가능해 17:17 <modulus> 1024비트로 제한된 DSA를 쓰는 거야, 아니야? 17:18 <modulus> 해시는 뭐야? sha1이야 아니면 더 높은 버전? 17:18 <cervantes> 그러니까 지금은 Syndie의 출발을 잘 하게 하는 데 신경 쓰는 거네 17:18 <jrandom> DSA는 1024비트뿐이야 (더 긴 dsa2 제안이 있긴 하지만 아직 표준화되지 않았어) 17:18 <jrandom> 그리고 맞아, DSA는 sha1이 필요해 17:18 <modulus> 음, 내가 알기론 표준 전에도 꽤 강력했던 걸로 알아. 17:18 <kostya213> cervantes 말이 맞아, Syndie 콘텐츠를 고정된 암호로 묶어두면 순방향 보안이 떨어져, 알고리즘이 언제 한순간에 망가질지 몰라 17:18 <modulus> 하지만 과정을 면밀히 따라가진 않아서 네가 아마 맞을 거야 17:19 <jrandom> kostya213: 하지만 선택지는 암호학에 안 좋아, 그래서 가능하면 값을 고정해야 해 17:19 <jrandom> (익명성 때문에 안 좋아) 17:19 <vulpine> <void> 왜 더 많은 사람/프로토콜이 ECC를 안 쓰는지 알아? 연구 부족이 걱정돼서야, 아니면 호환성 문제 때문이야? 17:19 <modulus> 특허. 17:20 <jrandom> 특허랑 FUD, 그리고 구현상의 우려가 좀 있어 17:20 <vulpine> <void> 아, 맞네 modulus 17:20 <modulus> 그런데, 예를 들어 rsa-sha512 대신 dsa로 갈 만한 좋은 이유가 있어? 17:20 <tethra> 특허와 FUD와 국가(이 모든 게 한꺼번에) 17:20 <modulus> 성가시게 하려는 건 아니고, gpg 같은 데서도 그 방향으로 갔잖아, 등등. 17:20 <jrandom> 그 옵션은 몇 년째 검토 안 해봤네 modulus 17:21 <modulus> 분명 DSA가 표준인 건 장점이지만, 키는 작고 해시는 약하지. 물론 그게 가장 약한 고리가 될 것 같진 않지만 ;-) 17:23 <cervantes> "선택"을 제안하고 싶은 건 아니고 - 새 버전의 Syndie가 점점 더 안전한(의무) 암호를 묶어서 제공하는 거지 17:23 <vulpine> <Complication> 어떤 암호가 현재 최선인지와 상관없이, 구조에 향후 변경을 위한 여지를 두는 건 합리적일 듯 17:23 <jrandom> 응, 다만 그건 상호운용을 위해 더 약한/오래된 버전으로의 폴백을 내포해 17:23 <jrandom> 뭐, 좋아, 그건 차차 풀어가자 17:24 <jrandom> 좋아, 5) ???로 넘어가자 17:24 <jrandom> 회의에 더 가져올 거 있는 사람? 17:25 <cervantes> 좋아하는 소스의 최신 글을 읽을 수 없다는 건 모두가 업그레이드를 유지하게 만드는 좋은 동기야 17:25 <jrandom> 어느 정도는 17:26 <cervantes> no=not 17:26 <jrandom> (응, 동기는 되지만, 사람들은 게으르거나 '소프트웨어 업그레이드'에 관심 없어, 등등) 17:27 <jrandom> s/people/some people/ 17:27 <cervantes> 그건 그 사람들 문제겠지 17:27 <jrandom> 맞는 말 17:27 <kostya213> 적어도 I2P 구현은 무통 업그레이드가 가능해 17:28 <jrandom> 물론이지 17:28 <cervantes> ???와 관련해 - irc 연결성에 대한 사과 - ISP가 주요 네트워크 캐리어 중 하나를 "가능한 한 빨리" 복구할 거야 17:29 <jrandom> w3wt 17:29 <vulpine> <Complication> ??? 주제로, NTP 수정의 두 번째(더 광범위한) 부분이 거의 동작 단계라 곧 테스트를 위해 커밋하고 싶다는 걸 덧붙일 수 있겠어 17:29 * cervantes 소금을 집어듦 17:29 <kostya213> router 개발의 단기 계획은 뭐야? 로드맵이 정확해? 17:29 <jrandom> wikked complication 17:29 <vulpine> <Complication> 목표는 피어의 시계 오차를 바탕으로 NTP 서버를 재평가하는 거야 17:29 <jrandom> kostya213: Syndie가 나올 때까지 안정화 17:30 <jrandom> (내 관점에서는) 17:30 <vulpine> <Complication> (그리고 잠재적으로 연결성을 해칠 수 있는 행동을 피하는 것) 17:31 <cervantes> 훌륭 17:32 <jrandom> 좋아, 회의에 더 있을까? 17:34 * jrandom 마무리함 17:34 * jrandom *baf*하며 회의를 마침