I2P Geliştirici Toplantısı - 08 Mart 2005

13:06 <@jrandom> 0) merhaba 13:06 <@jrandom> 1) 0.5.0.2 13:06 <@jrandom> 2) mail.i2p güncellemeleri 13:06 <@jrandom> 3) i2p-bt güncellemeleri 13:06 <legion> yani bu IRC sunucularıyla mı ilgili? 13:06 <@jrandom> 4) ??? 13:06 <@jrandom> 0) merhaba 13:06 <@jrandom> haftalık durum notları yayında @ http://dev.i2p.net/pipermail/i2p/2005-March/000633.html 13:07 <fedo> merhaba 13:07 <+postman> merhaba 13:07 <frosk> iyi günler 13:07 <@jrandom> legion: hayır, i2p hatalarıyla ilgili, üzerinde çalışılıyor 13:07 <bla> merhaba 13:07 <legion> tamam 13:07 <@jrandom> üzerinde çalışılan hatalardan söz etmişken, 1) 0.5.0.2'ye geçelim :) 13:07 <cervantes> selam 13:07 <cervantes> -- Bağlantı kesildi 13:08 <@jrandom> heh 13:08 <ant> <mihi> herkese merhaba 13:08 <@jrandom> 0.5.0.2 çıktı ve IRC bağlantınız zaman zaman gecikme yaşasa da toparlanacak ;) 13:08 <@jrandom> vay, selam mihi 13:09 <cervantes> selam mihi 13:09 <@jrandom> durum notları, işlerin nerede olduğuna ve en acil önceliklere genel bir bakış sunuyor 13:10 <@jrandom> peşine düştüğüm korkutucu şeyi http://localhost:7657/oldstats.jsp#router.invalidMessageTime adresinde görebilirsiniz 13:10 <bla> Bana gelince, 0.5.0.2'nin 0.5.0.1'e kıyasla güvenilirliği şimdiden ÇOK artırdığını söyleyebilirim: hedeflere ulaşılamayan hatalar neredeyse hiç olmuyor artık 13:10 <@jrandom> bu sayıların çok çok küçük olması gerekirdi, ama maalesef değiller 13:10 <@jrandom> harika bla 13:11 <@jrandom> evet, 0.5.0.2 kesinlikle bir iyileştirme ve herkesin en kısa sürede yükseltmesi gerek 13:11 <bla> burada son 10 dakikada 375,932.22.... 13:11 <@jrandom> asıl sorun tek tek değerler değil, sıklıkları 13:11 <@jrandom> (dönem başına olay) 13:12 <@jrandom> bu iletiler muhtemelen 0.5 router'lara, bir kısmı da 0.5.0.1 router'lara bağlanabilir; bu yüzden insanların mümkün olan en kısa sürede yükseltmesini istiyorum 13:12 <@jrandom> yine de başka bir şey de olabilir, ama bunu elemek istiyorum 13:12 <bla> jrandom: burada saatte yaklaşık 200 alıyorum 13:13 <@jrandom> bla: şu an bu saatte 93 oldu, ama tepe sayım çok daha yüksek (binler) 13:13 <@jrandom> neyse, bu özel istatistik netdb içinde yayınlanıyor 13:13 <bla> jrandom: 0.5.0.3'ü yayımlarken yazılımsal olarak 0.5-0'ı ağdan dışlamak nasıl olur? 13:14 <@jrandom> böylece hepimiz etrafa bakıp başkalarının hangi değerlere sahip olduğunu görebiliriz ;) 13:14 <@duck> 309,854.24 tepe 5,473,314.59 13:15 <@duck> yanlış olanı yapıştırıyorum, ha 13:15 <@jrandom> bla: kesinlikle. 0.5.0.2 rev'ine 0.5.0.1 ve 0.5'te olmayan bir miktar ileriye dönük uyumluluk eklemek için biraz kod ekledim 13:16 <@jrandom> duck: tam sayı olmayan bir olay sayısına sahip olmak zor ;) 13:16 <bla> jrandom: İyi. En azından geçersiz-iletiler-0.5-0-yüzünden hipotezini kontrollü şekilde test etmeni sağlar 13:16 <@jrandom> bla: aynen, yine de insanlar o zamandan önce güncellerse harika olur ;) 13:17 <@jrandom> (evde okuyanlar için: http://www.i2p.net/download sizin dostunuz ;) 13:17 <maestro^> jr: bu sayılar router.invalidMessageTime sapmaları için ms cinsinden mi? 13:17 <@jrandom> maestro^: evet 13:18 <@jrandom> (yani gerçekten aşırı sapmış değerler) 13:18 <legion> Küçük bir ağ raporu burada [sürüm|Düğüm sayısı][0.5|6][0.5.0.1|39][0.5.0.2|107] 13:18 <@jrandom> evet, güncelleme konusunda harikasınız 13:18 <legion> Demek ki hâlâ 0.5 çalıştıran birkaç kişi ve 0.5.0.1 çalıştıran epey kişi var 13:18 <maestro^> peki nerede gecikiyor olabilirler, bir fikrin var mı? 13:18 <bla> jrandom: Freenet, her sürümde hangi asgari düğüm sürümüyle iletişim kuracağını belirleyen bir bayrak içeriyor. Yeni ileri-uyumluluk kodu buna benzer bir şey mi? 13:19 <@jrandom> maestro^: 0.5 ve 0.5.0.1 kullanıcılarının neden geciktiğine dair bir sürü fikir var. 13:19 <@jrandom> bla: benzer 13:19 <maestro^> yoksa düğümlerde saat kayması mı? 13:20 <@jrandom> maestro^: saat sapması, bazı serileştirme (serialization) hataları, 100% CPU hatası 13:20 <@jrandom> tamam, şu anda genel odağım bu; ileti güvenilirliğini yeniden artırmaya çalışıyorum 13:21 <@jrandom> 0.5.0.2 hakkında soru/yorum/endişe olan var mı? 13:21 <ant> * mihi'nin burada diskte 22 Aralık'tan beri başlatılmamış 0.4.2.5 bir router'ı var... ama silse daha iyi olacağını düşünüyor... 13:21 <@jrandom> heh 13:21 <@jrandom> evet, o pek fazla router ile konuşmayacak ;) 13:21 * postman son 0.4 kurulumunun bir yedek kopyasını aldı :) 13:21 <ant> <mihi> benim için soru yükseltmek mi silmek mi olurdu. 13:22 <@jrandom> sil 13:22 <@jrandom> (herhangi bir hedef anahtarı yedeklenerek) 13:22 <@jrandom> artık 0.5 öncesinden yükseltme prosedürü yok 13:22 <legion> Belki yalnızca 0.5.0.2 veya daha yenilerden bağlantıya izin veren 0.5.0.2-1 gibi başka bir güncelleme çıkarmak iyi olur mu? 13:22 <@jrandom> legion: bu ağı bölümlere ayırır 13:22 <@jrandom> insanlar sadece yükseltmeli. 13:23 <@jrandom> (ve yapmayanlara yönelik çözümler üretmeliyiz) 13:24 <legion> evet, eskimiş düğümleri çalıştıranlar güncelleyene kadar ;) 13:24 <@jrandom> ağı bölmek sadece onları değil, hepimizi yaralar 13:25 <legion> Belki router konsolunda, eski sürüm çalıştırdıklarını haber veren bir güncelleme bildirimi olsa? 13:25 <@jrandom> evet, bu kesinlikle güzel olurdu 13:25 <@jrandom> umarım bu güncelleyiciyle de bağlanabilir 13:26 <legion> evet, biliyorum, bölümlendirme kötü... 13:26 <@jrandom> smeghead bunun bazı ana bileşenleri üzerinde çalışıyor, ama bu bildirim/indirmeyi içeriyor mu emin değilim 13:26 <@jrandom> (buna yardım etmek isteyen olursa, iletişime geçin!) 13:27 <@jrandom> tamam, 2) mail.i2p güncellemeleri'ne geçiyoruz 13:27 <@jrandom> postman: ping 13:27 <+postman> evet 13:27 <bla> jrandom: yanılmıyorsam smeghead imzalama ile ilgili bazı şeyler yapıyordu (böylece bir güncelleme bildirimi aldığınızda en azından gerçek olduğunu, phishing/casus yazılım/zırva olmadığını bilirsiniz) 13:28 * postman mikrofonu devralır 13:28 <legion> hımm, belki yerleşik bir otomatik güncelleme özelliği olsa; güncellemeler I2P üzerinden indirilse ve düğümler güncellemeyi indirip nazik bir yeniden başlatma yapsa. 13:28 <@jrandom> doğru bla 13:28 <ant> <Gatak> Bu arada. Bir port açamasanız bile I2P NAT arkasında çalışır mı? 13:28 <@jrandom> Gatak: henüz değil. bazı insanlar 0.6'da yapabilecek, diğerleri 2.0'da 13:29 <@jrandom> legion: yama kabul edilir 13:29 <ant> <Gatak> 2.0 vay, o epey ileride =) 13:29 <@jrandom> (http://www.i2p.net/roadmap#2.0 ;) 13:29 <+postman> şey, şimdi başlayayım mı? 13:29 <aum> herkese günaydın 13:30 <@jrandom> mikrofon tamamen sende postman (üzgünüm ;) 13:30 <@jrandom> 'lo aum, toplantıya yetiştin 13:30 <@jrandom> (ah be! /me shuts up again) 13:30 <cervantes> Gatek: http://www.i2p.net/roadmap 13:30 <+postman> öncelikle, postman.i2p'de kayıtlı 300 hesaba ulaştığımızı söylemek istedim 13:30 <@jrandom> w00t 13:30 <+postman> İnternet'ten/İnternet'e gelen/giden e-postaların sayısı istikrarlı biçimde artıyor ve bu da daha ileri gitmemiz gerektiğini bir kez daha kanıtlıyor 13:31 <cervantes> *squeeeel* 13:31 <+postman> birkaç hafta önce jr ile konuştuktan sonra v2mail'in I2P 1.0 ile birlikte yayımlanması konusunda anlaştık 13:31 <+postman> son durum: her düğümde çalışacak şekilde tasarlanan Java tabanlı SMTP proxy tamamlandı 13:31 <@jrandom> güzel! 13:32 <+postman> Java tabanlı POP3 proxy %80 seviyesinde; yalnızca maildir motoru eksik 13:32 <+postman> bir de web manager olacak; hâlâ ciddi ince ayar gerektiriyor (%15 tamam) 13:32 <+postman> düğümler arası iletişim %40 seviyesinde - HTTP/XML ile bazı veri kayıtı alışverişlerini test ettik 13:33 <+postman> oldukça iyi ve hatta hızlı çalışıyor gibi 13:33 <+postman> bir relay düğümü birkaç gün arızalansa/kapatılsa bile tekrar çevrimiçi olduktan sonra birkaç dakika içinde eşitlenecek 13:33 <@jrandom> harika 13:33 <+postman> bence iyi bir şekilde yoldayız 13:34 <+postman> dikkat edilmesi gereken bir şey var 13:34 <bla> postman: Harika iş dostum! Bir soru: Birçok düğüm 25 numaralı porttan veri alamıyor veya gönderemiyor (en azından doğrudan). Düğüm sahipleri bunu belirtebilecek mi (yoksa otomatik algılanacak mı)? 13:34 <cervantes> harika 13:34 <+postman> bla: sonra 13:34 <+postman> v2mail'de yerel olarak çalışan bir web uygulaması olacak 13:34 <+postman> bununla yerel proxy'lerinizi yönetebilir VE bir 'relayaccount' için başvurabilirsiniz 13:35 <+postman> bu relayaccount daha sonra adresinizi/alan adınızı relay'lere iliştirmek için kullanılacak 13:35 <+postman> relay'ler bilgiyi otomatik olarak eşitleyecek 13:35 <@jrandom> harika 13:35 <+postman> adres defteri / açık anahtarlar ve benzeri özellikler bile YEREL arayüzle çalışacak 13:36 <+postman> yani fikir, tüm posta işlerinizi yapabileceğiniz tek bir merkezî yöneticiye sahip olmak 13:36 <+postman> ilgili veriler relay'lerden BİRİNE aktarılır ve ardından relay'ler arasında eşitlenir 13:36 <+postman> ve bu web tabanlı yönetici doğrudan sizin düğümünüzde çalışacak 13:37 <+postman> düğümünüz çevrimiçi olduğunda, relay'ler hedefiniz/alan adınız/adresiniz için kuyrukta bekleyen e-postaları teslim edecek 13:37 <+postman> bu, yerel SMTP proxy'nize teslim edilecek 13:37 <+postman> hatta tüm süreci ETRN ile tetikleyebilirsiniz :) 13:37 <aum> yeniden merhaba 13:37 <aum> uygunsa bu toplantıda bir tartışma konusu açmak isterim 13:37 <+postman> gelecek hakkında şimdilik bu kadar arkadaşlar :) 13:37 <+postman> . 13:38 <@jrandom> kulağa süper geliyor postman 13:38 * postman mikrofonu geri verir 13:38 <@jrandom> aum: harika, 4)'te biraz zaman olmalı 13:38 <+postman> evet, çok mutluyum :) 13:38 <@jrandom> postman: yani normal kullanıcı için, SMTP proxy yerel maildir'e sahip olacak ve POP3 proxy okuyacak vs., doğru mu? 13:39 <+postman> evet, SMTP proxy'nin bir MDA'sı var 13:39 <+postman> ve postayı yerel maildir'lere teslim edecek 13:39 <+postman> hatta yerelde birden fazla hesap/kullanıcı oluşturulabilir 13:39 <cervantes> postman: relay'ler kotalarınızı vb. takip edip bu bilgiyi aralarında yayacak mı? 13:39 <+postman> ve alan adınızdaki hesaplara eşlenecek 13:39 <+postman> cervantes: evet, yapacaklar 13:39 <septu_ssh> affedersiniz, yeni modelde ödeme/anti-spam mekanizmaları hakkında postman'e sorabilir miyim? 13:40 <+postman> septu_ssh: web sayfasındaki belgelerden herhangi birini okudunuz mu? 13:40 <+postman> cervantes: bu mükemmel gerçek zamanlı değil 13:40 <+postman> cervantes: ama kota bilgi alışverişinin birkaç dakikalık gecikmeyle güncellenmesi benim için sorun değil 13:40 <septu_ssh> okuma sırasına aldım :/ 13:40 <septu_ssh> ama belgelendiyse sorun yok 13:40 <cervantes> postman: evet, öyle düşündüm 13:41 <+postman> septu_ssh: www.postman.i2p/inout.html 13:41 <+postman> septu_ssh: www.postman.i2p/mailv2.html 13:41 <+postman> cervantes: bu gerçekten bir dram değil - kota makul bir sınır 13:41 <cervantes> postman: birinin nrelays * kota kadar alıcıya gönderebilmesi bile kötü bir şey değil 13:41 * septu_ssh bungle'dır 13:41 <+postman> cervantes: evet 13:42 <+postman> amaç sadece birinin hizmeti gerçekten istismar etmesini engellemek 13:42 <+postman> testlerde 3 relay gerçekten hızlıydı 13:42 <@jrandom> postman: unutuyorum, bu, yerel SMTP relay'inizin, sizin düğümleriniz üzerinden sekmek yerine bir başkasının SMTP relay'iyle doğrudan konuşmasını destekleyecek mi? 13:42 <+postman> cervantes: 10 saniye içinde eşitlenmişlerdi :) 13:43 <@jrandom> (ya da belki bu daha sonraya) 13:43 <+postman> jrandom: i2p posta relay'leri birkaç kişi tarafından işletilecek ve postayı yönlendirmek için tercih edilen hedefler olacak 13:43 <cervantes> postman: gönderim kuyruğuna üstel bir gecikme ekleyebilirsin 13:43 <cervantes> eğer sorun haline gelirse 13:43 <+postman> jrandom: yani diğer hedeflere gönderim belirli durumlarda kullanışlı olabilir 13:44 <@jrandom> evet, ama başka durumlarda tehlikeli 13:44 <cervantes> yani ne kadar çok posta gönderirsen, postanın kuyruğa alınma süresi o kadar artar... relay'lerin yetişmesi için zaman tanımalı 13:44 <+postman> jrandom: ama bir düğümün sahibi IMIO hedefini açık ederse denetimsiz şekilde spam alabilir :) 13:44 <@jrandom> aynen 13:44 <@jrandom> öte yandan, i2p posta relay'leri düşmancıl ise de aynı şey geçerli 13:45 <+postman> jrandom: evet, bu WOT benzeri bir yapı 13:45 <@jrandom> </tinFoil> 13:45 <+postman> jrandom: bir relay operatörünün adresiniz için 0 kota dağıtmasını engelleyemem 13:45 <@jrandom> 'k harika. evet, şimdilik endişelenmeye gerek yok 13:45 <+postman> :) 13:46 <+postman> tamam 13:46 <+postman> . 13:46 <@jrandom> tamam, güncelleme için teşekkürler. gerçekten heyecan verici şeyler 13:46 <@jrandom> tamam, 3) i2p-bt güncellemeleri'ne geçiyoruz 13:46 <@jrandom> duck: ping 13:46 <@duck> merhaba 13:47 <@duck> Dün BitTorren 4.0.0 yayımlandı 13:47 <ant> <dm> Almanca gibi geliyor 13:47 <@duck> 0.2'ye başlamadan önce az çok bunu bekliyorduk 13:47 <@duck> bir görev listesi / yapılacaklar yazdım: http://pastebin.ca/raw/7037 13:47 <@duck> (üzgünüm, web sitem şu an kapalı) 13:48 <@jrandom> güzel 13:48 <legion> 0.2 için nasıl bir zaman çizelgesinden bahsediyoruz? 13:48 <@duck> hedef 4 haftaydı 13:49 <legion> güzel 13:49 <@duck> gördüğünüz gibi RawServer (I2P ile iletişim kuran kısım) en büyük iş 13:50 <@duck> . 13:50 <@duck> hızlı bir yoklama: 13:50 <legion> evet, bunun gayet farkındayım :) 13:50 <@duck> i2p-bt için fork oluşturmayı kim planlıyor? 13:50 <@jrandom> güzel, insanların yardımcı olmak için yapabileceği bir şey var mı? 13:50 <@jrandom> heh 13:51 <ant> <dm> ben 13:51 * jrandom bir kaşık kapar 13:51 <ant> <dm> yardım etmeye istekliyim 13:51 <legion> ben 13:51 <ant> <dm> ben gayim 13:51 <legion> bir fork üzerinde çalışıyorum 13:52 <@duck> iyi, o zaman ciddiye alınmayacakların kimler olduğunu biliyorum. 13:52 <@duck> gerçekten, bence bu saçma; kaynakları birleştirmek sizi çok daha ileri götürebilir 13:53 <@jrandom> ya da belki daha iyi yollar varsa, duck'ı o şekilde çalışmaya ikna edebilirsiniz? 13:53 <named> qbasic ile bir fork yazacağım, lütfen beni ciddiye alın. 13:53 <@duck> süreci daha açık hale getirmeye çalışacağım, böylece başkaları nelerin planlandığını görebilir vs 13:53 <ant> <dm> açıklığın bize etki etmiyor. FORK! FORK! FORK! FORK! 13:53 <@duck> başka önerileriniz varsa 13:54 <ant> * dm, legion'ı omuzlarına kaldırır. 13:54 <legion> hımm, bu doğru olabilir, ancak yaptığım işle ana i2p-bt geliştirme sürecini kirletmemi istemeyeceğinizden şüpheliyim ;) 13:54 <ant> <dm> FORK! FORK! FORK! FORK! 13:54 <@jrandom> legion: duck'ın desteklemek istemeyeceği ne yapıyorsun? 13:55 <@duck> legion: tebrikler, 'i2p bittorrent' diye Google'da ararsan, 'Windows I2P Bittorrent Version 1.0' duyurusu 1 numara 13:55 <@jrandom> aman 13:56 <bla> jrandom: Evet? 13:56 <+postman> jrandom: evet, yakında bu ağı darmadağın edecekler :) 13:56 <bla> ;) 13:56 <named> 1.0 mı? Kahretsin, ben 0.1.8 kullanıyorum! 13:56 <Ragnarok> oy 13:57 <legion> omfg, gerçekten mi?! İnanamıyorum... bu delilik. 13:57 <@duck> neyse, bunun hakkında söyleyecek çok yeni bir şey olduğunu sanmıyorum 13:57 <legion> 1.0 sürümüm 0.1.8'e dayanıyor, 0.1.8 çalıştırıyorsanız sorun yok. 13:58 <@jrandom> (ve 1.0 sürümü kimsenin incelemediği bir .exe, sonuçlarınız değişebilir) 13:58 <legion> Kötü adlandırıp numaralamışım, özür dilerim, bunun için tekrar kusura bakmayın. 13:58 <ant> <dm> 1.0>> 0.1.8 13:58 <ant> <dm> her gün 13:59 <@duck> az ilgili: 13:59 <@jrandom> tamam, 3) i2p-bt hakkında başka bir şey var mı, yoksa 4) ???'ye geçelim mi? 13:59 <+postman> legion: kaynak kodu ne zaman indirilebilir olacak? 13:59 <frosk> "I2P-BT 0.1.8 şimdiye kadar gayet iyi ve kararlı çalışıyor. Şahsen I2P-BT 1.0'a güncellemek için bir sebep görmüyorum" (forumda görüldü) 13:59 * jrandom iç çeker 13:59 <@duck> geçen ay bram cohen bir üniversitede bittorrent hakkında bir konuşma yaptı 14:00 <@duck> oldukça ilginç: http://netnews.nctu.edu.tw/~gslin/tmp/050216-ee380-100.wmv.torrent 14:00 <@duck> (büyük p2p programlarından çıkarılan dersler, ayrıca bazı bittorrent ayrıntıları açıklandı) 14:00 <@duck> . 14:01 <@jrandom> peki 14:01 <@duck> postman: legion biraz kaynak kodu yayımladı 14:01 <ant> <dm> BT'nin mucidi o mu? 14:01 <@duck> ama smeghead'e göre .exe ile aynı değil 14:01 <@jrandom> dm: evet 14:01 <legion> http://legion.i2p/archives/Itorrent_1_x_Developer_Source.zip.bz2 adresinden indirebileceğiniz bir geliştirici kaynak paketi var 14:02 <+postman> tamam, bakacağım 14:02 <ant> <dm> .exe o kaynağın doğrudan derlenmiş hâli mi? 14:03 <legion> gerçi 1.0 kaynağı aslında sadece smeghead'den bir yamayla 0.1.8; derlenmiş ve güzel paketlenmiş. 14:04 * cervantes 4)???'ye doğru yürür ve herkesin yetişmesini bekler 14:04 <ant> <dm> soru hâlâ yanıtlanmadı 14:04 <ant> <dm> Legion, sen code red emri verdin mi vermedin mi??? 14:04 <@jrandom> *öksürür* 14:04 <legion> Belki konuya dönmeliyiz, bt istemcisi tartışmam #itorrent'e taşındı 14:05 <@jrandom> tamam, 4) ??? 14:05 <@jrandom> başka gündeme getirmek istediğiniz bir şey var mı? 14:05 <@jrandom> aum: bir şeyin vardı? 14:06 <ant> <dm> stasher geri mi döndü? 14:06 <legion> 0.5.0.2 ile yoğun trafik dönemlerinde garip davranışlar görüyorum... 14:06 <aum> evet 14:06 <aum> otomatik tunnel oluşturma/yönetimi konusunu gündeme getirmek istiyorum 14:07 <ant> <dm> devam et 14:07 <+detonate> Windows'ta sistem tepsisi işinde bir null pointer exception var, az önce fark ettim 14:07 <aum> web konsolunun artık insanların tunnel'ları elle oluşturmasına/silmesine/yönetmesine izin vermesi 1337 14:07 <@jrandom> detonate: onu bugzilla'ya atabilir misin? 14:07 <aum> ama ayrıca programların da tunnel'ları yönetmesi için her zaman güvenilir ve kullanışlı bir yol olması gerektiğine güçlü şekilde inanıyorum 14:08 <@jrandom> aum: kimse katılmıyor değil. buna ihtiyacımız var ve olacak. sadece henüz değil. 14:08 <ant> <dm> bunu SAM üzerinden yapamaz mısın? 14:08 <aum> yakın zamanda i2p'ye dönüşümde pysam kütüphanesinin artık çalışmadığını fark ettim 14:08 <septu_ssh> aum'dan sonra benim de hızlı bir sorum var 14:08 <aum> bu bir hayal kırıklığıydı 14:08 <@jrandom> SAM protokolü çalışıyor, pysam çalışmıyor 14:08 <Ragnarok> hiç çalışmış mıydı? 14:09 <aum> doğru 14:09 <aum> pysam eskiden mükemmel çalışıyordu 14:09 <legion> Bu tür dönemlerde düğümümün katıldığı 1000+ tunnel oluyor ve birkaç saniyelik gecikme ve bekleme var. 14:09 <@jrandom> legion: evet, tunnel sayısı eski build'lerden dolayı 14:09 <cervantes> ah mymodesty 14:09 <cervantes> ııh pymodesty 14:09 <aum> şu anda 'i2ptunnel.py' adlı bir modül yazıyorum; bu, kolay tunnel yönetimine izin veren sınıflar tanımlıyor 14:10 <legion> yani eski build'lere bağlanılmasaydı ağ çok daha akıcı mı olurdu? 14:10 <@jrandom> 'k, bunun uzun vadeli doğru çözüm olup olmadığını bilmiyorum, ama şu an aradaki boşluğu kapatıyorsa, harika 14:10 <@jrandom> legion: sorun o tunnel'lar değil 14:11 <aum> şey, alttaki mekanizma değişse bile sınıf arayüzleri kalabilir 14:11 <@jrandom> 'k 14:11 <legion> değiller mi? 14:12 <legion> Az sayıda tunnel olduğunda gecikme ve bekleme çok az... 14:12 <cervantes> legion: üzgünüm, aum sadece bazı sorular soruyor, bir dakika beklersen 14:12 <legion> bana garip geliyor. 14:13 <legion> tamam 14:13 <@jrandom> geçmişte başarılı olanı da dikkate almamız gerektiğinden endişeliyim - web yapılandırması çalışıyor ve herkes kullandığı için bakım görüyor. belki üzerinde çalıştığın uygulamayı önce elle tunnel oluşturmayla çalışır hale getirmek en iyisi olur, bu daha verimli olur? 14:13 <@jrandom> böylece i2ptunnel.py'yi kullanan ve onu strese sokan bir şey her zaman olur 14:13 <aum> sanki kilitleniyoruz 14:13 <+detonate> jrandom:tabii 14:14 <ant> <dm> o hâlde devam edelim 14:14 <aum> güvenebileceğim bir tunnel yönetim API'sı olmadan uygulamamı geliştirmeye zaman harcamak istemiyorum 14:14 <septu_ssh> \o. - gündeme getirecek madde 14:14 <cervantes> gerçekçi olmak gerekirse, tunnel arayüzünün önümüzdeki birkaç ay içinde yenileneceğini hayal edemiyorum... 14:14 <@jrandom> ama eminim ki bunu kolayca ekleyebileceğimizi görüyorsun 14:14 <cervantes> yani geçici bir çözüm uygulanabilir 14:15 <named_> Web yapılandırmasının, aum'un programının manipüle edebileceği türden bir API'si olamaz mı? 14:15 <@jrandom> named_: evet 14:16 <@jrandom> URL'ler aracılığıyla güvenli kontrolü sağlamak için bir şey eklemek önemsiz derecede kolay, ama bunu gerektiren bir şey varsa anlamlı 14:16 <@jrandom> aksi takdirde sadece çürür 14:16 <aum> named_: bu güzel olurdu ve yapılandırmada sabit kodlanmış bir parola olup istemci programların tunnel kontrol alanlarıyla birlikte POST etmesi gerekse işe yarayabilir 14:16 <cervantes> şahsen tüm tunnel sisteminin tamamen yenilenmesini isterim; baştan bir tunnel yönetim arayüzü dahil edersen, ayrı bir arayüzü sürdürmek için gereken ekstra çabayı dert etmene gerek kalmaz 14:17 <@jrandom> evet, proxy'lerin bir sürü çalışmaya ihtiyacı var, ki ben mümkün olduğunca bundan kaçınıyordum :) 14:17 <aum> SAM bazı durumlarda iyi, bazılarında kötü 14:17 <cervantes> ama bu biraz ileride... 14:17 <fedo> ( 14:18 <@jrandom> aum: ama geçici olarak, mevcut üç yöntemden birini kullanamaz mısın? 14:18 <cervantes> yani web arayüzünün kendisi API'yi kullanırsa bakım yükü olmaz 14:18 <@jrandom> doğru. web arayüzü TunnelControllerGroup kullanır 14:19 <aum> SAM kullanımı, standart TCP soketlerine yoğun biçimde bağımlı mevcut kütüphaneleri kullanmak istediğinizde zorlaşıyor 14:19 <aum> jrandom: I2PTunnel CLI, server tunnel'ları açmada çalışmıyor; bu yüzden şu anda TunnelControllerGroup kullanmak için kod yazıyorum 14:19 <@jrandom> aum: mevcut kütüphanelerin dikkatle denetlenmesi gerekir. örneğin, gzip yardımcı programının kendisi hassas verileri ifşa ediyor 14:19 <aum> konuşurken kod yazıyorum 14:21 <@jrandom> CLI'nin server tunnel'ları için çalıştığından eminim, ama böyle ihtiyacın varsa TunnelControllerGroup kullanmak tercih edilir 14:21 <@jrandom> tamam, gündeme getirecek başka bir şeyi olan var mı? 14:22 <septu_ssh> Sorunum hosts.txt'nin dağıtık bir sürümüyle ilgili; şu anda routerInfo için bir DHT tablosu kullanılıyor, bu DNS'in dağıtık bir sürümüne genişletilemez mi? DNS DHT, www.bla.i2p'den eepsite SHA'ya eşlemeler içerebilir ve girdiler bir 'I2P registrar' tarafından imzalanır... yorumlar? itirazlar? 14:22 <mancom> yol haritasıyla ilgili bir soru: 0.6 hâlâ nisan için planlı mı? 14:22 <@jrandom> septu_ssh: yönlendirme dışı veri netDb'ye ancak cesedimi çiğneyerek girer ;) 14:23 <septu_ssh> jrandom: aynı veritabanı değil 14:23 <septu_ssh> farklı bir dağıtık veritabanı 14:23 <aum> jrandom: hata raporumu gördün mü? CLI 'server' komutu /çalışmıyor/ 14:23 <maestro^> septu_ssh: i2p registrar diye bir şey yok 14:23 <@jrandom> septu_ssh: adlandırmanın birçok tehlikeli yönü var ve birkaç kritik ödün içeriyor. ugha.i2p'deki adlandırma tartışmasını gördün mü? 14:24 <@jrandom> septu_ssh: ah, I2P'nin üzerinde bir DHT elbette girdileri dağıtmak için kullanılabilir, ancak bu adlar küresel girdiler olarak ele alınırsa güvenli olmaz 14:26 <@jrandom> aum: birkaç hafta öncesine kadar her gün kullanıyordum, yanıtımı gördün mü? 14:26 <@jrandom> maestro^: plan bu 14:26 <@jrandom> ee, mancom: 14:26 <cervantes> aum: jr'dan gelen o i2plist e-postasına bir yanıtım var; sana ulaşmadı mı, yoksa sorun devam ediyor mu? 14:26 <septu_ssh> bir 'registrar' önermemin tek nedeni, aksi halde çakışmaların meydana gelebilmesi 14:26 <@jrandom> septu_ssh: çakışmaları kucakla :) 14:26 <@jrandom> küresel olarak benzersiz, insan tarafından okunabilir, dağıtık ve güvenli adlandırma diye bir şey yok 14:27 <septu_ssh> bu, hosts.txt elle düzenlenirse orada da olabilir; ama sorun aynı kalır 14:27 <@jrandom> ilk parametreden vazgeç, gerisi tamam 14:27 <aum> jrandom: yanıtını gördüm - ve cp'mde streaming.jar /var/ 14:27 <septu_ssh> postman, postman'in outproxy'leri (I2P dışa çıkış vekil sunucuları) ve inproxy'leri (I2P içe giriş vekil sunucuları) için merkezî bir öğe olarak hareket ediyor, yani ağ içinde bir güven unsuru var; ad alanını yönetmesi için birine güvenmezler mi? 14:28 <@jrandom> tamam güzel, ve hâlâ o stacktrace ile mi dönüyor aum? 14:28 <aum> evet 14:28 <@jrandom> septu_ssh: postman yalnızca postman'in outproxy'leri ve inproxy'leri için merkezî bir öğe olarak hareket ediyor 14:28 * Ragnarok'un artık şu adres defteri belgesini yazması gerekiyor... 14:28 <aum> bu, CLI'yi elle çalıştırıp genkeys yapıp sonra genkeys'in ürettiği privkeyfile'ı kullanarak 'server' yaptığımda oluyor 14:28 <@jrandom> septu_ssh: kimse bir ad alanını yönetmesi için kimseye güvenmeyecek. sansür == o registrar üzerinde baskı kurmak. 14:28 <maestro^> aslında herkes kendi registrar'ıdır 14:29 <maestro^> siz arkadaşlarınıza güvenirsiniz, onlar da size 14:29 <aum> lanet olsun, eski bir classpath almışım 14:29 * aum tekrar test eder 14:30 <ant> <dm> tamam, ben registrar olacağım. 14:31 <ant> <dm> olabildiğince tarafsız olacağım... uygun mu? 14:31 <septu_ssh> hmmm, tamam, o hâlde meşhur çizim tahtasına geri... 14:31 <@jrandom> septu_ssh: gözden geçirmek için iyi bir yer: http://zooko.com/distnames.html :) 14:32 <@jrandom> herkes bunu istiyor, ama istedikleri şey güvenli değil. güvenli olan bir çözümümüz var, ama küresel benzersizliği feda ediyoruz 14:33 <septu_ssh> hmmm, tamam 14:33 <@jrandom> tamam, toplantı için başka gündeme getirecek bir şey olan var mı? 14:33 <cervantes> septu_ssh: http://forum.i2p.net/viewtopic.php?t=134 14:33 <aum> jrandom - tamam, CLI 'server' şimdi çalışıyor, ama tunnel için hiç 'job number' almadım 14:34 <@jrandom> hmm doğru, sonsuza dek çalışır 14:34 <aum> ah, 'list' yapıp iş numarasını almam gerekiyor 14:36 <@jrandom> tamam, güzel, başka bir şey yoksa... 14:36 * jrandom toparlanır 14:36 * jrandom *baf* toplantıyı kapatır