간단 요약

참석자: badger, bar, cervantes, Complication, HotTuna, jrandom, tethra

회의 로그

16:03 <jrandom> 0) 안녕 16:03 <jrandom> 1) 네트워크 상태 16:03 <jrandom> 2) Syndie 개발 상태 16:03 <jrandom> 3) ??? 16:03 <jrandom> 0) 안녕 16:03 * jrandom 손을 흔든다 16:03 * Complication 키보드에 손이 닿는 어딘가로 비틀거리며 감 (이번 주 시작은 지옥이었지만, 이제 끝났어) 16:04 <jrandom> (지옥 같은 시작 만세!) 16:04 <jrandom> 주간 상태 노트를 http://dev.i2p.net/pipermail/i2p/2006-October/001315.html 에 올렸어 16:04 <+Complication> 안녕 16:05 <jrandom> 다들 (짧은) 노트를 읽는 동안, 1) 네트워크 상태로 넘어가자 16:05 * jrandom freshcoffee 에 3일째 끊김 없이 연결되어 있고, 두 irc 서버 모두 사용자 수가 꽤 많은 것 같아 16:06 <jrandom> stats.i2p도 돌아왔고, tunnel 성공률이 좀 이상하게 출렁이긴 했지만 전반적으로 상태가 좋아 16:06 <jrandom> (그래도 아직은 20~30 범위) 16:06 <jrandom> ((5~10보다는 훨씬 낫지만, 60~80보다는 훨씬 못함)) 16:07 <jrandom> 좋아, 1) 네트워크 상태에 대해 얘기할 거 있는 사람? 16:08 <+Complication> 여기도 비슷하지만, 특별히 오래 지속되는 연결은 없어 16:08 <+tethra> 박수 외엔, 난 없어! 16:08 <+Complication> NTP 관련 이슈에 대해 한 마디만 하고 싶어 16:09 <+Complication> 기본적으로, 10월 29일 일요일에 일부 시간대가 일광 절약 시간제에서 벗어나게 돼 16:09 <jrandom> (좀 고생할 듯) 16:10 <+Complication> 개인적으로는 아무에게도 문제를 일으키지 않길 바라지만, 내가 NTP에 그 정도로 밝진 않아서 확신하긴 어려워 16:10 <+Complication> 그래서, 혹시라도 최근 NTP 서버 sanity check(버전 .26에 추가됨)가 그날 밤 누군가에게 불편을 줄 경우를 대비해서... 16:11 <+Complication> ...그걸 비활성화할 수 있는 설정 키를 알려두는 게 낫겠다고 생각했어 (필요한 경우를 대비해서) 16:11 <+Complication> (상태 노트를 읽는 사람들이 알 수 있게) 16:12 <+Complication> 비활성화하려면 http://localhost:7657/configadvanced.jsp 에서 "router.clockOffsetSanityCheck=false" 라인을 입력하면 돼 16:12 <+Complication> 하지만 말했듯이, 아무도 그게 필요 없길 바라 16:13 <+Complication> 그렇지만 그날 밤 서로 다른 시간대가 전환되기 시작하면서 네트워크가 어떻게 동작하는지 지켜보는 건 흥미로울 거야 16:13 <+Complication> 이상 징후가 보이면 아마 봄까지는 고칠 수 있길 바라면서, 난 꼭 관찰할게 :D 16:14 <jrandom> 그 시각 전후에는 꽤 출렁일 가능성이 크지만, 곧 정상화될 거야 16:14 <+Complication> ...내가 할 말은 그게 다야. :) 16:14 <jrandom> 하지만, 잘 되길 바라고, 안 되면 네 말처럼 봄이 있지 :) 16:14 <bar> 만약 정말로 b0rk이 난다면, 며칠 전 채팅에서 나온 향후 개선을 위한 제안이 두 가지 있었어: 16:15 <bar> "피어가 <some number 보다 적으면 NTP에 제어를 넘겨서 skewed routers가 서브넷을 형성하지 못하게 하기" 16:15 <bar> ...그리고 "너무 적을 경우 netdb에서 floodfill 피어 router 정보는 삭제하지 않기" 16:15 <jrandom> 응 16:16 <+Complication> 맞아, 피어의 skew 측정을 신뢰할 수 있다고 판단하는 데 필요한 데이터 포인트 수(사용 가능한 피어 시계 skew)를 조정하는 것 16:16 <+Complication> (앗, 방금 문장에 중복이 좀 있었네) 16:17 <+Complication> ...그리고 맞아, floodfill 체크. 현재 비슷한 체크는 없는 거지? 16:18 <jrandom> 맞아 16:18 <+Complication> 어떤 사람들은 때때로, 운이 좋든 마법이든, floodfill 피어를 놓쳐버리는 경우가 있는 것 같아 16:19 <jrandom> 그건 확실히 바로잡아야 해 16:19 <jrandom> (며칠 전에 그들 중 하나가 null routed 되었을 때 몇몇 사람에게 영향이 갔어) 16:20 <jrandom> (if #floodfill == 0, perhaps randomly treat a few as floodfill) 16:20 <+Complication> 그게 가능하다면, 그것도 가능해 16:21 <+Complication> 다만, 최소 2개(그 비슷하게) floodfill 피어를 유지하는 것에 더해 그걸 하는 게 두 배로 안전할 거야 16:22 <jrandom> 응 16:25 <jrandom> 좋아, 1) 네트워크 상태에 더 할 말 있어? 아니면 2) Syndie 개발 상태로 넘어갈까? 16:25 <badger> IRC 안정성 관련: 서버 쪽에서 재연결이 훨씬 훨씬 훨씬 줄어들고 있어. 16:25 <badger> 이제 거의 서비스라고 불러도 되겠어 :) 16:26 <jrandom> :) 16:28 <jrandom> 좋아, 2) Syndie 개발 상태로 넘어가자 16:28 <jrandom> 상태 노트에 적었듯이 여기 진전이 많아 16:28 <jrandom> 지난 며칠 동안 여기서도 그에 대해 논의가 꽤 있었고 16:28 <jrandom> 그 부분에 대해 얘기하고 싶은 사람 있어? 16:30 <@cervantes> mspaint 말고 다른 걸 설치해 16:30 <jrandom> 헤헷 16:30 <jrandom> 음, 스케치에는 *못생긴* 걸 쓰는 데에도 가치가 있어 - 기대치를 낮춰주거든 16:31 <+fox> <HotTuna> 포럼 게시글의 링크가 내려간 것 같아 ... 적어도 몇 개는.. 16:31 <@cervantes> 그건 글에 언급되어 있던 것 같아 16:31 <+fox> <HotTuna> 아. . 미안 16:31 <jrandom> hottuna: 그건 dev.i2p.net/~jrandom/mockup/ 에 미러되어 있어 16:31 <@cervantes> 몇 개는 아래쪽에 더 미러되어 있을 거야 16:32 <+Complication> 한 가지 질문: 그럼, 어떤 웹 브라우저를 분해하지 않고, 제한된 HTML을 (안전하게) 처음부터 구현하는 게 더 쉽다고 보나요? 16:33 * jrandom 방금 사진 두 장 더 올림: dev.i2p.net/~jrandom/mockup/forum.webp 그리고 blog.webp (지난 며칠 동안의, 포럼을 보는 다양한 방식에 관한 논의를 보여줌) 16:33 <@cervantes> 그게 안전하게 하기는 훨씬 쉬워 16:33 <+Complication> (GUI 쪽에서 무슨 일이 진행 중인지 궁금해서, 그 부분을 잘 몰랐거든) 16:33 <jrandom> Complication: 일반적인 포매팅 용도로 필요한 건 거의 다 해놨어 16:33 <@cervantes> 특히 Syndie가 지원할 html 서브셋이 제한적이라는 점을 감안하면 16:34 <+Complication> 아하 16:34 <jrandom> (글꼴, 정렬, 크기, 색상, 이미지, 링크, 목록(중첩 포함), 헤더, 문단, html entities) 16:35 <jrandom> 이제 배치를 위한 div나 테이블까지 하려면 상당히 더 많은 작업이 필요하지만, 지금은 그건 다루지 않을 거야 16:35 <+Complication> 충분히 좋아 보이네 16:36 <@cervantes> 그리고 물론 <blink> 태그 16:36 * jrandom †로 cervantes에게 투척 16:37 <@cervantes> 아야, 엔티티에 꿰뚫렸네 16:37 <jrandom> 그래도 지켜보자. 배포되어 쓰이기 시작하면, 아마 풀스펙 html 렌더링 엔진으로 전환할 필요가 생길 수도 있어 16:38 * jrandom 그래도 코드베이스를 가능한 한 작게 유지하고 싶어, 보안과 익명성 이슈에 대해 디버깅과 리뷰할 게 적어지도록 16:39 <+Complication> 확실히, text/plain으로 처리하는 데에는 장점이 많지 16:40 <+Complication> (바라건대 자연어 공격만 지원하겠지 ;P ) 16:41 <+Complication> hashcash(작업증명 방식) 기반 안티스팸 조치 가능성에 대한 의견은 어때? 판단하기엔 아직 이른가? 나중에 붙이기도 쉬울 거라고 보니? 16:42 <@cervantes> 음, 풀 html 엔진을 쓸 때는 bbcode나 위키 문법을 쓰면 마크업 인젝션 위험을 줄일 수 있겠지 16:42 <@cervantes> *렌더링 엔진 16:43 <jrandom> 붙이는 건 꽤 쉬워, Complication - 그냥 새로운 public header를 추가하면 돼(정규 syndie uri에 대해 hashcalc, 가져올 때 검증, 서명 시 생성) 16:44 * Complication 며칠 전에 몇 가지 생각해봤는데, 가볍게만 했어 16:44 <jrandom> hashcash도 여러 레벨에서 할 수 있어 - 새 채널마다(meta.syndie), 업데이트된 채널마다, 또는 게시물마다(아마 sizeof(post)나 #msgs/day에 따라 난이도를 조절하는 것도 가능) 16:44 <+Complication> 작업증명으로 hashcash를 구현한다면, 글 게시자가 어떤 것에 대해 충돌을 계산하도록 요구하는 게 가장 좋을지 궁금하네? 16:45 <+Complication> 아하, uri... 그게 맞을 수도 16:45 <+Complication> 오, 그렇네 16:45 <+Complication> 그건 내가 생각 못 했던 부분이야 16:48 <jrandom> cervantes: 맞는 말이야 16:48 <jrandom> 좋아, 2) Syndie 개발 상태에 대해 더 할 말 있어? 16:51 <jrandom> 좋아, 없으면 3) ???로 넘어가자 16:51 <jrandom> 더 꺼내고 싶은 얘기 있는 사람? 16:54 <jrandom> 좋아, 없으면... 16:54 * jrandom 예열 시작 16:54 * jrandom *baf*s 하며 회의를 종료함