I2P Geliştirici Toplantısı - 12 Eylül 2006

16:06 <jrandom> 0) merhaba 16:06 <jrandom> 1) 0.6.1.25 ve ağ durumu 16:06 <jrandom> 2) I2PSnark 16:06 <jrandom> 3) Syndie (ne/niçin/ne zaman) 16:06 <jrandom> 4) Syndie kripto soruları 16:06 <jrandom> 5) ??? 16:06 <jrandom> 0) merhaba 16:06 * jrandom el sallar 16:06 <jrandom> haftalık durum notları http://dev.i2p.net/pipermail/i2p/2006-September/001307.html adresinde yayınlandı 16:07 <jrandom> bu notlar saatler önce ortaya çıktığından, hepiniz onları çoktan okuyup notlarını hazırlamış olmalısınız, değil mi? ;) 16:07 <jrandom> 1) 0.6.1.25 ve ağ durumu'na atlayalım 16:08 <vulpine> <Complication> 0.6.1.25 ile ilgili olarak burada gayet iyi çalışmış görünüyor, sadece daha önce görmediğim tek bir hata var 16:08 <jrandom> harika, sorun ne? 16:08 <vulpine> * Complication günlükleri arıyor 16:09 <jrandom> ağın boyutu öncekinden büyük görünüyor, gerçi hâlâ aynı mertebede 16:09 <vulpine> <Complication> "Unknown error reading the net.i2p.data.i2np.GarlicMessage: wtf, fromLong got a negative? -840" 16:10 <vulpine> <Complication> Şununla başladı: "ERROR [NTCP read 1 ] .router.tunnel.FragmentHandler: Error receiving fragmented message (corrupt?)" 16:10 <jrandom> ah tamam süper, o uzun zamandır var, yok saymak güvenli 16:11 <vulpine> <Complication> Tek bir kez meydana geldi 16:11 <vulpine> <frosk> sonuncusundan birkaç tane aldım 16:11 <vulpine> * jrandom fox'u dürter 16:12 <vulpine> <Complication> Ah, bir tane daha: "router.tunnel.TunnelDispatcher: wtf, took 1121 to dispatch net.i2p.data.i2np.TunnelBuildMessage@XXXX out YYYYY in net.i2p.router.tunnel.PumpedTunnelGateway@ZZZZ" 16:12 <vulpine> <Complication> (bu da önemsiz görünüyor, belki basit bir tıkanıklık) 16:12 <jrandom> evet, muhtemelen 16:13 <jrandom> irc şu anda belli ki hâlâ biraz sıkıntılı 16:13 <jrandom> (ama bu seferlik, i2p'nin suçu değil :) 16:14 <jrandom> tamam, 1) Ağ durumu ve 0.6.1.25 için başka bir şey var mı? 16:15 <kostya213> sadece .25'in son birkaç aydır yaşadığım tüm sorunları düzelttiğini eklemek istiyorum 16:15 <jrandom> müthiş! 16:16 <vulpine> <green> lütfen, yalnızca NTCP kullanılırken durum hesaplamasını değiştir 16:16 <jrandom> 'k, ama udp'yi devre dışı bırakmak önerilmez (sanırım insanlara udp'yi nasıl devre dışı bırakacaklarını söylemeyeceğimi açıkça belirtmiştim) 16:17 <jrandom> ama udp'nin tek taşıma olmadığı göz önüne alınacak şekilde durum güncellenmeli 16:17 <jrandom> bunu bir sonraki revizyonda düzelteceğim, teşekkürler 16:17 <vulpine> <green> jrandom : elbette söylemiyorsun, ama ben kod okuyabiliyorum ;) 16:18 <jrandom> doğru, ancak bir şeyi önermediğimde ve insanlara denememelerini söylediğimde, ekranda kafa karıştırıcı bir mesaj çıkarsa şaşırma ;) 16:19 <vulpine> <green> tabii, konsolda da sadece "OK" gösterebilirim :) 16:19 <jrandom> doğru, yeter 16:21 <jrandom> tamam, 2) I2PSnark konusuna atlayalım 16:21 <jrandom> zzz şu an orada değil gibi görünüyor 16:22 <jrandom> zzz'nin i2psnark'taki zamanlamayı iyileştirmek için üzerinde çalıştığı bazı değişiklikler var 16:23 <jrandom> (şu anda hatırladığım kadarıyla biraz... basit, gerçi zzz'nin üzerinde uğraştığı değişikliklerden tam emin değilim) 16:23 <jrandom> ((ama ilerlemeyi dört gözle bekliyorum!)) 16:25 <jrandom> tamam, 2) I2PSnark hakkında başka bir şey yoksa, 3.*) Syndie işleri'ne geçelim 16:26 <jrandom> ele alınacak çok şey olduğundan, önce 3.1) syndie nedir'e girelim 16:27 <jrandom> toplantıdan önce gönderilerin şifrelenmesiyle ilgili birkaç soru aldım 16:27 <jrandom> temelde, gönderiler *symmetrically* şifrelenir - simetrik anahtara sahip olan herkes gönderiyi okuyabilir, çünkü yetkilidir 16:28 <jrandom> kanal yanıtları kanal/forum ile ilişkili genel anahtara asimetrik olarak şifrelenir 16:28 <jrandom> bazı gönderiler okumak için simetrik anahtarı üretmek amacıyla parola tabanlı şifreleme kullanabilir 16:29 <jrandom> ve bazı gönderiler simetrik anahtarı, gönderinin okunabilir başlıklarına dahil edebilir (böylece herkes okuyabilir) 16:29 <modulus> sonuncusunun amacı ne? 16:29 <jrandom> ve bazı forumlar simetrik anahtarı forumun üst verilerine dahil edebilir; böylece herkes gönderiyi okuyabilir ama yalnızca kanal üst verilerine sahipse 16:29 <jrandom> modulus: böylece herkese açık okunabilen şeyler bile daima şifrelenmiş olur 16:29 <jrandom> (basit dinlemeyi işe yaramaz kılmak için) 16:30 <modulus> doğru, anladım. 16:31 <jrandom> tamam, sanırım bu toplantıdan önce sorulan şifreleme sorularını kapsıyor 16:31 <jrandom> 3.1) syndie nedir konusunda sorusu olan var mı? 16:31 <jrandom> (Yani, dışarı yayıldıkça daha fazlası netleşecek elbette) 16:32 <vulpine> <void> hmm 16:33 <jrandom> que tal void? 16:33 <vulpine> <void> <void> sanırım ileti (.zip) arşivi, alıntılanan iletiler gibi, muhtemelen başkalarından gelen diğer iletileri de içerebilir? 16:34 <jrandom> şey, evet, .snd dosyalarını ek olarak dahil edebilirsiniz, ancak açık bir ad alanı var; dolayısıyla önceki iletilere standart References: tarzı bağlantılar yapabilirsiniz 16:34 <jrandom> (yani frost tarzı "threading" yapmak zorunda değilsiniz) 16:35 <vulpine> <void> tamam, doğru 16:37 <vulpine> <Complication> Syndie hakkında, insanların birden fazla yazarlı bir foruma (sıradan bir mesaj panosundaki hesaplar gibi) kişilere erişim vermeyi nasıl çözeceğini, fakat bunu geri döndürülemez biçimde vermeden ve erişimi iptal etme gereği doğduğunda (her ne sebeple olursa) istenmeyen karmaşadan kaçınarak nasıl yapacağını merak ediyordum 16:38 <vulpine> <Complication> Elbette, bir çözüm olarak, yazarın istemcilerin kimin yanıtlarını göstermesi gerektiğine dair bir öneri belirtmesi göründü 16:38 <jrandom> Complication: yeni bir genel/özel anahtar çifti oluştur, özel anahtarı (geçici olarak) yetkilendirilmiş kişilere ver ve genel anahtarı da "keys allowed to post" listesi olarak dahil et 16:38 <vulpine> <Complication> ..ve istemcilerin, geçmişi araştırmak istemedikçe, bu öneriyi (daha doğrusu en son sürümünü) takip etmesi 16:38 <jrandom> (ve artık yetkileri kalmadığında, o anahtarı "keys allowed to post" listesinden çıkar) 16:39 <kostya213> jrandom: .snd, ses uygulamalarında yaygın kullanılan bir uzantı olduğu için, .snd yerine farklı bir uzantı kullanmak isteyebilirsin; mime bunu karıştıracaktır 16:39 <jrandom> ah, doğru - tüm forumların, kimlerin gönderi yapmasına izin verildiği listesini yönetebilen bir "owner"ı (imza atan özel anahtar) var, vb. 16:39 <vulpine> <Complication> "keys allowed to post", yazarın en son gönderisine veya başka bir iletiye ekli üst veri olurdu, doğru mu? 16:39 <jrandom> iyi nokta kostya213, gerçi o zaman .dat'e takılı kalabiliriz ;) 16:40 <jrandom> Complication: ah üzgünüm, hayır, mevcut/eski syndie gibi - forum/kanalın kendisi için ayrı imzalı üst veri gönderileri var 16:40 <vulpine> * Complication, birilerinin .dat'i bile bir şey için sahiplendiğine inanıyor :) 16:40 <jrandom> evet, "octet-stream" adlı uygulama ;) 16:40 <vulpine> <void> .syn'in kayda değer bir şey için kullanıldığı görünmüyor 16:41 <vulpine> <Complication> Aha, özel üst veri gönderileri... doğru, bu işi görebilir 16:41 <jrandom> oh harika, syn'e geliyoruz! 16:41 <jrandom> (iyi göz void, teşekkürler kostya213) 16:41 <vulpine> <void> hmm, " 16:41 <vulpine> <void> hmm, "Word Synonym File", Şirket: Microsoft 16:42 <jrandom> şey, eminim bunun bir yolunu bulacağız 16:42 <kostya213> evet, Word tarafından kullanılıyor 16:42 <vulpine> <void> ama bunu görmezden gelebiliriz :) 16:42 <kostya213> ümidi kesmeyin, yaygın kullanılan MIME türleriyle sorun çıkarmayacak bir şey bulmanın mümkün olduğunu düşünüyorum 16:43 <jrandom> tamam, 3.1) syndie nedir hakkında başka bir şey? 16:43 <vulpine> <void> ee, ama neden üç harfli uzantılara takılı kalalım ki? bu DOS çağından kalma bir kalıntı 16:43 <kostya213> sorulması gereken bir şey: neden üç harfli uzantıyla sınırlayalım? artık kimse DOS kullanmıyor 16:44 <jrandom> heh 16:44 <kostya213> void ile aynı anda, jinx 16:44 <kostya213> .syndie bana iyi görünüyor 16:44 <vulpine> <void> .synd hiçbir şeyle çakışmaz 16:44 <kostya213> o da iyi 16:45 <vulpine> <void> lanet gecikme :( 16:48 <jrandom> tamam, 3.2) Neden Syndie önemli? konusuna atlayalım 16:48 <vulpine> <void> jrandom: bekle 16:48 <cervantes> (çünkü öyle söylediğin için) 16:48 * jrandom bekler 16:48 <jrandom> !thwap cervantes ;) 16:48 <vulpine> <void> durum notları gönderisi, bir iletiye bir avatar eklenebileceğini, aksi halde varsayılanın kullanılacağını belirtiyor 16:49 <vulpine> <void> ama ya bir kişi tek bir "varsayılan" yerine birkaç önceden tanımlı avatar istemek isterse? 16:49 <jrandom> evet, yazar kendi kanalının üst verilerine bir varsayılan avatar ekleyebilir 16:49 <vulpine> <void> diğerini her seferinde eklemek verimli olmayacak 16:50 <jrandom> iyi soru void - notlardaki o betik koduna geçelim 16:50 <jrandom> listauthkeys --authorizedOnly true 16:50 <jrandom> authenticate 0 16:50 <vulpine> <void> (?) 16:50 <jrandom> listauthkeys, kendisi olduğunu söyleyerek iletinin altını imzalayabileceğin tüm kimlikleri gösterecek, "authenticate 0" ise imzalamak için bir kimlik seçer 16:51 <jrandom> yani, o kimliğin kendi kanalı var ve o kanalın kendi üst verisi var; buna bir avatar dahil olabilir 16:51 <vulpine> <void> hmm, ayrı bir kimlik ayrı bir anahtar çifti mi demek? 16:51 <jrandom> evet 16:51 <vulpine> <void> peki bir kişi tek bir kimlikte birkaç avatar bulundurmak isterse? 16:52 <jrandom> kanallarının üst verisinde varsayılan bir avatarları olur ve bunu ileti bazında geçersiz kılabilirler 16:52 <kostya213> şüpheli fayda 16:52 <vulpine> <void> arasından seçebileceği birkaç "varsayılan" avatar 16:52 <vulpine> <void> yoksa pireyi deve mi yapıyorum? :) 16:53 <jrandom> ah, ne demek istediğini anladım. yok, ilk başta desteklenmeyecek 16:53 <jrandom> belki sonra 16:53 <vulpine> <void> doğru kostya213, o zaman boşver 16:53 <vulpine> <void> :) 16:53 <jrandom> (ama avatarlar boyut olarak çok sınırlı olacak, dolayısıyla dahil etmek pek sorun olmayacaktır) 16:53 <vulpine> * Complication, ileti başına olanların eklenmesinin yeterince kolay kodlanabileceğini düşünüyor 16:53 <vulpine> <void> yani, 3.1) syndie nedir? 16:53 <vulpine> <Complication> (er ya da geç) 16:54 <vulpine> * cervantes irc sunucularını birbirine yapıştırır 16:54 <vulpine> <void> Complication: jrandom bunun zaten yapılacağını az önce söyledi :) 16:54 <jrandom> (ileti bazındakiler temel durumda olacak complication, burada fikir, avatarın kendisini eklemek yerine bir iletide "use avatar 1" diyerek seçilebilecek çok sayıda 'varsayılan' olması) 16:54 <vulpine> <Complication> gecikme, gecikme... 16:54 <jrandom> tamam, 3.1 için başka bir şey? 16:54 <jrandom> değilse, 3.2'ye geçelim 16:55 <vulpine> <void> bence bu kadar 16:55 <jrandom> wr0d. 16:56 <jrandom> cervantes'in iğnelemesi dışında, "neden" hakkında sorusu/yorumu/endişesi olan var mı? 16:56 <jrandom> (şey, "endişeler") 16:58 <vulpine> <Complication> cervantes: ircd'ye yapıştırıcı sürmeden önce yüzeyi alkolle temizledin mi? ;) 16:58 <kostya213> bence syndie'nin gerekçelendirmeye ihtiyacı yok, anonimleştirme ağlarıyla zaten ilgilenen herkes için değeri kendi kendine aşikâr olmalı 16:58 <kostya213> ve bilginin merkezileşmesinin tehlikelerinin farkında 16:59 <vulpine> <Complication> (yeniden gönderim, sunucuya ulaştıysa lütfen görmezden gelin) 16:59 <vulpine> * Complication, Syndie'nin önemli olduğunu düşünüyor çünkü phpBB çalıştıran Joe Sixpack çok hızlı bir şekilde pwnage yaşar ve $random_blogging_tool çalıştıran Joe Sixpack de aynı akıbete uğrar 16:59 <vulpine> <Complication> (olasılık değişebilse bile) 16:59 <vulpine> <void> kesinlikle 16:59 <jrandom> evet, ayrıca gerçekten düşmanca hasımlarla karşı karşıya olan herkes (devlet düzeyi olmak zorunda bile değil) 17:00 <jrandom> tamam, harika, sadece bunları sizinle bir üzerinden geçmek istedim 17:00 <jrandom> 3.2 hakkında başka bir şey var mı, yoksa 3.3) syndie'yi ne zaman kullanabiliriz? bölümüne geçelim mi? 17:01 <vulpine> <void> şey, özünde kriptografik primitiflere dayanan ve bir taşıma katmanından bağımsız bir forum/blog/e-posta/iletişim aracıdır 17:01 <vulpine> <Complication> ...ve Joe Sixpack'in hasmının kesişim saldırıları düzenleyeceği uzak bir senaryoda, herhangi bir tür eepsite çalıştıran herkes er geç pwnage yaşar (çok büyük bir ağ dışında) 17:01 <kostya213> gizlilik/anonimliğin anında değerini görmeyenlere bunu anlatmak daha zor olabilir 17:01 <jrandom> kostya213: evet, gerçi bazı numaralar yapabiliriz, mesela çevrimdışı güvenle gezinebilmek gibi 17:02 <vulpine> <Complication> yine de güvenliği takdir edebilirler 17:02 <jrandom> (ör. yalnızca rss özetini değil, referans verilen sayfaların tamamını da çeken çevrimdışı bir rss okuyucu) 17:02 <vulpine> <void> yani evet, neden gerekçelendirmeye ihtiyaç duyduğunu göremiyorum :) 17:02 <vulpine> <void> kostya213: syndie kullanmak için anonim olmaları gerekmez 17:02 <cervantes> syndie'yi ne zaman kullanabiliriz yoksa syndie ne zaman kullanılabilir olacak? 17:02 <jrandom> haklısın void :) 17:03 <cervantes> metin arayüzü için epey yüklü miktarda kullanım belgesi gerektiğini düşünüyorum 17:03 <jrandom> cervantes: şu anda syndie işlevsel (gönderi oluşturabilir, kanalları yönetebilir, gönderileri okuyabilir, gönderilere yanıt verebilirsin, vb.) 17:03 <kostya213> jrandom: syndie fazlalığı (yedekliliği) nasıl ele alıyor? içeriğin kaybolmasına karşı ne kadar dayanıklı? 17:03 <cervantes> (kullanılabilir olmadan önce) 17:03 <jrandom> cervantes: her komutun belgelenmiş (en azından asgari düzeyde) olduğu satır içi menüler var 17:04 <cervantes> harika, bazı kullanım senaryosu örneklerine dair plan var mı? 17:04 <jrandom> kostya213: syndie içerik katmanında çalışır - yedeklilik başka bir şey tarafından ele alınır. usenet'e gönderirseniz, usenet genelinde çoğaltılır (örneğin) 17:04 <cervantes> bence püf nokta, hepsinin birlikte nasıl betikleneceğini öğrenmek olacak 17:04 <vulpine> <void> kostya213: bu syndie'nin kapsamı dışında, taşıma mekanizmasına bağlı 17:04 <vulpine> <void> ne yazık ki 17:04 <jrandom> iyi fikir cervantes 17:05 <jrandom> ilk syndie sürümü, eski/mevcut syndie gibi bir http çoğaltma sistemi içerecek 17:05 <jrandom> cervantes: belki beta kullanıcılarından bazıları dağıtmamız için en sevdikleri betikleri bir araya getirebilir :) 17:05 <modulus> mmm, bu bir konsol uygulaması mı? 17:05 <jrandom> modulus: evet, ilk metin tabanlı uygulama 17:06 <modulus> mükemmel! 17:06 <cervantes> jrandom: beta kullanıcıları nasıl kullanacaklarını çözebildikleri takdirde ;-) 17:06 <jrandom> hehe 17:06 * jrandom curses/vb.'yi ve sadece cli'yi de düşündü, fakat etkileşimli, betiklenebilir bir metin arayüzü muhtemelen en basiti ve en kullanışlısı 17:07 <jrandom> (yani gui olmadan) 17:07 <cervantes> modulus: gördün mü, jrandom senin amansız geri bildirimini dinledi :) 17:07 <vulpine> <Complication> insanlar isterse, muhtemelen bunun üzerine daha etkileşimli metinsel arayüzler inşa edebilirler 17:07 <jrandom> evet, elbette 17:08 <jrandom> (kod, pircbot gibi bir irc istemcisiyle kolay entegrasyonu destekleyecek şekilde tasarlandı) 17:08 <modulus> cervantes: hehe 17:09 <modulus> tahminen bunun üstüne bir gui de koyabilirsiniz, eğer kabaca hayal ettiğim gibi çalışıyorsa 17:09 <modulus> gerçi bu çok daha fazla iş olurdu. 17:09 * kostya213 emacs eklentisini bekler 17:09 <modulus> hahaha 17:09 <jrandom> heh 17:09 <modulus> aslında bir emacs modu o kadar da kötü bir fikir değil, belki daha fazla deliyi buna çeker. 17:10 <cervantes> kimliğinizi seçmek için ctrl-alt-shift-break-uparrow-num7-b'ye basın 17:10 * jrandom onu elipsers'a bırakacak ;) 17:10 <kostya213> alınma, ama bu projenin daha fazla deliyi çekmesine ihtiyaç olduğundan emin değilim 17:10 <vulpine> <Complication> o tür deliler kod da yazar mı? 17:11 <jrandom> umarım complication 17:11 <jrandom> tamam, umarım 3.3) yakında gelecekler hakkında biraz açıklama getirir 17:11 <jrandom> *ne zaman* kısmına gelince, göreceğiz, ama umudum "yakında" ;) 17:12 <jrandom> tamam, 3.3) için başka bir şeyi olan var mı? 17:12 <vulpine> * Complication o zaman o delilerden birkaç sürüyü memnuniyetle karşılar :D 17:12 <cervantes> şimdi bir de kod yazmak var, bir de tcl tarafından yorumlanan anlaşılmaz perl yazmak var 17:12 <kostya213> FUSE için bir eklenti de faydalı olabilir 17:13 <jrandom> evet 17:13 <jrandom> tamam, 4) syndie için kripto konusuna atlayalım 17:13 <jrandom> bu konular hakkında yorumu olan? 17:14 <vulpine> <Complication> keşke olsa, ama bu şifrelerin/hash'lerin/anahtar uzunluklarının gücünü tahmin edecek yetkinlikte değilim 17:15 <vulpine> <void> elgamal/rsa imzaları ne kadar uzun? 2kbit anahtar için 4kbit mi? 17:15 <vulpine> * Complication o tartışmayı tamamen başkalarına bırakıyor 17:15 <jrandom> şu anda bilmiyorum 17:15 <vulpine> <void> dsa'ya karşı? 17:16 <jrandom> (gerçi ecc hoş ve minik görünüyor) 17:16 <modulus> ElGamal imzaları zordur ve uzundur. gnupg ekibinin keşfettiği gibi. 17:16 <jrandom> evet, gerçi o numaraların bir kısmı anahtarın yeniden kullanımına ilişkindi 17:16 <vulpine> <void> ah, tamam 17:16 <vulpine> <void> evet, öyle 17:16 <tethra> modulus: eğer zor ve uzunsa, bunun için bir fetiş sitesi vardır 17:17 <jrandom> tamam, o nokta aslında sadece bir ön bilgilendirme ve aklınıza bir şey geldikçe yorum çağrısıydı 17:17 <cervantes> takılıp çıkarılabilir bir tür şifreleme uygulamak mümkün olamaz mı - anahtar oluşturmanın daha iyi bir yöntemi standardize edildiğinde onu syndie'ye ekleyebiliriz ve yeni gönderiler bunu kullanmaya başlayabilir, ancak daha eski gönderiler için yine de eski yöntemler kullanılabilir 17:17 <tethra> (üzgünüm) 17:17 <jrandom> cervantes: bir DSA: öneki içeriyor, dolayısıyla bir Elg: öneki de işe yarar 17:17 <modulus> 1024 ile sınırlı dsa mı kullanıyorsunuz, yoksa değil mi? 17:18 <modulus> ayrıca hangi hash? sha1 mı yoksa daha üst revizyonlar mı? 17:18 <cervantes> yani aslında tek derdin syndie'yi iyi bir başlangıçla çıkarmak 17:18 <jrandom> dsa sadece 1024 bit (daha uzun için dsa2 önerileri var, ama henüz standardize edilmediler) 17:18 <jrandom> ve evet, dsa sha1 gerektirir 17:18 <modulus> hmm, anladığım kadarıyla standart öncesinde epey güçlüydüler. 17:18 <kostya213> cervantes iyi bir noktaya değindi, syndie içeriğini sabit şifrelemelerde tutmak zayıf forward secrecy (ileri gizlilik) sunar, bir algoritmanın ne zaman çökeceğini asla bilemezsin 17:18 <modulus> ama süreci yeterince yakından takip etmiyorum, bu yüzden muhtemelen haklısın 17:19 <jrandom> kostya213: ama seçenek kripto için kötüdür, bu yüzden mümkün olduğunda sabit değerlerimiz olmalı 17:19 <jrandom> (anonimlik açısından kötü) 17:19 <vulpine> <void> bu arada, neden daha fazla kişi/protokol ecc kullanmıyor biliyor musun? araştırma eksikliğinden mi korkuyorlar, yoksa sadece uyumluluk konusunda mı endişeliler? 17:19 <modulus> patentler. 17:20 <jrandom> patentler ve FUD, bir de uygulamada bazı endişeler 17:20 <vulpine> <void> ah, doğru modulus 17:20 <modulus> bu arada, örneğin dsa yerine rsa-sha512 kullanmak için iyi bir neden var mı? 17:20 <tethra> patentler ve FUD ve devlet (amanin) 17:20 <modulus> rahatsız etmeye çalışmıyorum, sadece örneğin gpg'nin ve diğerlerinin bu yola gittiğini düşünerek söylüyorum. 17:20 <jrandom> yıllardır o seçeneği gözden geçirmedim modulus 17:21 <modulus> açıkça dsa bir standart, bu onun lehine, ama anahtarlar küçük ve hash'ler zayıf. yine de bunun en zayıf halka olacağını sanmıyorum ;-) 17:23 <cervantes> "seçenek" önermem - ancak syndie'nin yeni sürümleri giderek daha güvenli (zorunlu) şifrelemeleri paketler 17:23 <vulpine> <Complication> Yapılarda gelecekteki değişim için biraz pay bırakmak, şu anki kriptolardan hangisi en iyi çıkarsa çıksın, makul görünür diye düşünüyorum 17:23 <jrandom> evet, gerçi bu birlikte çalışabilirlik için daha zayıf/eski sürümlere geri dönüşü ima ediyor 17:23 <jrandom> ama tamam, bunun üstesinden geleceğiz 17:24 <jrandom> tamam, 5) ??? konusuna atlayalım 17:24 <jrandom> toplantı için gündeme getirmek istediği başka bir şeyi olan var mı? 17:25 <cervantes> en sevdiğiniz kaynaktan en son gönderileri okuyamamak, herkesin güncel kalmasını sağlamaya yönelik iyi bir teşviktir 17:25 <jrandom> bir dereceye kadar 17:26 <cervantes> no=not 17:26 <jrandom> (evet, bu bir teşvik, ama insanlar tembel/"yazılım yükseltmeyle" ilgilenmiyor, vs.) 17:27 <jrandom> s/people/some people/ 17:27 <cervantes> sanırım bu yine de onların meselesi 17:27 <jrandom> aynen öyle 17:27 <kostya213> en azından i2p uygulaması zahmetsiz yükseltmeye sahip olabilir 17:28 <jrandom> kesinlikle 17:28 <cervantes> ??? konusuna gelince - irc bağlantısı için özürler - İSS, başlıca ağ taşıyıcılarından birini "en kısa sürede" geri getirmeli 17:29 <jrandom> w3wt 17:29 <vulpine> <Complication> ??? konusuna, NTP değişikliklerinin ikinci (daha kapsamlı) bölümünün çalışmaya yakın olduğunu ve yakında test için commit etmeyi umduğumu ekleyebilirim 17:29 * cervantes bir tutam tuz alır 17:29 <kostya213> router geliştirmesi için kısa vadeli planlar nedir? yol haritası doğru mu? 17:29 <jrandom> müthiş complication 17:29 <vulpine> <Complication> Amacı, eş saat kaymalarına dayanarak NTP sunucularını çapraz kontrol etmektir 17:29 <jrandom> kostya213: syndie çıkana kadar stabilizasyon 17:30 <jrandom> (benim bakış açımdan) 17:30 <vulpine> <Complication> (ve potansiyel olarak bağlantıya zarar verebilecek işlemler yapmaktan kaçınmak) 17:31 <cervantes> harika 17:32 <jrandom> tamam, toplantı için başka bir şey? 17:34 * jrandom toparlar 17:34 * jrandom *baf* diye kapatır