Cuộc họp các nhà phát triển I2P - 18 tháng 1 năm 2005

13:04 <jrandom> 0) chào 13:04 <jrandom> 1) Tình trạng mạng 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> (tiếng chuyện crypto bay vèo qua tai tôi) 13:04 <jrandom> :) 13:04 * jrandom vẫy tay 13:04 <cervantes> 'lo 13:04 <jrandom> bạn cũng có thể nghe tiếng chuyện crypto bay vèo qua tai mình! ghi chú tình trạng hàng tuần đăng @ http://dev.i2p.net/pipermail/i2p/2005-January/000559.html 13:05 <bla> chào 13:05 <jrandom> nhảy vào luôn nhé, vì dù sao ta cũng đang cắt ngang một cuộc thảo luận thú vị... 1) tình trạng mạng 13:05 <jrandom> tôi không có gì để bổ sung ngoài những gì trong mail - có ai muốn nêu điều gì liên quan đến (wrt) tình trạng mạng không? 13:06 <bla> Ngoài việc lần đầu tiên chúng ta thấy các nút (node) trên TẤT CẢ các châu lục trừ Nam Cực, thì không. 13:06 <jrandom> w00t! 13:07 <jrandom> ok, chuyển sang 2) chuyện 0.5 13:07 <mule> này, bố tôi đang trên đường tới Nam Cực, lẽ ra phải đưa ông ấy một node 13:07 <ant> <duck> bọn Nam Cực chết tiệt 13:07 <Xan> không có người Nam Cực à? :( 13:07 <jrandom> hah hay đấy 13:07 <jrandom> dù tôi không nghĩ trên đó có một anonymity set (tập ẩn danh) lớn lắm 13:07 <Frooze> đổ lỗi cho Nam Cực đi 13:08 * cervantes dựng một giàn khoan dầu ở Nam Cực để có tiền vận hành một node ở đó 13:09 <jrandom> được rồi, có khá nhiều thứ 0.5, nên ta chia nhỏ ra 13:09 <jrandom> trước hết, cảm ơn những người đã thu thập số liệu trong một ngày - rất nhiều dữ liệu thú vị @ http://dev.i2p.net/~jrandom/messageSizes/ 13:09 <postman> rất hân hạnh :) 13:10 <cervantes> liên quan đến tình trạng mạng... thấy khá nhiều người gặp khó khăn khi khởi chạy I2P gần đây (trên diễn đàn v.v.) - tôi không biết là do lượng người dùng tăng hay có nhiều ứng dụng dựa trên i2p hơn để phát sinh lỗi 13:10 <+protokol> jrandom: ĐỒ NÓI DỐI! anh nói dữ liệu thú vị mà! 13:10 * jrandom ném bùn vào protokol 13:11 <ant> <duck> cervantes: Tôi cũng thấy báo cáo có người khởi chạy và chạy được trong vài phút 13:11 <ant> <duck> Tôi nghĩ NAT gây ra phần lớn vấn đề 13:11 <cervantes> duck: đúng... 13:11 <ant> <dmdm> NAT là ai? 13:11 <jrandom> cervantes: chắc chắn vẫn còn vài vấn đề xấu xí. chuyện NAT và osx hơi đau đầu dạo này, nhưng Jhor đang giúp vụ sau sẽ cải thiện 13:12 <cervantes> aye 13:12 <cervantes> *hắng giọng* vậy... 0.5 13:13 <Xan> dmdm: network address translation (dịch địa chỉ mạng) 13:13 <jrandom> heh, ok. cơ bản thì việc thu thập số liệu kích thước thông điệp là để khảo sát vấn đề padding (đệm) 13:14 <jrandom> tiếc là chiến lược tôi dựng bằng cách nhặt số liệu chọn lọc khá tệ, tạo ra 25% overhead chỉ riêng dữ liệu padding 13:14 <jrandom> nếu ta chọn một trong các đề xuất cho mã hóa 0.5 (tunnels-alt.html), ta sẽ không gặp vấn đề đó 13:15 <jrandom> (vì nó sẽ buộc kích cỡ cố định nhỏ kèm phân mảnh) 13:15 <mule> anh muốn pad loại thông điệp nào, những gì một router thấy hay những gì một quan sát viên bên ngoài thấy? 13:15 <jrandom> mule: câu hỏi quan trọng 13:15 <jrandom> nếu ta chỉ lo quan sát viên bên ngoài, có thể để thông điệp không padding, tạo chaff ở tầng truyền tải 13:16 <Teal`c> http://microsoft.i2p/david_hasselhoff_05_christmas_album__silent_night.mp3 13:16 <jrandom> ngược lại, nếu lo người tham gia tunnel làm flow analysis (phân tích luồng), ta cần quan tâm đến padding trong tunnel 13:16 <@duck> với 5-6 hop, nguy cơ một router làm traffic analysis lớn đến mức nào? 13:16 <cervantes> Teal`c: đang họp nhé... dùng #i2p-chat để thông báo mp3 được chứ ;-) 13:17 <Teal`c> xin lỗi 13:17 <cervantes> :) vì david hasselhoff ư? 13:18 <jrandom> tùy mức độ phân tích đó duck. nếu họ bằng cách nào đó lần ra tunnel họ đang ở (ví dụ họ là inbound tunnel gateway và đã thu thập netDb, rồi tương quan với một đích), đó là dữ liệu không hề tầm thường. ngược lại nó không lộ trực tiếp, nhưng vẫn cho một số thông tin 13:18 <jrandom> thậm chí còn quan trọng hơn padding trong tunnel là padding end-to-end, che giấu dữ liệu luồng thông điệp khỏi gateway và endpoint. 13:19 <jrandom> nếu ta điên/ngu, ta có thể làm đến mức pipenet, dùng tốc độ bit không đổi ở mọi nơi 13:19 <+polecat> Tôi hiểu rồi! 13:19 <jrandom> (và rồi chẳng còn ai chạy i2p) 13:19 <+polecat> Điều ta cần làm là tunnel i2p qua email! 13:19 <cervantes> xác suất các router câu kết rơi vào cùng một tunnel trên một mạng đủ lớn là bao nhiêu? 13:19 <+polecat> Không ISP nào dại mà chặn email đâu! 13:20 * jrandom chờ bản triển khai net.i2p.router.transport.gmail 13:20 <postman> polecat: trời, ngớ ngẩn quá 13:20 <postman> :) 13:20 <bla> cervantes: N^(-h) (N là # nút nhanh, h = # hop). Có vẻ vậy 13:20 <+polecat> =3 tôi biết. 13:21 <cervantes> nghe có nhiều không? :) 13:21 <jrandom> không phải # nút nhanh, vì người ngoài sẽ không biết profiles của bạn 13:21 <+polecat> Nghiêm túc thì, lạm dụng các dịch vụ IP sẵn có, ta có thể tunnel i2p theo nhiều cách khéo léo. 13:21 <jrandom> c^2/N^h để đưa hai peer vào cùng một tunnel 13:21 <jrandom> đồng ý polecat. đó là một trong những lý do vì sao ta không có tunnel hai chiều (bidirectional) 13:22 <jrandom> một số transport (ví dụ email) rất tệ cho giao tiếp hai chiều 13:22 <bla> jrandom: c = ? 13:22 <jrandom> c==# peer câu kết 13:23 <+polecat> Hừm, điểm thú vị. 13:23 <ant> <duck> về lộ trình, nếu i2p đi sai hướng và chọn sai giải pháp crypto thì tác động là gì? 13:23 <+polecat> Hoặc giao thức bồ câu đưa thư, chẳng hai chiều chút nào. 13:23 <+polecat> crypto đã mô-đun rồi, đúng không? 13:23 <jrandom> duck: đó chỉ là một gạch đầu dòng trong 0.5, và một tiểu mục của tài liệu tunnels*.html. còn rất nhiều thứ trong định tuyến tunnel ngoài cách ta bọc dữ liệu 13:24 <bla> jrandom: Mặt khác, đó là bài toán để cho họ vào tunnel NGAY BÂY GIỜ. Tuy nhiên, qua T lần làm mới tunnel (mỗi vài phút), xác suất là P = 1 - (1 - c^2/N^h)^T 13:24 <jrandom> ngược lại, khác biệt giữa "khối cố định 1KB" và "khối 0-40KB" có tác động đáng kể 13:24 <+polecat> Tôi không muốn mạng này đi vào vết xe Entropy, mắc kẹt với McEliece. 13:24 <jrandom> polecat: đọc http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt.html?rev=HEAD 13:24 <bla> jrandom: Và do đó tiến dần về 0 khi thời gian đủ lớn. Tức là: khi thời gian đủ lớn, kẻ tấn công sẽ vào cùng một tunnel ít nhất một lần 13:25 <jrandom> kế hoạch là AES256/CBC chuẩn 13:25 <+protokol> tôi nghe DNS tốt cho việc tunneling, hầu hết mọi người không chặn nó 13:25 <jrandom> chắc chắn bla, dù không hoàn toàn trực tiếp như vậy (với exploratory tunnel thì đúng, nhưng không phải tunnel client) 13:26 <+polecat> Và nếu chẳng may ngay cả AES cũng bị bẻ, thì sẽ dùng một mã khối đối xứng tương đương. 13:27 <jrandom> bla: tôi không nghĩ nó là mối lo thực tế lớn đến mức đó trong đa số trường hợp, nhưng khi bạn triển khai nó như một phần của predecessor attack (tấn công tiền nhiệm), vấn đề chủ yếu trở nên vô nghĩa 13:28 <jrandom> (bởi cách chúng ta làm phần còn lại của định tuyến tunnel) 13:28 <bla> jrandom: k 13:28 <jrandom> đúng vậy polecat 13:29 <jrandom> duck: nếu ta chọn phương án thứ hai, đổi sang phương án khác sau này có lẽ sẽ dễ. 13:29 <jrandom> ngược lại, phương án hai sẽ đòi hỏi tối ưu hiệu năng nặng tay để Không Tệ 13:29 <jrandom> nhưng tôi chắc ta làm được 13:31 <jrandom> dù sao, tôi nghĩ phần trên bao quát nơi ta đang đứng với công việc 0.5 13:31 <jrandom> có ai còn câu hỏi/bình luận/quan ngại gì không? 13:31 <bla> jrandom: Một điều 13:32 <bla> jrandom: Tôi nghĩ trước mắt ta nên coi trọng ẩn danh hơn một chút so với hiệu năng: vậy nên, lựa chọn PRNG (bộ sinh số giả ngẫu nhiên) nghe ổn 13:33 <jrandom> đồng ý. hiệu năng có thể tinh chỉnh sau, còn "thêm" ẩn danh tốt hơn thì khó hơn nhiều 13:33 <jrandom> (nhưng, đương nhiên, hiệu năng CŨNG là tham số an ninh. nếu Tệ, chẳng ai dùng) 13:33 <bla> Đúng. 13:33 <bla> jrandom: 13:33 <bla> xin lỗi 13:33 <@duck> đúng rồi, /me lật cái bit phép màu Freenet-performance 13:33 <cervantes> có lẽ nó sẽ khiến đám leech cầm torrent phất phới tránh xa thêm chút ;-) 13:34 <jrandom> heh 13:34 <cervantes> <-- connection reset 13:34 <bla> cervantes: Không, tôi không! :) 13:34 <cervantes> :) 13:35 <jrandom> tôi nghĩ ta có thể làm vài tối ưu rất hay, và có vẻ phần nghẽn cổ chai của chúng ta không liên quan nhiều đến chọn peer, mà chỉ là (heh) bug trong jobqueue 13:36 <jrandom> nhưng, dù sao, còn gì cho 2) 0.5 không? 13:36 <ant> <BS314159> anh có thể đăng giải thích về loop attack này không? 13:37 <ant> <BS314159> nó nghe có vẻ nguy hiểm hơn cách anh xử lý ngụ ý 13:37 <jrandom> loop: dựng một tunnel gồm A-->B-->C-->D-->C, gửi vào 10 thông điệp. 13:37 <jrandom> nếu không có PRNG, bạn có thể thêm bao nhiêu thông điệp vào vòng C<-->D tùy thích 13:38 <ant> <BS314159> ok 13:38 <jrandom> thực chất là DoS (tấn công từ chối dịch vụ) bất kỳ router nào chỉ với vài thông điệp 13:38 <ant> <BS314159> nhưng chỉ A mới làm được điều này 13:38 <jrandom> với PRNG, nó giới hạn số thông điệp có thể đi vào vòng lặp 13:38 <ant> <BS314159> vậy không có nguy cơ kẻ tấn công rút ngắn tunnel của tôi bằng cách tạo vòng lặp 13:38 <jrandom> không, không ai có thể rút ngắn tunnel của bạn 13:39 <jrandom> thứ duy nhất việc này hữu dụng là để DoS 13:39 <jrandom> (một cú DoS rất rẻ) 13:39 <jrandom> (nhưng khi bạn có thể DoS có chọn lọc các peer với chi phí thấp, bạn có thể làm mấy trò RẤT bẩn) 13:40 <ant> <BS314159> hiểu rồi 13:40 <+protokol> và chứng chỉ hashcash sẽ giúp chuyện này? 13:40 <jrandom> protokol: hashcash giải quyết vấn đề một peer dựng quá nhiều tunnel, và có lẽ dựng quá nhiều hop 13:41 <jrandom> protokol: nó không giúp với vòng lặp. hai cách tôi tìm được CÓ hiệu quả là PRNG (tunnel-alt.html) hoặc xác minh ở mỗi bước (tunnel.html) 13:42 <jrandom> xác minh ở mỗi bước có nguy cơ riêng, nên xu hướng hiện tại là PRNG 13:42 <+Ragnarok> phương pháp prng sẽ hiệu quả đến đâu? 13:42 <Xan> A-->B-->C-->D-->C - mỗi hop không nên có một id khác hay gì đó, để thông điệp rời tunnel lần thứ hai chúng đến C thay vì lặp vòng? 13:43 <jrandom> Xan: có, nhưng nếu không xác minh từng bước, bạn không thể biết nó xấu hay không 13:44 <jrandom> Ragnarok: tôi nghĩ nó sẽ rất hiệu quả trong việc giảm thiểu thiệt hại 13:45 <jrandom> ít nhất, theo những gì tôi thấy đến giờ 13:45 <jrandom> nếu ai thấy vấn đề/trục trặc gì với nó, hoặc đề xuất cải thiện, xin liên hệ :) 13:46 <Xan> hoặc có thể tôi bỏ lỡ ý 13:46 <Xan> bbl 13:46 <jrandom> 'k l8r, tôi sẽ cập nhật tài liệu cho rõ hơn 13:47 <jrandom> ok, nếu không còn gì khác, ta chuyển sang 3) i2pmail.v2? 13:47 <jrandom> postman: anh quanh đây chứ? 13:48 <postman> có 13:49 <postman> :) 13:49 <jrandom> có gì bổ sung từ bài của anh trên diễn đàn không? nghe khá ngầu 13:49 <postman> ừ, một vài bạn có thể đã đọc bản nháp cho i2pmail.v2 rồi 13:50 <bla> chuyện quái gì đang xảy ra? Rớt kết nối hàng loạt. Tôi cũng gặp khó khi truy cập site (như orion, library) ở đây 13:50 <postman> nó hướng tới một hạ tầng thư hoàn toàn phi tập trung trong tương lai 13:50 <postman> nhưng cần phần mềm proxy trên các node cũng như một loạt relay chuyên dụng 13:51 <postman> mời mọi người đóng góp ý tưởng / khái niệm / càm ràm 13:51 <postman> phát triển đã bắt đầu - đừng mong có gì trước cuối mùa xuân :) 13:51 <jrandom> w00t 13:51 <kaji> hmm, cảnh sát vừa gõ cửa nhà tôi 13:52 <bla> kaji: ? 13:52 <jrandom> nhanh lên, xóa sạch ổ cứng đi 13:52 <postman> jrandom: à, giờ tôi chỉ có vậy thôi :) 13:52 <cervantes> giấu bàn blackjack đi! 13:52 <jrandom> tuyệt, cảm ơn postman 13:52 <kaji> họ nói tôi gọi 911, nhưng tôi khá chắc cả tôi lẫn em tôi đều không gọi 13:53 <+protokol> kaji: họ chỉ đang kiểm tra i2p thôi 13:53 <jrandom> ok, nếu không còn gì cho 3) i2pmail, ta chuyển sang 4) azneti2p_0.2 13:53 <+protokol> <nhạc rùng rợn> 13:53 <jrandom> như đã nói trong email, dạo này có vài tiến triển quan trọng 13:53 <kaji> rồi họ nói điện thoại không dây có thể dở chứng khi nhấc khỏi giá, nhưng tất cả điện thoại không dây của tôi đang trên sạc -> #i2p-chat 13:55 <jrandom> nhóm azureus đã phản hồi rất nhanh để chuẩn bị bản cập nhật (yay!), nhưng mọi người cũng nên chú ý đề phòng vấn đề 13:55 <jrandom> (nếu bạn không đọc mailing list i2p mà dùng azneti2p, hãy đọc mailing list i2p) 13:55 <jrandom> ((hoặc ngay cả khi yuo không dùng azneti2p, hãy đọc list, vì đó là nơi ta thông báo những việc quan trọng ;) 13:56 <jrandom> duck và orion cũng đang cập nhật rất nhiều để đáp ứng client bt mới và định dạng 13:56 <jrandom> (yay!) 13:56 * orion mỉm cười 13:57 <orion> vẫn còn một chặng đường, nhưng hiện tại, nó chạy được. 13:57 <jrandom> (trong phạm vi i2p cho phép ;) 13:58 <orion> hehe, đúng vậy. ;) 13:58 <jrandom> có ai muốn nêu gì liên quan đến (wrt) azneti2p hay i2p-bt không? 13:58 <jrandom> (hoặc bytemonsoon2p ;) 14:00 <jrandom> ok nếu không, ta chuyển thẳng sang 5) ??? 14:00 <jrandom> mở sàn - còn ai muốn nêu gì không? 14:00 <postman> jrandom: tại sao addressbook lại publich các entry userhosts? 14:01 <jrandom> postman: lỗi. 14:01 <postman> vậy đây không phải hành vi dự định và sẽ được thay đổi? 14:01 <cervantes> chỉ một điều... 14:01 <jrandom> postman: đúng, và sẽ được thay đổi 14:02 <jrandom> (đúng không Ragnarok? :) 14:02 <+Ragnarok> còn tùy chính xác postman muốn nói gì... 14:03 <jrandom> Ragnarok: các entry mới do người dùng nội bộ thêm vào hosts riêng của họ không nên bị propogated sang hosts được công bố 14:03 <jrandom> (ví dụ userhosts.txt là private, hosts.txt được đồng bộ với người khác và là public) 14:03 <cervantes> Là một phần mục gần như định kỳ trên diễn đàn, sẽ có ghi nhận và trao thưởng cho những ai đã đóng góp điều tốt cho I2P gần đây hoặc trong suốt vòng đời dự án 14:03 <postman> Ragnarok: sau khi cập nhật lên 0.4.2.6 tôi thấy entry từ userhosts.txt của mình trong addressbook được công bố trong thư mục eepsite của tôi 14:03 <ant> <BS314159> hmm 14:04 <postman> Ragnarok: đó là các khóa thêm thủ công, vốn không được định là sẽ công bố 14:04 <cervantes> tuần này chúng tôi ghi nhận duck vì sự xuất sắc nói chung với vai trò nhà cung cấp dịch vụ cho cộng đồng và là một tay idle tuyệt vời: http://forum.i2p/viewtopic.php?t=275 14:04 <jrandom> w00t! 14:04 <jrandom> (go duck go, go duck go) 14:05 <Teal`c> còn chiếm đoạt tên miền thì sao? 14:05 * brachtus vỗ tay 14:05 * orion lắc lư kiểu vịt để tỏ lòng tôn trọng. 14:05 <cervantes> một điểm quan trọng cho tương lai... bạn không cần là thiên tài mật mã để được khen ngợi! 14:06 <+Ragnarok> không, đó là hành vi mong đợi. Tôi có thể thay đổi, nhưng trước hết tôi phải hoàn tất triển khai file locking để bạn có thể sửa trực tiếp hosts.txt 14:06 <orion> (nhưng cũng có ích) 14:06 <cervantes> bạn có thể chỉ cần đóng góp một eepsite cực chất hay gì đó... 14:06 <cervantes> hoặc là một người hữu ích trên diễn đàn v.v. 14:07 <ant> <BS314159> hmm 14:07 <cervantes> (không thì, thú thật, tuần nào jrandom cũng thắng) 14:07 <jrandom> này, mọi người đang tài trợ quỹ bia của tôi đấy, mấy thứ này đâu có miễn phí ;) 14:07 <ant> <BS314159> anh chỉ cần tạo một file mới, "publichosts.txt"? 14:07 <ant> <BS314159> rồi cho addressbook bỏ qua userhosts.txt, nhưng cho phép người dùng subscribe chính publichosts.txt của họ? 14:08 <jrandom> Teal`c: không có cách nào cướp tên miền, không entry nào bị ghi đè, và userhosts luôn override hosts 14:09 <jrandom> Ragnarok: có lẽ giao diện web có thể xử lý vấn đề khóa, vì người dùng sẽ không thêm vào file thủ công 14:09 <+Ragnarok> khi khóa xong, không còn lý do để kéo địa chỉ từ userhosts.txt nữa (hiện tại đó là cách duy nhất để tránh race), nên cũng không có nhiều ý nghĩa khi thêm file thứ ba 14:10 <+Ragnarok> jrandom: ừ, tôi định dùng java file locking api 14:10 <jrandom> nếu anh thấy cần, anh là sếp :) 14:10 <ant> <BS314159> nó sẽ cho phép bạn xóa hết tên lấy từ người khác trong khi giữ lại những tên bạn tự tạo 14:10 <ant> <BS314159> chỉ bằng cách xóa hosts.txt và đổi subscription của bạn 14:11 <ant> <BS314159> nhưng tôi đoán cái đó chờ đến khi có name-signing 14:11 <orion> metadata sẽ giải quyết vấn đề này. Đã có bản đặc tả nháp nào chưa? 14:11 <jrandom> dùng chỉ hai file là ổn - một cái do addressbook quản lý, một cái thì không 14:12 <jrandom> (thậm chí bạn có thể cho addressbook bỏ qua hoàn toàn userhosts.txt - userhosts.txt luôn override hosts.txt mà) 14:12 <+Ragnarok> jrandom: đó sẽ là kế hoạch, sau khi làm xong khóa (thực ra không nhiều việc, tôi chỉ chưa đụng vào :) 14:13 <+Ragnarok> và tôi đang học đủ xml schema để viết một cái cho namerecord 14:13 <ant> <dr_kavra> đây có phải kênh của kenosis không? kênh khác bảo tôi đến đây :D 14:13 <jrandom> lol 14:13 <jrandom> không, xin lỗi, đây là i2p 14:14 <jrandom> (trừ khi bạn đang tìm một lớp liên lạc ẩn danh) 14:14 <jrandom> tuyệt Ragnarok 14:14 <ant> <BS314159> tôi vẫn cho rằng XML quá dài dòng và khó đọc với con người cho việc này, so với YAML, nhưng tôi đâu phải người viết code 14:14 <jrandom> Ragnarok: phần khó sẽ là làm crypto với XML mà không phải quay về CDATA xấu xí 14:14 <orion> có ai viết bản nháp làm việc cho đặc tả metadata chưa? 14:15 <jrandom> (cá nhân tôi thấy xml chán, nhưng tôi chỉ là kẻ phản đối) 14:15 <jrandom> orion: http://dev.i2p.net/pipermail/i2p/2004-February/000135.html có thiết lập cơ bản 14:15 <orion> (metadata tên/khóa) 14:15 <dox> addressbook và các tính năng của nó đã được công bố đâu đó chưa? Tôi không biết hosts.txt của tôi bị publish 14:15 <jrandom> (xem các phần tử NameReference và LocalEntry) 14:16 <jrandom> dox: nó được ghi vào vị trí xác định trong addressbook/config.txt 14:16 <jrandom> (mặc định, ./eepsite/docroot/hosts.txt) 14:17 <orion> thiếu một cờ public/private (tức là phân phối, hoặc không) 14:17 <ant> <cervantes> điều tốt duy nhất về XML (và đây là một điểm cộng lớn) là nó là tiêu chuẩn được chấp nhận rộng rãi 14:17 <jrandom> đúng orion, đã có nhiều ý tưởng hay nảy ra từ bài viết đó 14:17 <+Ragnarok> xml có thể dở, nhưng thẳng thắn mà nói, nó tốt hơn bất kỳ lựa chọn nào khác cho việc tôi đang làm 14:17 <jrandom> cervantes: EDI cũng vậy 14:17 <orion> có nơi nào gom lại chúng không? ví dụ khu vực diễn đàn? 14:18 <orion> hay một trang wiki? 14:18 <jrandom> orion: wiki của susi hoặc ugha 14:18 <orion> Tôi sẽ dựng các wiki cho bytemonsoon và orion.i2p để giúp đạt đồng thuận cộng đồng về mục tiêu phát triển tương lai của mỗi cái. 14:18 <BrockSamson> xml + crypto mà không CDATA = mime, đúng không? 14:19 <jrandom> tuyệt orion 14:19 <jrandom> BrockSamson: smime, với parser khác ;) 14:19 <orion> (cũng một cái cho metadata tên) 14:21 <jrandom> có nhiều cách để làm metadata, điều quan trọng là tính linh hoạt và 'đúng đắn' để nó có thể lớn lên hoặc thay đổi theo thời gian 14:21 * jrandom chắc Ragnarok và đồng đội sẽ nghĩ ra thứ hay :) 14:21 <orion> vì vậy tôi nghĩ cần một bản nháp công khai. 14:22 <ant> <cervantes> i2p consortium :P 14:22 <jrandom> à, mọi người đã nói "ai đó nên đưa ý tưởng của mình lên wiki" mấy buổi họp gần đây, nhưng trang wiki không lớn lên mấy ;) cũng không sao, cứ theo nhịp của mình 14:23 * orion hứa sẽ có ba wiki trong vòng một ngày và email mọi người địa chỉ của chúng 14:23 <BrockSamson> gọi tôi là lười cũng được, nhưng so một EDI ANSI 850 Đơn đặt hàng với gần như bất kỳ Đơn đặt hàng dạng XML nào khác, tôi vẫn thích decode, code, và debug phiên bản XML hơn. Dù nó có lớn gấp 5 lần EDI 14:23 <jrandom> w00t 14:23 <jrandom> heh BrockSamson 14:24 <BrockSamson> Vị trí 10 là ST? à vậy vị trí 310 phải là tên 14:24 <BrockSamson> ngờ nghệch thật 14:24 <jrandom> BrockSamson: đừng nghĩ xml schema cho PO tốt hơn nhiều đâu ;) 14:24 <jrandom> (nhưng ừ, mấy thứ đó đúng là thảm họa đẫm máu) 14:25 <BrockSamson> chúng ổn lúc 4:30 sáng 14:25 <BrockSamson> trừ khi... 14:25 <jrandom> heh 14:25 <BrockSamson> nó được viết bởi một lập trình viên EDI cũ 14:25 <BrockSamson> và xml trông như thế này: <p1><po><q>1</q></po></p1> 14:26 <BrockSamson> tôi cá là, nếu cộng số giờ các dự án OpenSource dành để tranh luận 'XML' hay không 'XML' bạn có thể code linux 10 lần rồi. 14:26 <BrockSamson> dự án nào tôi tham gia cũng có tranh luận lớn về nó 14:27 <orion> tranh luận tốt cho dự án, tùy vào ai tranh luận. ;) 14:27 <jrandom> ừ, nó làm được việc của nó, nhưng không phải thần dược. nó có thể hợp với phần đặt tên 14:28 <BrockSamson> nhiều người ở trong dự án chỉ để tranh luận thôi. 14:28 <jrandom> không ở đây. tôi ở đây vì bia miễn phí 14:28 <ant> <cervantes> điều đó còn phải tranh luận 14:28 <orion> chi tiết triển khai sẽ rõ hơn khi bản đặc tả nháp cụ thể hơn. 14:28 <orion> do đó cần wiki/peer review. 14:29 <BrockSamson> Tôi nghe nói dự án này phát tỏi miễn phí (Garlic) 14:29 <jrandom> rất nhiều 14:30 <jrandom> ok, còn ai muốn nêu gì cho buổi họp không? 14:30 <ant> * cervantes lăn ra cái chuông nghi thức 14:30 <ant> <cervantes> call =cow 14:30 * jrandom lên dây cót 14:31 * jrandom *baf* rung chuông bò, kết thúc buổi họp