I2P Geliştirici Toplantısı - 04 Mart 2016

15:00:05 <zzz> 0) merhaba 15:00:23 <zzz> 1) bu toplantıların yapısı 15:00:32 <zzz> 2) yol haritası tartışması 15:00:37 <zzz> 0) merhaba 15:00:41 <zzz> merhaba 15:00:54 <str4d> merhaba 15:01:02 <xcps_> merhaba! 15:01:27 <orignal_> ne var ne yok? 15:02:18 <zzz> lütfen http://zzz.i2p/topics/2021 konusunu ve mevcut yol haritasını http://i2p-projekt.i2p/en/get-involved/roadmap adresinde inceleyin 15:02:27 <zzz> 1) bu toplantıların yapısı 15:03:22 <zzz> doğrudan yol haritasına mı geçelim yoksa önce üst düzey öncelikler hakkında mı konuşalım? 15:03:53 <str4d> Ben önce ikincisinden yanayım 15:04:41 <zzz> tamam, konuda iki öncelik ortaya attım - ağı büyütmek ve güvenliği artırmak 15:04:55 <zzz> bunlar üst düzey ilkeler olarak nasıl geliyor? 15:05:25 <zzz> önce neyin önemli olduğuna karar verelim 15:05:32 <EinMByte> Beklendiği gibi geliyorlar, bence 15:05:48 <EinMByte> "ağı büyütmek" geniş anlamda olmalı ama 15:05:57 <str4d> Bunların geniş temalar olarak harika olduğunu düşünüyorum 15:06:03 <zzz> anonimal konuda bir sürü başka şey ortaya attı ama benim peşinde olduğum bu değildi 15:06:13 <xcps_> bence (imho) güvenliği artırmak her zaman en önemli olmalı 15:06:28 <zzz> yol haritasını gözden geçirirken dikkate almamız gereken başka ilkeler? 15:06:28 <str4d> Burada bence (IMHO) yapmamız gereken, bunların potansiyel çıktılar açısından gerçekte ne anlama geldiğini belirlemek 15:06:40 <EinMByte> Yani "ağı büyütmek" aynı zamanda "araştırma ilgisini artırmak" anlamına da gelmeli 15:07:00 <zzz> "ağı büyütmek" çok çeşitli şeyler demek - konuya bakın 15:07:09 <str4d> EinMByte, evet, sanırım bunu konuda bahsetmiş olabilirim 15:07:36 <zzz> bunların ne anlama geldiğini yakında netleştireceğiz. şu anda neyin önemli olduğunda anlaşalım. 15:07:58 <str4d> Kullanılabilirlik benim için çok önemli ve bence (IMHO) yukarıdaki iki alanı da besliyor 15:07:58 <zzz> büyümeye devam edersek her şey mümkün. büyümeyi bıraktığımız anda ölüyüz 15:08:05 <zzz> katılıyorum str4d 15:08:41 <str4d> Daha kısa vadede kullanıcı tabanımızı artırma açısından, daha uzun vadede de kamuya görünürlüğümüzü, araştırmacılar tarafından kullanım kolaylığını vb. artırma açısından 15:09:11 <EinMByte> Ayrıca büyümenin araştırmacıları çekmenin tek yolu olduğunu unutmayın 15:09:25 <zzz> daha fazla kullanıcı daha fazla geliştirici, daha fazla araştırmacı, daha fazla içerik ve ve ve getirir 15:09:37 <EinMByte> Büyük ağlar genellikle incelenmesi daha ilgi çekicidir 15:10:05 <EinMByte> Dolayısıyla bu 2 öncelikte hepimizin anlaşabileceğini düşünüyorum 15:10:16 <zzz> son yıldaki büyümemizin büyük kısmı Vuze'den geldi. Bu harika ama daha fazla 'yerel' büyüme de görmek isterim 15:10:43 <zzz> ama belki gömülü uygulamalardaki büyüme ya da genel olarak uygulamalara odaklanmak büyümenin en kolay yoludur 15:10:48 <str4d> Evet 15:11:04 <EinMByte> zzz: Birçok insan için, arka planda I2P çalıştıran ve yapılandırmayı onlar adına halleden bir uygulamayı kullanmak daha kolay 15:11:12 <sadie> merhaba - partiye biraz geç kaldım 15:11:20 <zzz> merhaba sadie, geldiğine sevindim 15:11:23 <str4d> Bence (IMHO) bu, hem UI hem de API'lerdeki kullanılabilirlik iyileştirmelerinden gelecektir 15:11:42 <str4d> İkincisi üzerinde zaten çeşitli konularda çalışıyoruz 15:11:48 <zzz> bazı açılardan UI uzmanı olan uygulamaların kendisi; i2p'yi paketlemelerine ve en uygun gördükleri şekilde ortaya çıkarmalarına (veya gizlemelerine) izin verelim 15:11:58 <str4d> Hmm 15:12:08 <EinMByte> str4d: Bu aynı soruna farklı bir çözüm, evet. Ve daha çok hoşuma gidiyor çünkü bence (IMHO) I2P'yi her şeyle birlikte paketlemek ölçeklenmiyor 15:12:30 <str4d> Bu Android'de benimsediğim yaklaşıma benziyor 15:13:04 <EinMByte> İnsanların her uygulama için bir I2P örneğine sahip olmamasını sağlayacak bir yol olmalı 15:13:12 <zzz> tamam, 1) için başka bir şey var mı yoksa doğrudan yol haritasının kendisine mi geçelim? 15:14:00 <str4d> Sanırım burada herkes kabaca hemfikir 15:14:08 <str4d> (en azından itiraz yok :P) 15:14:14 <zzz> konudan satırları buraya kopyalayayım. Kutsal metin gibi değil, sadece referans olarak 15:14:25 <zzz> Ağı Büyütmek 15:14:25 <zzz> Şunları içerir: Pazarlama, ortak projeler, daha fazla şey paketlemek, başkalarının i2p paketlemesine yardım etmek, kullanılabilirlik, web sitesi iyileştirmeleri, daha fazla çeviri, konuşmalar ve sunumlar, makaleler ve hikayeler, UI, Android, Android uygulamaları, daha iyi GFW (Great Firewall - Çin'in Büyük Güvenlik Duvarı) atlatma, orchid, istemci geliştiriciler için daha fazla kütüphane ve araç, devasa web siteleri için daha iyi destek, alternatif router geliştirmeyi desteklemek, ittifaklar, hızlandırmalar ve verimlilik, kapasite, limitleri artırma, içeri 15:14:25 <zzz> Debian'a girmek, ... 15:14:25 <zzz> Güvenliği artırmak 15:14:25 <zzz> Şunları içerir: Kripto geçişi, abonelik protokolü, yeni taşıma protokolleri, pluggable transports (eklenebilir taşıma protokolleri), LS2, NTCP2, yeni DH, anahtar iptali, anahtar depolama, kod incelemesi, Sybil, hata düzeltmeleri, adlandırma, SSL, ... 15:14:46 <zzz> tamam, 2) doğrudan yol haritasının kendisine geçelim 15:15:10 <zzz> url http://i2p-projekt.i2p/en/get-involved/roadmap 15:15:50 <zzz> .25 büyük ölçüde bitti, yaklaşık 10 gün içinde yayın, o yüzden bu yıl için sonraki 4 sürüme 26-29 bakalım 15:16:00 <zzz> ki bu bizi CCC'ye kadar götürmeli 15:16:15 <EinMByte> Bir şey 2017 altında ise, örneğin, bu sadece o zaman mı bakmaya başlayacağımız anlamına geliyor, yoksa uygulamaya o noktada başlayacağımız anlamına mı? 15:16:41 <str4d> Yapmamız gereken şeyler açısından, kripto geçişini ve Sybil çalışmalarını en üst sıralara koyardım 15:16:42 <zzz> 1mb, kesinlikle yeni kripto/DH, NTCP2 vb. gibi 2017'nin büyük işlerine şimdiden başlamak istiyoruz 15:17:04 <EinMByte> Ayrıca, bence (IMHO) Eclipse saldırıları şu anda bir sorun 15:17:05 <zzz> dolayısıyla yol haritası bunlar için hazırlık çalışmalarını içerebilir 15:17:23 <str4d> EinMByte, evet, onu Sybil altında topluyordum 15:17:36 <EinMByte> Tüm "gece yarısı rotasyonu" fikri işe yaramıyor ve sanırım daha iyi alternatifler olmalı 15:17:52 <zzz> katılıyorum 15:18:05 <EinMByte> str4d: Tabii, bunları aynı tür saldırılar olarak sınıflandırmak makul 15:18:44 <str4d> EinMByte, bunu RWC'de birkaç kişiyle görüştüm 15:18:48 <str4d> Bazı fikirler edindim, ama burada konuşması zor 15:18:51 <EinMByte> zzz: 2017'ye kadar NTCP2/... işlerine başlamak istiyorsak ön hazırlık planlamamız gerekecek 15:18:58 <zzz> doğru 1mb 15:19:02 <str4d> Evet 15:19:20 <str4d> Planlama ve araştırmayı yol haritasına almak istiyorum :) 15:19:28 <zzz> mesele şu. Şu anda 26 üzerinde çalışıyor olmam gerek ve içinde ne var bilmiyorum 15:19:39 <orignal_> mevcut NTCP'ye rastgele padding eklemek mümkün mü? 15:20:01 <str4d> orignal_, hatırladığım kadarıyla değil, ama NTCP2 konusuna bakın 15:20:02 <zzz> o hâlde 26'yı planlamaya 10 dakika ayıralım, sonra daha uzun vadeye geçebiliriz 15:20:13 <str4d> ok 15:20:14 <zzz> bugün ne yapmam gerektiğini söyleyin 15:20:30 <EinMByte> Doğru, önce ona odaklanalım 15:20:34 <zzz> tamam 25 listesindeki olup da gerçekleşmeyenler neler 15:20:50 <zzz> wrapper olmadı, kytv kayıplara karıştı (AWOL) 15:20:54 <EinMByte> "kripto iyileştirmeleri" oldukça geniş 15:21:12 <zzz> kripto iyileştirmelerinde aslında olan, bazı 25519 hızlandırmalarıydı 15:21:34 <zzz> yani .25 listesindekilerin hepsi aslında içinde, wrapper hariç 15:22:00 <zzz> ama Sybil konusunda yapılacak daha çok şey var, bunu 26 listesinde tutalım 15:22:08 <str4d> Harika 15:22:25 <str4d> Daha fazla test gereksinimi nedeniyle GMP 6'yı .26'ya erteledik 15:22:35 <zzz> şimdi 26 listesinde olup içinde olması ya da taşınması gereken başka ne var 15:23:05 <EinMByte> Sonuçta Sybil'i önlemek muhtemelen çok iş olacak, bu yüzden bana uzun vadeli görünüyor 15:23:10 <EinMByte> (önce iyi bir literatür taramasına ihtiyacımız olduğu anlamında) 15:23:15 <zzz> orignal, evet, dolgu (padding) içeren NTCP, NTCP2'dir 15:23:21 <str4d> EinMByte, Sybil tespit aracını henüz hiçbir şey için kullanmıyoruz, daha fazla planlamaya ihtiyaç duyulan yer orası :) 15:23:49 <zzz> hottuna4 bir ay müsait değil, o ay ne zaman doluyor emin değilim, bu yüzden gmp6 26'ya girip girmeyebilir 15:24:02 <str4d> Tamam 15:24:37 <str4d> Adres defteri için abonelik protokolü iyileştirmeleri: bu, eski Dest sahiplerinin Ed25519'a geçebilmesi için mümkün olan en kısa sürede eklenmesi çok iyi olacak bir şey 15:24:37 <EinMByte> Bence CRL'lerin gerçekten soru işaretine ihtiyacı yok 15:24:47 <str4d> Ama bunun yapılması gerçekte ne kadar sürecek? 15:25:14 <zzz> yakında tuna'dan bir durum güncellemesine ihtiyacımız olacak, 26 için büyük şeyleri yetiştirme son tarihinin Mart sonu / Nisan'ın ilk haftası olacağını tahmin ediyorum 15:26:10 * str4d CRL işini hâlâ tam olarak anlamadı, zzz biraz açabilir mi? 15:26:14 <zzz> 25, diskten CRL'leri okuma yeteneğine sahip olacak, böylece güncellemeye dahil edebiliriz 15:26:35 <zzz> ama bu pek yardımcı değil çünkü bir güncellemede sertifikayı basitçe kaldırabiliriz ve aynı şeyi yapar 15:26:56 <zzz> o hâlde CRL'leri güncelleme yapmak zorunda kalmadan insanlara ulaştırmak için, onları beslemeye (feed) koyarız 15:26:57 <str4d> Sadece kullanım senaryosunu anlamaya çalışıyorum 15:27:09 <zzz> kullanım senaryosu birinin ele geçirilmesi 15:27:20 <str4d> Hâlâ sertifika pinleme (pinning) yapmıyor muyuz? 15:27:30 <zzz> hayır 15:27:56 <zzz> yani işin %90'ını yaptım ve sadece CRL'yi ad alanına (namespace) koymam gerekiyor 15:28:46 <zzz> pinleme (pinning) karmaşık ve tehlikeli 15:29:05 <zzz> crypto cat 'pinleme intiharı' yaptı 15:29:17 <zzz> sertifikalar pinlenmişti ama aradaki (intermediate) değişti 15:30:49 <zzz> pinlemenin cls'nin yerini aldığını sanmıyorum 15:30:51 <zzz> crl'ler 15:31:21 <zzz> CRL'ler sadece SSL için değil, reseed ve update anahtarları da var 15:31:58 <zzz> o zaman CRL'leri 26 listesinde tutabilir miyiz? neredeyse bitti 15:32:20 <str4d> Pinleme ile ilgili endişem şu: biri örneğin Quantum Insert benzeri bir şey yaparak bir reseed alan adını yönlendirebilir ve alan adı gereksinimini karşılayan herhangi bir geçerli SSL sertifikası koyabilir ve router'lar bunu kabul eder 15:33:05 <str4d> Ve CRL'lerle ilgili olarak, belirli bir sertifikayı devre dışı bırakmak için bunu kullanırsak, o sertifikanın yerine ne geçecek? 15:33:25 <zzz> hiçbir şey. bir sonraki sürümde muhtemelen bir yenisi olur 15:33:45 <str4d> Bu biraz fazla ayrıntıya giriyor 15:34:07 <str4d> Sanırım demek istediğim, bunu biraz daha düşünmemiz gerektiği 15:34:24 <zzz> tamam o hâlde CRL'leri 26 için tutalım ama ayrıntılarını önümüzdeki bir iki hafta içinde tartışalım 15:34:30 <zzz> çünkü %100 net değil 15:34:38 <zzz> devam edelim 15:34:42 <zzz> 26 listesinde başka ne var 15:34:43 <str4d> mmk 15:34:50 <EinMByte> tamam 15:35:08 <zzz> abonelik protokolü 15:35:28 <zzz> bu, sitelerin kripto geçişi için anahtar 15:35:40 <EinMByte> hosts.txt yerine mi yoksa ne demek istiyorsun? 15:36:22 <zzz> evet, bu hosts.txt'nin bir feed olarak sunulması işi, şu şekilde: foo.i2p=b64#sig=b64#cmd=alt ... 15:36:26 <str4d> EinMByte, adres defteri abonelik protokolüne imzalı anahtar-değer üst verisi (metadata) eklemek 15:36:49 <zzz> öneri oldukça net, ama yaklaşık 18 aydır beklemede 15:37:07 <EinMByte> Tabii, ancak hosts dosyasının boyutu çok fazla büyümez mi 15:38:02 <EinMByte> Belki bir since parametresi ekleyip, belirli bir zamandan önce eklenen tüm host'ları hariç tutarız 15:38:07 <EinMByte> (gerekmediği hâlde tüm listeyi indirmeyi önlemek için) 15:38:22 <zzz> bu aslında kripto geçiş planının bir parçasıydı ama zordu ve en önemli parça değildi 15:38:49 <zzz> ama imzaların kripto geçişinde kalan ana şey bu 15:39:26 <str4d> EinMByte, bunu etag ile zaten bir bakıma yapıyoruz 15:39:28 <zzz> bu da ayrıntılarıyla önerilmiş ama üzerinde tam bir mutabakat sağlanamadığı için başlanmamış şeylerden biri 15:39:42 <EinMByte> str4d: Ama kullanılıyor mu? 15:39:46 <str4d> EinMByte, evet 15:40:00 <EinMByte> Oh, boş ver. o zaman 15:40:03 <str4d> Bu mevcut kurulumdan farklı olmayacak 15:40:20 <zzz> dolayısıyla bunu 26 listesine koyacağız ve mümkün olan en kısa sürede başlayacağız. 26 için yeterince ilerleyebilir miyiz emin değilim ama deneyeceğim. zzz.i2p'deki konuyu gözden geçirmemiz gerekiyor 15:40:22 <str4d> ancak alan adı girdileri hiç tekrarlanmak yerine artık 'akış'ta (stream) tekrar eder 15:40:42 <EinMByte> Peki tuhaf biçimi neden korumamız gerektiğine dair özel bir neden var mı? 15:41:05 <EinMByte> Sadece standart bir şey kullansak daha kolay görünür bana 15:41:06 <zzz> olabilir. eski istemcilerle uyumluluk. ama bunun önemli olup olmadığına kesin karar vermek için gözden geçirmeliyiz 15:41:20 <zzz> belki bir yıldır hiçbirimiz buna bakmadık 15:41:28 <zzz> o hâlde tozunu alıp bir bakacağız 15:41:32 <EinMByte> zzz: Uyumluluk bir süre eski hosts.txt dosyasını da sağlayarak ele alınabilir 15:41:41 <str4d> Ayrıca örneğin tüm "kayıp" adlarla ne yapılacağı gibi daha geniş bir mesele var 15:41:53 <str4d> Ama bu mevcut tartışmanın dışında 15:41:57 <zzz> evet. diğer uygulamaları (impls) da dahil etmemiz gerekecek 15:42:18 <EinMByte> str4d: Bence bu, yeni bir adlandırma sistemi edindiğimizde (eğer bir gün edinebilirsek) karar verilecek bir şey 15:42:26 <str4d> Şimdilik, hâlen aktif alan adlarının dest'lerini güncelleyebilmesi için bir yol istiyorum 15:42:26 <zzz> tamam, şimdilik 26 listesinde kalıyor. listedeki sıradaki - Sybil işleri 15:42:45 <zzz> Sybil'i otomatik hâle getirebilir miyiz? Umarım hepiniz Philip Winter'ın makalesini okudunuz???? 15:42:50 <str4d> Ve çekirdek kodu ne kadar çabuk içeri alırsak, bir yıl kadar sonra o kadar çabuk açabiliriz 15:43:50 <EinMByte> zzz: Hangi makale? Belli ki bir şeyi kaçırdım 15:44:27 <zzz> bağlantı için Twitter'da @__phw'ye bakın 15:45:02 <zzz> CCC'de sadie'nin tanıştırması sayesinde kendisiyle çalışıyoruz 15:45:03 <EinMByte> zzz: bu mu: http://arxiv.org/pdf/1602.07787v1.pdf? 15:45:27 <zzz> son bir iki haftada yayımlandıysa odur 15:45:59 <EinMByte> Şey, bu yılın Şubat'ından bir e-print 15:46:09 <zzz> otomatik için hazır olduğumuzu sanmıyorum. onlar da pek hazır değil 15:46:22 <zzz> günde bir kez sadece dirauth'lara bir e-posta gönderiyorlar 15:46:36 <zzz> her iki tarafta da her şey sezgisel ve sihirli 15:46:49 <EinMByte> Yani muhtemelen yayımlandıktan sonra e-print'i çevrimiçi koymuş 15:46:57 <zzz> bu yüzden otomatik işleri yılın ilerleyen zamanlarına itmek isterim 15:47:07 <str4d> EinMByte, bende olan sürüm 25 Şubat 15:47:14 <EinMByte> zzz: Peki bu merkeziyetsiz bir yapıda tam olarak nasıl çalışacak? 15:47:44 <str4d> Üstten alta yerine alttan üste doğru yapmamız gerekiyor 15:48:06 <str4d> yani her router, eş profillerine 'potansiyel Sybil adayları'nı dahil etmek zorunda kalacak 15:48:13 <zzz> EinMByte, bilmiyorum. zor 15:48:20 <str4d> örneğin çevrimiçi süreler vb. temel alınarak 15:48:30 <EinMByte> Sybil saldırılarını tespit etmek yapılabilir bence, ancak bu tespitten yola çıkarak onları önlemek merkeziyetsiz bir ağda çok zor 15:48:30 <EinMByte> Ama meydan okumayı seviyorum 15:48:34 <zzz> ayrıca kurulumunu merkezi bir şekilde yeniden yapan gravy'ye de ihtiyacımız var 15:48:43 <str4d> Daha merkezi bir düzenek olma olasılığı da var 15:48:45 <str4d> Evet, o 15:48:45 <EinMByte> str4d: O noktada her router'a güven atamaya başlamanız gerekir 15:48:52 <EinMByte> bu da başlı başına bir anti-Sybil sistemi olur 15:49:07 <str4d> Ve router'ların potansiyel Sybil'lerin bir listesine abone olması 15:49:07 <zzz> biraz dagon önerilerine benzer 15:49:09 <str4d> EinMByte, bu aslında şu an eş profillerinin yaptığı şeye benziyor 15:49:31 <str4d> burada "güven" şu anda "geçmişte benim için güvenilir şekilde iyi yönlendirdi" olarak tanımlanıyor 15:49:42 <EinMByte> str4d: Evet, ve şimdiye kadar birkaç saldırıya da yol açtılar :) 15:50:15 <str4d> Evet 15:50:23 <EinMByte> Ayrıca, eş profilleri bir eşi ağdan dışlamanıza pek izin vermiyor 15:50:31 <EinMByte> Sybil önleme bunu bir nebze sağlar 15:50:35 <str4d> Eş profilleme ve eş seçimi de öncelik verilmesi gerektiğini düşündüğüm başka bir konu 15:50:46 <str4d> EinMByte, yapabilirler 15:51:01 <zzz> o hâlde 26'daki Sybil maddesini 'sürekli iyileştirme' olarak değiştirmeyi, ancak 'otomatik' kısmını daha sonraya taşımayı öneriyorum 15:51:01 <str4d> Şu an değil 15:51:11 <str4d> Sadece onu koyacağımız yerin orası olduğunu söylüyorum 15:51:34 <EinMByte> str4d: Evet, bu mümkün. 15:51:37 <str4d> (Sybil tespiti ve daha gelişmiş teknikleri I2P'nin sözlüğüne ve mimarisine katma açısından) 15:51:53 <EinMByte> Her hâlükârda, merkeziyetsizliği bırakmazdım. Bence (imho) I2P'nin en güzel yanı bu 15:52:14 <str4d> Evet 15:52:27 <EinMByte> (ve merkezileşme de zaten çeşitli pratik saldırılara yol açıyor) 15:52:43 <zzz> devam edelim. streaming iyileştirmeleri? bunun ne olduğundan emin değilim, belki de sürekli 'daha iyi yap' maddesi 15:52:49 <str4d> zzz, evet, o routerconsole sayfası üzerinde çalışmayı sürdürebiliriz ve bir stratejiye karar verdiğimizde bunu eş profilleri ve seçimine bağlarız 15:53:00 <zzz> streaming konusunda özel olarak ne yapılacağı aklıma gelmiyor. var mı öneri? 15:53:01 <EinMByte> Bazen merkezi bir otorite eklemek güvenlik kanıtınızı kolaylaştırabilir ama pratikte güvenlik açıklarına neden olabilir 15:53:20 <str4d> Araştırma ve optimizasyonlar iyi olur 15:53:28 <EinMByte> zzz: Orada yapabileceğimiz bariz iyileştirmeler var mı? 15:53:30 <str4d> Bu dış araştırma için iyi bir aday olurdu 15:53:46 <zzz> gerçekten daha iyi bir test düzenine ihtiyacımız var 15:53:51 <EinMByte> str4d: Katılıyorum. 15:53:55 <zzz> gecikmeler / düşürmeler ekle, yeniden sırala vb. 15:54:04 <EinMByte> Muhtemelen "açık araştırma soruları" sayfamızı bunun ve diğer şeylerin eklenmesiyle genişletmeliyiz 15:54:40 <zzz> streaming ile ilgili listemde pek 'mavi gökyüzü' (blue sky) türü şey yok. test sonuçlarıyla yönlendirilmesi gerekiyor 15:54:50 <EinMByte> tunnel tahsisinde daha fazla iyileştirme olabilir mi? 15:55:05 <str4d> zzz, yanlış hatırlamıyorsam (IIRC) bunu yapabilen konteynerlarla "İnternet"i simüle eden bir GH projesi var 15:55:08 <zzz> o hâlde bu maddeyi 'streaming test harness' yapalım mı 15:55:17 <str4d> Ne kadar kolay olur bilmiyorum ama, her konteyner için yeni bir JVM'e ihtiyacımız olur :P 15:55:25 <str4d> EinMByte, hmm 15:55:48 <EinMByte> str4d: Shadow kullanılabilir, sanırım. Java ile entegre edilebilir mi emin değilim ama kovri TODO listesinde 15:55:52 <str4d> Ama bu gerçekten streaming değil, datagram seviyesinde 15:56:22 <zzz> tunnel tahsisi konusu, istemcinin tunnel seçmesini sağlama fikri psi'ye ait 15:56:34 <EinMByte> str4d: Evet, bunu optimize edecek daha çok şey olduğunu düşünüyorum 15:56:46 <EinMByte> zzz: Kullanıcıların en iyi optimizasyon algoritmaları olduğunu pek sanmıyorum ama olabilir 15:57:10 <zzz> bu, katmanlaşmamızın vahşi bir bozulması ve bunu yapmanın bir yolunu görmüyorum. ama psi'nin önerdiği bu 15:57:19 <EinMByte> ... ya da muhtemelen 'client' kullanıcı anlamına gelmiyor 15:57:32 <zzz> client == I2CP'nin istemci tarafı 15:57:44 <str4d> Oradaki mesele şu 15:57:54 <str4d> Tor bunu Control Socket üzerinden sağlıyor 15:57:58 <EinMByte> Tamam yani öyle 15:57:59 <str4d> Ve araştırmacılar için çok yararlı 15:58:10 <str4d> Ama onların çok daha düz bir mimarisi var 15:58:19 <str4d> Biz ise farklı istemcileri I2CP aracılığıyla birbirinden yalıtıyoruz 15:58:31 <EinMByte> zzz: Daha ilgili bilgilere router'ın sahip olmasını beklerim. İstemci ek gereksinimleri iletebilir 15:58:41 <zzz> araştırmacılar için psi'nin Lua hook'ları da var, bunlar (ne Java'ya ne de kovri'ye) hiçbir zaman birleştirilmedi ama hâlâ bir seçenek 15:59:14 <zzz> şu anda istemci tarafı tunnel'lardan haberdar bile değil, dolayısıyla onları seçme yeteneği kesinlikle yok 15:59:16 <str4d> RWC'de nickm ile konuşurken, Tor için bir eklenti sisteminden ziyade bir Control Socket arayüzünü sürdürmenin çok daha kolay olduğunu söyledi 15:59:17 <EinMByte> Shadow'ın pratikte araştırmacılar tarafından kullanıldığını biliyorum 15:59:22 <EinMByte> Lua, bilmiyorum 15:59:55 <EinMByte> zzz: O hâlde muhtemelen ilgili bilgiyi I2CP üzerinden geçirerek aynı şey başarılabilir mi? 16:00:17 <zzz> 1mb, evet, ama gerçekten çok çirkin olur 16:00:44 <str4d> Bunu her zaman -research bayrağı veya benzeriyle sınırlayabiliriz 16:00:54 <str4d> (router.config içinde) 16:01:06 <str4d> Böylece çoğu kullanıcı bu çirkinlikle karşılaşmaz 16:01:13 <zzz> kovri/i2pd henüz istemci/router arasında o katı API bariyerlerine sahip değil, bu onlar için daha kolay 16:01:20 <zzz> *onlar için 16:01:28 <str4d> Ve en baştan '.research'in 'Bu API'leri değiştirme hakkını saklı tutarız' anlamına geldiğini tanımlayabiliriz 16:01:44 <str4d> yani araştırmacıların belirli bir sürümle birlikte .research bayrağını kullanması gerekir 16:01:57 <str4d> Asıl tartışma konusuna geri dönelim: 16:01:59 <EinMByte> zzz: tunnels hakkında. Duruma bağlı. Tunnel'ın amaçlanan kullanımı hakkında bilgi iletmek mantıklı olur bence. 16:02:20 <zzz> (Bilgi için: bu toplantı en fazla 25 dakika daha sürecek, pazar günü devam edecek) 16:02:33 <EinMByte> zzz: Bizim için esasen daha kolay çünkü Shadow C ile yazılmış, sanırım 16:02:42 <str4d> Bence bu 'daha fazla araştırma gerekiyor' kategorisine itilmelidir 16:02:44 <zzz> sorun şu ki seçilmesi gereken sadece sizin tunnel'larınız değil, uzak uçtaki (far-end) tunnel'lar 16:02:48 <EinMByte> Tamam. O zaman devam edelim. 16:03:08 <zzz> tamam, şu anda 26 listesinde olanlar bu kadar. Ne eklenmeli? 16:03:11 <EinMByte> zzz: Onu uzak uç (far-end) halletmiyor mu 16:03:36 <zzz> hayır, source-route yapıyoruz (yani onun inbound'u için far-end lease'i leaseset'inden seçiyoruz) 16:04:08 <zzz> 27-29 listesine bakın. 26'ya çekilmesi gereken bir şey var mı? 16:04:44 <str4d> Yeni LS'ler ve netDb için hazırlık işlerine başlamak istiyorum 16:04:46 <zzz> burada '2017 için xxx üzerinde başlangıç çalışması' olan her şey var, ama aynı zamanda bir sürü 2016 işi de var 16:05:23 <EinMByte> zzz: far-end ile ne demek istediğini yanlış anlamışım, boş ver 16:05:31 <str4d> Bunu ne kadar çabuk netleştirip kod tabanına alırsak, ağın geniş kapsamlı desteği o kadar çabuk olur 16:06:42 <EinMByte> Şunu unutmayın ki biz (kovri) spesifikasyon istiyoruz 16:06:52 <EinMByte> Aksi hâlde uygulamayla (implementation) ayak uydurmak zor olacak 16:07:31 <zzz> tabii. yeni bir spesifikasyon olan her şey üzerinde hep birlikte çalışmamız gerekiyor 16:07:36 <EinMByte> str4d: LS2'nin gerçekte neleri desteklemesi gerektiğini listeleyerek başlayalım 16:07:53 <EinMByte> (eğer bu zaten yapılmadıysa) 16:09:40 <zzz> temelde LS2 sadece birkaç şey 16:09:59 <zzz> flag'ler için biraz alan ekle 16:10:09 <zzz> ve gelecekteki kriptoya imkân tanı 16:10:52 <zzz> ama daha iyi multihoming ile ilgili tüm o önerilerim ve buna ek olarak grothoff benzeri servis arama var 16:11:00 <zzz> anycast 16:11:01 <EinMByte> Referans için belirli bir listemiz bir yerde var mı? 16:11:11 <zzz> zzz'de derlenmiş durumda, bir saniye 16:11:23 <str4d> EinMByte, bunların hepsini web sitesinde bir araya getirmek için yavaş yavaş çalışıyorum 16:11:41 <zzz> bunu hızlandırabilir miyiz str4d? mesela gelecek hafta ya da iki hafta? 16:11:47 <str4d> Bu .26 listesine girmeli 16:11:50 <str4d> Hmm 16:11:53 <str4d> Muhtemelen 16:11:59 <str4d> Buna daha çok göz lazım 16:11:59 <zzz> öneriler basit bir liste hâlinde olmadan bu iş fazlasıyla zor 16:12:08 <EinMByte> str4d: Harika. Aslında bu şeylerin bazıları için bir wiki işlevi faydalı olurdu 16:12:24 <EinMByte> (fikir, işin daha hızlı ilerlemesi) 16:12:48 <zzz> başlangıç olarak bir listeye ihtiyacımız var 16:12:50 <str4d> EinMByte, aynen 16:12:56 <zzz> her şeyi bir anda yapmaya kalkmayalım 16:13:11 <str4d> Arka uçta HTML gerekliliğinden (şimdilik) rST'ye geçmeye çalışıyorum 16:13:31 <str4d> Şunları kontrol etmek için elimdekilere insanların göz atmasına ihtiyacım var: a) kullanılabilir mi ve b) şu anda sahip olduğumuz hiçbir şeyi kaybettirmiyor mu 16:13:39 <str4d> Şu anda sadece spesifikasyon dokümanlarına uygulanıyor 16:13:40 <zzz> öneri işini 26 listesine koyalım ve bunun ne anlama geldiğini sonra konuşuruz. Ama bunun üzerinde mümkün olan en kısa sürede ilerleme kaydetmemiz gerekiyor. 16:13:55 <str4d> Ama bu sağlamlaşır sağlamlaşmaz, bunu önerilere genişletmek önemsiz derecede kolay 16:13:56 <zzz> bunları web sitesinde istiyorum. hangi biçimde olduğuna aldırmıyorum. 16:14:46 <EinMByte> Önerileri gözden geçirmeye hazırım, fakat bazen herhangi bir metin bulamadığım oluyor 16:15:10 <EinMByte> (sanırım web sitesinde bazı şeyler bir bakıma gizli) 16:15:37 <zzz> doğru 16:16:05 <zzz> zzz.i2p'den şeyleri web sitesine bir tür organizasyon içinde taşımamız gerekiyor 16:16:13 <EinMByte> str4d: HTML'den çeşitli formatlara kolayca dönüştürülebilen bir şeye geçmek iyi bir şey 16:16:28 <EinMByte> zzz: Evet, kesinlikle 16:16:35 <str4d> EinMByte, gözden geçirilmesini istediğim şey i2p.www.str4d içinde 16:16:36 <EinMByte> Belki tüm öneriler için sabit bir süreç 16:16:57 <zzz> tamam. 26 listesinde. ayrıntılar takip edecek. str4d işe koyul. çok fazla geri bildirim beklemem. Yeni bir sistemle gel ve hepimiz uyum sağlarız 16:17:02 <str4d> ve http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/ üzerinde 16:17:04 <str4d> EinMByte, bunu netleştirme konusunda benimle çalışmak istersen, bunu belki .25'e kadar bitirebilirim 16:17:23 <zzz> 26 için başka ne var? bunu toparlamamız lazım 16:17:36 <str4d> ( EinMByte, özellikle http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/spec ) 16:18:14 <zzz> bu çok kısa vadeli şeyler. pazartesi ne yapacağımı bilmem gerekiyor 16:18:27 <zzz> 26 için son çağrı 16:18:41 <str4d> Abonelik işleri biraz zaman alacak gibi geliyor 16:18:49 <str4d> Dolayısıyla bunun ana konu olmasından memnun olurum 16:18:52 <zzz> katılıyorum. 16:19:54 <zzz> tamam. toplantı pazar günü aynı saatte. vrp/h1 ile başlayacağız. lütfen önceden 1119 numaralı bileti inceleyin. ardından zaman elverirse 27-29'u konuşacağız. 16:20:06 <EinMByte> str4d: Bunlardan hangilerinin en çok dikkat gerektirdiğini düşünüyorsun? 16:20:27 <zzz> gerekirse pazar günü kısaca 26'ya geri dönebiliriz 16:20:43 <str4d> EinMByte, esasen öneri yazım formatının kullanılabilir olup olmadığına ve web sitesine (HTML veya TXT formatında) girenleri kısıtlayıp kısıtlamadığına karar vermek 16:20:45 <zzz> yani pazar günkü gündem 1) vrp/h1/1119; 2) 26; 3) 27-29 olacak 16:20:57 <zzz> herkese teşekkürler 16:21:25 * zzz toplantıyı *bafs* kapattı 16:27:50 <EinMByte> str4d: Muhtemelen çoğu diğer formata dönüştürülebildiği sürece sorun yoktur :)