I2P Geliştirici Toplantısı - 18 Ocak 2005

13:04 <jrandom> 0) selam 13:04 <jrandom> 1) Ağ durumu 13:04 <jrandom> 2) 0.5 13:04 <jrandom> 3) i2pmail.v2 13:04 <jrandom> 4) azneti2p_0.2 13:04 <jrandom> 5) ??? 13:04 <ant> <duck> (kulaklarımın yanından uçup giden kripto muhabbetinin sesi) 13:04 <jrandom> :) 13:04 * jrandom el sallar 13:04 <cervantes> selam 13:04 <jrandom> sen de kulaklarının yanından uçup giden kripto muhabbetinin sesini dinleyebilirsin! haftalık durum notu şurada yayınlandı @ http://dev.i2p.net/pipermail/i2p/2005-January/000559.html 13:05 <bla> merhaba 13:05 <jrandom> hemen dalıyorum, zaten ilginç bir tartışmayı bölüyoruz... 1) ağ durumu 13:05 <jrandom> mailde yazanların ötesine ekleyecek pek bir şeyim yok - ağ durumu ile ilgili gündeme getirmek istediğiniz bir şey var mı? 13:06 <bla> İlk kez Antarktika hariç *tüm* kıtalarda düğümleri gördüğümüz gerçeği dışında, hayır. 13:06 <jrandom> w00t! 13:07 <jrandom> tamam, 2) 0.5 işlerine geçiyoruz 13:07 <mule> hey, babam şu anda antarktika'ya gidiyor, ona bir düğüm vermeliydim 13:07 <ant> <duck> kahrolası Antarktikalılar 13:07 <Xan> Antarktikalı yok mu? :( 13:07 <jrandom> hah güzel 13:07 <jrandom> yine de orada pek büyük bir anonimlik kümesi olduğunu sanmıyorum 13:07 <Frooze> suçu antarktika'ya at 13:08 * cervantes orada bir düğümü finanse edebilmek için antarktika'da bir petrol platformu kurar 13:09 <jrandom> tamam tamam, 0.5 ile ilgili çok şey var, o yüzden parça parça ele alabiliriz 13:09 <jrandom> öncelikle, bir günlük istatistik toplayan arkadaşlara teşekkürler - burada bir sürü ilginç veri var @ http://dev.i2p.net/~jrandom/messageSizes/ 13:09 <postman> zevkti :) 13:10 <cervantes> ağ durumu ile ilgili... son zamanlarda I2P'yi kurup çalıştırmakta zorlanan epey kişi gördüm (forumlarda vs) - bunun artan kullanıcı hacminden mi yoksa hataya açık daha fazla I2P tabanlı uygulama olmasından mı kaynaklandığını bilmiyorum 13:10 <+protokol> jrandom: YALANCI! verilerin ilginç olduğunu söylemiştin! 13:10 * jrandom protokol'e çamur atar 13:11 <ant> <duck> cervantes: birkaç dakika içinde kurup çalıştırabildiğine dair raporlar da gördüm 13:11 <ant> <duck> bence çoğu soruna NAT (ağ adres çevirisi) neden oluyor 13:11 <cervantes> duck: doğru... 13:11 <ant> <dmdm> kim bu NAT? 13:11 <jrandom> cervantes: kesinlikle hâlâ bazı çirkin sorunlar var. NAT meselesi ve osx son zamanlarda biraz baş ağrısı oldu, ama ikincisi konusunda Jhor'un yardımı durumu iyileştirmeli 13:12 <cervantes> aynen 13:12 <cervantes> *öksürür* yani... 0.5 13:13 <Xan> dmdm: ağ adres çevirisi 13:13 <jrandom> heh, tamam. temelde o mesaj boyutu istatistikleriyle amaç dolguyla (padding) ilgili sorunları araştırmak 13:14 <jrandom> ne yazık ki, sayı seçip toplamayla kurduğum strateji berbattı, yalnızca dolgu verisiyle %25 ek yük getirdi 13:14 <jrandom> 0.5 şifreleme için önerilerden biriyle (tunnels-alt.html) gidersek, bu sorun olmayacak 13:15 <jrandom> (çünkü parçalama ile küçük sabit boyutları zorlayacak) 13:15 <mule> hangi tür mesajları doldurmak istiyorsunuz, bir router'ın gördükleri mi yoksa harici bir gözlemcinin gördükleri mi? 13:15 <jrandom> mule: önemli soru 13:15 <jrandom> sadece harici gözlemciyi dert ediyorsak, mesajları dolgusuz bırakabiliriz; sahte trafik (chaff) üretimini taşıma katmanında yaparız 13:16 <Teal`c> http://microsoft.i2p/david_hasselhoff_05_christmas_album__silent_night.mp3 13:16 <jrandom> öte yandan, eğer flow analysis (trafik akış analizi) yapan tunnel katılımcılarından endişe ediyorsak, tunnel boyunca padding (dolgu) ile ilgilenmemiz gerekir 13:16 <@duck> 5-6 sıçramada, bir router'ın trafik analizi yapma tehlikesi ne kadar büyük? 13:16 <cervantes> Teal`c: şu anda toplantı... mp3 duyurusu için #i2p-chat'i kullanabilir misin ;-) 13:17 <Teal`c> üzgünüm 13:17 <cervantes> :) david hasselhoff için mi? 13:18 <jrandom> analizin düzeyine bağlı duck. bir şekilde hangi tunnel içinde olduklarını tespit ettilerse (ör. inbound tunnel gateway'ler ve netDb'yi topladılar, bunu bir hedefle ilişkilendiriyorlar), bu yabana atılır veri değil. öte yandan doğrudan bir ifşa değil, ama bazı bilgiler verir 13:18 <jrandom> ancak tunnel padding'den bile daha önemlisi uçtan uca padding; ağ geçitlerinden ve uç noktalardan mesaj akışı verisini gizler. 13:19 <jrandom> eğer deli/aptal olursak, her yerde sabit bit hızı kullanan bir pipenet'e kadar gidebiliriz 13:19 <+polecat> anladım! 13:19 <jrandom> (ve I2P'yi çalıştıran hiç kullanıcı kalmaz) 13:19 <+polecat> Yapmamız gereken şey, I2P'yi e-posta üzerinden tünellemek! 13:19 <cervantes> yeterince büyük bir ağda işbirliği yapan router'ların aynı tunnel içinde yer alma olasılığı nedir? 13:19 <+polecat> Hiçbir ISP e-postayı durduracak kadar aptal olmaz! 13:20 * jrandom net.i2p.router.transport.gmail implementasyonunu bekler 13:20 <postman> polecat: vay, bu saçma 13:20 <postman> :) 13:20 <bla> cervantes: N^(-h) (N hızlı düğüm sayısı, h = sıçrama sayısı). Öyle görünüyor 13:20 <+polecat> =3 Biliyorum. 13:21 <cervantes> bu çok mu? :) 13:21 <jrandom> hızlı düğüm sayısı değil, çünkü dışarıdakiler profillerinizi bilmeyecek 13:21 <+polecat> Şaka bir yana, mevcut IP servislerini utanmazca suistimal ederek I2P'yi sayısız yaratıcı yolla tünelleyebiliriz. 13:21 <jrandom> c^2/N^h iki eşi aynı tunnel içine sokmak için 13:21 <jrandom> katılıyorum polecat. bu, bidirectional tunnels (çift yönlü tüneller) kullanmamamızın nedenlerinden biri 13:22 <jrandom> bazı taşıma yöntemleri (örn. e-posta) çift yönlü iletişim için berbat 13:22 <bla> jrandom: c = ? 13:22 <jrandom> c== işbirliği yapan eş sayısı 13:23 <+polecat> hm, ilginç nokta. 13:23 <ant> <duck> yol haritası açısından, I2P'nin yanlış bir yöne gidip yanlış bir kripto çözümü seçmesinin etkisi nedir? 13:23 <+polecat> Ya da taşıyıcı güvercin protokolü, hiç de çift yönlü değil. 13:23 <+polecat> kripto zaten modüler, değil mi? 13:23 <jrandom> duck: bu 0.5'in sadece bir madde başlığı ve tunnels*.html belgesinin bir alt bölümünden ibaret. veriyi nasıl sardığımızdan çok daha fazlası var tunnel yönlendirmesinde 13:24 <bla> jrandom: Yine de, bu onları şu anda tunnel içine sokmanın olasılığı. Ancak T adet tunnel yenilemesi (her birkaç dakikada bir) üzerinden bu P = 1 - (1 - c^2/N^h)^T olur 13:24 <jrandom> öte yandan, 'sabit 1KB bloklar' ile '0-40KB bloklar' arasındaki farkın kayda değer etkisi var 13:24 <+polecat> Bu ağın Entropy gibi olup McEliece’e saplanıp kalmasını istemem. 13:24 <jrandom> polecat: şunu oku http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt.html?rev=HEAD 13:24 <bla> jrandom: Ve böylece yeterince uzun zamanda sıfıra yaklaşır. Yani: yeterince uzun zamanda, saldırganlar en az bir kez aynı tunnel içinde olacak 13:25 <jrandom> plan standart AES256/CBC 13:25 <+protokol> duyduğuma göre DNS bir şeyleri tünellemek için iyi, çoğu insan engellemez 13:25 <jrandom> elbette bla, ama o kadar da doğrudan değil (keşif amaçlı tunnels için öyle, ancak istemci tunnels için değil) 13:26 <+polecat> Ve bir şekilde AES bile kırılsa, eşdeğer bir simetrik şifre. 13:27 <jrandom> bla: çoğu durumda bu ölçekte pratik bir endişe olacak kadar büyük olduğunu sanmıyorum, ancak bunu bir predecessor attack (öncül saldırı) parçası olarak uygularsan, konu büyük ölçüde tartışmalı olur 13:28 <jrandom> (tunnel yönlendirmesinin geri kalanını yapma biçimimiz nedeniyle) 13:28 <bla> jrandom: tamam 13:28 <jrandom> aynen polecat 13:29 <jrandom> duck: ikinci seçenekle gidersek, daha sonra başka birine geçmek muhtemelen kolay olacak. 13:29 <jrandom> öte yandan, ikinci seçenek berbat Olmaması için epey performans ayarı gerektirecek 13:29 <jrandom> ama eminim başarabiliriz 13:31 <jrandom> her neyse, sanırım yukarıdakiler 0.5 çalışmaları açısından şu an nerede olduğumuzu kapsıyor 13:31 <jrandom> başka soru/yorum/endişesi olan var mı? 13:31 <bla> jrandom: Bir 13:32 <bla> jrandom: bence şu anda anonimliği performanstan biraz daha fazla önemsemeliyiz: yani evet, PRNG seçenekleri iyi görünüyor 13:33 <jrandom> katılıyorum. performans sonra ayarlanabilir, ancak daha iyi anonimliği sonradan 'eklemek' çok daha zor 13:33 <jrandom> (ama elbette, performans bir güvenlik parametresidir. berbatsa kimse kullanmaz) 13:33 <bla> Evet. 13:33 <bla> jrandom: 13:33 <bla> üzgünüm 13:33 <@duck> tamam, /me büyülü Freenet-performans bit'ini çevirir 13:33 <cervantes> belki de ellerinde torrent sallayan tüm leecher'ları biraz daha uzak tutar ;-) 13:34 <jrandom> heh 13:34 <cervantes> <-- bağlantı sıfırlandı 13:34 <bla> cervantes: Hayır, ben değilim! :) 13:34 <cervantes> :) 13:35 <jrandom> bazı gerçekten havalı optimizasyonları başarabileceğimizi düşünüyorum ve darboğazlarımızın çoğu eş seçiminden değil de sadece (heh) jobqueue'daki hatalardan kaynaklanıyor gibi görünüyor 13:36 <jrandom> ama her neyse, 2) 0.5 için başka bir şey? 13:36 <ant> <BS314159> bu döngü saldırısı için bir açıklama gönderebilir misin? 13:37 <ant> <BS314159> anlattığından daha tehlikeli gibi geliyor 13:37 <jrandom> döngü: A-->B-->C-->D-->C içeren bir tunnel kur, 10 mesaj gönder. 13:37 <jrandom> PRNG'ler olmadan, o C<-->D döngüsüne istediğin kadar mesaj ekleyebilirsin 13:38 <ant> <BS314159> tamam 13:38 <jrandom> yalnızca birkaç mesajla herhangi bir router'ı fiilen DoS (hizmet engelleme saldırısı) edebilirsin 13:38 <ant> <BS314159> ama bunu yalnızca A yapabilir 13:38 <jrandom> PRNG'lerle, döngüye girebilecek mesaj sayısı sınırlandırılır 13:38 <ant> <BS314159> yani bir saldırganın döngüler ekleyerek tunnel'larımı kısaltması gibi bir tehlike yok 13:38 <jrandom> hayır, kimse tunnel'larını kısaltamaz 13:39 <jrandom> bunun işe yaradığı tek şey bir DoS 13:39 <jrandom> (çok ucuz bir DoS) 13:39 <jrandom> (ama düşük maliyetle eşleri seçerek DoS edebildiğinde, çoooook pis şeyler yapabilirsin) 13:40 <ant> <BS314159> anladım 13:40 <+protokol> ve hashcash sertifikaları buna yardımcı olur mu? 13:40 <jrandom> protokol: hashcash, bir eşin çok fazla tunnel inşa etmesi ve belki de çok fazla sıçrama yapması sorununu ele alır 13:41 <jrandom> protokol: döngülerde yardımcı olmaz. işe yarayan iki yol PRNG'ler (tunnel-alt.html) veya her adımda doğrulama (tunnel.html) idi 13:42 <jrandom> her adımda doğrulamanın riskleri var, bu yüzden şu an eğilim PRNG'lere doğru 13:42 <+Ragnarok> PRNG yöntemi ne kadar etkili olacak? 13:42 <Xan> A-->B-->C-->D-->C - her sıçrama farklı bir kimlik ya da bir şey almamalı mı, böylece mesajlar C'ye ikinci kez ulaştıklarında döngüye girmek yerine tunnel'dan çıkmalı? 13:43 <jrandom> Xan: alıyorlar, ama her adımı doğrulamadan bunun kötü olup olmadığını anlayamazsın 13:44 <jrandom> Ragnarok: verilen zararı en aza indirmede çok etkili olacağını düşünüyorum 13:45 <jrandom> en azından, şimdiye kadar gördüğüm kadarıyla 13:45 <jrandom> bunda herhangi bir sorun gören ya da iyileştirme önerisi olan varsa, lütfen iletişime geçin :) 13:46 <Xan> ya da belki ben konuyu kaçırıyorum 13:46 <Xan> birazdan dönerim 13:46 <jrandom> 'k l8r, belgeyi daha net olacak şekilde güncelleyeceğim 13:47 <jrandom> tamam, başka bir şey yoksa 3) i2pmail.v2'ye geçelim mi? 13:47 <jrandom> postman: buralarda mısın? 13:48 <postman> evet 13:49 <postman> :) 13:49 <jrandom> forumdaki gönderinden ekleyeceğin bir şey var mı? oldukça havalı geliyor 13:49 <postman> şey, bazılarınız i2pmail.v2 taslağını zaten okumuş olabilir 13:50 <bla> neler oluyor böyle? Devasa kopmalar. Burada da sitelere (mesela orion, library) ulaşmakta sorun yaşıyorum 13:50 <postman> gelecekte tamamen merkezsiz bir e-posta altyapısını hedefliyor 13:50 <postman> ancak düğümlerde proxy yazılımına ve ayrıca bir grup adanmış aktarım noktasına ihtiyaç var 13:51 <postman> herkes fikir/konsept/söylenme katkısına davetlidir 13:51 <postman> geliştirme başladı bile - ilkbaharın sonundan önce bir şey beklemeyin :) 13:51 <jrandom> w00t 13:51 <kaji> hmm, polis az önce kapıma geldi 13:52 <bla> kaji: ? 13:52 <jrandom> çabuk, sabit diskinin uçur 13:52 <postman> jrandom: peki, şimdilik söyleyeceklerim bu kadar :) 13:52 <cervantes> blackjack masası saklayın! 13:52 <jrandom> wikked, teşekkürler postman 13:52 <kaji> sonra ahizeden düşünce kablosuz telefonların sapıtabileceğini söylediler, ama benim tüm kablosuz telefonlarım şarjında -> #i2p-chat 13:55 <jrandom> azureus tayfası bir güncellemeyi hazır etmekte çok hızlı davrandı (yaşasın!), ama insanlar sorunlara karşı da tetikte olmalı 13:55 <jrandom> (i2p posta listesini okumuyor ve azneti2p kullanıyorsanız, i2p posta listesini okuyun) 13:55 <jrandom> ((hatta azneti2p kullanmıyor olsanız bile, listeyi okuyun; önemli şeyleri orada duyuruyoruz ;) 13:56 <jrandom> duck ve orion da yeni bt istemcisi ve biçimlendirmeye uyum sağlamak için birçok güncelleme yapıyor 13:56 <jrandom> (yaşasın!) 13:56 * orion gülümser 13:57 <orion> gidecek yol hâlâ var, ama şimdilik çalışıyor. 13:57 <jrandom> (I2P izin verdiği ölçüde ;) 13:58 <orion> hehe, evet. ;) 13:58 <jrandom> azneti2p veya i2p-bt ile ilgili gündeme getirecek başka bir şey var mı? 13:58 <jrandom> (ya da bytemonsoon2p ;) 14:00 <jrandom> değilse, doğrudan 5) ???'e geçiyoruz 14:00 <jrandom> açık gündem - başka bir şey gündeme getirmek isteyen? 14:00 <postman> jrandom: addressbook neden userhosts girdilerini yayımlıyor? 14:01 <jrandom> postman: hata. 14:01 <postman> yani bu planlanmış bir davranış değil ve değişecek? 14:01 <cervantes> sadece bir şey... 14:01 <jrandom> postman: doğru ve değiştirilecek 14:02 <jrandom> (doğru mu Ragnarok? :) 14:02 <+Ragnarok> postman'ın tam olarak ne kastettiğine bağlı... 14:03 <jrandom> Ragnarok: yerel kullanıcının kendi özel hosts'una eklediği yeni girdiler yayımlanan hosts'a yayılmamalı 14:03 <jrandom> (ör. userhosts.txt özeldir, hosts.txt başkalarıyla senkronize edilir ve geneldir) 14:03 <cervantes> Forumdaki yarı düzenli bir köşe kapsamında, I2P'ye son zamanlarda veya projenin yaşamı boyunca iyi şeyler katkıda bulunanlara takdir ve ödüller verilecek 14:03 <postman> Ragnarok: 0.4.2.6'ya güncelledikten sonra eepsite klasörümdaki yayımlanan addressbook'ta userhosts.txt'den girdiler buldum 14:03 <ant> <BS314159> hmm 14:04 <postman> Ragnarok: bunlar elle eklenmiş anahtarlardı, yayımlanmaları gerekmiyordu 14:04 <cervantes> bu hafta topluluk için bir hizmet sağlayıcı olarak genel mükemmelliği ve her açıdan harika bir takılan olması nedeniyle duck'ı takdir ediyoruz: http://forum.i2p/viewtopic.php?t=275 14:04 <jrandom> w00t! 14:04 <jrandom> (go duck go, go duck go) 14:05 <Teal`c> alan adı ele geçirme (hijacking) ne olacak ? 14:05 * brachtus alkışlar 14:05 * orion saygı göstergesi olarak bir ördek yürüyüşü yapar. 14:05 <cervantes> gelecek için önemli bir nokta... övgü almak için kriptografi dahisi olmak zorunda değilsiniz! 14:06 <+Ragnarok> hayır, bu beklenen davranış. değiştirebilirim, ama önce hosts.txt'yi doğrudan değiştirebilmeniz için dosya kilitlemeyi tamamlamam gerekecek 14:06 <orion> (ama yardımcı olur) 14:06 <cervantes> belki de harika bir eepsite veya başka bir şey katkıda bulunmuşsunuzdur... 14:06 <cervantes> ya da forumda yardımcı bir tip olmuşsunuzdur vb. 14:07 <ant> <BS314159> hmm 14:07 <cervantes> (yoksa, kabul edelim, jrandom her hafta kazanırdı) 14:07 <jrandom> hey, hepiniz benim bira fonumu ödüyorsunuz, bu işler bedava değil ;) 14:07 <ant> <BS314159> yeni bir dosya, "publichosts.txt" yapamaz mısın? 14:07 <ant> <BS314159> sonra addressbook userhosts.txt'yi yok saysın ama kullanıcıların kendi publichosts.txt'lerine abone olmalarına izin verilsin? 14:08 <jrandom> Teal`c: bir alan adını ele geçirmenin yolu yok, hiçbir girişin üzerine yazılmıyor ve userhosts her zaman hosts'un önüne geçer 14:09 <jrandom> Ragnarok: belki web arayüzü kilitleme sorununu ele alabilir, çünkü kullanıcılar dosyalara elle ekleme yapmayacak 14:09 <+Ragnarok> kilitleme yapıldıktan sonra, userhosts.txt'den adresleri içeri çekmek için gerçek bir neden kalmayacak (şu anda yarış durumundan kaçınmanın tek yolu bu), dolayısıyla üçüncü bir dosya eklemenin pek anlamı yok 14:10 <+Ragnarok> jrandom: şey, Java dosya kilitleme API'sini kullanmayı planlıyordum 14:10 <jrandom> gerekli olduğunu düşünüyorsan, patron sensin :) 14:10 <ant> <BS314159> bu, kendi oluşturduklarını tutarken başkalarından alınan tüm adları silmene izin verirdi 14:10 <ant> <BS314159> sadece hosts.txt'yi temizleyip aboneliğini değiştirerek 14:11 <ant> <BS314159> ama sanırım bu name-signing için bekleyebilir 14:11 <orion> metadata bu sorunu çözecek. bir taslak spesifikasyon var mı? 14:11 <jrandom> yalnızca iki dosya kullanmak yeterli olmalı - biri addressbook tarafından yönetilir, diğeri edilmez 14:12 <jrandom> (hatta addressbook'un userhosts.txt'yi tamamen yok saymasını sağlayabilirsin - userhosts.txt zaten hosts.txt'nin önüne geçer) 14:12 <+Ragnarok> jrandom: kilitleme bittiğinde plan bu olur (ki aslında çok iş değil, sadece fırsat bulamadım :) 14:13 <+Ragnarok> ve şu anda namerecords için bir tane yazabilecek kadar XML şemayı öğrenmek üzerinde çalışıyorum 14:13 <ant> <dr_kavra> kenosis için kanal burası mı? başka bir kanal buraya gelmemi söyledi :D 14:13 <jrandom> lol 14:13 <jrandom> yok, üzgünüm, burası i2p 14:14 <jrandom> (anonim bir iletişim katmanı aramıyorsan) 14:14 <jrandom> wikked Ragnarok 14:14 <ant> <BS314159> bence yine de XML buna kıyasla (YAML ile karşılaştırıldığında) fazla geveze ve insan okunurluğu düşük, ama kodu yazan ben değilim 14:14 <jrandom> Ragnarok: zor kısım, çirkin CDATA'ya dönmeden XML ile kriptoyu yapmak olacak 14:14 <orion> metadata spesifikasyonu için çalışan bir taslak yazan oldu mu? 14:15 <jrandom> (ben şahsen XML'in berbat olduğunu düşünüyorum, ama ben sadece mızmızın biriyim) 14:15 <jrandom> orion: http://dev.i2p.net/pipermail/i2p/2004-February/000135.html temel bir kurulum içeriyor 14:15 <orion> (ad/anahtar metadata) 14:15 <dox> addressbook ve özellikleri bir yerde duyuruldu mu? hosts.txt'min yayımlandığını bilmiyordum 14:15 <jrandom> (NameReference ve LocalEntry öğelerine bakın) 14:16 <jrandom> dox: addressbook/config.txt'de belirtilen konuma yazılıyor 14:16 <jrandom> (varsayılan olarak, ./eepsite/docroot/hosts.txt) 14:17 <orion> public/private (yani dağıt, dağıtma) bayrağı eksik. 14:17 <ant> <cervantes> XML ile ilgili tek iyi şey (ve bu büyük bir artı) geniş kabul görmüş bir standart olması 14:17 <jrandom> doğru orion, o gönderiden beri birçok iyi fikir çıktı 14:17 <+Ragnarok> XML berbat olabilir, ama açıkçası benim yaptığım şey için alternatiflerin hepsinden daha iyi 14:17 <jrandom> cervantes: EDI de öyle 14:17 <orion> bunları toparlamak için bir yer var mı? yani forum alanı? 14:18 <orion> ya da belki bir wiki sayfası? 14:18 <jrandom> orion: susi'nin ya da ugha'nın wiki'si 14:18 <orion> bytemonsoon ve orion.i2p için her birinin gelecekteki geliştirme hedefleri konusunda topluluk uzlaşısı sağlanmasına yardımcı olmak üzere wikiler kuracağım. 14:18 <BrockSamson> XML + kripto CDATA olmadan = MIME, değil mi? 14:19 <jrandom> wikked orion 14:19 <jrandom> BrockSamson: S/MIME, farklı ayrıştırıcılarla ;) 14:19 <orion> (ad metadata'sı için de bir tane) 14:21 <jrandom> metadata'yı yapmanın birçok yolu var, önemli olan esneklik ve 'doğruluk'; böylece zamanla büyüyebilir veya değişebilir 14:21 * jrandom, Ragnarok ve diğerlerinin güzel şeyler çıkaracağından emin :) 14:21 <orion> bu yüzden kamusal bir taslağın gerekli olduğunu düşünüyorum. 14:22 <ant> <cervantes> i2p konsorsiyumu :P 14:22 <jrandom> son birkaç toplantıdır insanlar "biri fikirlerini wiki'ye koymalı" diyor, ama wiki sayfaları pek büyümüyor ;) sorun değil, kendi hızımızda gidiyoruz 14:23 * orion bir gün içinde üç wiki'yi ayağa kaldıracağına ve konumlarını herkese e-postayla göndereceğine söz verir 14:23 <BrockSamson> tembel deyin, ama bir ANSI 850 Purchase Order EDI'yi diğer XML tabanlı satın alma siparişleriyle karşılaştırın; XML sürümünü çözmeyi, kodlamayı ve hata ayıklamayı tercih ederim. EDI boyutunun 5 katı olsa bile 14:23 <jrandom> w00t 14:23 <jrandom> heh BrockSamson 14:24 <BrockSamson> Pozisyon 10 ST mi? o zaman pozisyon 310 ad olmalı 14:24 <BrockSamson> aptal ben 14:24 <jrandom> BrockSamson: PO'lar için XML şemalarının çok daha iyi olduğunu sanmıyorum ;) 14:24 <jrandom> (ama evet, o işler tam bir felaket) 14:25 <BrockSamson> sabah 4:30'da öyleler 14:25 <BrockSamson> tabii... 14:25 <jrandom> heh 14:25 <BrockSamson> bir eski EDI programcısı tarafından yazılmışsa 14:25 <BrockSamson> ve XML şöyle görünür: <p1><po><q>1</q></po></p1> 14:26 <BrockSamson> bahse girerim, Açık Kaynak projelerinin 'XML mi değil mi' diye konuşarak harcadığı saatleri toplasan, Linux'u 10 kez yazabilirsin. 14:26 <BrockSamson> yer aldığım her projede bunun üzerine büyük tartışmalar oldu 14:27 <orion> tartışmalar proje için iyidir, kimin tartıştığına bağlı olarak. ;) 14:27 <jrandom> eh, yaptığı şeyi yapar, ama panzehir değil. adlandırma işleri için iyi çalışabilir 14:28 <BrockSamson> ama birçok insan projelerde sadece tartışmak için var. 14:28 <jrandom> burada değil. ben bedava bira için buradayım 14:28 <ant> <cervantes> o tartışılır 14:28 <orion> taslak spesifikasyon daha elle tutulur olduğunda uygulama detayları daha net olacak. 14:28 <orion> bu yüzden bir wiki/akran incelemesine ihtiyaç var. 14:29 <BrockSamson> bu projenin bedava Garlic dağıttığını duydum 14:29 <jrandom> bolca 14:30 <jrandom> tamam, toplantı için gündeme getirecek başka bir şeyi olan? 14:30 <ant> * cervantes törensel çağrı için zil çanını dışarı çıkarır 14:30 <ant> <cervantes> call =cow 14:30 * jrandom hazırlanır 14:31 * jrandom toplantıyı kapatarak inek ziline *baf* diye vurur