(Wayback Machine 제공 http://www.archive.org/)
간단한 요약
참석자: eco\_, i2p, jrandom, mihi, Ophite1, polo, rsk
회의 로그
<jrandom> 0) 안녕 <jrandom> 1) router 상태 <jrandom> 2) i2ptunnel <jrandom> 3) IM <jrandom> 4) 0.3 계획 <jrandom> 5) 시간 동기화 <jrandom> 6) ??? <jrandom> mihi, polo 안녕 <polo> 안녕하세요! <mihi> 안녕 jrandom <jrandom> 0) 안녕 <jrandom> :) <rsk> hi <i2p> <duck> hi <jrandom> 1) router 상태 <jrandom> 0.2.3.3가 나왔고, 잘 동작하는 것 같아 <jrandom> 물론 할 일이 아직 많지만 <jrandom> 하지만 이게 0.2의 마지막 릴리스가 될 거야 <jrandom> 0.3에서는 peer profiling을 추가해서 router들이 나쁜 router를 피할 수 있게 할 거야 <jrandom> (그리고 0.3.1은 transports의 개편) <jrandom> hola Ophite1 <Ophite1> 헤이. <rsk> 그럼 0.3에서는 오버헤드가 더 생기는 거야? <jrandom> 그렇기도 하고 아니기도 해 <jrandom> peer 테스트가 들어가지만, 더 집중적으로 할 거야 <rsk> path selection에서 속도 향상을 볼 수 있을까? <jrandom> 응 <jrandom> 'liveliness' 계산기가 있고, 여기에 latency와 throughput 계산기도 새로 추가될 거야 <jrandom> 게다가 사람들이 특정 피어에 대해 자신의 선호도를 조정할 수 있게 될 거야 <jrandom> 예를 들어, peer Y보다 peer X를 선호하고 싶다면 임의의 포인트만큼 가중치 보너스를 줄 수 있게 될 거야 <mihi> 깨끗한 종료가 생길까? *g* <jrandom> 그거 사실 좋은 질문이야, mihi <jrandom> I2P가 이제 admin interface가 필요할 정도에 이르렀어. <jrandom> 동작을 가장 오래 지연시키는 Job은 GenerateStatusConsoleJob이야 <jrandom> 지금은 4~6초까지 걸릴 수 있어 <jrandom> (다른 모든 걸 잡아먹고) <jrandom> 그건 비동기화되고, 온디맨드로 바꿔야 해. <jrandom> 하지만 web listener 같은 건 쓰고 싶지 않아. <jrandom> 아마 반대로—router를 시작하고 통신하는 servlet <mihi> 완전한 웹 서버는 필요 없어. GET을 보면 데이터만 돌려줘. <jrandom> 맞아 <jrandom> 맞아, 그런 것들도 0.3에 들어가야 해. <mihi> 그리고 다른 걸 보면(SHUTDOWN 같은) 원하는 대로 하면 돼. 물론 localhost에서만 ;) <jrandom> 아이, 그러지 마 <mihi> 그럼 누군가 멋진 admin 프로그램을 만들 수 있지 <jrandom> 맞아 <mihi> 파일로 트리거하는 게 몇 개 있었지, 맞지? 어디 문서화되어 있어? >>> mihi [~mihi@ags9-d9ba536a.pool.mediaWays.net] requested PING 1072820995 from jrandom <jrandom> 그건 router 자체가 아니라 IDN에 있었어 <jrandom> 하지만 그 방법으로 가는 것도 좋을 듯 <jrandom> 그건 매우 쉬운 시스템이야 <jrandom> 좋은 생각이야, 그렇게 하자 <jrandom> (그리고 그 코드를 그냥 재사용하면 되지 :) <i2p> <duck> 이 마법 같은 파일 관련 물건이 plan9처럼 보이기 시작하네 <jrandom> ㅋㅋ <mihi> 하지만 파일 트리거는 폴링이 필요해 <jrandom> 맞아, mihi. 30초마다 디렉터리를 읽는 게 그렇게 나쁘진 않아 <mihi> 하지만 ServerSocket#accept가 더 저렴하지. <mihi> 시간을 거의 안 먹거든. (좋은 OS라는 전제에서) <mihi> 좋아, 파일 트리거라도 없는 것보단 낫지. <jrandom> server socket이면 원격 admin도 가능해져 <jrandom> (적절할 때) <jrandom> 글쎄. <jrandom> 고민해 볼 문제야. <jrandom> (아니면 누가 덥석 물고 코딩해도 좋고... :) <mihi> 그리고 server socket으로 routerConsole도 제공할 수 있어. <jrandom> 맞아 <jrandom> 좋아, 2) i2ptunnel <jrandom> :) <jrandom> i2ptunnel은 여전히 최고고, 이걸 제어할 socket 기반 API를 추가하고 싶어지는 상황이야 <i2p> <anon> aum의 ic2cp2pc 계획은 당분간 보류야? <jrandom> 응, ci2cp는 물 건너갔고, I2PTunnel을 제어하는 socket 기반 API로 대체됐어 <jrandom> 며칠 안에 그 API를 얹을 수 있을 것 같아서, 그가 구현 작업을 시작할 수 있을 거야 <mihi> 그냥 socket을 쓰고, in.readLine() 해서 그 라인을 runCommand()에 넘겨 ;) <rsk> 그 API가 I2P에 뭘 제공하는 건데? <jrandom> 거의 그렇지, mihi (결과를 포맷해서 표준적인 방식으로 돌려주는 것만 빼면) <mihi> 적절한 "logger"로 결과를 되돌려 보내고. <mihi> s/commands/results/ <jrandom> rsk> 애플리케이션 개발자가 I2CP의 암호화 요구 사항을 다루지 않고도 I2P 위에 클라이언트/서버 소켓을 만들 수 있게 해 <jrandom> 그래 그래 <jrandom> i2ptunnel은 i2ptunnel이 많을 때는 /확실히/ 오버헤드가 있어 <jrandom> JVM과는 상관없이 <jrandom> i2ptunnel 클라이언트는 접속하는 클라이언트마다 새로운 destination을 만들고, 로컬 destination의 수가 늘어날수록 router 성능이 훨씬 나빠져. <rsk> 아 <jrandom> 이건 네트워크의 익명성 요구와 우리의 암호화 방식이 맞물려 있기 때문이야 <jrandom> 피어에 tunnel 한두 개만 열고 싶은 애플리케이션에는 이 새 API가 정말 최고일 거야 <jrandom> 하지만 많은 다른 피어와 통신해야 하는 애플리케이션에는 I2CP가 정답이야. <jrandom> (그건 i2cp가 멀티플렉싱하는 단일 destination이니까) <jrandom> 어떤 면에선 옛날 TCP 대 UDP의 균형 같은 거지 <jrandom> mihi> 생각이나, i2ptunnel의 미래에 대한 아이디어가 있어? <rsk> IP-over-I2P나 VPN 관련 작업은 어떻게 돼가? <mihi> jrandom: 누군가 좋은 streaming API를 쓰고, i2ptunnel이 그걸 쓰게 하자. <mihi> naming server도 마찬가지. <mihi> 위 걸 아무도 안 하면 시퀀스 넘버라도 좀 추가하고. <mihi> 그건 비호환 변경이라는 뜻이지. <jrandom> 비호환 변경이 나쁜 건 아냐, 아직 개발 초기니까 <jrandom> (ID 크기도 한 쪽당 2바이트나 4바이트로 늘릴 수 있을까?) <mihi> 어쨌든 streaming API는 비호환 변경이 될 거야. 그리고 I2P가 잘 동작하면 시퀀스 넘버는 필요 없어. <jrandom> rsk> 누가 맡아서 진행할 시간이 생길 때까지 보류? ≡ rsk/#i2p는 비호환 변경이 가장 좋은 종류라고 생각함 <jrandom> 맞아, mihi <mihi> ID는 지금 3바이트여야 해, 그런데 왜 2바이트로 *늘려*? <jrandom> mihi> 사실 mode=GUARANTEED는 천천히 폐기하고 그건 streaming API에서 구현하고 싶어 ≡ mihi/#i2p도 동의 <jrandom> I2P는 IP로 남기고, TCP나 UDP가 아니게 <jrandom> 젠장, 하루에 14시간만 더 있었으면. <mihi> 고작 14시간? ;) <jrandom> ;) <jrandom> 3바이트 ID는 연결 양쪽에서 유도되는 거 아냐? 아니면 내가 헷갈리는 건가 <mihi> 각 쪽이 3바이트 ID를 가지지만, 한 번에 하나만 보내면 돼. <jrandom> 아마 내가 streaming API를 구현하고, GUARANTEED를 들어내고, 그 socket 컨트롤러를 다음에 추가할게. <jrandom> 아, 오케이 <mihi> 참고: /apps/i2p/i2ptunnel/java/src/protocol.txt <jrandom> 그래 그래 <mihi> 그나저나, 누가 그 파일을 *거기*에 잘못 둔 거야? ≡ jrandom은 eco 탓으로 돌림 ;) <jrandom> 잠깐, 아냐, 네가 거기 뒀잖아 <jrandom> 그렇지? <jrandom> 아 잠깐, 아니 내가 임포트했지 ≡ jrandom은 자기 멍청함을 탓함. <jrandom> (라라라) <jrandom> 젠장. 좋아, streaming API랑 socket 컨트롤러 작업을 하면 peer testing/profiling/selection 선언문을 곰곰이 생각해볼 수 있겠어 <jrandom> 며칠 내로 의견을 구하려고 올릴게 <jrandom> (그리고 머리를 router에서 좀 떼게 되지. variety++) <jrandom> mihi> i2ptunnel 관련해서 더 있어? <mihi> 내가 알기론 없어 <jrandom> 쿨 <jrandom> (이런 것들에 의견 보태주느라 시간 내줘서 고마워, fiw랑 다른 것들로 바쁜 거 알아) <jrandom> 좋아, thecrypto는 없지만 IM 앱은 진척이 있어. <jrandom> (그게 안건 3번) <jrandom> 4) 0.3 계획 <jrandom> 0.3.0 ~= peer profiling 관련 작업, 그리고 이제 i2ptunnel용 streaming API와 그 socket 컨트롤러도 포함될 거야 <jrandom> 하지만, 예상했겠지만 1월 1일에는 릴리스되지 않아 <jrandom> 1월 15일은 최대한 잡아본 가능성이야. 지켜보자. <jrandom> 0.3.1은 한 달 치 작업은 아니라서, 미뤄지지 않을 수도 있어. <jrandom> 그 밖에는, 로드맵은 여전히 궤도에 있고 우리가 가는 방향을 잘 보여줘 <jrandom> 5) 시간 동기화 <jrandom> 새 FAQ가 http://wiki.invisiblenet.net/iip-wiki?I2PTiming 에 올라갔어 <jrandom> mihi, 거기 네 번째 옵션(우리만의 in-I2P 타이밍 구축)에 대해 제안이 있었지? <jrandom> 안녕 brawl <mihi> 응. ∙φ∙ brawl is now known as eco_ <eco_> 안녕 여러분 <jrandom> 오, 안녕 eco <mihi> 방금 streaming API / tunnel API를 논의했어 <mihi> 그리고 그걸 보정하는 네만의 getTimeMillis를 해킹해 만들어. <Ophite1> mihi: 아니, 그러면 안 돼. <jrandom> mihi> 그럼 공격자가 시간이 틀린 노드 1000개를 만들면 모두 망가지는 거잖아 <jrandom> (평균이 중간 어딘가로 랜덤하게 쏠릴 테니까) <mihi> 공격자가 1000개 노드를 만든다면 어차피 모두 망가지는 거 아닌가...? <rsk> 그게 스스로 보정되지 않을까? <Ophite1> mihi: 좋아, 3. <jrandom> 아니, 우리는 그걸 처리할 수 있어야 해, mihi. <mihi> 좋아, 그럼 표준편차가 1초 이하 정도일 때만 평균을 쓰자. <rsk> 모두 시간이 같으면, 그 시간이 틀려도 괜찮은 거지, 맞지? <jrandom> rsk> 1000개 노드가 동기라면 그런데, 전부 랜덤이면 어떡해 <mihi> 서로 충분히 가까운 시간만 사용해. 아니면 새 노드 3개를 가져와. <jrandom> mihi> 맞아, NTP를 구현할 수도 있어(기본적으로 네 말처럼 일련의 후보 평균을 사용해 반복적으로 올바른 시간에 수렴해 <mihi> 하지만 NTP처럼 모든 것(예: 핑 지연)에 신경 쓸 필요는 없어. <Ophite1> 그걸 안 하면, mihi, 시간이 서서히 뒤로 밀릴 거야. ≡ mihi/#i2p는 그게 사용자에게 각자 시간을 맞추게 하는 것보단 낫다고 생각함. <jrandom> 그럼 그 틀어진 노드 중 임의로 3개를 고른 사람은 자기만의 프라이빗 네트워크로 보내지는 거야? <jrandom> 세 번째 옵션은 어때 - <jrandom> I2P에 NTP 또는 SNTP로 실제 NTP 서버를 조회하는 컴포넌트를 두는 거야 <mihi> 네 netDB에 틀어진 노드만 있다면, 너도 그 프라이빗 넷에 있는 거지... <jrandom> 바퀴를 재발명하기보다는 <Ophite1> 그게 부분적으로는 마음에 들지만... <Ophite1> NTP는 서명되지 않아서 MITM 공격에 취약해. <Ophite1> 또는 예를 들어 time.nist.gov에 대한 DNS 캐시 오염 <jrandom> 맞아, Ophite1. 그래도 SNTP나 NTP 호스트가 20만 개 이상이라 공격 대상으로는 굉장히 큰 집합이야. <jrandom> 우리는 절대 time.nist.gov로 동기화하진 않을 거야. <Ophite1> I2P에서 NSA의 타임 서버로 연결되면 눈살이 좀 찌푸려지겠지, 그치? :) <jrandom> 그리고 누가 time.nist.gov를 공격하면 어디서나 모두가 영향을 받아 <jrandom> 헐 <mihi> 그럼 둘을 결합하자. '진짜' NTP 서버와 네 이웃에게 물어봐. 둘이 같다고 하면 괜찮아. <jrandom> 그러면 코드가 /더/ 늘지 ;) <jrandom> 하지만 그래, 합리적이야. <Ophite1> 재밌네. 만약 같지 않으면? <Ophite1> 다른 NTP 서버를 고를까? <jrandom> 그 피어는 거부. <mihi> 다른 NTP 서버와 다른 피어로 다시 시도. <mihi> 일치할 때까지. 그다음 이전 피어는 다 거부. ≡ mihi/#i2p는 jrandom보다 타이핑이 느림 :( <Ophite1> 특정 임계값 내에서 일치, 예를 들어 1초? <jrandom> 1초가 좋겠어. <jrandom> 지연을 감안해 피어는 최대 30초 정도까지 허용 <Ophite1> 매우 부하가 큰 연결에서 1초가 괜찮을까? <jrandom> 동기화엔 1초, 통신엔 30초. <Ophite1> DSL에 못된 짓을 하면 지연이 5초까지 가는 걸 본 적 있어. <jrandom> TCP로? UDP로? <Ophite1> 하지만 그런 경우라면, 어차피 그 호스트는 시간 동기화 대상으로 적합하지 않겠지 ;) <jrandom> 맞아 <Ophite1> UDP. <jrandom> 흠, 오케이 <Ophite1> 패킷이 드롭될 거라고 생각했겠지 :) <i2p> <duck> 문제는 문제 있다는 걸 사용자에게 알려주는 쪽에 더 가깝다고 봐 <jrandom> duck> 맞아. <i2p> <duck> 큰 로그를 뒤져본 다음에야 (찾는다면) 자기 시계가 틀렸다는 걸 알지 <Ophite1> 아마. 뭐 그런 셈. <i2p> <duck> 아니면 포트가 이미 바인딩돼 있다든가 <jrandom> admin interface가 있으면 좋겠어. <i2p> <duck> 세상은 모두가 로컬 stantrum (sp) 2 서버에 연결된 NTP를 쓰면 더 나아짐 CTCP Cloaking is now [On] <jrandom> 아마 1.0 가기 전에 정리와 엔드유저용 개선을 묶은 0.4 릴리스를 낼 수도? <jrandom> 맞아 (stratum) <i2p> <duck> 윈도 클라이언트만 그게 없을 가능성이 높아 <i2p> <duck> 하지만 그들도 안정적일 가능성은 낮지 <jrandom> Windows에도 NTP가 있어 <i2p> <duck> 그러면 누가 신경 써 <Ophite1> duck: Windows XP와 Windows Server 2003에는 NTP가 들어 있어. <jrandom> 유닉스보다 훨씬 더 쉽게 <Ophite1> 기본적으로 time.windows.com에 동기화되도록 되어 있지, 내 기억으론. <jrandom> 다른 것들에 대한 드롭다운 옵션도 있고 <Ophite1> 그건 Windows 제품 활성화의 필수 요소야. <Ophite1> 시간을 모르면 만료시킬 수 없지 :) <jrandom> ㅎㅎ <mihi> 내 대학에선 선택지가 없어... 모든 시계가 1시간에서 5시간까지 틀려. 어차피 거기서 I2P를 돌리는 게 허용되지도 않을지 모르고... <Ophite1> mihi: I2P는 그런 상황에서도 특별히 잘 동작하려고 노력해야 해... <jrandom> mihi> 굉장해! 숨김 동작을 테스트하는 데 도움을 줄 수 있겠네 :) <jrandom> 여담이지만, 올여름에 좀 여행을 다닐 거야 <jrandom> 노트북 없이, 아마 오프라인일 듯. <i2p> <duck> 곁다리 생각: ntp.duck.i2p :) <Ophite1> 이렇게 생각해 보자: Brianna Kazaa가 그녀의 절친이 정말 멋지고 사람들과 비밀스럽게 채팅도 할 수 있다고 알려준 새 익명 파일공유 클라이언트를 내려받았어. 우리가 그녀에게 시계를 30초 이내로 맞추라고 말하고 싶을까(어떻게 맞추라고?)? 아니면 그냥 작동하게 하고 싶을까? <jrandom> 하지만 공용 터미널만으로도 I2P에 접속할 수 있도록 해둘 거야. CTCP Cloaking is now [Off] <jrandom> 생각할 것도 없어, Ophite1. 그냥 동작해야지(덕후들을 위한 문서는 따로 하고) <jrandom> duck> bootstrap ;) <jrandom> 그리고 I2P는 root를 /요구하지 않을/ 거야. <Ophite1> 그게 내 요점이야. <Ophite1> jrandom: root 권한이 없는 박스에서 router를 돌릴 거야? <jrandom> 그러니, 옵션 3과 4의 혼합이겠지 <Ophite1> 옵션 3.5, 내겐 멋지게 들리네 ;) <jrandom> Ophite1> 나는 백 대라도 돌릴 거야 :) <mihi> 옵션 3.1415926... <jrandom> (그리고 다음 연구실로 가서 백 대 더 돌리고) <Ophite1> 오. 파이. 맛있겠다;) <Ophite1> jrandom: root가 없다고 했잖아. 아마추어. :) <jrandom> ㅋㅋ <jrandom> 대체로 우리가 보고 있는 방향이 그래. <jrandom> 시간 관련 기능이 구현되기 전까지는 모두 옵션 1이나 2를 써야 해. <jrandom> 옵션 2에 대해서 누가 문서 좀 써주면 고맙겠어 <Ophite1> 지금은 괜찮아, 아직 Brianna Kazaa 같은 사람들을 맞이할 준비가 안 됐으니까 ;) <mihi> 참고로: 나는 '숨김 동작'은 테스트하지 않을게. 내 대학 계정이 이미 한 번 정지된 적이 있고 또 막히고 싶진 않아... <Ophite1> mihi: 너만큼 좋은 테스트 케이스는 없어. <jrandom> Ophite1 > 테스트용으론 안 돼. <jrandom> 'k mihi, 방법을 찾을게, 준비되면 네가 쓸 수 있을 거야. <Ophite1> 그래, 테스트는 아닐 수도. 어떤 대학은 막는 걸 넘어서 내쫓을 정도로 까다로우니까. <Ophite1> 미국에서 가장 반-파일공유, 친-RIAA인 대학에 다니는 사람을 알아. 걔는 2Gbit 덤프사이트를 운영해. <jrandom> ㅋㅋ 좋네 <Ophite1> 이렇게 대담한 사람은 극히 드물다는 거 잘 알아. <jrandom> 좋아, 시간 동기화는 여기까지. <jrandom> eco_> 안녕. BT 관련해서 얘기할 거 있어? {아니면 다음 주까지 미룰까} <Ophite1> 하지만 인터넷의 대다수는 장차 대학/기업 네트워크가 될 가능성이 크다는 점을 명심해. I2P는 금지될 수도 있어. I2P를 주요 ISP가 남용으로 간주할 수도 있어. I2P는 어떻게든 동작해야 해. <Ophite1> 그 방향으로 흥미로운 아이디어가 몇 개 있는데, 나중에 발표할게. <jrandom> ㄹㅇ <Ophite1> (transport) <rsk> 주요 ISP는 I2P를 남용으로 본다, 너희 계약서 읽어봐 <Ophite1> rsk: 분산 프록시 캐시를 돌리는 건? <rsk> '서버'를 뭐든 돌리는 것 <Ophite1> rsk: SMTP나 WWW로 릴레이하지 않는 한은 아냐. <jrandom> 어떤 종류의 서비스든 돌리는 것 <jrandom> 맞아 <Ophite1> rsk: 헤헤, 그거 해결책이 있어 ;) <eco_> jrandom: 간단한 업데이트를 줄 수 있어 <jrandom> 마음껏 말해 :) <eco_> I2P에 익숙해지려고 자바 기반 BitTorrent 클라이언트인 snark (www.klomp.org/snark)를 포팅하고 있어 <eco_> 첫 포트는 i2ptunnel 위에서 동작하고, 자바 클래스를 직접 호출해 <eco_> 현재 상태: 피어 2개에서는 동작하지만, 2개 초과에선 엉망이 되고, tunnel이 정리되지 않아서 재시작이 고통스러워 <eco_> 예상 완료: 이번 주말 ≡ eco_/#i2p는 이게 2003년을 넘어선 걸로 간주될 수 있음을 깨달음 <jrandom> w00t! ≡ jrandom이 time.nist.gov를 해킹함 <eco_> ‘진짜’ 포트라면 아마 tunnel 오버헤드를 줄일 수 있겠지만, 그건 다음 단계야 <jrandom> 좋아 ≡ eco_/#i2p가 마이크를 mc jrandom에게 돌려줌 <jrandom> 'k, 그게 전부였던 것 같아 <jrandom> 6) ??? <jrandom> 다른 거 있어? ≡ eco_/#i2p는 지금까지 훌륭한 일을 해온 jrandom 씨에게 감사의 뜻을 전하고 싶어 함 <eco_> 그리고 수면은 호모 사피엔스에게 어느 정도 쓸모가 있는데, jrandom은 그게 거짓임을 증명하는 듯 <jrandom> ;) <jrandom> I2P가 충분히 안정될 때까지, iip 대신 여기서 회의하는 것에 대해 어떻게 생각해? <jrandom> 개인적으로, 매주 회의가 엉망이 되는 게 지겨워. <i2p> <anon> lilo 구려! <eco_> 여기로 오면 사람들을 배제하는 꼴이 될 수도 있어 <jrandom> 그렇지, 알아. <jrandom> iip<-->여기 브리지를 만들 수 있다면 <i2p> <duck> IIP는 매일 사람들을 배제하고 있어 <jrandom> 좋지. <jrandom> 맞아. <jrandom> 불행히도 iip는 신뢰할 수 있는 개발 커뮤니티에 쓰기 어렵다. <i2p> <duck> http://banaan.zeelandnet.nl/open/changate.html <i2p> <duck> 그게 eyeKon 등이 기반으로 하는 코드야 <jrandom> 그리고 혼자 코딩하는 걸 좋아하지만, 여러분은 정말 좋은 아이디어를 내고 필수적인 일을 잘해 ≡ rsk/#i2p는 Windows 업데이트 스크립트를 작성 중 <i2p> <duck> 이론적으로는 3개 서버에 연결해 각각을 미러링할 수 있어 <jrandom> ㅇㅇ duck, i2p.dnsalias.net에서 하나 돌려보려고 해 <jrandom> 지옥에서 온 핑 플러드 ;) <eco_> duck.i2p의 IRC가 오늘 꽤 좋았어, iip를 이겼지 <jrandom> 동의 <jrandom> 근데 몇 번은 끊겼어. <jrandom> 아마 다음 주에는 더 신뢰할 수 있을 거야 <eco_> 네 손에 달렸지 :-) <jrandom> 신뢰성은 아마 0.3이 나오기 전에는 안 좋아질 거야, 대략 2주 남았어 <jrandom> (tunnel/streaming 작업에 1주, peer profiling/테스트에 1주) <jrandom> 그러고 나면 그걸로 생기는 온갖 버그들이 있겠지 :) <jrandom> 어젯밤 aum에서 오디오 스트리밍을 해서 정말 신났어 <jrandom> 그리고 ardvark는 버퍼링 없이 42분 동안 스트리밍할 수 있었어! <jrandom> 그래서 아마 충분히 신뢰할 수 있을지도 <jrandom> (내 로컬 router는 phttp 전용이라, 아마 그것도 약간의 원인일 거야) <jrandom> 좋아, 다른 거 있어? <i2p> <duck> 아무것도 생각나지 않네 ≡ eco_/#i2p도 없어 ≡ jrandom 마무리하고... ≡ jrandom *baf* 회의를 종료함