From anwitaman at hotmail.com Fri Apr 1 07:56:37 2005 From: anwitaman at hotmail.com (Anwitaman Datta) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] RE: p2p-hackers Digest, Vol 20, Issue 27 In-Reply-To: <20050331200006.1887D3FD40@capsicum.zgp.org> Message-ID: Hi Walter, May be you can reuse ideas from "Randomized rumor spreading" http://dcg.ethz.ch/lectures/ws0304/seminar/papers/randomized_rumor.pdf Hi list, The challenge is to gather information from all Nodes (fast) and handle failures I guess this problem must be around since modems exists. Can anyone point me to some resources where i can find programs/literature ? re, walter ------------------------------ _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers End of p2p-hackers Digest, Vol 20, Issue 27 ******************************************* _________________________________________________________________ NRIs, operate Rupee Checking Account. http://creative.mediaturf.net/creatives/citibankrca/rca_msntagofline.htm Without minimum balance for 20 yrs! From eugen at leitl.org Wed Apr 6 06:28:03 2005 From: eugen at leitl.org (Eugen Leitl) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] [i2p] weekly status notes [apr 5] (fwd from jrandom@i2p.net) Message-ID: <20050406062803.GY24702@leitl.org> ----- Forwarded message from jrandom ----- From: jrandom Date: Tue, 5 Apr 2005 14:26:27 -0700 To: i2p@i2p.net Subject: [i2p] weekly status notes [apr 5] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi y'all, time for the weekly update * Index 1) 0.5.0.5 2) Bayesian peer profiling 3) Q 4) ??? * 1) 0.5.0.5 Last week's 0.5.0.5 release has had its ups and downs - the major change to address some attacks in the netDb seems to work as expected, but has exposed some long overlooked bugs in the netDb's operation. This has caused some substantial reliability issues, especially for eepsites. The bugs have however been identified and addressed in CVS, and those fixes among a few others will be pushed out as a 0.5.0.6 release within the next day. * 2) Bayesian peer profiling bla has been doing some research into improving our peer profiling by exploiting simple bayesian filtering from the gathered stats [1]. It looks quite promising, though I'm not sure where it stands at the moment - perhaps we can get an update from bla during the meeting? [1] http://forum.i2p.net/viewtopic.php?t=598 http://theland.i2p/nodemon.html * 3) Q There is lots of progress going on with aum's Q app, both in the core functionality and with a few people building various xmlrpc frontends. Rumor has it we might be seeing another Q build out this weekend with a whole slew of goodies described on http://aum.i2p/q/ * 4) ??? Ok, yeah, very brief status notes, as I got the timezones mixed up *again* (actually, I got the days mixed up too, thought it was Monday until a few hours ago). Anyway, there is lots of stuff going on not mentioned above, so swing on by the meeting and see whats up! =jr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCUvNtWYfZ3rPnHH0RAlzmAKCAX5PQP8s2wWIxhWnHWG6eeps1nQCffkNC Li2s44HU5EehnMoCMxIOZlc= =WNZp -----END PGP SIGNATURE----- _______________________________________________ i2p mailing list i2p@i2p.net http://i2p.dnsalias.net/mailman/listinfo/i2p ----- End forwarded message ----- -- Eugen* Leitl leitl ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050406/2d640fb1/attachment.pgp From lutianbo at software.ict.ac.cn Wed Apr 6 07:39:41 2005 From: lutianbo at software.ict.ac.cn (Lutianbo) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] Springer LaTex template Message-ID: <004301c53a7b$cba5db40$9402000a@ictltbo> Hi all, Have anyone used the Springer Verlag Latex template? Now I'm using it to make a camera ready paper. But I can't include any figures in the paper. If you have used the Latex for Springer camera ready papers, Would you please send me your Tex files for that paper? Thank you. Kind regards ---Tianbo Lu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20050406/97dd3f51/attachment.htm From larytet.8753341 at bloglines.com Wed Apr 6 15:34:46 2005 From: larytet.8753341 at bloglines.com (larytet.8753341@bloglines.com) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] Stabel release of Rodi Message-ID: <1112801686.4139579262.12776.sendItem@bloglines.com> i think that i reached first stable version supporitng main functionality (ver 0.2.10) screenshots, links to source and binary, forums - all can be found here http://larytet.sourceforge.net/tryRodi.shtml From dcarboni at gmail.com Thu Apr 7 17:47:59 2005 From: dcarboni at gmail.com (Davide Carboni) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] keytool wrapper Message-ID: <71b79fa905040710474d65946@mail.gmail.com> Hi, does anybody know an open source GUI wrapper to java keytool I found http://www.lazgosoftware.com/kse/ but it is commercial -- I have made this letter longer than usual because I lack the time to make it shorter. B. Pascal From dsandler at cs.rice.edu Thu Apr 7 18:15:32 2005 From: dsandler at cs.rice.edu (Dan Sandler) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] keytool wrapper In-Reply-To: <71b79fa905040710474d65946@mail.gmail.com> References: <71b79fa905040710474d65946@mail.gmail.com> Message-ID: <0a41bb9dc5f3cb1f34937c91ccde9840@cs.rice.edu> On Apr 7, 2005, at 12:47 PM, Davide Carboni wrote: > Hi, does anybody know an open source GUI wrapper to java keytool Try Portecle: http://portecle.sourceforge.net/ ---dan -- Try ePOST -- secure peer-to-peer email. http://www.epostmail.org/ From larytet.8753341 at bloglines.com Mon Apr 11 02:51:31 2005 From: larytet.8753341 at bloglines.com (larytet.8753341@bloglines.com) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] DTD for hashed files Message-ID: <1113187891.2723078307.9735.sendItem@bloglines.com> I am looking for DTD describing files/folders + MD5/SHA-1 hashes + block hashes Is anybody aware of existing DTDs. thanks This is what i am looking for (rough idea) ]> 56675f2303d5087e80f3aea757a37d45 From eugen at leitl.org Mon Apr 11 13:52:27 2005 From: eugen at leitl.org (Eugen Leitl) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] [i2p] I2P Consumer Caveat (fwd from david@rebirthing.co.nz) Message-ID: <20050411135227.GL24702@leitl.org> ----- Forwarded message from David McNab ----- From: David McNab Date: Mon, 11 Apr 2005 15:28:35 +1200 To: i2p@i2p.net Subject: [i2p] I2P Consumer Caveat User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) Hi, Following from discussions with smeghead et al on irc, I've realised there's a critical need for a 'System Requirements' section on the website, linked from the 'Documentation' heading in the left column of the main page. In particular, I refer to I2P's relatively voracious traffic requirements. IMHO, users need to be very clearly informed that I2P in its present state of development appears to be incapable of functioning effectively long-term with the consumer internet connection packages available in many countries. As such, it sits alongside Freenet in the ultra-heavy-duty end of the p2p programs' traffic usage spectrum. I humbly tender some serious counsel about making incorrect assumptions about consumer bandwidth availability in different parts of the world. In high-density populated regions like USA, Europe and parts of Asia, bandwidth is high and cheap, and traffic is abundant. Many ISPs are unfazed by people using 30, 50 or more GB/month. But in countries like Au, NZ etc, with (1) geographical isolation, (2) low population density and (3) monopolistic backbone owners, bandwidth and traffic are much scarcer. Here in NZ, typical traffic caps range from 3GB/mo to 15GB/mo. Users who exceed these are either throttled or hit with surprise bills ranging from several hundreds to several thousands of dollars. So what I propose is a 'System Requirements' link under the 'Documentation' link, and for the System Requirements page to contain wording such as: "Please note that in order for I2P to work effectively on your computer, you will need a broadband connection with available bandwidth of at least 128kbits/sec inbound and outbound. "Also please note - an I2P router can generate considerable volumes of traffic, upwards of 30 gigabytes/month or more. "If your internet service provider account does not comfortably allow for your traffic to increase by 30GB/month, then the wisdom of installing I2P on your system at this time might be questionable. "If this is your situation, running an I2P router may lead to unexpected exorbitant excess usage charges, or may lead to your bandwidth being throttled to a level at which your I2P router fails to function effectively. (end of 'System Requirements' text) --- Next - a case study: After leaving my router throttles set to 3kB/s in/out, I got up this morning to find my router had a grand total of 1 active peers :( Obviously 3kB/s in/out (== 15GB/mo) is not enough. smeghead suggested that 30GB/month traffic generated by an I2P router is about the norm. My current router throttle is now set to 8kB/s in/out over 60secs, my router's been up for over an hour with now 50 peers, but nobody (except one) can reach my eepSite. --- Lastly - a strong motivation for me writing Q is to provide a way for bandwidth/traffic-users such as myself to host websites (qSites, like freenet freesites) without needing a 24/7 router. I'm just now building the Q web interface, which listens exclusively within I2P (ie, no TCP connections from browsers). Q URLs will look a lot like: - http://q.i2p/3hfye48ghw3hh39F~74HHew/aum/downloads.html In mandating through-eeproxy access for Q's web interface, anonymity worries like 'gif bugs' are largely solved, since non-I2P HTTP hits will either die in the butt or go sans-IP through one of the outproxies, thanks to eeproxy's strict blocking when it's not configured in the browser as a proxy. (reason for the 'http://q.i2p/...' instead of 'http://q/...' is that eepproxy presently refuses to hit hosts.txt unless the 'domain' ends with '.i2p' - any chance of repealing this, or making an exception on the part of Q?) -- Cheers aum _______________________________________________ i2p mailing list i2p@i2p.net http://i2p.dnsalias.net/mailman/listinfo/i2p ----- End forwarded message ----- -- Eugen* Leitl leitl ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050411/b5f589df/attachment.pgp From eugen at leitl.org Mon Apr 11 19:41:22 2005 From: eugen at leitl.org (Eugen Leitl) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] Re: [i2p] I2P Consumer Caveat (fwd from jrandom@i2p.net) Message-ID: <20050411194121.GS24702@leitl.org> ----- Forwarded message from jrandom ----- From: jrandom Date: Mon, 11 Apr 2005 12:07:31 -0700 To: i2p@i2p.net Subject: Re: [i2p] I2P Consumer Caveat -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Aum (et al) Thanks for the note. I read the scrollback from the channel and I have to say that there's much I agree with you on. We must support users who don't have high capacity links, we must support users who cannot maintain reliable internet connectivity, and when I2P fails, it must fail gracefully. While we've come a long way, we've got a lot of work ahead of us. Right now we do have users on dialup and low end pentiums running I2P. I know it can often be straining in those situations, but the hesitancy I have about stating a minimum set of requirements is that we don't know the minimum requirements yet. A while back, most people were pushing 1-2KBps lifetime, and at another release, people were pushing 8-12KBps. Right now it seems 3-6KBps is the norm. We currently use TCP, so those values are off by a bit (since it doesn't include ACKs and resends), but the move to UDP in 0.6 will throw all those numbers out of wack yet again. So, what are the bandwidth requirements going to be once 1.0 comes out? What affect will restricted routes have upon bandwidth usage in 2.0? What disk resources will be required for nontrivial delays in 3.0? I haven't the foggiest idea. "As little as possible". Our anonymity goals have us aiming at state level adversaries, but to pull that off, we've got to get it working and kicking ass in less hostile regimes first. Along those same lines, our target audience includes those without many resources, but we've got to start somewhere. As for the Q URLs, we've got lots of options. The eepproxy itself is, well, a ball of duct tape. How would the config work - we'd add a new field to the I2PTunnel httpclient edit page to let them specify a destination, and end users copy and paste the destination from Q after they start it up? I'm not entirely sure I understand what the Q architecture is shaping up to look like - could you put together something describing what the components are and what protocols they speak between each other? In any case, I'm sure we can find something to let people have dirt easy Q URLs without mucking around too much. =jr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCWruhWYfZ3rPnHH0RAlSfAJ9W6OlT2ABkUL4ZO2TK6YAowAIdkgCfTH09 CwgbNJIe6VI1XaimX1v8DH8= =iBuO -----END PGP SIGNATURE----- _______________________________________________ i2p mailing list i2p@i2p.net http://i2p.dnsalias.net/mailman/listinfo/i2p ----- End forwarded message ----- -- Eugen* Leitl leitl ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050411/016bc647/attachment.pgp From lemonobrien at yahoo.com Wed Apr 13 00:12:03 2005 From: lemonobrien at yahoo.com (Lemon Obrien) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] peer-to-peer commerce systems In-Reply-To: 6667 Message-ID: <20050413001203.90414.qmail@web53608.mail.yahoo.com> i'm creating a peer-to-peer commerce system for digital media. Eugen Leitl wrote: ----- Forwarded message from jrandom ----- From: jrandom Date: Mon, 11 Apr 2005 12:07:31 -0700 To: i2p@i2p.net Subject: Re: [i2p] I2P Consumer Caveat -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Aum (et al) Thanks for the note. I read the scrollback from the channel and I have to say that there's much I agree with you on. We must support users who don't have high capacity links, we must support users who cannot maintain reliable internet connectivity, and when I2P fails, it must fail gracefully. While we've come a long way, we've got a lot of work ahead of us. Right now we do have users on dialup and low end pentiums running I2P. I know it can often be straining in those situations, but the hesitancy I have about stating a minimum set of requirements is that we don't know the minimum requirements yet. A while back, most people were pushing 1-2KBps lifetime, and at another release, people were pushing 8-12KBps. Right now it seems 3-6KBps is the norm. We currently use TCP, so those values are off by a bit (since it doesn't include ACKs and resends), but the move to UDP in 0.6 will throw all those numbers out of wack yet again. So, what are the bandwidth requirements going to be once 1.0 comes out? What affect will restricted routes have upon bandwidth usage in 2.0? What disk resources will be required for nontrivial delays in 3.0? I haven't the foggiest idea. "As little as possible". Our anonymity goals have us aiming at state level adversaries, but to pull that off, we've got to get it working and kicking ass in less hostile regimes first. Along those same lines, our target audience includes those without many resources, but we've got to start somewhere. As for the Q URLs, we've got lots of options. The eepproxy itself is, well, a ball of duct tape. How would the config work - we'd add a new field to the I2PTunnel httpclient edit page to let them specify a destination, and end users copy and paste the destination from Q after they start it up? I'm not entirely sure I understand what the Q architecture is shaping up to look like - could you put together something describing what the components are and what protocols they speak between each other? In any case, I'm sure we can find something to let people have dirt easy Q URLs without mucking around too much. =jr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCWruhWYfZ3rPnHH0RAlSfAJ9W6OlT2ABkUL4ZO2TK6YAowAIdkgCfTH09 CwgbNJIe6VI1XaimX1v8DH8= =iBuO -----END PGP SIGNATURE----- _______________________________________________ i2p mailing list i2p@i2p.net http://i2p.dnsalias.net/mailman/listinfo/i2p ----- End forwarded message ----- -- Eugen* Leitl leitl ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences You don't get no juice unless you squeeze Lemon Obrien, the Third. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20050412/4a6f72ec/attachment.html From eugen at leitl.org Wed Apr 13 07:14:58 2005 From: eugen at leitl.org (Eugen Leitl) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] [i2p] weekly status notes [apr 12] (fwd from jrandom@i2p.net) Message-ID: <20050413071458.GP24702@leitl.org> ----- Forwarded message from jrandom ----- From: jrandom Date: Tue, 12 Apr 2005 13:55:08 -0700 To: i2p@i2p.net Subject: [i2p] weekly status notes [apr 12] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi y'all, update time again * Index 1) Net status 2) SSU status 3) Bayesian peer profiling 4) Q status 5) ??? * 1) Net status Last week's 0.5.0.6 release seems to have fixed the netDb issues we were seeing (yay). Sites and services are much more reliable than they were on 0.5.0.5, though there have been some reports of trouble where a site or service would become unreachable after a few days uptime. * 2) SSU status There's been lots of progress on the 0.6 UDP code, with the first batch of commits already made to CVS. Its not anything you could actually use yet, but the fundamentals are in place. Session negotiation works well and the semireliable message delivery performs as expected. There's still a lot of work to do though, test cases to write, and oddball situations to debug, but its progress. If things go well, we may have some alpha testing next week, just for people who can explicitly configure their firewalls/NATs. I'd like to get the general operation hammered out first before adding in the relay handler, tuning up the netDb for faster routerInfo expiration, and selecting relays to publish. I'm also going to take this opportunity to do a whole slew of testing, as there are several critical queueing factors being addressed. * 3) Bayesian peer profiling bla has been churning away at some revisions to how we decide what peers to tunnel through, and though bla couldn't make it to the meeting, there's some interesting data to report: <+bla> I've performed direct node speed measurements: I've profiled some 150 nodes by using OB tunnels of length 0, IB tunnels of length 1, batching-interval = 0ms <+bla> In addition, I've just done some _very_ basic and _preliminary_ speed estimation using naive Bayesian classification <+bla> The latter was done using the default expl. tunnel lengths <+bla> The intersection between the set of nodes on which I have "ground truth", and the set of nodes in the current measurements, is 117 nodes <+bla> Results are not _that_ bad, but not too impressive either <+bla> See http://theland.i2p/estspeed.png <+bla> Basic very-slow/fast separation is ok-ish, but fine-grained separation among the faster peers could be much better <+jrandom2p> hmm, how'd the actual values get calculated - is that full RTT or is it RTT/length ? <+bla> Using the normal expl. tunnels, it's next to impossible to prevent batching delays. <+bla> The actual values are the ground-truth values: those obtained using OB=0 and IB=1 <+bla> (and variance=0, and no batching delay) <+jrandom2p> the results look pretty good from here though <+bla> The estimated timings are those obtained using Bayesian inference from _actual_ expl. tunnels of length 2 +/- 1 <+bla> This is obtained from 3000 RTTs, recorded over a period of about 3 hours (that's long) <+bla> It does assume (for the moment) that peer speed is static. I've yet to implement weighting <+jrandom2p> sounds kickass. nice work bla <+jrandom2p> hmm, so the estimate should equal 1/4 actual <+bla> jrandom: No: All measured RTTs (using the normal expl. tunnels), are corrected for the number of hops in the round-trip <+jrandom2p> ah ok <+bla> Only after that, the Bayesian classifier is trained <+bla> For now, I bin the measured times-per-hop into 10 classes: 50, 100, ..., 450 ms, and an additional class >500 ms <+bla> E.g., small delays-per-hop could be weighted using a larger factor, as could complete failures (>60000 ms). <+bla> Though.... 65% of the estimated timings, fall within 0.5 standard deviations from the actual node time <+bla> However, this has to be redone, since the standard deviation is influenced heavily by the >60000 ms failures After further discussion, bla pulled up a comparison against the existing speed calculator, posted @ http://theland.i2p/oldspeed.png Mirrors of those pngs are up at http://dev.i2p.net/~jrandom/estspeed.png and http://dev.i2p.net/~jrandom/oldspeed.png (for terminology, IB=inbound tunnel hops, OB=outbound tunnel hops, and after some clarification, the "ground truth" measurements were obtained by 1 hop outbound and 0 hop inbound, not the other way around) * 4) Q status Aum has been making lots of headway on Q as well, most recently working on a web based client interface. The next Q build will not be backwards compatible, as it includes a whole slew of new features, but I'm sure we'll hear more info from Aum when there's more info to be heard :) * 5) ??? Thats about it for the moment (gotta wrap this up before meeting time). Oh, as an aside, it looks like I'll be moving earlier than planned, so perhaps some of the dates in the roadmap might shift around while I'm in transit to wherever I end up. Anyway, swing on by the channel in a few minutes to harass us with new ideas! =jr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCXCZwWYfZ3rPnHH0RAkFGAJwPHpB7/VkZjOtpLNojf+210p0CeACfeC7t ONGe96zS1hmVNeAzqQgjeUo= =0FjK -----END PGP SIGNATURE----- _______________________________________________ i2p mailing list i2p@i2p.net http://i2p.dnsalias.net/mailman/listinfo/i2p ----- End forwarded message ----- -- Eugen* Leitl leitl ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050413/41dbacc7/attachment.pgp From justin at chapweske.com Wed Apr 13 16:02:31 2005 From: justin at chapweske.com (Justin Chapweske) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] DTD for hashed files In-Reply-To: <1113187891.2723078307.9735.sendItem@bloglines.com> References: <1113187891.2723078307.9735.sendItem@bloglines.com> Message-ID: <1113408151.6702.1077.camel@bog> You might want to look at what we did for THEX, the format has served us quite well: http://www.open-content.net/specs/draft-jchapweske-thex-02.html By the way, we're ditching DIME for multi-part MIME for bundled THEX files. -Justin On Mon, 2005-04-11 at 02:51 +0000, larytet.8753341@bloglines.com wrote: > I am looking for DTD describing files/folders + MD5/SHA-1 hashes + block hashes > > Is anybody aware of existing DTDs. > thanks > > > This is what i am looking > for (rough idea) > > > [ > > > > > name CDATA #REQUIRED > size CDATA #REQUIRED > > blockSize CDATA #REQUIRED > blocksNumber CDATA #REQUIRED > hashType > (md5|sha1) "md5" #REQUIRED > hash CDATA #REQUIRED > modified CDATA > #IMPLIED > > > > > (md5|sha1) "md5"> > > > CDATA #REQUIRED> > ]> > > > modified="6:29 PM 4/9/2005" size="566944" blockSize="4194304" blocksNumber="1" > md5="56675f2303d5087e80f3aea757a37d45"> > > index="0">56675f2303d5087e80f3aea757a37d45 > > > > > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences -- Justin Chapweske From larytet.8753341 at bloglines.com Wed Apr 13 16:26:59 2005 From: larytet.8753341 at bloglines.com (larytet.8753341@bloglines.com) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] DTD for hashed files Message-ID: <1113409619.3841805055.906.sendItem@bloglines.com> i can't find DTD this link http://open-content.net/spec/thex/thex.dtd does not exist (error 404) May you point me to the DTD file or just send me the file thank you --- Peer-to-peer development." quite well: > > http://www.open-content.net/specs/draft-jchapweske-thex-02.html > > By the way, we're ditching DIME for multi-part MIME for bundled THEX > files. > > -Justin > > On Mon, 2005-04-11 at 02:51 +0000, larytet.8753341@bloglines.com wrote: > > I am looking for DTD describing files/folders + MD5/SHA-1 hashes + block hashes > > > > Is anybody aware of existing DTDs. > > thanks > > > > > > This is what i am looking > > for (rough idea) > > > > > > > [ > > ELEMENT rodiHash (file, folder)+ > > > > ELEMENT file (blocks) > > > > ATTLIST file > name CDATA #REQUIRED > > size CDATA #REQUIRED > > > > blockSize CDATA #REQUIRED > > blocksNumber CDATA #REQUIRED > > hashType > > (md5|sha1) "md5" #REQUIRED > > hash CDATA #REQUIRED > > modified CDATA > > #IMPLIED > > > > > > > ELEMENT blocks (block+) > > ATTLIST blocks hashType > (md5|sha1) "md5"> > > > > ELEMENT block (#CDATA) > > ATTLIST block index > CDATA #REQUIRED> > > ]> > > > > > > > modified="6:29 PM 4/9/2005" size="566944" blockSize="4194304" blocksNumber="1" > > md5="56675f2303d5087e80f3aea757a37d45"> > > > > > index="0">56675f2303d5087e80f3aea757a37d45 > > > > > > > > > > > > _______________________________________________ > > p2p-hackers mailing list > > p2p-hackers@zgp.org > > http://zgp.org/mailman/listinfo/p2p-hackers > > _______________________________________________ > > Here is a web page listing P2P Conferences: > > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > -- > Justin Chapweske > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > From justin at chapweske.com Thu Apr 14 04:12:49 2005 From: justin at chapweske.com (Justin Chapweske) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] DTD for hashed files In-Reply-To: <1113409619.3841805055.906.sendItem@bloglines.com> References: <1113409619.3841805055.906.sendItem@bloglines.com> Message-ID: <1113451970.6702.1271.camel@bog> Fixed. It had been removed for a bit since some stupid client was hitting it 50,000 times per day. On Wed, 2005-04-13 at 16:26 +0000, larytet.8753341@bloglines.com wrote: > i can't find DTD > this link > http://open-content.net/spec/thex/thex.dtd > > does not exist (error 404) > May you point me to the DTD file or just send > me the file > thank you > > > --- Peer-to-peer development." wrote: > You might want to look at what we did for THEX, the format has served > us > > quite well: > > > > http://www.open-content.net/specs/draft-jchapweske-thex-02.html > > > > > By the way, we're ditching DIME for multi-part MIME for bundled THEX > > > files. > > > > -Justin > > > > On Mon, 2005-04-11 at 02:51 +0000, larytet.8753341@bloglines.com > wrote: > > > I am looking for DTD describing files/folders + MD5/SHA-1 hashes > + block hashes > > > > > > Is anybody aware of existing DTDs. > > > thanks > > > > > > > > > > This is what i am looking > > > for (rough idea) > > > version='1.0' encoding='utf-8'?> > > > > > > > > [ > > > > ELEMENT rodiHash (file, folder)+ > > > > > > ELEMENT file (blocks) > > > > > > > ATTLIST file > > name CDATA #REQUIRED > > > size CDATA #REQUIRED > > > > > > > blockSize CDATA #REQUIRED > > > blocksNumber CDATA #REQUIRED > > > > hashType > > > (md5|sha1) "md5" #REQUIRED > > > hash CDATA #REQUIRED > > > > modified CDATA > > > #IMPLIED > > > > > > > > > > ELEMENT blocks > (block+) > > > ATTLIST blocks hashType > > (md5|sha1) "md5"> > > > > > > > ELEMENT block (#CDATA) > > > ATTLIST block index > > CDATA #REQUIRED> > > > > ]> > > > > > > > > > > > > modified="6:29 PM 4/9/2005" size="566944" blockSize="4194304" blocksNumber="1" > > > > md5="56675f2303d5087e80f3aea757a37d45"> > > > > > > > > > index="0">56675f2303d5087e80f3aea757a37d45 > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > p2p-hackers mailing list > > > p2p-hackers@zgp.org > > > http://zgp.org/mailman/listinfo/p2p-hackers > > > > _______________________________________________ > > > Here is a web page > listing P2P Conferences: > > > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > > > -- > > Justin Chapweske > > > > _______________________________________________ > > > p2p-hackers mailing list > > p2p-hackers@zgp.org > > http://zgp.org/mailman/listinfo/p2p-hackers > > > _______________________________________________ > > Here is a web page listing > P2P Conferences: > > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > > > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences -- Justin Chapweske From me at pixelcort.com Thu Apr 14 07:29:30 2005 From: me at pixelcort.com (Cortland Klein) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] Hybrid Static/Dynamic DHT Systems Message-ID: <425E1BDA.7010800@pixelcort.com> This design proposal aims to describe a DHT system which has both a functional mutable hash table and a replicating static content hash table. The problem I see with traditional DHT systems is that they can not easilly replicate data without making it much more difficult to maintain up-to-date state. In addition, it becomes impossible to provide an immutable reference to particular data. A Hybrid DHT System would have two subsystems, the traditional dynamic mutable hash table and the added replicating static content hash table. The static content hash table is a simple table where the keys are the SHA-1 of the content and the content is a length prefixed amount of data limited to 256KB. When a key is requested, it's value is automatically cached among the path of nodes to the node requesting the data. Nodes maintain their own caches and replace old keys with new keys as they pass through. Old keys are chosen based not only on their last request time, but also how close the key is to the node's ID. If the node is 'responsible' for a key, it remains in the cache indefinitely. Thus, we can achieve replication while ensuring at least one copy is always on the network. Data larger than 256KB is split up into chunks and a splitfile containing a list of the static content keys for each chunk is used to represent the data. The dynamic mutable hash table provides for each key a revisioned list of pointers to static content keys. Thus, each dynamic key's content has a table with datestamps and static content keys. To get the current value for a dynamic key, the system then does a lookup for the static content key. The node responsible for the key maintains this revisioned list and updates it when a put is made on the key. It can then expire old revisions after both a set number of revisions and at least a certain amount of time have passed. My reasoning behind having two tables is that dynamic data cannot easilly be replicated due to its mutability, however it can point to static data which can be replicated. By having the static data retain a 'responsible' node, we can ensure that at least one copy of the static data is available. Any thoughts? -- Cortland Klein (XMPP/SMTP) nuWeb Project Founder - http://nuweb.org/ "Infinite Scalability" Journal - http://pixelcort.com/ "Ranting and Raving" The geeks shall take over the world and the bits shall be set free! From lemonobrien at yahoo.com Thu Apr 14 18:49:30 2005 From: lemonobrien at yahoo.com (Lemon Obrien) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] Hybrid Static/Dynamic DHT Systems In-Reply-To: 6667 Message-ID: <20050414184931.14194.qmail@web53603.mail.yahoo.com> when i designed my hashing system i gave up trying to understand all the academic stuff. i don't get it....i don't even know why you need hashing in peer to peer systems. I used it for search and db entries to make it supper fast; cause somparing strings would be slow; the only real requirements are 1) speed (fast hashing), 2) wide distribution (little collision) and 3) all software running on my netowrk use the same function (not hard since you need software to search). I then found one on the internet; and now just use that. so Cortland Klein wrote: This design proposal aims to describe a DHT system which has both a functional mutable hash table and a replicating static content hash table. The problem I see with traditional DHT systems is that they can not easilly replicate data without making it much more difficult to maintain up-to-date state. In addition, it becomes impossible to provide an immutable reference to particular data. A Hybrid DHT System would have two subsystems, the traditional dynamic mutable hash table and the added replicating static content hash table. The static content hash table is a simple table where the keys are the SHA-1 of the content and the content is a length prefixed amount of data limited to 256KB. When a key is requested, it's value is automatically cached among the path of nodes to the node requesting the data. Nodes maintain their own caches and replace old keys with new keys as they pass through. Old keys are chosen based not only on their last request time, but also how close the key is to the node's ID. If the node is 'responsible' for a key, it remains in the cache indefinitely. Thus, we can achieve replication while ensuring at least one copy is always on the network. Data larger than 256KB is split up into chunks and a splitfile containing a list of the static content keys for each chunk is used to represent the data. The dynamic mutable hash table provides for each key a revisioned list of pointers to static content keys. Thus, each dynamic key's content has a table with datestamps and static content keys. To get the current value for a dynamic key, the system then does a lookup for the static content key. The node responsible for the key maintains this revisioned list and updates it when a put is made on the key. It can then expire old revisions after both a set number of revisions and at least a certain amount of time have passed. My reasoning behind having two tables is that dynamic data cannot easilly be replicated due to its mutability, however it can point to static data which can be replicated. By having the static data retain a 'responsible' node, we can ensure that at least one copy of the static data is available. Any thoughts? -- Cortland Klein (XMPP/SMTP) nuWeb Project Founder - http://nuweb.org/ "Infinite Scalability" Journal - http://pixelcort.com/ "Ranting and Raving" The geeks shall take over the world and the bits shall be set free! _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences You don't get no juice unless you squeeze Lemon Obrien, the Third. --------------------------------- Do you Yahoo!? Yahoo! Small Business - Try our new resources site! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20050414/bb7f2e64/attachment.html From lemonobrien at yahoo.com Thu Apr 14 18:49:55 2005 From: lemonobrien at yahoo.com (Lemon Obrien) Date: Sat Dec 9 22:12:53 2006 Subject: [p2p-hackers] Hybrid Static/Dynamic DHT Systems In-Reply-To: 6667 Message-ID: <20050414184955.13109.qmail@web53606.mail.yahoo.com> when i designed my hashing system i gave up trying to understand all the academic stuff. i don't get it....i don't even know why you need hashing in peer to peer systems. I used it for search and db entries to make it supper fast; cause somparing strings would be slow; the only real requirements are 1) speed (fast hashing), 2) wide distribution (little collision) and 3) all software running on my netowrk use the same function (not hard since you need software to search). I then found one on the internet; and now just use that. Cortland Klein wrote: This design proposal aims to describe a DHT system which has both a functional mutable hash table and a replicating static content hash table. The problem I see with traditional DHT systems is that they can not easilly replicate data without making it much more difficult to maintain up-to-date state. In addition, it becomes impossible to provide an immutable reference to particular data. A Hybrid DHT System would have two subsystems, the traditional dynamic mutable hash table and the added replicating static content hash table. The static content hash table is a simple table where the keys are the SHA-1 of the content and the content is a length prefixed amount of data limited to 256KB. When a key is requested, it's value is automatically cached among the path of nodes to the node requesting the data. Nodes maintain their own caches and replace old keys with new keys as they pass through. Old keys are chosen based not only on their last request time, but also how close the key is to the node's ID. If the node is 'responsible' for a key, it remains in the cache indefinitely. Thus, we can achieve replication while ensuring at least one copy is always on the network. Data larger than 256KB is split up into chunks and a splitfile containing a list of the static content keys for each chunk is used to represent the data. The dynamic mutable hash table provides for each key a revisioned list of pointers to static content keys. Thus, each dynamic key's content has a table with datestamps and static content keys. To get the current value for a dynamic key, the system then does a lookup for the static content key. The node responsible for the key maintains this revisioned list and updates it when a put is made on the key. It can then expire old revisions after both a set number of revisions and at least a certain amount of time have passed. My reasoning behind having two tables is that dynamic data cannot easilly be replicated due to its mutability, however it can point to static data which can be replicated. By having the static data retain a 'responsible' node, we can ensure that at least one copy of the static data is available. Any thoughts? -- Cortland Klein (XMPP/SMTP) nuWeb Project Founder - http://nuweb.org/ "Infinite Scalability" Journal - http://pixelcort.com/ "Ranting and Raving" The geeks shall take over the world and the bits shall be set free! _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences You don't get no juice unless you squeeze Lemon Obrien, the Third. --------------------------------- Do you Yahoo!? Make Yahoo! your home page -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20050414/a165290e/attachment.htm From mleslie at fnal.gov Sat Apr 16 19:55:09 2005 From: mleslie at fnal.gov (Matt Leslie) Date: Sat Dec 9 22:12:53 2006 Subject: [p2p-hackers] Hybrid Static/Dynamic DHT Systems In-Reply-To: <425E1BDA.7010800@pixelcort.com> References: <425E1BDA.7010800@pixelcort.com> Message-ID: <42616D9D.5050005@fnal.gov> The idea of having both mutable pointers to the latest version, and immutable versions of a data item is used in OceanStore (http://oceanstore.cs.berkeley.edu/publications/papers/pdf/fast2003-pond.pdf). The problem arises that revision lists in the 'dynamic hash table' should also be replicated for reliability, so you are going to have to pay the cost of maintaining consistent replicas at some level. I'm currently looking at the costs and benefits of several replication schemes for DHTs, and I hope to be able to make the results public soon. Matt Cortland Klein wrote: > This design proposal aims to describe a DHT system which has both a > functional mutable hash table and a replicating static content hash > table. > > The problem I see with traditional DHT systems is that they can not > easilly replicate data without making it much more difficult to > maintain up-to-date state. In addition, it becomes impossible to > provide an immutable reference to particular data. > > A Hybrid DHT System would have two subsystems, the traditional dynamic > mutable hash table and the added replicating static content hash table. > > The static content hash table is a simple table where the keys are the > SHA-1 of the content and the content is a length prefixed amount of > data limited to 256KB. When a key is requested, it's value is > automatically cached among the path of nodes to the node requesting > the data. Nodes maintain their own caches and replace old keys with > new keys as they pass through. Old keys are chosen based not only on > their last request time, but also how close the key is to the node's > ID. If the node is 'responsible' for a key, it remains in the cache > indefinitely. Thus, we can achieve replication while ensuring at least > one copy is always on the network. Data larger than 256KB is split up > into chunks and a splitfile containing a list of the static content > keys for each chunk is used to represent the data. > > The dynamic mutable hash table provides for each key a revisioned list > of pointers to static content keys. Thus, each dynamic key's content > has a table with datestamps and static content keys. To get the > current value for a dynamic key, the system then does a lookup for the > static content key. The node responsible for the key maintains this > revisioned list and updates it when a put is made on the key. It can > then expire old revisions after both a set number of revisions and at > least a certain amount of time have passed. > > My reasoning behind having two tables is that dynamic data cannot > easilly be replicated due to its mutability, however it can point to > static data which can be replicated. By having the static data retain > a 'responsible' node, we can ensure that at least one copy of the > static data is available. > > Any thoughts? > From larytet.8753341 at bloglines.com Sun Apr 17 01:29:12 2005 From: larytet.8753341 at bloglines.com (larytet.8753341@bloglines.com) Date: Sat Dec 9 22:12:53 2006 Subject: [p2p-hackers] DTD for search requests Message-ID: <1113701352.4086302061.21613.sendItem@bloglines.com> is anybody aware of such DTD ? the following is part of XML i would like to see Linux tutorial document 10 i need something flexible, because sometimes i will look for folders and sometimes for chat rooms ID's thanks From nlothian at educationau.edu.au Sun Apr 17 23:36:38 2005 From: nlothian at educationau.edu.au (Nick Lothian) Date: Sat Dec 9 22:12:53 2006 Subject: [p2p-hackers] DTD for search requests Message-ID: The closest you are going to come (AFAIK) is the Google API's WSDL: http://api.google.com/GoogleSearch.wsdl. Most search applications use different syntaxes for query strings rather than an XML based query API. Nick > -----Original Message----- > From: p2p-hackers-bounces@zgp.org > [mailto:p2p-hackers-bounces@zgp.org] On Behalf Of > larytet.8753341@bloglines.com > Sent: Sunday, 17 April 2005 10:59 AM > To: p2p-hackers@zgp.org > Subject: [p2p-hackers] DTD for search requests > > is anybody aware of such DTD ? > the following is part of XML i would like to see > Linux tutorial > document > > 10 > > i need something > flexible, because sometimes i will look for folders and > sometimes for chat rooms ID's > > thanks > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of education.au limited except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email. From larytet.8753341 at bloglines.com Sun Apr 17 23:44:11 2005 From: larytet.8753341 at bloglines.com (larytet.8753341@bloglines.com) Date: Sat Dec 9 22:12:53 2006 Subject: [p2p-hackers] DTD for search requests Message-ID: <1113781451.2872432250.9007.sendItem@bloglines.com> thanks. i think i will go ahead with proprietary solution. no need to read google license agreement, etc.. besides i suspect that my application can eventually compete with Google. --- Peer-to-peer development." The closest you are going to come (AFAIK) is the Google API's WSDL: > http://api.google.com/GoogleSearch.wsdl. > > Most search applications use different syntaxes for query strings rather > than an XML based query API. > > Nick > > > -----Original Message----- > > From: p2p-hackers-bounces@zgp.org > > [mailto:p2p-hackers-bounces@zgp.org] On Behalf Of > > larytet.8753341@bloglines.com > > Sent: Sunday, 17 April 2005 10:59 AM > > To: p2p-hackers@zgp.org > > Subject: [p2p-hackers] DTD for search requests > > > > is anybody aware of such DTD ? > > the following is part of XML i would like to see > > Linux tutorial > > document > > > > 10 > > > > i need something > > flexible, because sometimes i will look for folders and > > sometimes for chat rooms ID's > > > > thanks > > _______________________________________________ > > p2p-hackers mailing list > > p2p-hackers@zgp.org > > http://zgp.org/mailman/listinfo/p2p-hackers > > _______________________________________________ > > Here is a web page listing P2P Conferences: > > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > > > > > IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. > This email represents the views of the individual sender, which do not necessarily reflect those of education.au limited except where the sender expressly states otherwise. > It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. > education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email. > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > From sam at neurogrid.com Mon Apr 18 05:14:59 2005 From: sam at neurogrid.com (Sam Joseph) Date: Sat Dec 9 22:12:53 2006 Subject: [p2p-hackers] DTD for search requests In-Reply-To: <1113701352.4086302061.21613.sendItem@bloglines.com> References: <1113701352.4086302061.21613.sendItem@bloglines.com> Message-ID: <42634253.3020902@neurogrid.com> There is also WEBDAV Search. http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html CHEERS> SAM larytet.8753341@bloglines.com wrote: >is anybody aware of such DTD ? >the following is part of XML i would like >to see > > Linux tutorial > document > > 10 > > >i need something >flexible, because sometimes i will look for folders and sometimes for chat >rooms ID's > >thanks >_______________________________________________ >p2p-hackers mailing list >p2p-hackers@zgp.org >http://zgp.org/mailman/listinfo/p2p-hackers >_______________________________________________ >Here is a web page listing P2P Conferences: >http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > > > > From p2p-hackers at ryanb.org Mon Apr 18 09:27:29 2005 From: p2p-hackers at ryanb.org (Ryan Barrett) Date: Sat Dec 9 22:12:53 2006 Subject: [p2p-hackers] DTD for search requests In-Reply-To: <1113701352.4086302061.21613.sendItem@bloglines.com> References: <1113701352.4086302061.21613.sendItem@bloglines.com> Message-ID: in addition to google's api wsdl and webdav search, consider ibm's UIMA, which owes a fair amount to their webfountain project. http://www.research.ibm.com/UIMA/ http://www.alphaworks.ibm.com/tech/uima http://www.almaden.ibm.com/webfountain/ On Sat, 17 Apr 2005 larytet.8753341@bloglines.com wrote: > is anybody aware of such DTD ? > the following is part of XML i would like > to see > > Linux tutorial > document > > 10 > > > i need something > flexible, because sometimes i will look for folders and sometimes for chat > rooms ID's > > thanks > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > -Ryan -- http://ryan.barrett.name/ From nlothian at educationau.edu.au Mon Apr 18 07:15:31 2005 From: nlothian at educationau.edu.au (Nick Lothian) Date: Sat Dec 9 22:12:53 2006 Subject: [p2p-hackers] DTD for search requests Message-ID: >From the FAQ (http://www.alphaworks.ibm.com/tech/uima/faq#09): "Is an XML Fragment Query supposed to be valid XML? Not exactly. The XML Fragment query syntax used by the semantic search engine that is shipped with UIMA uses basic XML syntax as an intuitive way to describe hierarchical patterns of annotations that may occur in a CAS. It deviates from valid XML in a few minor ways in order to support queries over "overlapping" or "cross-over" annotations." Is there any documentation of this query format available? (Since we are talking about search engine APIs, forgive me for plugging my library: http://argos.dev.java.net/ . It isn't P2P but may be of interest in the current context). Nick > -----Original Message----- > From: p2p-hackers-bounces@zgp.org > [mailto:p2p-hackers-bounces@zgp.org] On Behalf Of Ryan Barrett > Sent: Monday, 18 April 2005 6:57 PM > To: Peer-to-peer development. > Cc: Daniel N. Meredith > Subject: Re: [p2p-hackers] DTD for search requests > > in addition to google's api wsdl and webdav search, consider > ibm's UIMA, which owes a fair amount to their webfountain project. > > http://www.research.ibm.com/UIMA/ > http://www.alphaworks.ibm.com/tech/uima > http://www.almaden.ibm.com/webfountain/ > > > On Sat, 17 Apr 2005 larytet.8753341@bloglines.com wrote: > > > is anybody aware of such DTD ? > > the following is part of XML i would like to see > > Linux tutorial document > > > > 10 > > > > i need something > > flexible, because sometimes i will look for folders and > sometimes for > > chat rooms ID's > > > > thanks > > _______________________________________________ > > p2p-hackers mailing list > > p2p-hackers@zgp.org > > http://zgp.org/mailman/listinfo/p2p-hackers > > _______________________________________________ > > Here is a web page listing P2P Conferences: > > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > > > > -Ryan > > -- > > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > IMPORTANT: This e-mail, including any attachments, may contain private or confidential information. If you think you may not be the intended recipient, or if you have received this e-mail in error, please contact the sender immediately and delete all copies of this e-mail. If you are not the intended recipient, you must not reproduce any part of this e-mail or disclose its contents to any other party. This email represents the views of the individual sender, which do not necessarily reflect those of education.au limited except where the sender expressly states otherwise. It is your responsibility to scan this email and any files transmitted with it for viruses or any other defects. education.au limited will not be liable for any loss, damage or consequence caused directly or indirectly by this email. From wangyong at software.ict.ac.cn Mon Apr 18 07:18:25 2005 From: wangyong at software.ict.ac.cn (=?gb2312?B?zfXTwg==?=) Date: Sat Dec 9 22:12:53 2006 Subject: [p2p-hackers] question Message-ID: <20050418071827.881D73FC2C@capsicum.zgp.org> Hi, ALL I want to model the srpead of worms on the p2p system. how to express the model with discrete methods? the basic routing model is chord, the worms will spread according the routing tale of eacch node. my msn is crazy_wang2004@hotmail.com wangyong 　　　　　　　　wangyong@software.ict.ac.cn 　　　　　　　　　　2005-04-18 -------------- next part -------------- A non-text attachment was scrubbed... Name: 3.GIF Type: image/gif Size: 13690 bytes Desc: not available Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050418/a978d5c2/3.gif From Bernard.Traversat at Sun.COM Wed Apr 20 20:14:06 2005 From: Bernard.Traversat at Sun.COM (Bernard Traversat) Date: Sat Dec 9 22:12:53 2006 Subject: [p2p-hackers] Hybrid Static/Dynamic DHT Systems In-Reply-To: <425E1BDA.7010800@pixelcort.com> References: <425E1BDA.7010800@pixelcort.com> Message-ID: <4266B80E.9080002@sun.com> You should look at JXTA (www.jxta.org). We have implemented a loosely-coupled DHT that uses a lazy synchronization mechanism to reduce the DHT re-synchronization issues you are describing. Hth, B. Cortland Klein wrote: > This design proposal aims to describe a DHT system which has both a > functional mutable hash table and a replicating static content hash > table. > > The problem I see with traditional DHT systems is that they can not > easilly replicate data without making it much more difficult to > maintain up-to-date state. In addition, it becomes impossible to > provide an immutable reference to particular data. > > A Hybrid DHT System would have two subsystems, the traditional dynamic > mutable hash table and the added replicating static content hash table. > > The static content hash table is a simple table where the keys are the > SHA-1 of the content and the content is a length prefixed amount of > data limited to 256KB. When a key is requested, it's value is > automatically cached among the path of nodes to the node requesting > the data. Nodes maintain their own caches and replace old keys with > new keys as they pass through. Old keys are chosen based not only on > their last request time, but also how close the key is to the node's > ID. If the node is 'responsible' for a key, it remains in the cache > indefinitely. Thus, we can achieve replication while ensuring at least > one copy is always on the network. Data larger than 256KB is split up > into chunks and a splitfile containing a list of the static content > keys for each chunk is used to represent the data. > > The dynamic mutable hash table provides for each key a revisioned list > of pointers to static content keys. Thus, each dynamic key's content > has a table with datestamps and static content keys. To get the > current value for a dynamic key, the system then does a lookup for the > static content key. The node responsible for the key maintains this > revisioned list and updates it when a put is made on the key. It can > then expire old revisions after both a set number of revisions and at > least a certain amount of time have passed. > > My reasoning behind having two tables is that dynamic data cannot > easilly be replicated due to its mutability, however it can point to > static data which can be replicated. By having the static data retain > a 'responsible' node, we can ensure that at least one copy of the > static data is available. > > Any thoughts? > -- --http://weblogs.java.net/blog/tra "As Java implies platform independence, and XML implies language independence, JXTA implies network independence." From me at pixelcort.com Wed Apr 20 20:30:15 2005 From: me at pixelcort.com (Cortland Klein) Date: Sat Dec 9 22:12:53 2006 Subject: [p2p-hackers] Static Keyspace in Hybrid Static/Dynamic DHTs In-Reply-To: <4266B80E.9080002@sun.com> References: <425E1BDA.7010800@pixelcort.com> <4266B80E.9080002@sun.com> Message-ID: <3F8F0CAA-6471-4BE6-84B1-67689F83F69A@pixelcort.com> On Apr 20, 2005, at 1:14 PM, Bernard Traversat wrote: > You should look at JXTA (www.jxta.org). We have implemented a > loosely-coupled DHT that uses a lazy synchronization > mechanism to reduce the DHT re-synchronization issues you > are describing. I'm presuming you mean dynamic keys can be replicated and synchronized. If my presumption is correct, that sounds like a great functionality that would imply no static keyspace is necessary. However, I would like to make another case for a static keyspace, in addition to a dynamic keyspace, in a DHT. The issue comes down to being able to refer directly to a particular exact piece of data, such that the system can guarantee that the data will not mutate. Sure, one could use the dynamic keyspace, but all it takes is another to modify a given key that is not meant to be modified. Thusly, I remain in support of Hybrid Static/Dynamic DHTs, to support both static data and dynamic metadata (pointers to static data). Note: Additional concerns over identification and subspaces are not addressed in this message and may be addressed in future threads. -- Cortland Klein (XMPP/SMTP) nuWeb Project Founder - http://nuweb.org/ "Infinite Scalability" Journal - http://pixelcort.com/ "Ranting and Raving" The geeks shall take over the world and the bits shall be set free! From srhea at cs.berkeley.edu Wed Apr 20 21:57:19 2005 From: srhea at cs.berkeley.edu (Sean C. Rhea) Date: Sat Dec 9 22:12:53 2006 Subject: [p2p-hackers] Static Keyspace in Hybrid Static/Dynamic DHTs In-Reply-To: <3F8F0CAA-6471-4BE6-84B1-67689F83F69A@pixelcort.com> References: <425E1BDA.7010800@pixelcort.com> <4266B80E.9080002@sun.com> <3F8F0CAA-6471-4BE6-84B1-67689F83F69A@pixelcort.com> Message-ID: <5023bc95e27c05ed8479ce6266f5043b@cs.berkeley.edu> On Apr 20, 2005, at 1:30 PM, Cortland Klein wrote: > However, I would like to make another case for a static keyspace, in > addition to a dynamic keyspace, in a DHT. The issue comes down to > being able to refer directly to a particular exact piece of data, such > that the system can guarantee that the data will not mutate. Sure, one > could use the dynamic keyspace, but all it takes is another to modify > a given key that is not meant to be modified. Caveat: I'm not sure I know what you're talking about. That said, the Bamboo DHT (bamboo-dht.org) supports both immutable and mutable values. The interface we allow for OpenDHT (opendht.org) does not, but the underlying code does. It doesn't support atomic read-modify-write, but you can easily set a new value for a key and remove the old one. If two clients do this at the same time, you'll end up with both values; so it's easy to notice that something went wrong and fix it. Does that fit your needs? Sean -- I contend that we are both atheists. I just believe in one fewer god than you do. When you understand why you dismiss all the other possible gods, you will understand why I dismiss yours. -- Stephen Roberts -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050420/1911c02f/PGP.pgp From tyler.close at gmail.com Wed Apr 20 23:26:11 2005 From: tyler.close at gmail.com (Tyler Close) Date: Sat Dec 9 22:12:53 2006 Subject: [p2p-hackers] Zooko's Triangle in action Message-ID: <5691356f050420162627102780@mail.gmail.com> Hi all, A number of list members have built, or are building, p2p environments where files or public keys are referred to by their hash. The common wisdom seems to be that a petname system, as popularized by Zooko's Triangle, can be used to make the human interface to this world of computer/cryptography friendly identifiers. Given that, I thought list members might be interested in the petname tool Firefox extension. The petname tool is a fully functional petname system for SSL secured web sites. It is compatible with existing HTTPS sites, so you can create a petname for your bank. It really is Zooko's Triangle in action. You can get it at: http://petname.mozdev.org/ Tyler -- The web-calculus is the union of REST and capability-based security: http://www.waterken.com/dev/Web/ From coderman at gmail.com Wed Apr 20 23:39:25 2005 From: coderman at gmail.com (coderman) Date: Sat Dec 9 22:12:53 2006 Subject: [p2p-hackers] Re: Byzantine Quorum Systems / key predistribution In-Reply-To: <63099cbffbb15834bf7e5478a6dabd69@zooko.com> References: <20050223013206.42103.qmail@szabo.best.vwh.net> <63099cbffbb15834bf7e5478a6dabd69@zooko.com> Message-ID: <4ef5fec605042016397422a70b@mail.gmail.com> I'm interested in using key predistribution for transitive introduction with strong identities. I have to echo Zooko's sentiment that the popularity of such methods in the kazaa crowd is not going to be high. I'm mainly interested in feasibility. The way I have kludged this together is as follows: 1. Bootstrap with a live CD. you create an "identity" on a USB fob with AES256 loopback (knoppix). 2. Create a large number of RSA key pairs for use in transitive introduction. "large" may be 1,000 keys or 10M. (GnuPG) 3. Burn a copy of live CD for your friend(s). Each copy includes all of the public keys associated with your identity (for use with transitive introduction). 4. Friends bootstrap their CD (creating an identity if they don't have one) and can request connections from the peers with predistributed keys on the disc. When a connection is requested the remote peer tells the client which of the predistributed keys to use. I let the remote peer select the key to use (via a simple offset, key #2048 for ex.) to prevent keys from being re-used. 5. These connections can in turn be used for secure transitive introduction to other peers. The goal is to exchange keys "out of band" via DVD-R ISO images, with the cache of public predistributed keys appended to as the distribution is copied from friend to friend. What kinds of things would you use this for? On 2/23/05, Zooko O'Whielacronx wrote: > ... > This paper can be lossily compressed as: "Your scheme can handle up to > K malicious nodes. My attacker can bring K+1 malicious nodes to the > party.". > > ... > This implicit premise is that a connection between two node arises ex > nihilo. That is: for any three nodes A, B, and C, A has (at the start) > no information about how B differs from C. This assumption is > obviously key to the whole issue. It is also obviously wrong! > > In practice the opposite is often true: for any three nodes A, B, and > C, A often has information distinguishing B from C. This is because A > has been introduced to B somehow, and that introduction gave A > information. (Likewise with A's introduction to C.) From lemonobrien at yahoo.com Thu Apr 21 00:17:10 2005 From: lemonobrien at yahoo.com (Lemon Obrien) Date: Sat Dec 9 22:12:53 2006 Subject: [p2p-hackers] Re: Byzantine Quorum Systems / key predistribution In-Reply-To: 6667 Message-ID: <20050421001710.17726.qmail@web53607.mail.yahoo.com> >> What kinds of things would you use this for? to hide from the cops coderman wrote: I'm interested in using key predistribution for transitive introduction with strong identities. I have to echo Zooko's sentiment that the popularity of such methods in the kazaa crowd is not going to be high. I'm mainly interested in feasibility. The way I have kludged this together is as follows: 1. Bootstrap with a live CD. you create an "identity" on a USB fob with AES256 loopback (knoppix). 2. Create a large number of RSA key pairs for use in transitive introduction. "large" may be 1,000 keys or 10M. (GnuPG) 3. Burn a copy of live CD for your friend(s). Each copy includes all of the public keys associated with your identity (for use with transitive introduction). 4. Friends bootstrap their CD (creating an identity if they don't have one) and can request connections from the peers with predistributed keys on the disc. When a connection is requested the remote peer tells the client which of the predistributed keys to use. I let the remote peer select the key to use (via a simple offset, key #2048 for ex.) to prevent keys from being re-used. 5. These connections can in turn be used for secure transitive introduction to other peers. The goal is to exchange keys "out of band" via DVD-R ISO images, with the cache of public predistributed keys appended to as the distribution is copied from friend to friend. What kinds of things would you use this for? On 2/23/05, Zooko O'Whielacronx wrote: > ... > This paper can be lossily compressed as: "Your scheme can handle up to > K malicious nodes. My attacker can bring K+1 malicious nodes to the > party.". > > ... > This implicit premise is that a connection between two node arises ex > nihilo. That is: for any three nodes A, B, and C, A has (at the start) > no information about how B differs from C. This assumption is > obviously key to the whole issue. It is also obviously wrong! > > In practice the opposite is often true: for any three nodes A, B, and > C, A often has information distinguishing B from C. This is because A > has been introduced to B somehow, and that introduction gave A > information. (Likewise with A's introduction to C.) _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences You don't get no juice unless you squeeze Lemon Obrien, the Third. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20050420/90e642dd/attachment.html From eugen at leitl.org Fri Apr 22 08:18:10 2005 From: eugen at leitl.org (Eugen Leitl) Date: Sat Dec 9 22:12:53 2006 Subject: [p2p-hackers] I2P triple+file sharing network? (Was Re: [i2p] simple gnucleus over i2p needed) (fwd from adam@atommic.com) Message-ID: <20050422081810.GM31578@leitl.org> ----- Forwarded message from Adam Atlas ----- From: Adam Atlas Date: Thu, 21 Apr 2005 17:19:28 -0400 To: i2p@i2p.net Subject: I2P triple+file sharing network? (Was Re: [i2p] simple gnucleus over i2p needed) X-Mailer: Apple Mail (2.619.2) I had an idea like this a while ago, but I had a potentially important thought: If we just port a P2P network onto this anonymizing framework, it'll seem like we're doing it solely to break the law and evade punishment. (Depending on the ruling of the current US Supreme Court case relating to file sharing, MGM v. Grokster, this could actually get the I2P devs in trouble, or at least whichever ones live in the US.) I personally am not interested in doing this just to share music -- I actually support all that "free speech" stuff (as I'm sure most I2P users do) -- but I won't judge others' motives, either way. However, to unleash an untraceable, unstoppable file-sharing network would undeniably make the I2P project look really evil, even though individual users wouldn't get caught. Anyway, since an I2P file-sharing network doesn't exist yet, we have the chance to be truly innovative, instead of just copying existing things that were innovative a few years ago. I've thought of a way to make an I2P network much more useful than any existing file-sharing networks, including several possible uses that *don't* have to do with warez or illegal MP3s! (We can leave that to Freenet.) Here's how it works: It's still a distributed searchable data store at heart. Nodes search other nodes, and then download the files, thus helping to share them further. The classic file-sharing network. But the difference is that it's integrated with RDF [1]. *Not* the RDF/XML serialization [2], mind you -- anonymizing networks are slow enough *without* huge XML payloads flying around. No, just the triple-oriented core metadata model. That would allow for smarter searches, maybe based on RDQL, going far beyond the present style of dumb filename searching (and even the Filename/Artist/Album music metadata searching available on some P2P protocols). So what would be the use of this, aside from finding potentially evil and/or illegal content with greater ease? I'll tell you. Combined with file-signing (distinct from I2P's built-in encryption), it would open up a world of decentralized democratic content-organization capabilities. As one example, here's how one would build a distributed discussion forum/BBS platform atop such a network. (For now I won't discuss the network architecture -- we'll assume that the peers are already connected to each other, however we decide the best way would.) We define an RDF predicate -- let's call it for now -- indicating that the subject file is a message posted into a discussion board represented by the object, and , indicating that the subject file is a message replying to the object message. Now suppose we're chatting away in #i2p, and a few people decide they want a more permanent discussion area. So they mint a tag [3] in a namespace controlled by one of them -- perhaps a Postman I2P email address, or a well-accepted .i2p domain name, as the authority name -- or maybe just a uuid URI. A URI representing their discussion board, in any case. Let's suppose it's . They then add that URI to their forum-browsing programs ("subscribe" to it). Since this P2P network can also store metadata about abstract non-file resources (as well as the usual file annotations), the contributors throw some basic Dublin Core [4] metadata into the mesh -- title, description, stuff like that. This is stored not centrally anywhere, but is propagated on a triple-by-triple basis. Once people have added some metadata, anyone else who subscribes to this forum will receive this info. Behind the scenes, the forum browser will have retrieved this by making a query to the network, asking for all triples where the subject is . Once it receives this metadata, it will begin sharing it also. (What stops people from distributing incorrect triples? By combining social means with technological means. Clients might have a capability to "disagree" with a triple, where it stops sharing it. Further, it reifies [5] the triple, and forms a new triple saying that the aforementioned statement is inaccurate, and another saying that its source is untrustworthy. This can eventually result in a complex web of trust.) Then, introductory metadata aside, conversation can commence. They post a message by doing so in their forum client, which may be a local web-based app or a stand-alone program. (Most likely, it would not connect directly to the network, but would connect through a daemon which would handle the SAM connections and provide a public API for client programs. Naturally there would be a vanilla file-search client, but that would only be the tip of the iceberg.) When they post a message, that's where the file-sharing comes in. The program generates a file containing their message, digitally signed using PGP or some other public-key cryptography (only so multiple messages can be securely associated with the same person -- not to identify the sender by a real name, of course). Then, the most important part, it adds the metadata key. Other forum clients can now find this message, without it being stored anywhere, simply by searching for all ?x such that { ?x }. ?x should match multiple files -- one for each post in the forum (though from any number of sources). The client can then download it, however the download mechanism works (it would be good to include a swarming mechanism and transport compression from the start, at least for bigish files). Then, in a manner similar to but not the same as Freenet, popular things propagate, while unpopular things eventually disappear. Things (triples AND files) spread when people download and keep them. That increases their availability. And thanks to the digital signatures, you know a message is from who it appears, even if you're downloading it through someone else. Of course, all that would take place behind the scenes. In the hypothetical forum client, you'd see a list of forums you subscribe to, and you could view recent posts in any of them, and post new messages. I think this demonstrates fairly well what such a simple extension to the traditional P2P paradigm could bring. Extending it further, we could have anonymous blogs, websites, etc. *without* a designated file store, whether central (i.e. HTTP) or distributed (i.e. Freenet or Stasher). And as I said, there would no doubt also be a plain file-searching client, perhaps as a module for GiFT or mlnet so we instantly have a bunch of full-featured clients. Any comments/criticism, anyone? Better/worse than porting Gnutella, etc.? Too much effort? Potential problems? 'Tis just a thought. A very long thought, but just a thought. Whether or not anyone likes the idea, I'm just hoping it can lead to some insightful discussion and useful results. -- Adam Atlas, non-anonymous Semantic Web geek [1] http://www.w3.org/RDF/ [2] http://www.w3.org/TR/rdf-syntax-grammar/ [3] http://www.taguri.org/ [4] http://dublincore.org/ [5] http://www.w3.org/TR/rdf-schema/#ch_reificationvocab On 2005-04-15, thus spake closedshop : >Hi >we need a simple gnutella client with accepting magnet links workable >over i2p. >then all users will come. >It woudl be best, if this gnucleus dna is installed with i2p installer. >cause gnutella is most c++ and i2o is java, we need a exe installer, >which isntalles both on windows. >See here these simple gnutella clients., >the first one is quite easy and has a good design. > >http://www.diyp2p.com/ >http://www.slyck.com/forums/viewtopic.php?t=10570 > >It this is done, we will see all other second generation apps >chanionging thier sockets for i2p. >So make an initial phase, please. > >thanks >_______________________________________________ >i2p mailing list >i2p@i2p.net >http://i2p.dnsalias.net/mailman/listinfo/i2p _______________________________________________ i2p mailing list i2p@i2p.net http://i2p.dnsalias.net/mailman/listinfo/i2p ----- End forwarded message ----- -- Eugen* Leitl leitl ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050422/8e2fbeb7/attachment.pgp From em at em.no-ip.com Fri Apr 22 11:44:54 2005 From: em at em.no-ip.com (Enzo Michelangeli) Date: Sat Dec 9 22:12:53 2006 Subject: [p2p-hackers] Ways of enforcing "property rights" for data published to a DHT Message-ID: <039601c54730$c70f5400$0200a8c0@em.noip.com> >From what I understand of Overnet's implementation of Kademlia, any record published by a peer can be easily overwritten by any other peer if the latter publishes a different record with the same key and the same "secondary hash" (the "data" part in Overnet comprises another 128-bit string -- what I call "secondary hash" -- and an optional dictionary of pairs). I wonder if other DHT's implement mechanisms to make a record protected from being overwritten by unauthorized parties. A simple way could be based on adding to the data an unguessable "cookie" (say, another 128-bit string with randoly-generated content) that would be stored in the DHT but NOT returned as result of a successful search; republishing a record with a different dictionary would result in the replacement of one previously existing ONLY if also the cookie were the same. Unfortunately this improvement cannot be put in place while preserving interoperability with the existing Overnet network, but I wonder if and how other DHT's have tackled this issue. Enzo From srhea at cs.berkeley.edu Fri Apr 22 17:11:20 2005 From: srhea at cs.berkeley.edu (Sean C. Rhea) Date: Sat Dec 9 22:12:53 2006 Subject: [p2p-hackers] Ways of enforcing "property rights" for data published to a DHT In-Reply-To: <039601c54730$c70f5400$0200a8c0@em.noip.com> References: <039601c54730$c70f5400$0200a8c0@em.noip.com> Message-ID: <6a921b17a9f7c79aa9748d5b9d7d8c87@cs.berkeley.edu> On Apr 22, 2005, at 4:44 AM, Enzo Michelangeli wrote: > I wonder if other DHT's implement mechanisms to make a record protected > from being overwritten by unauthorized parties. A simple way could be > based on adding to the data an unguessable "cookie" (say, another > 128-bit > string with randoly-generated content) that would be stored in the DHT > but > NOT returned as result of a successful search; republishing a record > with > a different dictionary would result in the replacement of one > previously > existing ONLY if also the cookie were the same. Unfortunately this > improvement cannot be put in place while preserving interoperability > with > the existing Overnet network, but I wonder if and how other DHT's have > tackled this issue. In OpenDHT, we store all records for a certain time-to-live (TLL), specified by the client that puts the record, and capped at one week (although we're going to push the cap up to a month soon). If two clients store under the same key, and the values are different, we store both values. If the values are the same, we store just one, but for the longest of the two TTLs specified. The problem, of course, is that some people want to remove their values from time to time. We could handle this with public key crypto (and we have a planned interface that does so), but a lot of people want something more simple for now. Here's our planned interface, which we should be rolling out in the next few weeks: The idea is to use one-way functions. For example, with each put, you give OpenDHT a key k, a value v, and some number y. To remove, you provide k and SHA(v) (in order to specify which value you want to remove, in case there are more than one), plus the value x such that f(x)=y, where f is a well-known one-way function, such as SHA (recent results aside). Gets on k will also return y in addition to v. Once a remove is issued, it's stored in the DHT for a TTL just like any other k,v pair, and an OpenDHT node won't return k,v pairs for which it has a remove. The semantics are simple and consistent with the current eventually-consistent model. We'll leave 0 as the "null y", so that you can specify that some k,v pairs cannot be removed. (You could just pick a random y for which you can't compute the pre-image under f, but that's annoying.) Moreover, you can build client-side extensions so that one client can remove another's puts, and you don't really need a different secret for each put. Consider a set of clients who all share some secret key s. For each put, a client picks a random number x, computes y=f(x), and computes x'=x encrypted with s. It then does put(k,(v,x'),y). If one of its friends wants to remove the value, it does get(k) to learn x', decrypts it using s to get x, and then does remove(k,v,x). But s is never sent over the wire, so there's no eavesdropping problem as there would be with the cookie idea you mentioned above. The source code for OpenDHT is all available on the Bamboo web site (bamboo-dht.org), so you can use it in projects of your own if you don't want to use the public deployment on PlanetLab. I should have this new remove functionality in there in the next few weeks. Sean -- I contend that we are both atheists. I just believe in one fewer god than you do. When you understand why you dismiss all the other possible gods, you will understand why I dismiss yours. -- Stephen Roberts -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050422/e6abf71d/PGP.pgp From me at pixelcort.com Fri Apr 22 19:33:13 2005 From: me at pixelcort.com (Cortland Klein) Date: Sat Dec 9 22:12:53 2006 Subject: [p2p-hackers] Ways of enforcing "property rights" for data published to a DHT In-Reply-To: <039601c54730$c70f5400$0200a8c0@em.noip.com> References: <039601c54730$c70f5400$0200a8c0@em.noip.com> Message-ID: <32671A30-C8CB-4C57-824A-0B283C1C59F6@pixelcort.com> One solution could be Freenet-style dynamic subspaces. The keys for a dynamic subspace would be marked with a 160-bit public key, and the values or linked values would include a cryptographic signature. When a peer receives a Put message, they look up the value and check that the inner value hashed and encrypted decrypts with the given public key. If that test passes, the put is successful. Likewise, any get on a key that is a subspace key will cause the peer to check the validity of the signature against the public key. On Apr 22, 2005, at 4:44 AM, Enzo Michelangeli wrote: > I wonder if other DHT's implement mechanisms to make a record > protected > from being overwritten by unauthorized parties. A simple way could be > based on adding to the data an unguessable "cookie" (say, another > 128-bit > string with randoly-generated content) that would be stored in the > DHT but > NOT returned as result of a successful search; republishing a > record with > a different dictionary would result in the replacement of one > previously > existing ONLY if also the cookie were the same. Unfortunately this > improvement cannot be put in place while preserving > interoperability with > the existing Overnet network, but I wonder if and how other DHT's have > tackled this issue. > -- Cortland Klein (XMPP/SMTP) nuWeb Project Founder - http://nuweb.org/ "Infinite Scalability" Journal - http://pixelcort.com/ "Ranting and Raving" The geeks shall take over the world and the bits shall be set free! From lemonobrien at yahoo.com Sat Apr 23 01:42:17 2005 From: lemonobrien at yahoo.com (Lemon Obrien) Date: Sat Dec 9 22:12:53 2006 Subject: [p2p-hackers] Ways of enforcing "property rights" for data published to a DHT In-Reply-To: 6667 Message-ID: <20050423014217.80063.qmail@web53607.mail.yahoo.com> if i told you i'd have to kill you; but the first solution would to get ride of or re-think what a DHT is. Cortland Klein wrote:One solution could be Freenet-style dynamic subspaces. The keys for a dynamic subspace would be marked with a 160-bit public key, and the values or linked values would include a cryptographic signature. When a peer receives a Put message, they look up the value and check that the inner value hashed and encrypted decrypts with the given public key. If that test passes, the put is successful. Likewise, any get on a key that is a subspace key will cause the peer to check the validity of the signature against the public key. On Apr 22, 2005, at 4:44 AM, Enzo Michelangeli wrote: > I wonder if other DHT's implement mechanisms to make a record > protected > from being overwritten by unauthorized parties. A simple way could be > based on adding to the data an unguessable "cookie" (say, another > 128-bit > string with randoly-generated content) that would be stored in the > DHT but > NOT returned as result of a successful search; republishing a > record with > a different dictionary would result in the replacement of one > previously > existing ONLY if also the cookie were the same. Unfortunately this > improvement cannot be put in place while preserving > interoperability with > the existing Overnet network, but I wonder if and how other DHT's have > tackled this issue. > -- Cortland Klein (XMPP/SMTP) nuWeb Project Founder - http://nuweb.org/ "Infinite Scalability" Journal - http://pixelcort.com/ "Ranting and Raving" The geeks shall take over the world and the bits shall be set free! _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences You don't get no juice unless you squeeze Lemon Obrien, the Third. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20050422/69ab9c5e/attachment.htm From joaquin.keller at francetelecom.com Wed Apr 27 10:31:23 2005 From: joaquin.keller at francetelecom.com (KELLER Joaquin RD-MAPS-ISS) Date: Sat Dec 9 22:12:53 2006 Subject: [p2p-hackers] Solipsis: a peer-to-peer shared virtual world Message-ID: The Solipsis Team would like to announce the release of Solipsis-0.8. http://solipsis.netofpeers.net/ Solipsis is a massively multiparticipant virtual world based on a peer-to-peer system (ie without servers). Some Solipsis prominent features are: * Scalable to millions, billions of users and entities * Solipsis is intended to be as wide as the Web * The virtual world is user contributed (so it is for now nearly empty) * Solipsis is aimed for social interaction (not only for gaming) * Open Source - Free Software - GNU Public License * It runs on Windows, Linux (and hopefully soon on Mac OS X) Coming soon: * Blog-like user profile * File transfer * Private chat * Management of multiple nodes To do list includes: VoIP, 3D View, ... Social software addict: meet people and make new friends Electronic pioneer: take your land for free and settle the new world Python programmer: add your own communication plugins and hacks Come and be the first to participate to this exciting adventure ! ;-) http://solipsis.netofpeers.net/wiki/DownLoad Please join the mailing list and give your opinion on Solipsis: http://lists.berlios.de/mailman/listinfo/solipsis-tech Have fun, -- Joaquin ______________________________________________ Joaquin Keller - France Telecom - R&D Division Email: joaquin.keller Peer networks @rd.francetelecom.com Solipsis Project http://solipsis.netofpeers.net/ From solipsis at pitrou.net Wed Apr 27 11:46:09 2005 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat Dec 9 22:12:53 2006 Subject: [p2p-hackers] Solipsis: a peer-to-peer shared virtual world In-Reply-To: References: Message-ID: <1114602369.3749.6.camel@p-dhcp-333-72.rd.francetelecom.fr> > * Open Source - Free Software - GNU Public License Correction: it is distributed under the GNU Lesser General Public License (LGPL). From luigi at diacronic.org Wed Apr 27 13:01:20 2005 From: luigi at diacronic.org (=?iso-8859-1?Q?Luigi_De_Don=E0?=) Date: Sat Dec 9 22:12:53 2006 Subject: [p2p-hackers] porting FreePastry (java NIO) to J2ME Message-ID: <426D3A4B0002962D@vsmtp2alice.tin.it> (added by postmaster@aliceposta.it) Hi all, I would like to make a port of FreePastry from the J2SE to a Java micro edition platform. My main concern is about Java NIO. The exact destination platform is JVM Skelmir CEE-J (it supports Personal Java 1.0 - JDK 1.1.8) running on Linux kernel 2.4. I am looking for a java micro edition JNIO or similar libraries. Any ideas ? Please let me know. Luigi De Don? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20050427/904f7cd0/attachment.html From qop-submission at dit.unitn.it Fri Apr 29 11:50:25 2005 From: qop-submission at dit.unitn.it (qop-submission) Date: Sat Dec 9 22:12:53 2006 Subject: [p2p-hackers] CFP - Quality of Protection Workshop - Security Measurements and Metrics Message-ID: <685656169.20050429135025@dit.unitn.it> (* Apologies for multiple copies *) =========================================================================== Preliminary Call for Paper for the 1st International Workshop on QUALITY of PROTECTION - QoP 2005 Security Measurements and Metrics http://dit.unitn.it/~qop/ Milano, Italy, Thu. 15 September 2005. Affiliated with 10th European Symposium on Research in Computer Security (ESORICS 2005) in Milano (12-14 Sep). http://esorics05.dti.unimi.it and the 11th IEEE International Software Metrics Symposium (METRICS 2005) in Como (19-22 Sep) http://www.swmetrics.org/metrics2005 =========================================================================== WORKSHOP OVERVIEW Information Security in Industry has matured in the last few decades. Standards such as ISO17799, the Common Criteria, a number of industrial certification and risk analysis methodologies have raised the bar on what is considered a good security solution from a business perspective. Yet, if we compare Information Security with Networking or Empirical Software Engineering we find a major difference. Networking research has introduced concepts such as Quality of Service and Service Level Agreements. Conferences and Journals are frequently devoted to performance evaluation, QoS and SLAs. Empirical Software Engineering has made similar advances. Notions such as software metrics and measurements are well established. Processes to measure the quality and reliability of software exist and are appreciated in industry. Security looks different. Even a fairly sophisticated standard such as ISO17799 has an intrinsically qualitative nature. Notions such as Security Metrics, Quality of Protection (QoP) or Protection Level Agreement (PLA) have surfaced in the literature but still have a qualitative flavour. The "QoP field" in WS-Security is just a data field to specify a cryptographic algorithm. Indeed, neither ISO17799 nor ISO15408 (the Common Criteria) addresses QoP sufficiently. ISO17799 is a management standard, not directly concerned with the actual quality of protection achieved; ISO15408 is instead a product assessment standard and yet does not answer the question of how a user of a product assessed by it can achieve a high QoP within his/her operational environment. Both standards cover just one aspect of an effective QoP and even the combination of both would not address the aspect sufficiently. "Best practice" standards, such as the baseline protection standard published by many government agencies, also belong to the category of standards that are useful, but not sufficient, for achieving a good QoP. Security is different also in another respect. A very large proportion of recorded security incidents has a non-IT cause. Hence, while the networking and software communities may concentrate on technical features (networks and software), security requires a much wider notion of "system", including users, work processes, organisational structures in addition to the IT infrastructure. The QoP Workshop intends to discuss how security research can progress towards a notion of Quality of Protection in Security comparable to the notion of Quality of Service in Networking, Software Reliability, or Software Measurements and Metrics in Empirical Software Engineering. SUBMISSION TOPICS: Original submissions are solicited from industry and academic experts to presents their work, plans and views related to Quality of Protection. The topics of interest include but are not limited to: * Industrial Experience * Security Risk Analysis * Security Quality Assurance * Measurement-based decision making and risk management * Empirical assessment of security architectures and solutions * Mining data from attacks and vulnerabilities repositories * Security metrics * Measurement theory and formal theories of security metrics * Security measurement and monitoring, * Experimental verification and validation of models, * Simulation and statistical analysis, stochastic modeling * Reliability analysis INVITED SPEAKERS - Stefano De Panfilis - Engineering SpA (IT) - TBA IMPORTANT DATES: - Fri 10 June - Paper submissions - Fri 8 July - Notification of acceptance - Mon 12 Sep - Wed 14 Sep ESORICS - Thu 15 Sep - QoP Workshop - Mon 19 Sep - Thu 22 Sep IEEE METRICS in Como PAPER SUBMISSION: Original RESEARCH PAPERS are solicited in any of the above mentioned topics. Research papers should be limited to 12 pages in the standard Springer Verlag format, describing significant research results based on sound theory or experimental assessment. We also solicit INDUSTRY EXPERIENCE REPORTS, limited to 6 pages, about the use of security measurements and metrics in industrial environments. Industry papers should have at least one author from industry or government, and will be considered for their industrial relevance. PUBLICATION: Authors of accepted papers will be expected to give full presentations at the workshop. Revised versions of the papers presented at the workshop will be published by Kluwer/Springer in the Applied Security Series. STEERING COMMITTEE - Imrich Chlamtac - UTDallas (US) & CreateNet (IT) - Gerhard Eschelbeck - QUALYS (US) - Dieter Gollmann - TU Hamburg-Harburg (DE) - Helmut Kurth - ATSEC (DE) - Bev Littlewood - City University, London (UK) - Fabio Massacci - Univ. di Trento (IT) - Ketil Stoelen - SINTEF (NO) & Univ. of Oslo (NO) - Lorenzo Stringini - City University, London (UK) - Jeannette Wing - CMU (USA) From seth.johnson at RealMeasures.dyndns.org Sat Apr 30 09:24:18 2005 From: seth.johnson at RealMeasures.dyndns.org (Seth Johnson) Date: Sat Dec 9 22:12:53 2006 Subject: [p2p-hackers] Solipsis: a peer-to-peer shared virtual world References: Message-ID: <42734EC2.2881BF62@RealMeasures.dyndns.org> Running on Win98 SE, I get this error when I run navigator.exe: Traceback (most recent call last): File "navigator.py", line 16, in ? File "solipsis\navigator\wxclient\main.pyo", line 37, in main File "solipsis\navigator\wxclient\app.pyo", line 72, in __init__ File "wx\_core.pyo", line 5301, in __init__ File "wx\_core.pyo", line 4980, in _BootstrapApp File "solipsis\navigator\wxclient\app.pyo", line 200, in OnInit File "solipsis\navigator\wxclient\app.pyo", line 119, in InitResources File "solipsis\util\wxutils.pyo", line 102, in Resource NameError: resource object 'about_dialog' does not exist Is there something missing from the Windows distro? twistednode.exe seems to be doing something when I run it, no apparent problems. Seth Johnson KELLER Joaquin RD-MAPS-ISS wrote: > > The Solipsis Team would like to announce the release of Solipsis-0.8. > > http://solipsis.netofpeers.net/ > > Solipsis is a massively multiparticipant virtual world > based on a peer-to-peer system (ie without servers). > > Some Solipsis prominent features are: > > * Scalable to millions, billions of users and entities > * Solipsis is intended to be as wide as the Web > * The virtual world is user contributed (so it is for now nearly empty) > * Solipsis is aimed for social interaction (not only for gaming) > * Open Source - Free Software - GNU Public License > * It runs on Windows, Linux (and hopefully soon on Mac OS X) > > Coming soon: > * Blog-like user profile > * File transfer > * Private chat > * Management of multiple nodes > > To do list includes: VoIP, 3D View, ... > > Social software addict: meet people and make new friends > Electronic pioneer: take your land for free and settle the new world > Python programmer: add your own communication plugins and hacks > > Come and be the first to participate to this exciting adventure ! ;-) > http://solipsis.netofpeers.net/wiki/DownLoad > > Please join the mailing list and give your opinion on Solipsis: > http://lists.berlios.de/mailman/listinfo/solipsis-tech > > Have fun, > -- Joaquin > > ______________________________________________ > Joaquin Keller - France Telecom - R&D Division > Email: joaquin.keller Peer networks > @rd.francetelecom.com Solipsis Project > http://solipsis.netofpeers.net/ > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > > -- > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 266.10.3 - Release Date: 4/25/05 -- RIAA is the RISK! Our NET is P2P! http://www.nyfairuse.org/action/ftc DRM is Theft! We are the Stakeholders! New Yorkers for Fair Use http://www.nyfairuse.org [CC] Counter-copyright: http://realmeasures.dyndns.org/cc I reserve no rights restricting copying, modification or distribution of this incidentally recorded communication. Original authorship should be attributed reasonably, but only so far as such an expectation might hold for usual practice in ordinary social discourse to which one holds no claim of exclusive rights.