I2P 개발자 회의 - 2005년 12월 20일

15:20 <jrandom> 0) 안녕하세요 15:20 <jrandom> 1) 네트워크 상태 15:20 <jrandom> 2) I2PSnark 업데이트 15:20 <jrandom> 3) Syndie 블로그 UI 15:20 <jrandom> 4) ??? 15:20 <jrandom> 0) 안녕하세요 15:20 * jrandom 손을 흔듭니다 15:20 <jrandom> 주간 상태 노트를 http://dev.i2p.net/pipermail/i2p/2005-December/001240.html 에 올려두었습니다 15:22 <jrandom> 좋아요, 1) 네트워크 상태로 바로 들어가죠 15:22 <jrandom> 상태 노트에 있는 내용 외에는 덧붙일 게 많지 않아요. 15:22 <+Complication> 가끔 있는 OOM(Out-Of-Memory)만 아니면, 꽤 괜찮다고 말하겠어요 15:22 <jrandom> 부하 테스트 결과가 꽤 고무적이라, 성능을 더 개선할 여지가 많다는 걸 시사합니다 15:23 <+Complication> 그리고 OOM이 15:23 <jrandom> 헤, I2PSnark 관련 OOM인가요? 아니면 그 전부터요? 15:23 <+Complication> 는 i2p-bt, i2psnark, i2p-rufus 인스턴스가 ... 뭔가를 할 때 불안정성에 기여하죠. 15:24 <zzz> 제 가설로는 토렌트 트래픽 증가가 IRC 안정성에 다소 악영향을 주는 듯합니다 15:24 <+Complication> (SAM의 이상 현상을 OOM이라고 부르면 안 될지도요, 자세히 보진 않았거든요. 하지만 확실히 요인 중 하나이긴 해요) 15:24 <jrandom> 흠, 잘 모르겠어요. IRC 상태가 최신 snark 업데이트 전과 비슷했거든요 15:25 <+Complication> 대역폭은 안정적이었고, 부분적으로도 tunnel도 탄탄했어요... 다만 가끔씩 크래시가 날 뿐 15:26 <zzz> 어쨌든 0.6.1.8에 들어갈 tunnel 빌드 수정 사항이 IRC 경험을 개선해 줄 거라고 낙관합니다 15:26 <+Complication> 잘 알려진 이유 때문이죠, 때가 되면 사라지길 바랍니다 :) 15:26 <jrandom> 네, 저도 그렇게 봐요 zzz, 그래서 아마 하루 이틀 안에 릴리스를 낼 것 같아요 15:26 <+legion> 음, IRC가 너무 민감한 걸 수도 있어요. 그냥 jabber 같은 걸 쓰는 게 더 낫지 않을까요? 15:26 <zzz> 특히 느린 기기나/또는 연결을 쓰는 분들에겐요 15:27 <jrandom> jabber로도 달라지진 않을 거예요 15:27 <+Complication> 특히 tunnel 중복도가 2일 때는요 15:28 <+bar> IRC는 네트워크 상황을 가늠하는 훌륭한 '엉망-미터'라고 말하겠어요 15:28 <+legion> 네, 바람만 살짝 불어도 IRC가 금방 뻗어버리죠 15:28 <+bar> 바로 그거죠 :) 15:28 <+Complication> shitlisting(차단 목록) 수정 이후에는 "Recent"가 늘 "Known"보다 많아지는 경향이 있더군요 15:29 <+Complication> "Known"에는 shitlisted(차단된) 피어가 포함되지 않지만 "Recent"에는 포함되기 때문일까요? 15:29 <jrandom> 네, IRC는 상황을 보기 좋은 창이에요. 사용자별로 편차가 상당히 나타나거든요(예: dreamtheaterfan은 항상 문제가 있음 등) 15:30 <jrandom> 흠, 일리 있네요 Complication 15:30 <+Complication> (정확한지는 모르고, 그냥 추측이에요) 15:30 <jrandom> (shitlisted 피어는 netDb에서 제거되지만, 그들의 프로필은 삭제되지 않기 때문이죠) 15:32 <+Complication> 그렇다면 지표들은 괜찮아 보이네요(혹시 아닐까 싶어 물어봤어요) 15:33 <jrandom> 좋습니다, 1) 네트워크 상태에 대해 더 있을까요? 15:33 <jrandom> 아니면 2) I2PSnark 업데이트로 넘어가죠 15:33 <tealc_> 어떤 종류의 업데이트가 있나요? 15:34 <jrandom> 간단한 목록은 http://dev.i2p.net/pipermail/i2p/2005-December/001240.html 에서 보세요 ;) 15:34 <jrandom> 기본적으로 I2PSnark는 이제 하나의 I2P destination(목적지)에서 동시에 여러 토렌트를 처리할 수 있고, 웹 인터페이스가 있으며, router 콘솔에 내장되어 있어요 15:35 <tealc_> 최신 CVS 빌드를 돌리고 있는데, i2psnark가 메모리 힙 오류 같은 걸 많이 일으켜요 15:35 <+Complication> ...그리고 이상한 메타태그가 있는 Azureus 제작 토렌트도 처리합니다. 15:35 <+Complication> 예전에는 그걸로 멈추곤 했죠. 15:35 <jrandom> 아, 네, 아직 그 안에서 디버깅 중인 부분이 좀 있어요 tealc_ 15:35 <jrandom> (주간 상태 노트에도 적어놨듯이 ;) 15:35 <jrandom> 아, 맞아요 Complication 15:36 <jrandom> 아, 그리고 Azureus 쪽에서 I2PSnark가 그 트래커를 쓰지 못하게 하던 버그를 고쳤습니다 15:36 <jrandom> (그래서 B16 이전 Azureus 트래커를 운영 중인 분들은 가능한 한 빨리 업그레이드하세요) 15:37 <+bar> i2psnark 자동 시작을 쉽게 끌 수 있으면 좋겠어요(낮은 대역폭 상황 등에서). 15:38 <jrandom> 그건 쉽게 추가할 수 있을 거예요 15:38 <+bar> 좋네요 15:39 <jrandom> 좋아요, 2) I2PSnark 업데이트에 대해 더 있을까요? 15:40 <jrandom> 아니면 3) Syndie 블로그 UI로 넘어가죠 15:40 <zzz> 새 i2psnark 정말 최고예요 - 잘하셨어요 15:41 <jrandom> 감사, mjw가 고생했죠. snark를 확장하기 쉽게 만들어줬어요 15:41 <jrandom> 자, 상태 노트에 언급했듯이, 이제 syndie에는 새로운 블로그 UI가 있어요 15:42 <jrandom> 사람들에게 닥칠 수 있는 다양한 스팸 문제를 다루기 위해 화이트리스트와 블랙리스트 사이의 균형을 제공할 거라 봐요 15:43 <jrandom> 그건 다음 릴리스에 포함될 거라, 하루이틀 안에 여러분이 직접 써보실 수 있을 거예요 15:43 <+legion> 스팸이 가까운 시일 내에 정말 큰 문제가 될까요? 15:44 <+Complication> legion: 친절하게도 누군가가 보여줬듯, 그럴 수 있어요 15:44 <jrandom> 아니요, 블랙리스트로 홍수처럼 올리는 작성자들을 막고, 화이트리스트로 작성자를 잔뜩 만드는 스패머를 막으면 됩니다 15:44 <dust> (익명성이 어떤 사람들에겐 최악을 끌어내죠) 15:44 <jrandom> (그래서 스팸은 문제가 되지 않아요) 15:45 <+Complication> (그 사람이 영구 블랙리스트를 피하려고 키를 재생성하고 있었던 듯해요. 그건 확실히 약간의 속도 저하를 일으키긴 하죠.) 15:45 <+Complication> 그렇다고 큰 저하는 아니고, 그래서 화이트리스트도 좋다는 데 전적으로 동의합니다 :) 15:46 <+bar> 필요하다면, 나중에는 hashcash(작업증명 방식) 같은 해결책도 가능하겠죠 15:46 <jrandom> 필요하다면요. 하지만 그럴 이유를 못 보겠어요 15:46 <+bar> 동의해요. 지금은 저도 그렇게는 안 보이네요 15:46 <+Complication> bar: 일종의 "약간의 연산을 하지 않으면 보이지 않게" 하는 건가요? 15:47 <+bar> 네, 그런 류죠 15:47 <+Complication> 가능해 보이네요, 아마 필요 없겠지만요. 15:47 <+bar> 아마 그렇죠. 15:47 <jrandom> 스패머들이 늘 새로운 작성자를 잔뜩 만들어 도배하더라도, 사람들은 자기 블로그에 그 작성자들의 북마크와 블로그 참조를 올려서 다른 사람들에게 알릴 수 있어요 15:47 <+Complication> 아니, 더 정확히는, 필요 없기를 바라요. 15:48 <+Complication> 혹시나 필요가 생길 경우를 대비해, Syndie가 그런 기능을 수용할 수 있는지 검토해두면 좋겠네요. 15:49 <jrandom> 네, 가능합니다. 블로그 게시물의 헤더나 블로그 자체의 메타정보로요 15:49 <jrandom> 어, 메타데이터요(이런 bt!) 15:51 <jrandom> 좋아요, 3) Syndie에 더 없으면, 4) ???로 넘어가죠 15:51 <jrandom> 회의에서 더 논의하고 싶은 사항이 있나요? 15:51 <+legion> 네, 몇 가지 있어요 15:52 <+legion> 먼저 clunk요 15:52 <jrandom> 멋지네요, clunk는 흥미로워 보여요 15:52 <+legion> 오늘 i2p-chat에서 말했듯이, cygwin이나 mingw로 컴파일되게 하려고 작업하고 있어요. 15:53 <+legion> 지금까지는 클라이언트만 깨져 있고, 서버를 포함한 나머지는 컴파일되고 동작하는 듯해요 15:53 <jrandom> 좋네요 15:54 <tealc_> i2p는 George Bush의 끝없는 감시 프로그램에 정말 큰 골칫거리가 될지도 몰라요. 수용소에서 봅시다, 카드나 챙겨오세요 15:54 <+legion> 클라이언트가 왜 깨졌는지 추적하는 것뿐 아니라 해결하려고도 해왔어요. 지금은 막혀 있어요. 15:56 <+legion> 다른 한 가지는, 제 jabber 서버로 가는 기본 tunnel을 다음 업데이트에 포함할 수 있을까요? jabber를 써보려는 사람이 쉽게 시작할 수 있도록요. 15:57 <tethra> 20:34:37 <jrandom> 스패머들이 늘 새로운 작성자를 잔뜩 만들어 도배하더라도, 사람들은 자기 블로그에 그 작성자들의 북마크와 블로그 참조를 올려서 다른 사람들에게 알릴 수 있어요 <--- 아마 polecat의 신뢰 결합 방식 같은 게 여기서 역할을 할 수 있지 않을까요? (즉, 스패머를 차단하고 인기 있는 작성자를 부각하는 식으로.) 15:57 <tethra> </$0.02> 15:58 <+polecat> 맞아요, 제 신뢰 네트워크 아이디어의 원시적인 예가 될 수 있겠네요. 100% 신뢰 전이를 가정한 휴리스틱으로요. 15:58 <jrandom> legion: 흠, 비활성화된 설정을 추가하는 건 새 사용자에겐 충분히 쉽지만, 제가 주저하는 부분은 프로토콜 필터링(그리고 어떤 클라이언트가 어떤 정보를 유출하는지)에 관한 거예요. 다양한 클라이언트를 써본 경험은 어떤가요? 15:59 <jrandom> 네, syndie에 신뢰 지표를 통합할 여지는 많아요 16:01 <+legion> 제가 아는 한 jeti는 파일 전송을 제외하곤 유출하지 않아요. 그건 어차피 제 서버 설정에서 비활성화돼 있기도 하고요. 아마 다음 jeti 버전에서 수정될 겁니다. 그 외 다른 클라이언트는 잘 모르겠네요. 16:02 <+legion> 확실히 아는 건, 클라이언트와 무관하게 그룹 채팅은 탄탄하다는 거예요. 다만 그룹 채팅 밖의 연락에서 일부 클라이언트가 유출할 수도 있는데, 확실하진 않아요. 16:03 <jrandom> 흠, 유출은 정말 이분법적(불리언) 문제가 아니에요. 핵심은 클라이언트가 정보를 유출하느냐가 아니라, /어떤 정보/를 유출하느냐죠 16:04 <+legion> 맞아요. 물론 IP 주소 같은 중요한 정보를 말한 거예요. 다만 좋은 클라이언트라면 그런 정보를 유출하더라도 127.0.0.1 또는 localhost로만 보고해야겠죠 16:06 <+legion> 그래서 jeti 같은, 유출하지 않는 것으로 알려진 클라이언트만 쓸 것을 권합니다. 16:07 <zzz> 클라이언트 표에 '유출 없음 검증' 컬럼을 추가해 줄 수 있을까요? 16:07 <jrandom> jeti가 어떤 것은 유출하고 어떤 것은 유출하지 않는지 문서화해 주면 유용하겠어요(SMTP와 POP 프록시에 대해 postman이 정리한 것처럼요) 16:08 <+legion> jeti 개발자에 따르면 익명성을 훼손할 만한 것은 아무것도 유출하지 않는다고 합니다. 그 점은 의심의 여지 없이 확실해요. 저도 소스를 살펴봤지만 그와 다르게 생각하게 만들 만한 것은 찾지 못했습니다. 16:09 <jrandom> 개발자가 그렇게 말했다는 사실은 확실할 수 있지만, 그 개발자가 익명성을 얼마나 이해하는지는 또 다른 문제죠 ;) 16:09 <+legion> 네, zzz 그런 컬럼을 하나 더 추가할 수 있어요 16:09 <jrandom> jeti가 제대로 동작할 가능성을 의심하진 않아요. 다만 그게 정확히 무엇을 의미하는지 알아야 해요 16:10 <zzz> 비유출 여부는 프로토콜 추적으로만 검증할 수 있을 것 같네요 16:10 <zzz> 소스를 보거나 개발자에게 묻는 걸로는 아니고요 16:12 <jrandom> 좋아요, 회의에 대해 다른 안건이 있나요? 16:12 <+bar> amd64 jbigi 잊지 말아 달라는 알림만요 16:13 <+bar> (하지만 여러분의 TODO 목록에 있을 거라 확신해요) 16:13 <jrandom> 네 :) 16:13 <jrandom> (win amd64요. linux amd64는 이미 동작 중이고요) 16:13 <jrandom> 그럼, 더 없으면... 16:14 * jrandom 마무리합니다 16:14 <+bar> 네, win amd64요. 16:14 * jrandom *baf* 하며 회의를 마감합니다