I2P 개발자 회의 - 2005년 1월 18일

13:04 <jrandom> 0) 안녕하세요 13:04 <jrandom> 1) 네트워크 상태 13:04 <jrandom> 2) 0.5 13:04 <jrandom> 3) i2pmail.v2 13:04 <jrandom> 4) azneti2p_0.2 13:04 <jrandom> 5) ??? 13:04 <ant> <duck> (암호화 얘기가 내 귓가를 스쳐 지나가는 소리) 13:04 <jrandom> :) 13:04 * jrandom 손을 흔든다 13:04 <cervantes> 'lo 13:04 <jrandom> 여러분도 암호화 얘기가 귓가를 스쳐 지나가는 소리를 들을 수 있어요! 주간 상태 노트 게시 @ http://dev.i2p.net/pipermail/i2p/2005-January/000559.html 13:05 <bla> 안녕하세요 13:05 <jrandom> 어차피 흥미로운 토론에 끼어든 김에 바로 시작하죠... 1) 네트워크 상태 13:05 <jrandom> 메일에 있는 내용 외엔 딱히 덧붙일 게 없네요 - 네트워크 상태와 관련해(wrt) 누가 제기할 내용이 있나요? 13:06 <bla> 남극을 제외하고, 처음으로, 모든* 대륙에서 노드가 보였다는 것 외에는 없네요. 13:06 <jrandom> w00t! 13:07 <jrandom> 좋아요, 2) 0.5 얘기로 넘어가죠 13:07 <mule> 이봐요, 우리 아버지가 지금 막 남극으로 가는 중인데, 노드를 하나 드렸어야 했네요 13:07 <ant> <duck> 빌어먹을 남극인들 13:07 <Xan> 남극인들이 없다고요? :( 13:07 <jrandom> 하하 좋네요 13:07 <jrandom> 그래도 거긴 anonymity set(익명성 집합)이 별로 없을 듯 13:07 <Frooze> 남극 탓이죠 13:08 * cervantes 남극에 유전을 설치해 거기서 나는 돈으로 노드를 운영한다 13:09 <jrandom> 자자, 0.5 얘기가 많으니 나눠서 합시다 13:09 <jrandom> 먼저, 하루치 통계를 모아준 분들께 감사 - 흥미로운 데이터가 많아요 @ http://dev.i2p.net/~jrandom/messageSizes/ 13:09 <postman> 기쁩니다 :) 13:10 <cervantes> 네트워크 상태와 관련해(wrt)... 요즘 I2P를 시작하고 돌리는 데 어려움을 겪는 사람들이 꽤 보여요(포럼 등에서) - 단순히 사용자 수가 늘어서인지, 아니면 I2P 기반 앱이 많아지면서 문제가 생길 지점이 늘어서인지 모르겠네요 13:10 <+protokol> jrandom: 거짓말쟁이! 데이터가 흥미롭다면서요! 13:10 * jrandom protokol 에게 진흙을 던진다 13:11 <ant> <duck> cervantes: 몇 분 만에 올리고 돌렸다는 보고도 봤어요 13:11 <ant> <duck> 문제 대부분은 NAT 때문인 듯해요 13:11 <cervantes> duck: 맞아요... 13:11 <ant> <dmdm> NAT가 누구죠? 13:11 <jrandom> cervantes: 여전히 지저분한 이슈가 좀 있죠, 분명히. NAT 문제랑 osx 쪽이 요즘 좀 고통이었는데, Jhor가 후자에 도와줘서 개선될 거예요 13:12 <cervantes> 옙 13:12 <cervantes> *콜록* 자... 0.5 13:13 <Xan> dmdm: network address translation 13:13 <jrandom> 헤헷, 좋아요. 기본적으로 그 메시지 크기 통계의 목적은 패딩(padding) 이슈를 탐구하려는 거예요 13:14 <jrandom> 안타깝게도, 임의로 숫자를 골라 만든 전략이 별로라서, 패딩 데이터만으로도 25% 오버헤드가 나왔어요 13:14 <jrandom> 0.5 암호화에 대한 제안 중 하나(tunnels-alt.html)를 택하면, 그 이슈는 사라집니다 13:15 <jrandom> (조각화와 함께 작은 고정 크기를 강제하니까요) 13:15 <mule> 어떤 종류의 메시지에 패딩을 하려는 건가요, router가 보는 메시지인가요 아니면 외부 관찰자가 보는 메시지인가요? 13:15 <jrandom> mule: 중요한 질문이에요 13:15 <jrandom> 외부 관찰자만 걱정한다면 메시지를 패딩하지 않은 채로 두고, 전송 계층에서 chaff 생성(교란용 더미 트래픽 생성)을 하면 됩니다 13:16 <Teal`c> http://microsoft.i2p/david_hasselhoff_05_christmas_album__silent_night.mp3 13:16 <jrandom> 한편(otoh), tunnel 참가자가 흐름 분석을 한다고 걱정한다면, tunnel 내부에서의 패딩을 고민해야 해요 13:16 <@duck> 5-6 홉이면, router가 트래픽 분석을 할 위험이 얼마나 큰가요? 13:16 <cervantes> Teal`c: 지금 회의 중이니... mp3 알림은 #i2p-chat을 써줄래요 ;-) 13:17 <Teal`c> 미안 13:17 <cervantes> :) 데이비드 해서elhoff 때문에? 13:18 <jrandom> 분석의 수준에 달렸죠, duck. 만약 그들이 어떤 tunnel에 있는지 추적해냈다면(예: 그들이 인바운드 tunnel 게이트웨이이고 netDb를 수집해 목적지와 상관관계를 만들었다면), 그건 만만치 않은 데이터예요. 한편 직접적인 노출은 아니지만, 어느 정도 정보를 주죠 13:18 <jrandom> tunnel 패딩보다 더 중요한 건 end-to-end 패딩이에요, 게이트웨이와 엔드포인트로부터 메시지 흐름 데이터를 숨기는 거죠. 13:19 <jrandom> 우리가 미쳤거나 멍청하다면, 아예 pipenet(네트워크 전반에 고정 비트레이트 적용)으로 가버릴 수도 있어요 13:19 <+polecat> 찾았다! 13:19 <jrandom> (그리고 아무도 i2p를 안 쓰게 되겠죠) 13:19 <+polecat> 우리가 해야 할 건 이메일 위에 i2p를 터널링하는 거예요! 13:19 <cervantes> 충분히 큰 네트워크에서 공모하는 routers가 같은 tunnel에 들어갈 가능성은 어느 정도죠? 13:19 <+polecat> 어떤 ISP도 이메일을 막을 만큼 멍청하진 않죠! 13:20 * jrandom net.i2p.router.transport.gmail 구현을 기다린다 13:20 <postman> polecat: 와, 이건 우스워요 13:20 <postman> :) 13:20 <bla> cervantes: N^(-h) (N은 빠른 노드의 수, h = 홉 수)인 듯해요 13:20 <+polecat> =3 알아요. 13:21 <cervantes> 그게 많나요? :) 13:21 <jrandom> 빠른 노드 수는 아니에요, 외부인들은 당신의 프로필을 모르거든요 13:21 <+polecat> 진지하게 말하면, 기존 IP 서비스를 뻔뻔하게 남용하면, 온갖 기발한 방식으로 i2p를 터널링할 수 있어요. 13:21 <jrandom> 같은 tunnel에 두 피어가 들어갈 확률은 c^2/N^h 13:21 <jrandom> 동의해요, polecat. 그래서 양방향 tunnel이 없는 이유 중 하나죠 13:22 <jrandom> 어떤 전송(예: 이메일)은 양방향 통신에 별로거든요 13:22 <bla> jrandom: c = ? 13:22 <jrandom> c==공모하는 피어의 수 13:23 <+polecat> 흠, 흥미로운 지점이네요. 13:23 <ant> <duck> 로드맵 관점에서, i2p가 잘못된 방향으로 가서 잘못된 암호 솔루션을 고르면 어떤 영향이 있나요? 13:23 <+polecat> 혹은 전서구 프로토콜, 전혀 양방향이 아니죠. 13:23 <+polecat> 암호(crypto)는 이미 모듈식이죠, 아닌가요? 13:23 <jrandom> duck: 그건 0.5의 한 항목일 뿐이고, tunnels*.html 문서의 한 하위 섹션일 뿐이에요. 데이터를 감싸는 방식 외에도 tunnel 라우팅에는 훨씬 더 많은 게 있어요 13:24 <bla> jrandom: 하지만 이건 그들을 지금 바로 tunnel에 집어넣을 확률이고요. 다만, T번의 tunnel 갱신(몇 분마다) 동안에는 P = 1 - (1 - c^2/N^h)^T 로 가죠 13:24 <jrandom> 한편, "고정 1KB 블록"과 "0-40KB 블록"의 차이는 영향이 상당하죠 13:24 <+polecat> 이 네트워크가 Entropy처럼 McEliece에 갇혀 버리는 길을 가는 건 보기 싫네요. 13:24 <jrandom> polecat: http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt.html?rev=HEAD 를 읽어보세요 13:24 <bla> jrandom: 그래서 시간이 충분히 크면 0으로 수렴합니다. 즉, 시간이 충분히 길면 공격자들은 결국 한 번쯤은 같은 tunnel에 있게 되죠 13:25 <jrandom> 계획은 표준 AES256/CBC 13:25 <+protokol> 듣자하니 dns가 터널링에 좋다던데, 대부분이 그걸 막지 않죠 13:25 <jrandom> 물론이에요, bla. 다만 그게 그리 단순하진 않아요(탐색용 tunnel에선 맞지만, 클라이언트 tunnel은 아님) 13:26 <+polecat> 그리고 만약 어떻게든 AES조차 뚫리면, 동등한 대칭키 암호로. 13:27 <jrandom> bla: 그 정도 수준이 실용적으로 큰 걱정거리는 아니라고 봐요. 하지만 선행자 공격(predecessor attack)의 일부로 걸면, 그 이슈는 크게 의미가 없어지죠 13:28 <jrandom> (우리가 나머지 tunnel 라우팅을 하는 방식 때문에) 13:28 <bla> jrandom: 오케이 13:28 <jrandom> 맞아요, polecat 13:29 <jrandom> duck: 두 번째 옵션으로 가면, 나중에 다른 걸로 바꾸기도 아마 쉬울 거예요. 13:29 <jrandom> 하지만 한편, 두 번째 옵션은 형편없지 않게(Not Suck) 만들려면 묵직한 성능 튜닝이 필요하죠 13:29 <jrandom> 그래도 우리가 해낼 수 있을 거라 확신해요 13:31 <jrandom> 어쨌든, 위에서 0.5 작업과 관련해(wrt) 현재 어디쯤인지 대충 다뤘네요 13:31 <jrandom> 더 질문/코멘트/우려사항 있나요? 13:31 <bla> jrandom: 하나요 13:32 <bla> jrandom: 지금은 성능보다 익명성을 약간 더 중시해야 한다고 봐요: 그러니 예, PRNG 옵션이 좋아 보여요 13:33 <jrandom> 동의해요. 성능은 나중에 튜닝할 수 있지만, 더 나은 익명성을 "추가"하는 건 훨씬 어렵죠 13:33 <jrandom> (물론, 성능도 /보안/ 파라미터예요. 형편없으면 아무도 안 쓰니까요) 13:33 <bla> 맞아요. 13:33 <bla> jrandom: 13:33 <bla> 미안 13:33 <@duck> 좋아요, /me 마법의 Freenet-성능 비트를 전환 13:33 <cervantes> 아마 그럼 토렌트 흔드는 빨대(리지)들이 좀 더 오래 못 오게 막겠죠 ;-) 13:34 <jrandom> 헤헷 13:34 <cervantes> <-- 연결 재설정 13:34 <bla> cervantes: 아니요, 저 그런 사람 아니에요! :) 13:34 <cervantes> :) 13:35 <jrandom> 멋진 최적화를 해낼 수 있다고 보고요, 병목의 많은 부분이 피어 선택 때문이 아니라, 단지(헤헷) jobqueue에 있는 버그들 때문인 것 같아요 13:36 <jrandom> 그럼, 어쨌든, 2) 0.5에 대해 더 있을까요? 13:36 <ant> <BS314159> 이 루프 공격에 대한 설명을 게시해 주실 수 있나요? 13:37 <ant> <BS314159> 말씀하신 것보다 더 위험해 보이는데요 13:37 <jrandom> 루프: A-->B-->C-->D-->C 를 포함하는 tunnel을 만들고, 메시지 10개를 보냅니다. 13:37 <jrandom> PRNG(의사난수 생성기, PRNG)가 없으면, 그 C<-->D 루프에 원하는 만큼 메시지를 더 넣을 수 있어요 13:38 <ant> <BS314159> 알겠습니다 13:38 <jrandom> 사실상 몇 개의 메시지만으로 routers들을 DoS할 수 있죠 13:38 <ant> <BS314159> 하지만 이건 A만 할 수 있죠 13:38 <jrandom> PRNG가 있으면, 루프로 들어갈 수 있는 메시지 수가 제한됩니다 13:38 <ant> <BS314159> 그러면 공격자가 루프를 끼워 넣어서 내 tunnel을 짧게 만들 위험은 없군요 13:38 <jrandom> 네, 누구도 당신의 tunnel을 줄일 수는 없어요 13:39 <jrandom> 이게 쓸모가 있는 건 DoS뿐이에요 13:39 <jrandom> (아주 값싼 DoS) 13:39 <jrandom> (하지만 큰 비용 없이 피어를 선별적으로 DoS할 수 있으면, 진짜 나아아쁜 짓을 할 수 있죠) 13:40 <ant> <BS314159> 이해했습니다 13:40 <+protokol> 그럼 hashcash certs가 이걸 도와주나요? 13:40 <jrandom> protokol: hashcash는 한 피어가 너무 많은 tunnel을 만들거나, 너무 많은 hop을 만드는 이슈를 다룹니다 13:41 <jrandom> protokol: 루프엔 도움이 안 돼요. 제가 찾은 두 가지 /되는/ 방법은 PRNG(위 tunnel-alt.html)나 매 단계마다 검증하는 것(tunnel.html)이었어요 13:42 <jrandom> 단계별 검증은 위험이 있어요, 그래서 현재로선 PRNG 쪽으로 기우는 중입니다 13:42 <+Ragnarok> prng 방식은 얼마나 효과적일까요? 13:42 <Xan> A-->B-->C-->D-->C - 각 hop마다 다른 id를 받게 해서, 메시지가 두 번째로 C에 도달하면 루프 말고 tunnel 밖으로 나가게 해야 하는 거 아닌가요? 13:43 <jrandom> Xan: 그렇게 해요, 하지만 매 단계마다 검증하지 않으면 그게 나쁜지 아닌지 알 수 없어요 13:44 <jrandom> Ragnarok: 피해를 최소화하는 데 꽤 효과적일 거라 봐요 13:45 <jrandom> 적어도, 지금 보기엔 그래요 13:45 <jrandom> 누가 거기서 문제/이슈를 보거나, 개선 제안이 있으면, 꼭 연락해 주세요 :) 13:46 <Xan> 아니면 내가 뭔가 놓치는 걸지도 13:46 <Xan> bbl 13:46 <jrandom> 'k l8r, 문서를 더 명확히 업데이트할게요 13:47 <jrandom> 자, 다른 게 없으면, 3) i2pmail.v2로 갈까요? 13:47 <jrandom> postman: 계신가요? 13:48 <postman> 네 13:49 <postman> :) 13:49 <jrandom> 포럼에 쓴 글에서 덧붙일 게 있나요? 꽤 멋져 보이던데요 13:49 <postman> 음, 몇몇 분은 이미 i2pmail.v2 초안을 읽었을 거예요 13:50 <bla> 무슨 일이죠? 대량으로 끊깁니다. 여기서도 사이트(예: orion, library)에 접속에 문제가 있어요 13:50 <postman> 장기적으로 완전히 탈중앙화된 메일 인프라를 지향합니다 13:50 <postman> 하지만 노드에서의 프록시 소프트웨어와, 여러 개의 전용 relay가 필요해요 13:51 <postman> 아이디어/개념/잔소리 모두 환영합니다 13:51 <postman> 개발은 이미 시작됐어요 - 늦봄 이전에는 아무것도 기대하지 마세요 :) 13:51 <jrandom> w00t 13:51 <kaji> 흠, 방금 경찰이 우리 집에 왔어요 13:52 <bla> kaji: ? 13:52 <jrandom> 빨리, 하드 드라이브를 날려버려요 13:52 <postman> jrandom: 음, 지금은 이게 전부예요 :) 13:52 <cervantes> 블랙잭 테이블을 숨겨! 13:52 <jrandom> 좋네요, 고마워요 postman 13:52 <kaji> 내가 911에 전화했다는데, 나도 형도 안 했거든요 13:53 <+protokol> kaji: i2p 확인하러 온 거예요 13:53 <jrandom> 좋아요, 3) i2pmail에 더 없으면, 4) azneti2p_0.2로 넘어가죠 13:53 <+protokol> <오싹한 음악> 13:53 <jrandom> 메일에서 언급했듯이, 최근에 중요한 진전이 있었어요 13:53 <kaji> 그러더니 무선전화기가 훅 상태가 되면 오작동할 수 있다고, 하지만 우리 집 무선전화기는 전부 충전기에 올려놨는데요 -> #i2p-chat 13:55 <jrandom> Azureus 분들이 업데이트 준비에 매우 민첩하게 대응해 주셨어요(만세!), 하지만 문제도 주의해서 봐주세요 13:55 <jrandom> (i2p 메일링 리스트를 읽지 않으면서 azneti2p를 쓰는 분들은, 메일링 리스트를 읽으세요) 13:55 <jrandom> ((azneti2p를 안 쓰더라도, 리스트를 읽으세요, 거기에 중요한 걸 공지하거든요 ;) 13:56 <jrandom> duck과 orion도 새 BT 클라이언트와 포맷을 수용하도록 많은 업데이트를 했어요 13:56 <jrandom> (야호!) 13:56 * orion 미소 짓는다 13:57 <orion> 아직 갈 길이 남았지만, 당장은 동작합니다. 13:57 <jrandom> (i2p가 허락하는 한 ;) 13:58 <orion> 헤헤, 맞아요. ;) 13:58 <jrandom> azneti2p나 i2p-bt와 관련해(wrt) 다른 얘기할 분 있나요? 13:58 <jrandom> (아니면 bytemonsoon2p ;) 14:00 <jrandom> 자, 없으면, 바로 5) ???로 갑니다 14:00 <jrandom> 자유발언 - 다른 얘기할 거 있나요? 14:00 <postman> jrandom: addressbook이 왜 userhosts 항목을 게시하나요 ? 14:01 <jrandom> postman: 버그요. 14:01 <postman> 그럼 의도된 동작이 아니었고, 수정될 건가요? 14:01 <cervantes> 한 가지만... 14:01 <jrandom> postman: 맞아요, 수정될 거예요 14:02 <jrandom> (그렇죠 Ragnarok? :) 14:02 <+Ragnarok> postman이 정확히 뭘 의미하는지에 따라 다릅니다... 14:03 <jrandom> Ragnarok: 로컬 사용자가 자신의 private hosts에 새 항목을 추가해도, 공개용으로 게시되는 hosts에는 전파되지 않아야 해요 14:03 <jrandom> (예: userhosts.txt는 private, hosts.txt는 다른 사람과 동기화되는 public) 14:03 <cervantes> 포럼의 반정기 코너로, 최근 혹은 프로젝트 기간 동안 I2P에 좋은 기여를 해주신 분께 감사와 상을 드리려 합니다 14:03 <postman> Ragnarok: 0.4.2.6으로 업데이트한 뒤 eepsite 폴더의 게시된 addressbook에서 userhosts.txt의 항목을 발견했어요 14:03 <ant> <BS314159> 흠 14:04 <postman> Ragnarok: 그건 수동으로 추가한 키들이었고, 게시되면 안 되는 것들이었어요 14:04 <cervantes> 이번 주엔 커뮤니티 서비스 제공자로서의 전반적인 탁월함과 훌륭한 만성 아이들러로서의 duck을 기립니다: http://forum.i2p/viewtopic.php?t=275 14:04 <jrandom> w00t! 14:04 <jrandom> (go duck go, go duck go) 14:05 <Teal`c> 도메인 이름 하이재킹은 어떤가요 ? 14:05 * brachtus 박수 친다 14:05 * orion 존경의 표시로 오리걸음을 한다. 14:05 <cervantes> 앞으로 한 가지 중요한 점... 암호학의 천재가 아니어도 칭찬받을 수 있어요! 14:06 <+Ragnarok> 아니요, 그건 예상된 동작이에요. 바꿀 수는 있지만, 먼저 파일 잠금을 구현해 직접 hosts.txt를 고칠 수 있게 해야 해요 14:06 <orion> (그치만 도움이 되죠) 14:06 <cervantes> 멋진 eepsite를 기여했을 수도 있고요... 14:06 <cervantes> 아니면 포럼에서 도움이 되었을 수도 있고 14:07 <ant> <BS314159> 흠 14:07 <cervantes> (아니면, 솔직히 말해, 매번 jrandom이 상을 받겠죠) 14:07 <jrandom> 얘들아, 너희가 내 맥주 기금을 대고 있잖아, 이거 공짜가 아니라고 ;) 14:07 <ant> <BS314159> 그냥 새 파일 "publichosts.txt"를 만들면 어때요? 14:07 <ant> <BS314159> 그러면 addressbook이 userhosts.txt는 무시하되, 사용자가 자기 publichosts.txt를 구독하도록 할 수 있죠? 14:08 <jrandom> Teal`c: 도메인 이름을 하이재킹할 방법은 없어요, 어떤 항목도 덮어쓰지 않고, 항상 userhosts가 hosts보다 우선합니다 14:09 <jrandom> Ragnarok: 사용자들이 파일을 수동으로 추가하지 않을 테니, 웹 인터페이스로 잠금 이슈를 처리할 수도 있겠네요 14:09 <+Ragnarok> 잠금이 끝나면, 더는 userhosts.txt에서 주소를 끌어올 필요가 없어요(지금은 경쟁 상태를 피하는 유일한 방법이에요), 그래서 세 번째 파일을 추가할 실익이 별로 없죠 14:10 <+Ragnarok> jrandom: 음, 자바 파일 잠금 API를 쓸 계획이었어요 14:10 <jrandom> 필요하다고 보시면, 당신이 보스죠 :) 14:10 <ant> <BS314159> 그럼 다른 사람에게서 받은 이름은 다 지우면서, 내가 만든 건 유지할 수 있겠네요 14:10 <ant> <BS314159> hosts.txt를 비우고 구독을 바꾸기만 하면요 14:11 <ant> <BS314159> 하지만 그건 이름 서명(name-signing)까지 기다려도 되겠죠 14:11 <orion> metadata가 이 문제를 해결할 거예요. 스펙 초안은 나왔나요? 14:11 <jrandom> 두 파일만 쓰면 충분할 거예요 - 하나는 addressbook이 관리하고, 하나는 관리하지 않는 걸로 14:12 <jrandom> (addressbook이 userhosts.txt는 완전히 무시해도 돼요 - 어차피 userhosts.txt가 hosts.txt보다 우선이니까요) 14:12 <+Ragnarok> jrandom: 그게 계획이에요, 잠금만 끝나면요(그렇게 많은 작업은 아니고, 아직 손을 못 댔을 뿐 :) 14:13 <+Ragnarok> 그리고 지금 namerecords용 XML 스키마를 작성하려고 XML 스키마를 공부 중이에요 14:13 <ant> <dr_kavra> 여기 케노시스 채널 맞나요? 다른 채널에서 여기로 오라던데요 :D 14:13 <jrandom> ㅋㅋ 14:13 <jrandom> 아니요, 죄송, 여긴 i2p예요 14:14 <jrandom> (익명 통신 계층을 찾는 거라면 별개고요) 14:14 <jrandom> 멋져요, Ragnarok 14:14 <ant> <BS314159> 전 여전히 XML이 이 용도에 비해 너무 장황하고 사람이 읽기 어렵다고 봐요, YAML과 비교하면요, 하지만 전 코드를 쓰는 사람이 아니니까요 14:14 <jrandom> Ragnarok: XML에서 CDATA 없이 crypto를 하는 게 골칫거리겠죠 14:14 <orion> 누가 이름 metadata 스펙의 워킹 드래프트를 썼나요? 14:15 <jrandom> (개인적으로 XML은 별로라고 봅니다만, 전 그냥 트집꾼이죠) 14:15 <jrandom> orion: http://dev.i2p.net/pipermail/i2p/2004-February/000135.html 에 기본 구성이 있어요 14:15 <orion> (이름/키 메타데이터) 14:15 <dox> addressbook과 그 기능들은 어디엔가 공지됐나요? 제 hosts.txt가 게시되는 줄은 몰랐어요 14:15 <jrandom> (NameReference와 LocalEntry 요소를 보세요) 14:16 <jrandom> dox: addressbook/config.txt에 지정한 위치에 기록돼요 14:16 <jrandom> (기본값은 ./eepsite/docroot/hosts.txt) 14:17 <orion> 공개/비공개(배포한다/안 한다) 플래그가 빠졌네요. 14:17 <ant> <cervantes> XML의 유일한 장점(그리고 큰 + 포인트)이 있다면, 널리 받아들여지는 표준이라는 거죠 14:17 <jrandom> 맞아요, orion, 그 글 이후로 좋은 아이디어가 많이 나왔죠 14:17 <+Ragnarok> XML이 별로일 수 있지만, 솔직히 제가 하려는 일에는 대안들보다 낫습니다 14:17 <jrandom> cervantes: EDI도 그래요 14:17 <orion> 그걸 모아둘 곳이 있나요? 예: 포럼 섹션? 14:18 <orion> 아니면 위키 페이지? 14:18 <jrandom> orion: susi나 ugha의 위키요 14:18 <orion> bytemonsoon과 orion.i2p용 위키를 만들어서 각각의 향후 개발 목표에 대한 커뮤니티 합의를 돕겠습니다. 14:18 <BrockSamson> xml + crypto 에서 CDATA 없이 = mime, 아닌가요? 14:19 <jrandom> 멋져요, orion 14:19 <jrandom> BrockSamson: smime죠, 파서만 다를 뿐 ;) 14:19 <orion> (이름 메타데이터용 것도요) 14:21 <jrandom> metadata를 하는 방법은 많아요, 중요한 건 유연성과 '정확성'이라서 시간이 지나며 크거나 바뀔 수 있어야 한다는 거죠 14:21 * jrandom 은 Ragnarok 등이 좋은 걸 내놓을 거라 확신합니다 :) 14:21 <orion> 그래서 공개 초안이 필요하다고 봐요. 14:22 <ant> <cervantes> i2p 컨소시엄 :P 14:22 <jrandom> 글쎄요, 지난 몇 번의 회의에서 사람들이 "누가 위키에 자기 아이디어를 올려야 한다"고 말하곤 했는데, 위키 페이지가 크게 늘진 않네요 ;) 뭐 괜찮아요, 우린 우린 속도로 가죠 14:23 * orion 하루 안에 위키 세 개를 올리고 모두에게 위치를 이메일로 보내겠다고 약속 14:23 <BrockSamson> 날 게을렀다고 해도 좋아요, ANSI 850 구매 주문서 EDI랑 거의 모든 XML 기반 구매 주문서를 비교하면, 전 XML 버전을 디코드, 코딩, 디버그하겠어요. 크기가 EDI의 5배여도요 14:23 <jrandom> w00t 14:23 <jrandom> 헤헷 BrockSamson 14:24 <BrockSamson> 위치 10이 ST? 그럼 위치 310은 이름이어야죠 14:24 <BrockSamson> 에휴 나란 인간 14:24 <jrandom> BrockSamson: PO용 XML 스키마들도 그리 낫진 않을걸요 ;) 14:24 <jrandom> (그래도 그쪽은 정말 완전한 재앙이죠) 14:25 <BrockSamson> 새벽 4시 30분엔 XML이 더 낫죠 14:25 <BrockSamson> 아니면... 14:25 <jrandom> 헤헷 14:25 <BrockSamson> 전직 EDI 프로그래머가 쓴 거라면요 14:25 <BrockSamson> 그리고 XML이 이렇게 생겼죠: <p1><po><q>1</q></po></p1> 14:26 <BrockSamson> 근데 아마, 오픈소스 프로젝트들이 'XML' 할지 말지 얘기하는 데 쓰는 시간을 다 합치면 리눅스를 10번은 다시 코딩할 수 있을걸요. 14:26 <BrockSamson> 제가 참여했던 모든 프로젝트가 이걸로 대논쟁을 했어요 14:27 <orion> 논쟁은 프로젝트에 좋아요, 누가 논쟁하느냐에 따라. ;) 14:27 <jrandom> 에이, 제 할 일은 해요, 만능열쇠는 아니죠. 네이밍에는 잘 맞을 수도 있고요 14:28 <BrockSamson> 많은 사람들이 논쟁하려고 프로젝트에 들어오기도 하죠. 14:28 <jrandom> 여긴 아니에요. 전 공짜 맥주 때문에 왔어요 14:28 <ant> <cervantes> 그건 논쟁의 여지가 있죠 14:28 <orion> 초안 스펙이 좀 더 손에 잡히면 구현 세부사항도 더 명확해질 거예요. 14:28 <orion> 그래서 위키/피어 리뷰가 필요하죠. 14:29 <BrockSamson> 이 프로젝트에서 공짜 마늘을 준다고 들었는데요 14:29 <jrandom> 잔뜩요 14:30 <jrandom> 자, 회의에서 더 얘기할 분 있나요? 14:30 <ant> * cervantes 종 달린 의식용 소를 굴려 나온다 14:30 <ant> <cervantes> call =cow 14:30 * jrandom 시동을 건다 14:31 * jrandom 카우벨을 *뱁* 울리며 회의를 마친다