Cuộc họp của các nhà phát triển I2P - ngày 04 tháng 3 năm 2016

15:00:05 <zzz> 0) chào 15:00:23 <zzz> 1) cấu trúc cho các buổi họp này 15:00:32 <zzz> 2) thảo luận lộ trình 15:00:37 <zzz> 0) chào 15:00:41 <zzz> chào 15:00:54 <str4d> chào 15:01:02 <xcps_> chào! 15:01:27 <orignal_> có gì mới? 15:02:18 <zzz> vui lòng xem chủ đề tại http://zzz.i2p/topics/2021 và lộ trình hiện tại tại http://i2p-projekt.i2p/en/get-involved/roadmap 15:02:27 <zzz> 1) cấu trúc cho các buổi họp này 15:03:22 <zzz> chúng ta nên đi thẳng vào lộ trình hay trước tiên nói về các ưu tiên cấp cao? 15:03:53 <str4d> Tôi nghiêng về phương án thứ hai trước 15:04:41 <zzz> ok, trong chủ đề đó, tôi nêu ra hai ưu tiên - phát triển mạng lưới và tăng cường bảo mật 15:04:55 <zzz> hai nguyên tắc cấp cao đó nghe ổn chứ? 15:05:25 <zzz> trước hết hãy quyết định điều gì quan trọng 15:05:32 <EinMByte> Nghe đúng như kỳ vọng, tôi nghĩ vậy 15:05:48 <EinMByte> "phát triển mạng lưới" nên được hiểu theo nghĩa rộng, dù vậy 15:05:57 <str4d> Tôi nghĩ đó là những chủ đề bao quát rất tốt 15:06:03 <zzz> anonimal đã nêu thêm cả đống thứ trong chủ đề, nhưng đó không thật sự là điều tôi nhắm tới 15:06:13 <xcps_> tăng cường bảo mật luôn nên là quan trọng nhất theo tôi 15:06:28 <zzz> còn nguyên tắc nào khác chúng ta nên cân nhắc khi xem lại lộ trình không? 15:06:28 <str4d> Theo tôi điều chúng ta cần làm ở đây là xác định những điều đó thực sự có nghĩa gì về các đầu mục có thể bàn giao 15:06:40 <EinMByte> Vậy "phát triển mạng lưới" cũng nên bao hàm "tăng sự chú ý của giới nghiên cứu" 15:07:00 <zzz> "phát triển mạng lưới" nghĩa là rất nhiều thứ - xem chủ đề 15:07:09 <str4d> EinMByte, ừ, tôi nghĩ tôi đã nhắc đến trong chủ đề 15:07:36 <zzz> chúng ta sẽ sớm làm rõ ý nghĩa của những điều này. Lúc này hãy thống nhất điều gì quan trọng. 15:07:58 <str4d> Tính dễ dùng rất quan trọng với tôi, và theo tôi nó góp vào cả hai mảng trên 15:07:58 <zzz> mọi thứ đều khả thi nếu chúng ta tiếp tục phát triển. một khi ngừng phát triển là coi như chết 15:08:05 <zzz> đồng ý, str4d 15:08:41 <str4d> Trước mắt là tăng số lượng người dùng, còn dài hạn là tăng mức độ xuất hiện công khai, dễ dùng hơn cho giới nghiên cứu, v.v. 15:09:11 <EinMByte> Cũng lưu ý rằng phát triển là cách duy nhất để thu hút các nhà nghiên cứu 15:09:25 <zzz> nhiều người dùng hơn mang lại nhiều dev hơn, nhiều nhà nghiên cứu hơn, nhiều nội dung hơn, và vv 15:09:37 <EinMByte> Các mạng lớn thường thú vị hơn để nghiên cứu 15:10:05 <EinMByte> Vậy tôi nghĩ tất cả chúng ta đều có thể đồng ý về 2 ưu tiên đó 15:10:16 <zzz> phần lớn tăng trưởng của chúng ta năm qua đến từ vuze. Điều đó rất tốt nhưng tôi cũng muốn có thêm tăng trưởng 'bản địa' 15:10:43 <zzz> nhưng có lẽ tăng trưởng trong các ứng dụng nhúng, hoặc tập trung vào ứng dụng nói chung, là con đường dễ nhất để phát triển 15:10:48 <str4d> Ừ 15:11:04 <EinMByte> zzz: Với nhiều người, dễ hơn là dùng một ứng dụng chạy I2P ở nền và tự xử lý cấu hình cho họ 15:11:12 <sadie> chào - đến bữa tiệc hơi muộn 15:11:20 <zzz> chào sadie, mừng là bạn đến được 15:11:23 <str4d> Theo tôi, điều đó sẽ đến từ việc cải thiện khả năng sử dụng cho cả UI và API 15:11:42 <str4d> Vế sau thì chúng ta đã làm trong nhiều chủ đề rồi 15:11:48 <zzz> ở một số khía cạnh, chính các ứng dụng mới là chuyên gia UI, hãy để họ bundle i2p và hiển thị (hoặc ẩn) nó theo cách họ thấy tốt nhất 15:11:58 <str4d> Ừm 15:12:08 <EinMByte> str4d: Đúng, đó là một cách khác cho cùng vấn đề. Và tôi thích hơn vì bundle I2P với mọi thứ thì không mở rộng tốt theo tôi 15:12:30 <str4d> Đó đại khái là cách tôi đang làm với Android 15:13:04 <EinMByte> Cần có cách đảm bảo mọi người không chạy một instance I2P cho mỗi ứng dụng 15:13:12 <zzz> ok, còn gì về mục 1) không hay chúng ta chuyển sang xem chính lộ trình? 15:14:00 <str4d> Tôi nghĩ mọi người ở đây có vẻ đồng thuận sơ bộ 15:14:08 <str4d> (ít nhất thì không ai phản đối :P) 15:14:14 <zzz> để tôi chép vào vài dòng từ chủ đề. Không phải kinh thánh, chỉ để tham khảo 15:14:25 <zzz> Phát triển Mạng lưới 15:14:25 <zzz> Bao gồm: Marketing, dự án hợp tác, bundle nhiều thứ hơn, giúp người khác bundle i2p, khả năng sử dụng, cải tiến website, thêm bản dịch, bài nói và thuyết trình, bài viết và câu chuyện, UI, Android, ứng dụng Android, né GFW tốt hơn, orchid, thêm thư viện và công cụ cho dev phía client, hỗ trợ tốt hơn cho các website cực lớn, hỗ trợ phát triển router thay thế, liên minh, tăng tốc và hiệu suất, năng lực, tăng các giới hạn, đưa vào 15:14:25 <zzz> Debian, ... 15:14:25 <zzz> Tăng cường bảo mật 15:14:25 <zzz> Bao gồm: chuyển đổi crypto, giao thức subscription, giao thức truyền tải mới, pluggable transports, LS2, NTCP2, DH mới, thu hồi khóa, lưu trữ khóa, rà soát mã, Sybil, sửa lỗi, hệ thống đặt tên, SSL, ... 15:14:46 <zzz> ok, chuyển sang 2) chính lộ trình 15:15:10 <zzz> url là http://i2p-projekt.i2p/en/get-involved/roadmap 15:15:50 <zzz> .25 gần như xong, phát hành khoảng 10 ngày nữa, vậy hãy xem 4 bản phát hành tiếp theo 26-29 cho năm nay 15:16:00 <zzz> mà sẽ đưa chúng ta tới ccc 15:16:15 <EinMByte> Nếu một việc nằm dưới 2017, ví dụ, có nghĩa là chúng ta chỉ bắt đầu xem xét lúc đó, hay là bắt đầu triển khai vào thời điểm đó? 15:16:41 <str4d> Về các việc chúng ta cần làm, tôi xếp di chuyển crypto và công việc về Sybil lên hàng đầu 15:16:42 <zzz> 1mb, chắc chắn chúng ta muốn bắt đầu các hạng mục lớn của 2017 ngay bây giờ, như crypto/dh mới, ntcp2, v.v. 15:17:04 <EinMByte> Ngoài ra, tấn công eclipse là vấn đề ngay lúc này, theo tôi 15:17:05 <zzz> vì vậy lộ trình có thể bao gồm công việc chuẩn bị cho những thứ đó 15:17:23 <str4d> EinMByte, ừ, tôi gộp cái đó vào Sybil 15:17:36 <EinMByte> Ý tưởng rotation lúc nửa đêm hoàn toàn không hiệu quả và nên có các phương án tốt hơn, tôi đoán vậy 15:17:52 <zzz> đồng ý 15:18:05 <EinMByte> str4d: Chắc rồi, phân loại chúng là cùng loại tấn công cũng hợp lý 15:18:44 <str4d> EinMByte, tôi đã bàn chuyện này với vài người tại RWC 15:18:48 <str4d> Có vài ý tưởng, nhưng khó bàn ở đây 15:18:51 <EinMByte> zzz: Vậy nếu muốn bắt đầu NTCP2/... trước 2017 chúng ta sẽ cần lên kế hoạch công việc sơ bộ 15:18:58 <zzz> đúng rồi 1mb 15:19:02 <str4d> Ừ 15:19:20 <str4d> Tôi muốn có cả lên kế hoạch và nghiên cứu trong lộ trình :) 15:19:28 <zzz> vấn đề là thế này. Tôi đáng lẽ phải làm 26 ngay bây giờ mà tôi chưa biết trong đó có gì 15:19:39 <orignal_> có thể thêm padding ngẫu nhiên vào NTCP hiện có không? 15:20:01 <str4d> orignal_, tôi không nhớ là được, nhưng hãy xem chủ đề NTCP2 15:20:02 <zzz> vậy hãy dành 10 phút lập kế hoạch cho 26, rồi chúng ta chuyển sang dài hạn 15:20:13 <str4d> ok 15:20:14 <zzz> nói tôi biết hôm nay tôi nên làm gì 15:20:30 <EinMByte> Đúng, hãy tập trung vào việc đó trước 15:20:34 <zzz> ok hãy xem những gì trong danh sách 25 mà chưa làm 15:20:50 <zzz> wrapper chưa làm, kytv thì vắng mặt (awol) 15:20:54 <EinMByte> "cải tiến crypto" khá rộng 15:21:12 <zzz> thực tế "cải tiến crypto" là một vài tăng tốc cho 25519 15:21:34 <zzz> vì vậy danh sách .25 thực ra đều có trong đó, trừ wrapper 15:22:00 <zzz> nhưng còn nhiều việc về Sybil nên hãy giữ nó trong danh sách 26 15:22:08 <str4d> Tốt 15:22:25 <str4d> Chúng ta đã dời GMP 6 sang .26 vì cần thêm kiểm thử 15:22:35 <zzz> còn gì trong danh sách 26 bây giờ nên giữ lại hay chuyển đi 15:23:05 <EinMByte> Cuối cùng việc ngăn chặn Sybil có lẽ sẽ rất nhiều việc, nên với tôi đó là dài hạn 15:23:10 <EinMByte> (theo nghĩa là trước hết cần một tổng hợp tài liệu nghiên cứu tốt) 15:23:15 <zzz> orignal, đúng, ntcp có padding thì là ntcp2 15:23:21 <str4d> EinMByte, công cụ phát hiện Sybil vẫn chưa được dùng cho việc gì, đó là chỗ cần lập kế hoạch thêm :) 15:23:49 <zzz> hottuna4 bận khoảng một tháng, không chắc khi nào hết, nên gmp6 có thể vào 26 hoặc không 15:24:02 <str4d> Ok 15:24:37 <str4d> Cải tiến giao thức subscription cho addressbook: đó là thứ rất nên bổ sung càng sớm càng tốt, để chủ các Dest cũ có thể chuyển sang Ed25519 15:24:37 <EinMByte> Tôi nghĩ CRL không thật sự cần dấu hỏi 15:24:47 <str4d> Nhưng thực tế sẽ mất bao lâu để làm việc đó? 15:25:14 <zzz> chúng ta sẽ cần cập nhật trạng thái từ tuna sớm, tôi đoán hạn chót để chống lưng (propping) các thứ lớn cho 26 sẽ là cuối tháng ba / tuần đầu tháng tư 15:26:10 * str4d vẫn chưa hiểu rõ chuyện CRL, zzz có thể giải thích thêm không? 15:26:14 <zzz> 25 sẽ có khả năng đọc crl từ đĩa, nên ta có thể đưa vào bản cập nhật 15:26:35 <zzz> nhưng thế không hữu ích lắm vì trong một bản cập nhật ta chỉ cần xóa cert là cũng có tác dụng tương tự 15:26:56 <zzz> vậy để gửi crl tới mọi người mà không cần phát hành bản cập nhật, chúng ta sẽ đưa chúng vào feed 15:26:57 <str4d> Tôi chỉ đang cố hiểu trường hợp sử dụng 15:27:09 <zzz> trường hợp sử dụng là ai đó bị xâm nhập (compromised) 15:27:20 <str4d> Chúng ta vẫn chưa làm ghim chứng chỉ (cert pinning) à? 15:27:30 <zzz> chưa 15:27:56 <zzz> vậy tôi đã làm 90% rồi và chỉ cần nhét crl vào namespace 15:28:46 <zzz> pinning rất rắc rối và nguy hiểm 15:29:05 <zzz> crypto cat đã làm 'pinning tự sát' 15:29:17 <zzz> khi họ ghim rồi nhưng một chứng chỉ trung gian thay đổi 15:30:49 <zzz> tôi không nghĩ pinning thay thế cls 15:30:51 <zzz> crls 15:31:21 <zzz> crl không chỉ dành cho ssl, còn có khóa reseed và khóa cập nhật 15:31:58 <zzz> vậy ta giữ crl trong danh sách cho 26 nhé? gần xong rồi 15:32:20 <str4d> Điều tôi lo về pinning là ai đó có thể làm một thứ kiểu Quantum Insert để chuyển hướng tên miền reseed, rồi chỉ cần đưa lên bất kỳ chứng chỉ SSL hợp lệ nào đáp ứng yêu cầu tên miền, và các router sẽ chấp nhận 15:33:05 <str4d> Còn về CRL, nếu dùng để vô hiệu hóa một chứng chỉ cụ thể, chứng chỉ đó được thay bằng cái gì? 15:33:25 <zzz> không gì cả. trong bản phát hành tiếp theo sẽ giả định có bản thay thế 15:33:45 <str4d> Cái này bắt đầu đi quá sâu vào chi tiết rồi 15:34:07 <str4d> Ý tôi là chúng ta cần suy nghĩ thêm về việc này 15:34:24 <zzz> ok vậy giữ crl cho 26 nhưng bàn chi tiết trong tuần tới hoặc hai tuần nữa 15:34:30 <zzz> vì nó chưa rõ ràng 100% 15:34:38 <zzz> chuyển tiếp 15:34:42 <zzz> còn gì trong danh sách 26 15:34:43 <str4d> ừm 15:34:50 <EinMByte> ok 15:35:08 <zzz> giao thức subscription 15:35:28 <zzz> đây là chìa khóa cho việc di chuyển crypto của các site 15:35:40 <EinMByte> thay thế hosts.txt hay ý bạn là gì? 15:36:22 <zzz> đúng, đây là hosts.txt dưới dạng feed, kiểu như foo.i2p=b64#sig=b64#cmd=alt ... 15:36:26 <str4d> EinMByte, bổ sung giao thức subscription của addressbook bằng metadata key-value có chữ ký 15:36:49 <zzz> đề xuất khá ổn rồi, nhưng tạm dừng khoảng 18 tháng nay 15:37:07 <EinMByte> Chắc rồi, nhưng kích thước file hosts sẽ không quá lớn sao 15:38:02 <EinMByte> Có lẽ thêm tham số since, để loại trừ tất cả host được thêm trước một thời điểm cho trước 15:38:07 <EinMByte> (để tránh tải cả danh sách khi không cần) 15:38:22 <zzz> điều này ban đầu là một phần của kế hoạch di chuyển crypto nhưng nó khó và không phải phần quan trọng nhất 15:38:49 <zzz> nhưng nó là việc chính còn lại trong di chuyển crypto cho chữ ký 15:39:26 <str4d> EinMByte, chúng ta đã có thứ đó rồi với etag 15:39:28 <zzz> đây lại là một trong những thứ đã có đề xuất rất cụ thể, nhưng chưa đạt đồng thuận nên chưa bắt đầu 15:39:42 <EinMByte> str4d: Nhưng nó có được dùng không? 15:39:46 <str4d> EinMByte, có 15:40:00 <EinMByte> Ồ, không sao. trong trường hợp đó 15:40:03 <str4d> Cái này sẽ không khác thiết lập hiện tại 15:40:20 <zzz> vậy chúng ta sẽ để nó trong danh sách 26 và bắt đầu càng sớm càng tốt. không chắc có thể tiến đủ xa cho 26 nhưng tôi sẽ cố. chúng ta cần xem lại chủ đề trên zzz.i2p 15:40:22 <str4d> nhưng thay vì các mục tên miền không bao giờ lặp lại, giờ chúng sẽ lặp trong "stream" 15:40:42 <EinMByte> Có lý do cụ thể nào mà chúng ta cần giữ định dạng kỳ quặc đó không? 15:41:05 <EinMByte> Theo tôi sẽ dễ hơn nếu ta chỉ dùng thứ gì đó tiêu chuẩn 15:41:06 <zzz> có thể. để tương thích với client cũ. nhưng ta nên rà soát và quyết định chắc chắn xem điều đó có quan trọng không 15:41:20 <zzz> có lẽ đã khoảng một năm không ai trong chúng ta xem lại chuyện này 15:41:28 <zzz> vậy ta sẽ phủi bụi và xem lại 15:41:32 <EinMByte> zzz: Tương thích có thể xử lý bằng cách cung cấp file hosts.txt cũ song song trong một thời gian 15:41:41 <str4d> Cũng có vấn đề rộng hơn là làm gì với, ví dụ, tất cả các tên "lost" 15:41:53 <str4d> Nhưng đó nằm ngoài thảo luận hiện tại 15:41:57 <zzz> đúng. chúng ta cũng cần lôi kéo các impl khác tham gia 15:42:18 <EinMByte> str4d: Tôi nghĩ đó là việc cần quyết khi chúng ta có hệ thống đặt tên mới (nếu có bao giờ) 15:42:26 <str4d> Còn bây giờ, tôi muốn có cách để các domain đang hoạt động cập nhật dest của họ 15:42:26 <zzz> ok, vậy tạm thời nó vẫn ở danh sách 26. tiếp theo trong danh sách - chuyện Sybil 15:42:45 <zzz> chúng ta có thể làm Sybil tự động không? Tôi hy vọng mọi người đều đã đọc bài báo của philip winter???? 15:42:50 <str4d> Và chúng ta càng đưa mã lõi vào sớm, càng có thể bật nó lên trong khoảng một năm nữa 15:43:50 <EinMByte> zzz: Bài báo nào? Rõ ràng tôi đã bỏ lỡ gì đó 15:44:27 <zzz> xem @__phw trên twitter để lấy link 15:45:02 <zzz> chúng ta đang làm việc với anh ấy nhờ sadie giới thiệu ở ccc 15:45:03 <EinMByte> zzz: cái này: http://arxiv.org/pdf/1602.07787v1.pdf? 15:45:27 <zzz> nếu nó xuất bản trong vài tuần vừa rồi thì đúng 15:45:59 <EinMByte> Ừm, đó là eprint từ tháng Hai năm nay 15:46:09 <zzz> tôi không nghĩ chúng ta sẵn sàng cho tự động. họ cũng vậy 15:46:22 <zzz> họ chỉ nhả một email mỗi ngày cho các dirauth 15:46:36 <zzz> hai bên đều là heuristic và 'phép màu' cả 15:46:49 <EinMByte> Vậy có lẽ anh ấy đưa eprint lên mạng sau khi nó được xuất bản 15:46:57 <zzz> vì vậy tôi muốn đẩy phần tự động sang cuối năm 15:47:07 <str4d> EinMByte, 25 Feb là phiên bản tôi có 15:47:14 <EinMByte> zzz: Vậy chính xác nó sẽ hoạt động thế nào trong bối cảnh phi tập trung? 15:47:44 <str4d> Chúng ta cần làm từ dưới lên thay vì từ trên xuống 15:48:06 <str4d> tức là mỗi router cần đưa "các ứng viên Sybil tiềm năng" vào các profile peer 15:48:13 <zzz> EinMByte, tôi không biết. khó lắm 15:48:20 <str4d> dựa trên, ví dụ, thời gian online, v.v. 15:48:30 <EinMByte> Phát hiện tấn công Sybil thì làm được theo tôi, nhưng ngăn chặn dựa trên phát hiện đó là rất khó trong một mạng phi tập trung 15:48:30 <EinMByte> Nhưng tôi thích thử thách 15:48:34 <zzz> chúng ta cũng cần gravy, người đang làm lại thiết lập của mình theo hướng tập trung 15:48:43 <str4d> Cũng có khả năng có một dạng thiết lập tập trung hơn 15:48:45 <str4d> Ừ, cái đó 15:48:45 <EinMByte> str4d: Tới lúc đó bạn cần bắt đầu gán độ tin cậy cho từng router 15:48:52 <EinMByte> mà bản thân nó sẽ là cả một hệ thống chống Sybil 15:49:07 <str4d> Và cho các router subscribe một danh sách Sybil tiềm năng 15:49:07 <zzz> kiểu giống các đề xuất dagon 15:49:09 <str4d> EinMByte, thực chất đó là những gì peer profile đang là hiện nay 15:49:31 <str4d> nơi "độ tin cậy" hiện được định nghĩa là "đã định tuyến tốt cho tôi trong quá khứ" 15:49:42 <EinMByte> str4d: Đúng, và đến giờ chúng đã gây ra vài tấn công :) 15:50:15 <str4d> Ừ 15:50:23 <EinMByte> Ngoài ra, peer profile thật ra không cho bạn loại trừ một peer khỏi mạng 15:50:31 <EinMByte> Ngăn chặn Sybil phần nào sẽ cho phép điều đó 15:50:35 <str4d> Peer profiling và chọn peer là một việc khác tôi nghĩ cần ưu tiên 15:50:46 <str4d> EinMByte, chúng có thể 15:51:01 <zzz> vậy tôi đề xuất đổi mục Sybil trong 26 thành 'tiếp tục cải tiến' nhưng chuyển phần 'tự động' sang sau 15:51:01 <str4d> Không phải lúc này 15:51:11 <str4d> Ý tôi là đó sẽ là chỗ chúng ta đặt nó 15:51:34 <EinMByte> str4d: Vâng, có thể. 15:51:37 <str4d> (theo nghĩa đưa phát hiện Sybil và các kỹ thuật nâng cao vào từ vựng và kiến trúc của I2P) 15:51:53 <EinMByte> Dù sao, tôi sẽ không bỏ tính phi tập trung. Đó là phần hay nhất của I2P theo tôi 15:52:14 <str4d> Ừ 15:52:27 <EinMByte> (và tập trung cũng dẫn tới nhiều tấn công thực tế) 15:52:43 <zzz> chuyển tiếp. cải tiến streaming? không chắc đó là gì, có thể chỉ là mục 'làm cho tốt hơn' muôn thuở 15:52:49 <str4d> zzz, ừ, chúng ta có thể tiếp tục làm trang routerconsole đó, rồi gắn nó vào peer profile và lựa chọn sau khi quyết định chiến lược 15:53:00 <zzz> tôi chưa nghĩ ra việc cụ thể gì cho streaming. ai có ý tưởng? 15:53:01 <EinMByte> Đôi khi thêm một cơ quan trung tâm có thể làm chứng minh bảo mật dễ hơn, nhưng lại gây thất bại bảo mật trên thực tế 15:53:20 <str4d> Nghiên cứu và tối ưu hóa sẽ tốt 15:53:28 <EinMByte> zzz: Có cải tiến hiển nhiên nào ta có thể làm ở đó không? 15:53:30 <str4d> Đó sẽ là ứng cử viên tốt cho nghiên cứu bên ngoài 15:53:46 <zzz> chúng ta thật sự cần một thiết lập kiểm thử tốt hơn 15:53:51 <EinMByte> str4d: Tôi đồng ý. 15:53:55 <zzz> thêm trễ / rớt gói, đảo thứ tự, v.v. 15:54:04 <EinMByte> Có lẽ chúng ta nên mở rộng trang 'câu hỏi nghiên cứu mở' với việc đó và những thứ khác 15:54:40 <zzz> tôi không có nhiều ý tưởng 'trời xanh' trong danh sách việc về streaming. nó cần được dẫn dắt bởi kết quả kiểm thử 15:54:50 <EinMByte> Có lẽ còn cải tiến trong việc phân bổ tunnels? 15:55:05 <str4d> zzz, có một dự án GH mô phỏng "The Internet" bằng các container có thể làm vậy, nếu tôi nhớ không lầm 15:55:08 <zzz> vậy sao không biến mục này thành 'khung kiểm thử streaming' 15:55:17 <str4d> Không rõ dễ thế nào, chúng ta sẽ cần một JVM mới cho mỗi container :P 15:55:25 <str4d> EinMByte, mmm 15:55:48 <EinMByte> str4d: shadow có thể dùng được, tôi nghĩ vậy. Không chắc có tích hợp với Java được không nhưng nó nằm trong danh sách TODO của kovri 15:55:52 <str4d> Nhưng cái đó không hẳn là streaming, nó ở mức datagram 15:56:22 <zzz> chuyện phân bổ tunnel là ý tưởng của psi để client chọn tunnels 15:56:34 <EinMByte> str4d: Vâng, tôi nghi có nhiều thứ để tối ưu 15:56:46 <EinMByte> zzz: Tôi không nghĩ người dùng là thuật toán tối ưu tốt nhất, nhưng biết đâu 15:57:10 <zzz> đó là sự phá vỡ mạnh tính phân lớp của chúng ta, và tôi không thấy cách nào làm được. nhưng đó là điều psi đang đề xuất 15:57:19 <EinMByte> ... hoặc có lẽ "client" không có nghĩa là người dùng 15:57:32 <zzz> client == phía client của i2cp 15:57:44 <str4d> Vấn đề ở đó là 15:57:54 <str4d> Tor có cung cấp khả năng này qua Control Socket của họ 15:57:58 <EinMByte> Ok vậy đúng là có nghĩa như thế 15:57:59 <str4d> Và nó rất hữu ích cho nhà nghiên cứu 15:58:10 <str4d> Nhưng họ cũng có kiến trúc phẳng hơn nhiều 15:58:19 <str4d> Trong khi chúng ta cô lập các client với nhau qua I2CP 15:58:31 <EinMByte> zzz: Tôi kỳ vọng router có nhiều thông tin liên quan hơn. Client có thể truyền các yêu cầu bổ sung 15:58:41 <zzz> chúng ta cũng có lua hooks của psi cho giới nghiên cứu, chưa bao giờ được merge (trong java hay kovri), nhưng vẫn là một lựa chọn 15:59:14 <zzz> hiện tại phía client thậm chí không biết về tunnels, nên chắc chắn không có khả năng chọn 15:59:16 <str4d> Nói chuyện với nickm tại RWC, anh ấy nói Tor dễ duy trì giao diện Control Socket hơn là một hệ thống plugin 15:59:17 <EinMByte> Tôi biết shadow đang được các nhà nghiên cứu sử dụng thực tế 15:59:22 <EinMByte> Lua, tôi không rõ 15:59:55 <EinMByte> zzz: Vậy có lẽ có thể đạt được điều tương tự bằng cách truyền thông tin liên quan qua I2CP? 16:00:17 <zzz> 1mb, đúng, nhưng nó sẽ rất xấu xí 16:00:44 <str4d> Ta luôn có thể giới hạn nó bằng cờ -research hay gì đó 16:00:54 <str4d> (trong router.config) 16:01:06 <str4d> Bằng cách đó đa số người dùng sẽ không phải thấy cái xấu xí đó 16:01:13 <zzz> kovri/i2pd chưa có những rào cản API cứng giữa client/router, điều đó dễ hơn cho 16:01:20 <zzz> *họ 16:01:28 <str4d> Và ta có thể định nghĩa ".research" ngay từ đầu là "Chúng tôi có quyền thay đổi các API này" 16:01:44 <str4d> tức là nhà nghiên cứu sẽ cần dùng cờ .research cùng với một phiên bản cụ thể 16:01:57 <str4d> Quay lại chủ đề chính đang thảo luận: 16:01:59 <EinMByte> zzz: Về tunnels. Còn tùy. Tôi nghĩ hợp lý là truyền thông tin về mục đích sử dụng dự kiến của tunnel. 16:02:20 <zzz> (FYI cuộc họp này còn tối đa 25 phút nữa, sẽ tiếp tục vào chủ nhật) 16:02:33 <EinMByte> zzz: Chủ yếu là dễ hơn cho chúng tôi vì shadow viết bằng C, tôi nghĩ vậy 16:02:42 <str4d> Tôi nghĩ nên đẩy cái này vào danh mục "cần nghiên cứu thêm" 16:02:44 <zzz> vấn đề là không chỉ tunnels của bạn cần được chọn mà còn tunnels của phía xa 16:02:48 <EinMByte> Ok. Vậy chuyển tiếp. 16:03:08 <zzz> ok đó là tất cả trong danh sách 26 hiện giờ. Nên thêm gì? 16:03:11 <EinMByte> zzz: Phía xa không tự xử lý việc đó sao 16:03:36 <zzz> không, chúng ta source-route (tức là chọn lease phía xa từ leaseset của họ cho luồng inbound của họ) 16:04:08 <zzz> xem danh sách 27-29. có gì nên kéo vào 26 không? 16:04:44 <str4d> Tôi muốn bắt đầu làm công việc chuẩn bị cho LS mới và netdb 16:04:46 <zzz> đây là nơi có tất cả 'công việc khởi đầu cho xxx của 2017', nhưng cũng có nhiều thứ 2016 16:05:23 <EinMByte> zzz: Tôi hiểu nhầm ý bạn với 'far-end', không sao 16:05:31 <str4d> Càng sớm ổn định và đưa vào codebase thì mạng sẽ càng sớm hỗ trợ rộng rãi 16:06:42 <EinMByte> Lưu ý là chúng tôi (kovri) muốn có specification 16:06:52 <EinMByte> Nếu không sẽ khó theo kịp phần triển khai 16:07:31 <zzz> chắc rồi. bất cứ thứ gì là specification mới, chúng ta cần cùng làm 16:07:36 <EinMByte> str4d: Hãy bắt đầu bằng cách liệt kê LS2 thực sự nên hỗ trợ những gì 16:07:53 <EinMByte> (nếu điều đó chưa được làm) 16:09:40 <zzz> cơ bản thì ls2 chỉ có vài thứ 16:09:59 <zzz> thêm một chút không gian cho flags 16:10:09 <zzz> và cho phép crypto tương lai 16:10:52 <zzz> nhưng tôi có tất cả các đề xuất về multihoming tốt hơn, cộng với tra cứu dịch vụ kiểu grothoff 16:11:00 <zzz> anycast 16:11:01 <EinMByte> Chúng ta có danh sách cụ thể ở đâu đó để tham khảo không? 16:11:11 <zzz> nó được tập hợp trên zzz, đợi chút 16:11:23 <str4d> EinMByte, tôi đang từ từ gom tất cả lại trên website 16:11:41 <zzz> ta làm nhanh hơn được không str4d ? như tuần tới hoặc hai tuần nữa? 16:11:47 <str4d> Việc đó nên đưa vào danh sách .26 16:11:50 <str4d> Hmm 16:11:53 <str4d> Có thể 16:11:59 <str4d> Tôi cần thêm người xem giúp 16:11:59 <zzz> không có đề xuất trên một danh sách đơn giản thì việc này quá khó 16:12:08 <EinMByte> str4d: Tuyệt. Thực ra với vài thứ, chức năng wiki sẽ hữu ích 16:12:24 <EinMByte> (ý tưởng là như vậy sẽ nhanh hơn) 16:12:48 <zzz> trước hết chúng ta cần một danh sách 16:12:50 <str4d> EinMByte, chính xác 16:12:56 <zzz> đừng cố làm mọi thứ một lúc 16:13:11 <str4d> Tôi đang cố chuyển từ yêu cầu HTML backend sang (hiện tại) rST 16:13:31 <str4d> Tôi cần người xem qua những gì tôi có để kiểm tra rằng a) nó dùng được và b) không mất đi thứ gì hiện có 16:13:39 <str4d> Hiện tại nó chỉ áp dụng cho tài liệu spec 16:13:40 <zzz> hãy đưa chuyện đề xuất vào danh sách 26 và chúng ta sẽ bàn sau về ý nghĩa của nó. Nhưng chúng ta cần tiến triển về việc đó càng sớm càng tốt. 16:13:55 <str4d> Nhưng một khi việc đó ổn định, mở rộng sang đề xuất là chuyện nhỏ 16:13:56 <zzz> tôi muốn chúng có trên website. không quan tâm định dạng. 16:14:46 <EinMByte> Tôi sẵn sàng duyệt đề xuất, nhưng đôi khi tôi chẳng tìm thấy văn bản nào 16:15:10 <EinMByte> (một số thứ trên website hơi bị ẩn, tôi nghĩ vậy) 16:15:37 <zzz> đúng 16:16:05 <zzz> chúng ta cần chuyển đồ từ zzz.i2p sang website theo một cách có tổ chức 16:16:13 <EinMByte> str4d: Chuyển từ HTML sang thứ có thể chuyển đổi dễ dàng sang nhiều định dạng là tốt 16:16:28 <EinMByte> zzz: Vâng, hoàn toàn 16:16:35 <str4d> EinMByte, thứ tôi cần được review nằm ở i2p.www.str4d 16:16:36 <EinMByte> Có lẽ cần một quy trình cố định cho tất cả đề xuất 16:16:57 <zzz> ok. nó đã ở danh sách 26. chi tiết sẽ cập nhật. str4d bắt tay vào đi. tôi không kỳ vọng nhiều phản hồi. Cứ đưa ra hệ thống mới và chúng ta sẽ làm theo 16:17:02 <str4d> và ở http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/ 16:17:04 <str4d> EinMByte, nếu bạn muốn cùng tôi chốt việc đó, tôi có thể hoàn thành có lẽ vào .25 16:17:23 <zzz> còn gì cho 26 nữa? chúng ta cần kết thúc thôi 16:17:36 <str4d> ( EinMByte, cụ thể là http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/spec) 16:18:14 <zzz> đây là việc ngắn hạn. tôi cần biết thứ hai phải làm gì 16:18:27 <zzz> lời gọi cuối cho 26 16:18:41 <str4d> Tôi nghĩ phần subscriptions sẽ mất thời gian 16:18:49 <str4d> Vậy tôi sẽ hài lòng nếu đó là việc chính 16:18:52 <zzz> đồng ý. 16:19:54 <zzz> ok. họp vào chủ nhật cùng giờ. chúng ta sẽ bắt đầu với vrp/h1. vui lòng xem trước ticket 1119. sau đó sẽ nói về 27-29, nếu còn thời gian. 16:20:06 <EinMByte> str4d: Có cái nào bạn nghĩ cần chú ý nhất không? 16:20:27 <zzz> chúng ta cũng có thể quay lại 26 một chút vào chủ nhật nếu cần 16:20:43 <str4d> EinMByte, cơ bản là quyết định xem định dạng viết đề xuất có dùng được không, và nó có giới hạn thứ lên website không (dưới dạng HTML hoặc TXT) 16:20:45 <zzz> vậy chương trình chủ nhật sẽ là 1) vrp/h1/1119; 2) 26; 3) 27-29 16:20:57 <zzz> cảm ơn mọi người 16:21:25 * zzz *bafs* kết thúc cuộc họp 16:27:50 <EinMByte> str4d: Có lẽ ổn miễn là có thể chuyển đổi sang hầu hết định dạng khác :)