From clausen at gnu.org Mon Jul 1 01:21:02 2002 From: clausen at gnu.org (Andrew Clausen) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Distributed Domain Name System In-Reply-To: References: <5.1.0.14.0.20020625193545.039fbec0@popmail.cortland.com> Message-ID: <20020626051807.GD1153@gnu.org> On Tue, Jun 25, 2002 at 10:03:35PM -0700, Bram Cohen wrote: > Come on people, this is p2p-hackers, not bluesky. Some of us have actual > working projects here, and really don't care to hear this pie-in-the-sky > rambling. I'm interested in pie-in-the-sky rambling (as well as working projects). Is there another list for ramblings? Andrew From lgonze at panix.com Mon Jul 1 01:22:24 2002 From: lgonze at panix.com (Lucas Gonze) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Distributed Timestamping Service In-Reply-To: <3D22AA49.8090900@yahoo.com> Message-ID: > >>To make things easier, I don't really need the real time. All I need is a > >>timeline of discrete events, one following the other, rather than the real > >>time. For example, each "time click" could be a hash, and the next time-click > >>would fold the previous hash into itself, and so on. So instead of having a > >>service that says 1:00 PM, then 2:00 PM, etc., it simply says Time Click A, > >>Time Click B, Time Click C, etc. ...fun stuff... some thoughts on it while I'm taking a coffee break: This seems doable as a directed graph with edges from signed data to data which it it is used to sign. When a node signs data for some other node, it certifies that the signed data was present by that time. But what about the key being signed with? It might have been created at any point. So, the key should have been signed at some previous time by a third node. This establishes sequential information between the signed data and the signing key. It says that the key existed first. There is no need to have just one signer. The opposite -- you want a lot of signers and a lot of signatures so that you can establish a sequence as a directed graph. The sequence does break. It's not perfect at all. Signing chains can't be traced back infinitely. A signer is not available to affirm that the sequence is correct. There will be parallel sequences of signing chains where there aren't crosslinks available to help you interleave events. Constantly establishing keys doesn't make sense. The algorithm works just as well if there is a third bit of data, a use-once token. Can that work? Don't know. Like anything else this half assed, somebody must have already written this idea up better with actual discipline! - Lucas From bram at gawth.com Mon Jul 1 02:50:02 2002 From: bram at gawth.com (Bram Cohen) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Next san francisco p2p-hackers meeting sunday, july 14th Message-ID: A groundhog showed its face in golden gate park and we now know when the next p2p-hackers meeting will be San Francisco SONY Metreon (food court area - there may be better places to mee upstairs, I'm gonna check it out this sunday) Sunday, July 14th, 3pm till we feel like leaving And, this being a special groundhog, we now have a regular schedule! Second sunday of the month. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From bram at gawth.com Mon Jul 1 07:46:02 2002 From: bram at gawth.com (Bram Cohen) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Distributed Domain Name System In-Reply-To: <20020626051807.GD1153@gnu.org> Message-ID: Andrew Clausen wrote: > I'm interested in pie-in-the-sky rambling (as well as working projects). > Is there another list for ramblings? http://groups.yahoo.com/group/decentralization/ http://www.transarc.ibm.com/~ota/bluesky/ -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From cefn.hoile at bt.com Mon Jul 1 10:27:02 2002 From: cefn.hoile at bt.com (cefn.hoile@bt.com) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Distributed Domain Name System Message-ID: Hal, Sorry for the response to the old posting below re: distributing names amongst the world's population. There was a similar approach to the distribution of property of publically owned companies in the old soviet bloc countries. Everyone in the population was given an equal amount of shares for free, and they let the market fight out the value. In practice, a few wise old hounds sneaked the shares out of the hands of most shareholders for the price of a potato, (in which people saw more immediate value). They then went on to become multi-millionaires as majority shareholders. Cefn -----Original Message----- From: Hal Finney [mailto:hal@finney.org] Sent: 25 June 2002 07:53 To: p2p-hackers@zgp.org Subject: Re: [p2p-hackers] Distributed Domain Name System Brad Neuberg writes: > Taking names is on a first come, first served basis. If you get it > first, you have it. At first I was concerned that this would produce a "gold rush" mentality like we saw in the early days of the .com era and make people build huge name-reservation farms to grab names as fast as possible. Thousands of names a second, millions of names a day, every possible word, every possible combination of letters, all snapped up by speculators. But then I thought again, and I realized that this is actually a good thing. According to Coase's Theorem, if you have an efficient market in property titles (and the net is great at that kind of thing) and everything is clearly owned by some person, you have a very efficient system. It doesn't matter how the initial allocation is done, the property will end up in the hands of the people who can put it to the best use. So really the problem in a system like the DNS is how to make the names available as efficiently as possible. A system like this where they are made available very quickly and cheaply is a good choice. Another possibility is somehow to distribute all of the names among every person in the world. If you wanted a certain name you could look up in a registry (or run an algorithm) and figure out which one person in the entire world owned it. Then you would try and buy it from them. One way to do this would be to number every person in the world, and use a hash function from names to numbers for the initial assignment. This is not that practical because most people aren't on the net, and even if they were, it doesn't seem possible to number each person. Then there are all those births and deaths, although this can be handled in principle like any other form of property title. So failing a system like this, just getting the names into people's hands any old way is not a bad approach. Make it as cheap as possible so that no labor is lost in getting the names out there, and the market will solve the rest of the problem... Hal Finney _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers From bradneuberg at yahoo.com Mon Jul 1 16:21:02 2002 From: bradneuberg at yahoo.com (Brad Neuberg) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Distributed Timestamping Service References: Message-ID: <3D28CDF9.8010007@yahoo.com> Lucas Gonze wrote: >>>>To make things easier, I don't really need the real time. All I need is a >>>>timeline of discrete events, one following the other, rather than the real >>>>time. For example, each "time click" could be a hash, and the next time-click >>>>would fold the previous hash into itself, and so on. So instead of having a >>>>service that says 1:00 PM, then 2:00 PM, etc., it simply says Time Click A, >>>>Time Click B, Time Click C, etc. >>>> >>>> > >...fun stuff... some thoughts on it while I'm taking a coffee break: > >This seems doable as a directed graph with edges from signed data to data >which it it is used to sign. > >When a node signs data for some other node, it certifies that the signed >data was present by that time. But what about the key being signed with? >It might have been created at any point. So, the key should have been >signed at some previous time by a third node. > > Interesting idea. I'm still trying to "grok" it. I should have brought up that this distributed timing service is living above a very unreliable network; i.e. nodes pop into and out of existence quite often (probably on the range that every hour over half the nodes are replaced). In a sense it sounds like your idea is to create very long certificate chains. As time "clicks" on and the directed graph of nodes signing nodes grows, won't it get longer and longer to "authenticate" that time, or do I have a misunderstanding? >This establishes sequential information between the signed data >and the signing key. It says that the key existed first. > >There is no need to have just one signer. The opposite -- you want >a lot of signers and a lot of signatures so that you can establish a >sequence as a directed graph. > >The sequence does break. It's not perfect at all. Signing chains can't >be traced back infinitely. A signer is not available to affirm that the >sequence is correct. There will be parallel sequences of signing >chains where there aren't crosslinks available to help you interleave >events. > >Constantly establishing keys doesn't make sense. The algorithm works >just as well if there is a third bit of data, a use-once token. Can that >work? Don't know. > > What do you mean? >Like anything else this half assed, somebody must have already written >this idea up better with actual discipline! > > You'd be surprised; this looks like virgin territory. There has been _very_ little work on distributed timing services, unless someone made breakthroughs in a parallel field and didn't realize that it could be applied to this problem. I think the problem is worth solving. Once you have a crytographicly secure distributed time service you can use it to create first come, first served bindings between pieces of data, such as username to public key, or web site name to IP address. Binding username to public key and stamping it with the time would let you create a first come, first served distributed PKI service, while binding web site name to IP address would let you create a first come, first served distributed naming service. As a solution to this problem, I'm wondering how our bodies establish a sort of time or cycles that are used somehow. I think there might be some interesting biological/chemical solutions to this problem that can be used as inspiration, similar to the famous Bray-Liebhafsky reaction that exhibited chemical oscillations. In the BL reaction, certain chemicals are placed in a dish. After a brief period of inactivity, the dish begins to oscillate from red to blue and back again in a cyclic, clock-like pattern. The BL experiment has been called important because it is a simple chemical reaction that might help us understand how biological time-like oscillations happen. A biological time-keeping service, so to speak, would have to solve many of the problems in the peer-to-peer example: decentralized, no central trust, nodes fall in and out (cell birth and death), and resistance to hijacking by cancerous cells or viruses. Thanks, Brad Neuberg codinginparadise.org >- Lucas > > >_______________________________________________ >p2p-hackers mailing list >p2p-hackers@zgp.org >http://zgp.org/mailman/listinfo/p2p-hackers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20020701/84082595/attachment.htm From lgonze at panix.com Mon Jul 1 18:35:01 2002 From: lgonze at panix.com (Lucas Gonze) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Distributed Timestamping Service In-Reply-To: <3D28CDF9.8010007@yahoo.com> Message-ID: On Sun, 7 Jul 2002, Brad Neuberg wrote: > Interesting idea. I'm still trying to "grok" it. I should have brought > up that this distributed timing service is living above a very > unreliable network; i.e. nodes pop into and out of existence quite often > (probably on the range that every hour over half the nodes are replaced). I think that we can establish alternate routes along the directed graph, given luck. So it comes down to how much churn and how long the timestamp chains need to be. > In a sense it sounds like your idea is to create very long certificate > chains. As time "clicks" on and the directed graph of nodes signing > nodes grows, won't it get longer and longer to "authenticate" that time, > or do I have a misunderstanding? A signs B's key, B signs C's key. There's an authenticated chain of events where A's key is known to exist before B's, and B's is known to exist before C's. The more you have to authenticate, the more of the network you have to traverse. That doesn't mean that any one signature has to include all of the prior signatures. Just like with a chain, a link only has to touch its nearest neighbors. > >Constantly establishing keys doesn't make sense. The algorithm works > >just as well if there is a third bit of data, a use-once token. Can that > >work? Don't know. > > > > > What do you mean? The older a key is, the less chronological data it provides. For example if A's key is five minutes old, and it is used to sign B's key, then B's key is known to be no older than five minutes. If A's key is a year old, the signature on B's key gives less exact information about when the signature on B's key happened. So you need to keep generating keys to keep clock ticks reasonably fine grained. Generating keys is expensive. Is there a cheat to reduce the expense? > Once > you have a crytographicly secure distributed time service you can use it > to create first come, first served bindings between pieces of data, such > as username to public key, or web site name to IP address. I wonder how much of this niche SPKI already fills? Maybe that is a good place to start cannibalizing. - Lucas From bram at gawth.com Mon Jul 1 21:51:02 2002 From: bram at gawth.com (Bram Cohen) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] New release of BitTorrent out Message-ID: A new release of BitTorrent is out - http://bitconjurer.org/BitTorrent/download.html New in this release - massive performance enhancements and bug fixes, greatly cleaned up and simplified publication process, and new ability for the tracker to keep out downloaders, using --nonat 1 If there aren't any major snags in this release (and I don't expect any, every bad performance artifact which showed up before has now been thoroughly nuked) then the next release will no longer have a version check on startup. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From lgonze at panix.com Tue Jul 2 10:18:02 2002 From: lgonze at panix.com (Lucas Gonze) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Distributed Timestamping Service In-Reply-To: <3D293064.2010709@yahoo.com> Message-ID: Brad Neuberg wrote: > >>In a sense it sounds like your idea is to create very long certificate > >>chains. As time "clicks" on and the directed graph of nodes signing > >>nodes grows, won't it get longer and longer to "authenticate" that time, > >>or do I have a misunderstanding? You're right, given that the maximum length of the chain depends on the amount of time between two events. However there can be a minimal path which is shorter. Let's say A->B, B->C, ..., Y->Z == 25 hops. But also, A->Y, Y->Z == 2 hops. You could probably do that with standard topological tools like Chord, so that the maximum path between two clicks would be log N. You have a chain A...Z with intermediaries B...Y. How do you find the shortest path { A->Y, Y->Z }, starting with Z? You look up Y, X has two signatures { W->X, A->X }, then you jump from X back to A. On the other hand you may not be able to find the shortest path. Let's say there are two paths from A...E -- A->B->C->E and A->D->E. From E's perspective, there's no way to tell whether C or D will lead to the shorter path. A neat thing is that you could also work out the maximum length of a verifiable sequence, because it's a function of the network half life. - Lucas From rikdmont at attbi.com Wed Jul 3 12:15:01 2002 From: rikdmont at attbi.com (ricardo montoya) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] RE: Welcome to the "p2p-hackers" mailing list (Digest mode) In-Reply-To: <20020702214037.14ADE3FC1B@capsicum.zgp.org> Message-ID: <000401c222c5$ebfe2bc0$6501a8c0@we.client2.attbi.com> Thank you so much for the latest report, as a matter of fact I was beginning to wander how come such a powerful hacker community was being left over with bread crumbles by the recording industry, all this p2p stuff began by hackers and should be decentralize so there is no foul up, most everybody agrees the internet was, is and will be peoples property, not of whoever or whomsoever looking for more ways to enrich themselves, these companies do not want to listen,this could have been avoided, all of this mess, by simply lowering CD prices, instead of, they sued none faulty parties, raised prices of it, claiming loses on sales and forcing everybody to repay for their business ineptitud, they forgot customers (Uhmp, that's us) make them rich and believe me they will pay the price. To finish let me remember some of the words of Abraham Lincoln: "You Can't fool the people all the time". Ricardo montoya p.s.: hackers all the world "get to work, c'mon!, I needed that P2P software on my desk YESTERDAY" -----Original Message----- From: p2p-hackers-admin@zgp.org [mailto:p2p-hackers-admin@zgp.org] On Behalf Of p2p-hackers-request@zgp.org Sent: Tuesday, July 02, 2002 2:41 PM To: rikdmont@attbi.com Subject: Welcome to the "p2p-hackers" mailing list (Digest mode) Welcome to the p2p-hackers@zgp.org mailing list! At the first O'Reilly Peer-to-Peer Conference in San Francisco in February of 2001, I had the pleasure of meeting and talking to hackers who were actively working on peer to peer systems. The first thing I learned is that we had different words for many similar or identical concepts. Much of the early conversation was simply trying to understand what the other was saying despite different terminology. The second thing I learned (thanks especially to Wes Felter's presentation), was that different p2p designers had made different architectural decisions on a few key points, and had never looked back after that early architectural decision. The third thing I learned (thanks especially to Branden Wiley and Serguei Osokino, and Wes Felter again) is that interoperability between different p2p file-sharing networks looks like an easier hack than I would have guessed. So here is a mailing list which I hope will continue the noble tradition of fraternization among p2p hackers. I would like to continue the process we've begun of generating common terminology, a common architectural taxonomy, and just "nuts and bolts" engineering chit-chat about things that are important to all of us, for example TCP vs. HTTP (vs. UDP?), MD5 vs. SHA1 (just don't use MD5!), bundled meta-data vs. referenced meta-data, and probably a thousand other important and interesting details. Mailing lists are living things, and I expect that I (or someone else) will have to replace this welcome message as soon as we evolve away from these initial ideas. Don Marti and myself are the List Maintainers, and we are using his scheme of requiring approved registration. The initial invite list is a bunch of hackers who have specific expertise and experience in p2p engineering, and who expressed interest in this list. Feel free to invite others that you know who can contribute to this list. Regards, Zooko To post to this list, send your email to: p2p-hackers@zgp.org General information about the mailing list is at: http://zgp.org/mailman/listinfo/p2p-hackers If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: http://zgp.org/mailman/options/p2p-hackers/rikdmont%40attbi.com You can also make such adjustments via email by sending a message to: p2p-hackers-request@zgp.org with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: w23f If you forget your password, don't worry, you will receive a monthly reminder telling you what all your zgp.org mailing list passwords are, and how to unsubscribe or change your options. There is also a button on your options page that will email your current password to you. You may also have your password mailed to you automatically from the Web page noted above. From burton at openprivacy.org Sat Jul 6 17:46:01 2002 From: burton at openprivacy.org (Kevin A. Burton) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Distributed Timestamping Service In-Reply-To: <3D22AA49.8090900@yahoo.com> References: <3D1FFA22.3020909@yahoo.com> <87n0tjyvkf.fsf@openprivacy.org> <3D20D5A5.7030003@yahoo.com> <87ofdxy9w2.fsf@openprivacy.org> <3D22AA49.8090900@yahoo.com> Message-ID: <87pty0jrmv.fsf@openprivacy.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brad Neuberg writes: > Isn't that called JXTA? :) I now Tristero is working on the same thing, > but JXTA is here today. It's quite nice. The C implementation needs to > go a little further though. No... it isn't JXTA. (disclaimer... I am a JXTA developer) JXTA still has work that needs to be done. I think we are about 5 years a way from a decent P2P framework (IMO) - -- Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burton@peerfear.org ) Location - San Francisco, CA, Cell - 415.595.9965 Jabber - burtonator@jabber.org, Web - http://www.peerfear.org/ GPG fingerprint: 4D20 40A0 C734 307E C7B4 DCAA 0303 3AC5 BD9D 7C4D IRC - openprojects.net #infoanarchy | #p2p-hackers | #reptile Single acts of tyranny may be ascribed to the accidental opinion of the day; but a series of oppressions, begun at a distinguished period, and pursued unalterably thro' every change of ministers, to plainly prove a deliberate, systematical plan of reducing us to slavery. -- Thomas Jefferson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE9J45YAwM6xb2dfE0RApusAJ9etz+H8mRJF6oOf3MlH3ldej8BggCePZWh U4sK4c8rYxz17LH+V2DaSvg= =u76+ -----END PGP SIGNATURE----- From artimage at aftershock.blackhat.net Mon Jul 8 08:51:02 2002 From: artimage at aftershock.blackhat.net (Artimage) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Distributed Timestamping Service Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I stumbled across this paper yesterday, I thought it may be useful to those of you discussing this topic. Maybe this is well known, but since I hadn't seen it mentioned I thought I would throw it out there. http://citeseer.nj.nec.com/haber91how.html Abstract: The prospect of a world in which all text, audio, picture, and video documents are in digital form on easily modifiable media raises the issue of how to certify when a document was created or last changed. The problem is to time-stamp the data, not the medium. We propose computationally practical procedures for digital time-stamping of such documents so that it is infeasible for a user either to back-date or to forward-date his document, even with the collusion of a time-stamping service.... This paper is also sighted by some others which may be of further interest. I hope this is useful to someone. Artimage.- -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use iQA/AwUBPSMdV04KmWNliG6EEQLPAACfc8+hb/34zwCXP5F0wC1CJqvp72wAoMTs dC4ycOXCd1hbBYtwE/qZZJn+ =dLQp -----END PGP SIGNATURE----- From me at aaronsw.com Mon Jul 8 08:59:02 2002 From: me at aaronsw.com (Aaron Swartz) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Distributed Timestamping Service In-Reply-To: Message-ID: <8E8A7CBB-928B-11D6-B0E1-0003936780B2@aaronsw.com> Hi there, We met at Emerging Technologies several months ago. Where is your key available? It doesn't seem to be on the public keyservers. Thanks, -- Aaron Swartz [http://www.aaronsw.com] 4FAC4838B7D8D13FA6D92EDB4145521E79F0DF4B From me at aaronsw.com Mon Jul 8 09:03:01 2002 From: me at aaronsw.com (Aaron Swartz) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Distributed Timestamping Service In-Reply-To: <8E8A7CBB-928B-11D6-B0E1-0003936780B2@aaronsw.com> Message-ID: <191A201E-928C-11D6-B0E1-0003936780B2@aaronsw.com> On Monday, July 8, 2002, at 10:58 AM, Aaron Swartz wrote: > We met at Emerging Technologies several months ago. Where is your key > available? It doesn't seem to be on the public keyservers. Argh, stupid reply-to headers! That email wasn't meant to be public. Can we please fix this for the reasons listed in http://www.unicom.com/pw/reply-to-harmful.html Thanks, -- Aaron Swartz [http://www.aaronsw.com] 4FAC4838B7D8D13FA6D92EDB4145521E79F0DF4B From jeff at platypus.ro Mon Jul 8 09:49:02 2002 From: jeff at platypus.ro (Jeff Darcy) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Distributed Timestamping Service References: <191A201E-928C-11D6-B0E1-0003936780B2@aaronsw.com> Message-ID: <004301c2269f$4a3ad3a0$407b9fa8@lss.emc.com> > Argh, stupid reply-to headers! That email wasn't meant to be public. > > Can we please fix this for the reasons listed in > http://www.unicom.com/pw/reply-to-harmful.html I second the motion. From hal at finney.org Mon Jul 8 09:50:02 2002 From: hal at finney.org (Hal Finney) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Distributed Timestamping Service Message-ID: <200207081638.g68GcmR05398@finney.org> Aaron Schwarts writes: > Argh, stupid reply-to headers! That email wasn't meant to be public. > > Can we please fix this for the reasons listed in > http://www.unicom.com/pw/reply-to-harmful.html A rebuttal to this essay, which argues that reply-to munging is beneficial and should be the default, is at http://www.metasystema.org/essays/reply-to-useful.mhtml. Both sides should be considered in a policy issue of this kind, of course. Hal Finney From lgonze at panix.com Mon Jul 8 10:15:02 2002 From: lgonze at panix.com (Lucas Gonze) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Distributed Timestamping Service In-Reply-To: <004301c2269f$4a3ad3a0$407b9fa8@lss.emc.com> Message-ID: > I second the motion. I oppose the motion. From sah at thalassocracy.org Mon Jul 8 10:41:02 2002 From: sah at thalassocracy.org (Steven Hazel) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Distributed Timestamping Service References: Message-ID: <3D29D0AB.450F36DC@thalassocracy.org> Lucas Gonze wrote: > > I oppose the motion. I'm also opposed. -- Steven Hazel sah@thalassocracy.org From oskar at freenetproject.org Mon Jul 8 14:21:02 2002 From: oskar at freenetproject.org (Oskar Sandberg) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Distributed Timestamping Service In-Reply-To: <200207081638.g68GcmR05398@finney.org> References: <200207081638.g68GcmR05398@finney.org> Message-ID: <20020708211926.GN11265@sporty.spiceworld> Can't this be set per user in mailman? On Mon, Jul 08, 2002 at 09:38:48AM -0700, Hal Finney wrote: > Aaron Schwarts writes: > > Argh, stupid reply-to headers! That email wasn't meant to be public. > > > > Can we please fix this for the reasons listed in > > http://www.unicom.com/pw/reply-to-harmful.html > > A rebuttal to this essay, which argues that reply-to munging is beneficial > and should be the default, is at > http://www.metasystema.org/essays/reply-to-useful.mhtml. Both sides > should be considered in a policy issue of this kind, of course. > > Hal Finney > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers -- Oskar Sandberg oskar@freenetproject.org From pete at petertodd.ca Mon Jul 8 18:13:02 2002 From: pete at petertodd.ca (Peter Todd) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Distributed Timestamping Service In-Reply-To: <3D29D0AB.450F36DC@thalassocracy.org> References: <3D29D0AB.450F36DC@thalassocracy.org> Message-ID: <20020709011245.GA12729@petertodd.ca> On Mon, Jul 08, 2002 at 12:49:31PM -0500, Steven Hazel wrote: > Lucas Gonze wrote: > > > > I oppose the motion. > > I'm also opposed. Me too. -- Need some Linux help or custom C(++) programming? Drop me a line and I'll see what I can do. Resume at http://www.petertodd.ca/resume.php pete@petertodd.ca http://www.petertodd.ca -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://zgp.org/pipermail/p2p-hackers/attachments/20020708/38f30d1a/attachment.pgp From mvicario at hdemia.it Wed Jul 10 02:11:02 2002 From: mvicario at hdemia.it (Marco Vicario) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] To Gene Kan References: <200207081638.g68GcmR05398@finney.org> <20020708211926.GN11265@sporty.spiceworld> Message-ID: <002101c227f1$956dae30$6ec01d97@marcovic> He was dead... He left his genius and software to us...hi Gene see you. marcovic From bram at gawth.com Fri Jul 12 20:06:01 2002 From: bram at gawth.com (Bram Cohen) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Reminder - meeting this sunday Message-ID: Remember everyone, we're having a meeting this sunday, the 12th, starting around 3pm at the metreon in san francisco, in the food court area. I didn't have a chance to scout out other possible places to meet in the metreon or elsewhere. Maybe next time. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From bram at gawth.com Fri Jul 12 20:52:01 2002 From: bram at gawth.com (Bram Cohen) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Reminder - meeting this sunday In-Reply-To: Message-ID: Bram Cohen wrote: > Remember everyone, we're having a meeting this sunday, the 12th I meant, of course, the 14th. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From bram at gawth.com Sun Jul 14 10:13:02 2002 From: bram at gawth.com (Bram Cohen) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] p2p-hackers meeting TODAY Message-ID: welp, meeting today, 3pm, metreon, I'll be there... -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From zooko at zooko.com Sun Jul 14 12:11:02 2002 From: zooko at zooko.com (Zooko) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] reply-to Message-ID: It seems preferable to me that when you reply to a mailing list message, your reply goes back to the mailing list by default, and if you want it *not* to do so you have to make an explicit choice. That seems preferable to the reverse. However, if there is a consensus for the other setting then I'll change it. Hm.. Haven't we had this dicussion before? Oh yes, google tells me that I changed it to "reply-to the list" more than a year ago when several people requested that I do so... Regards, Zooko From seanl at chaosring.org Sun Jul 14 12:22:02 2002 From: seanl at chaosring.org (Sean R. Lynch KG6CVV) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] reply-to In-Reply-To: References: Message-ID: <1026674469.612.5.camel@makoto.chaosring.org> I am strongly opposed to having Reply-To go to the list. It is FAR less embarrassing (and annoying) to accidentally send a public message to the poster than it is to accidentally send a private message to the list. I speak from LOTS of experience having to watch people's private conversations going on on mailing lists. Besides, any decent MUA software has a "group reply" or "list reply" function. On Sun, 2002-07-14 at 13:06, Zooko wrote: > > It seems preferable to me that when you reply to a mailing list message, your > reply goes back to the mailing list by default, and if you want it *not* to do > so you have to make an explicit choice. That seems preferable to the reverse. > > However, if there is a consensus for the other setting then I'll change it. > > Hm.. Haven't we had this dicussion before? Oh yes, google tells me that > I changed it to "reply-to the list" more than a year ago when several people > requested that I do so... > > Regards, > > Zooko > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers -- Sean R. Lynch KG6CVV http://www.chaosring.org/~seanl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://zgp.org/pipermail/p2p-hackers/attachments/20020714/06a9338b/attachment.pgp From blair at orcaware.com Sun Jul 14 12:25:02 2002 From: blair at orcaware.com (Blair Zajac) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] reply-to References: Message-ID: <3D31CFCD.7E443F70@orcaware.com> Zooko wrote: > > It seems preferable to me that when you reply to a mailing list message, your > reply goes back to the mailing list by default, and if you want it *not* to do > so you have to make an explicit choice. That seems preferable to the reverse. > > However, if there is a consensus for the other setting then I'll change it. > > Hm.. Haven't we had this dicussion before? Oh yes, google tells me that > I changed it to "reply-to the list" more than a year ago when several people > requested that I do so... > > Regards, > > Zooko I vote to keep the current reply-to the mailing list setting. Best, Blair -- Blair Zajac Web and OS performance plots - http://www.orcaware.com/orca/ From agl at imperialviolet.org Mon Jul 15 06:51:02 2002 From: agl at imperialviolet.org (Adam Langley) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] reply-to In-Reply-To: <1026674469.612.5.camel@makoto.chaosring.org> References: <1026674469.612.5.camel@makoto.chaosring.org> Message-ID: <20020714194829.GA18151@linuxpower.org> On Sun, Jul 14, 2002 at 12:21:07PM -0700, Sean R. Lynch KG6CVV wrote: > Besides, any decent MUA software has a "group reply" or "list reply" > function. Well, I support setting the Reply-To. Despite reading many posts on the evils of Reply-To I've still yet to see any good argument against. But for those who want it set, and it isn't: :0 * List-Id: Peer-to-peer development.* | formail -i "Reply-To: p2p-hackers@zgp.org" >> /home/USER/mail/p2phackers And for when it is set, and you don't want it to be: :0 * List-Id: Peer-to-peer development.* | formail -R "Reply-To" "X-Reply-To" >> /home/USER/mail/p2phackers (P.S. test those first) -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org (+44) (0)7986 296753 PGP: 9113 256A CC0F 71A6 4C84 5087 CDA5 52DF 2CB6 3D60 From ry4an at ry4an.org Mon Jul 15 07:50:01 2002 From: ry4an at ry4an.org (Ry4an Brase) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Re: reply-to Message-ID: <20020715091002.A8504@ry4an.org> > It seems preferable to me that when you reply to a mailing list message, your > reply goes back to the mailing list by default, and if you want it *not* to do > so you have to make an explicit choice. That seems preferable to the reverse. > > However, if there is a consensus for the other setting then I'll change it. > > Hm.. Haven't we had this dicussion before? Oh yes, google tells me that > I changed it to "reply-to the list" more than a year ago when several people > requested that I do so... > > Regards, > > Zooko Maybe this: http://www.unicom.com/pw/reply-to-harmful.html and this: http://www.metasystema.org/essays/reply-to-useful.mhtml can help short-cut this discussion. -- Ry4an Brase - http://ry4an.org /~\ 'If you're not a rebel when you're 20 you've got no heart; if \ / you're not establishment when you're 30 you've got no brain. X Join the ASCII ribbon campaign against HTML email / \ From seanl at chaosring.org Mon Jul 15 09:36:02 2002 From: seanl at chaosring.org (Sean R. Lynch KG6CVV) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Re: reply-to In-Reply-To: <20020715091002.A8504@ry4an.org> References: <20020715091002.A8504@ry4an.org> Message-ID: <1026750932.1317.149.camel@nietzsche> On Mon, 2002-07-15 at 07:10, Ry4an Brase wrote: > Maybe this: > > http://www.unicom.com/pw/reply-to-harmful.html > > and this: > > http://www.metasystema.org/essays/reply-to-useful.mhtml > > can help short-cut this discussion. I especially like the paragraph titled, "Coddling the Brain-Dead, Penalizing the Conscientious" in the first document. This pretty much defines the Internet today, especially when a list of supposed "hackers" has to coddle the brain dead. Regarding the second, the only reason that mailers even *have* the "reply to from address" feature is because of this stupid munging in the first place, and the second document uses its existence as an excuse to do the munging anyway! Of course, it completely ignores the fact that such munging destroys the original Reply-To, which may have been used for a legitimate purpose. Consider this: "Group reply" is *always* useful. "Reply to from address" is *only* useful in the presense of reply-to munging. So the author of the second document is telling mailer authors to add a feature that is of minimal utility at the same time as his munging is disabling a feature that is usually of much wider utility. It's interesting that the author of the second document doesn't consider breaking mailers that are missing the fairly rare "reply to from address" bad (Ximian Evolution doesn't have it), but does consider it bad to make things more difficult for the even rarer mailers that are missing the "group reply" features (does someone have a list of these?). This indicates to me that the author started with his desired outcome and then just made up arguments to support it, rather than thinking about the issues for making his plea. If you really want the kind of people who can't handle getting their replies to the list or who are too lazy to hit a different button when replying, go ahead. At least one argument stands in favor of reply-to munging: the people who will be annoyed by reply-to munging are smart enough to use procmail, whereas the people who *need* it generally are not. (Lazy people who just *want* it are not the people I'm talking about here, so don't get insulted unless you truly *are* an idiot, in which case you probably won't understand this paragraph.) Here is one more document for reference: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://zgp.org/pipermail/p2p-hackers/attachments/20020715/55a9c39f/attachment.pgp From hal at finney.org Mon Jul 15 09:48:01 2002 From: hal at finney.org (Hal Finney) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Re: reply-to Message-ID: <200207151634.g6FGYt517944@finney.org> > Maybe this: > > http://www.unicom.com/pw/reply-to-harmful.html > > and this: > > http://www.metasystema.org/essays/reply-to-useful.mhtml > > can help short-cut this discussion. I doubt it, since both of those links were posted to this list on Monday, July 8. Hal From svanegmond at tinyplanet.ca Mon Jul 15 11:42:02 2002 From: svanegmond at tinyplanet.ca (Stephen van Egmond) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Re: reply-to References: <200207151634.g6FGYt517944@finney.org> Message-ID: <01bd01c22c2f$1b4d21c0$33094d8e@uunet.ca> > I doubt it, since both of those links were posted to this list on > Monday, July 8. Hitler. Can we stop this conversation now? From zooko at zooko.com Mon Jul 15 12:27:02 2002 From: zooko at zooko.com (Zooko) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] the resolution of the reply-to issue (was: reply-to) In-Reply-To: Message from "Stephen van Egmond" of "Mon, 15 Jul 2002 14:40:20 EDT." <01bd01c22c2f$1b4d21c0$33094d8e@uunet.ca> References: <200207151634.g6FGYt517944@finney.org> <01bd01c22c2f$1b4d21c0$33094d8e@uunet.ca> Message-ID: This isn't a democracy, but I did say that I would change my mind if faced with a consensus. By my count there are four votes to switch to no-munging (counting a private vote sent directly to me), five votes to continue munging, and five votes for putting an end to this discussion. I've decided to keep the reply-to munging in place as it currently is. Please be extra careful when replying -- your replies go to the public list by default. I have added a note to the welcome message which warns newcomers about this setting. Regards, Zooko From bug1 at optushome.com.au Mon Jul 15 18:04:02 2002 From: bug1 at optushome.com.au (Glenn McGrath) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a file in p2p Message-ID: <20020716110331.4554ef3f.bug1@optushome.com.au> Everything as a file is a mantra of the unix world. Everything as a file doesnt mean everything is a file, its more like everything has a file handle. For this to be true, the file handle must be independent of the content that it processes. I think the Content Addressable Web (namespace based on content hash) approach used by many systems hinders efforts to see everything as a file becasue the file handle is derived from the hash of the content. It makes every file read-only, if a file is modified it becomes a completely new entry (sometimes this is wanted). If we abstracting the transport layer from our p2p systems in a generic way then individual p2p systems can implement there different search/retrieval system ontop of that, you could have a CAW system ontop of the generic transport layer, maping the hash based filename to an independent file handle. The trasport layer would need properties such as content independence, security, (limited?) anonymity, accountability, intelligent routing... other ? Does anyone know of any projects attempting to create such a network layer, anyone interesting in trying to design such a beast if there is nothing else around ? Thanks Glenn -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://zgp.org/pipermail/p2p-hackers/attachments/20020715/0bc0036f/attachment.pgp From sam at neurogrid.com Mon Jul 15 18:15:01 2002 From: sam at neurogrid.com (Sam Joseph) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a file in p2p References: <20020716110331.4554ef3f.bug1@optushome.com.au> Message-ID: <3D337505.8050907@neurogrid.com> Hi Glenn Glenn McGrath wrote: >Everything as a file is a mantra of the unix world. Everything as a file >doesnt mean everything is a file, its more like everything has a file >handle. For this to be true, the file handle must be independent of the >content that it processes. > >I think the Content Addressable Web (namespace based on content hash) >approach used by many systems hinders efforts to see everything as a file >becasue the file handle is derived from the hash of the content. It makes >every file read-only, if a file is modified it becomes a completely new >entry (sometimes this is wanted). > >If we abstracting the transport layer from our p2p systems in a generic >way then individual p2p systems can implement there different >search/retrieval system ontop of that, you could have a CAW system ontop >of the generic transport layer, maping the hash based filename to an >independent file handle. > >The trasport layer would need properties such as content independence, >security, (limited?) anonymity, accountability, intelligent routing... >other ? > I think the NeuroGrid project is trying to do this: http://www.neurogrid.net but also Semplesh and Alpine have similar goals: http://cubicmetercrystal.com/alpine/overview.html http://semplesh.com/ Actually if we're thining about overlaying CAW over reliable file retrieval then you might be interested in a review of distributed meta-data in general, which includes a categorisation of the search process into three parts 1. Identification of desired resource through fuzzy search 2. Identification of resource location or locations 3. Download or interaction with resource http://www.neurogrid.net/Decentralized_Meta-Data_Strategies-neat.html >Does anyone know of any projects attempting to create such a network >layer, anyone interesting in trying to design such a beast if there is >nothing else around ? > I'm sure any of the above projects would be very interested to have you on board, and new projects are always welcome, although they are generally better received if you review what's currently being done and try to avoid re-inventing the wheel :-) CHEERS> SAM From bram at gawth.com Mon Jul 15 18:22:02 2002 From: bram at gawth.com (Bram Cohen) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a file in p2p In-Reply-To: <20020716110331.4554ef3f.bug1@optushome.com.au> Message-ID: Glenn McGrath wrote: > Everything as a file is a mantra of the unix world. Everything as a file > doesnt mean everything is a file, its more like everything has a file > handle. For this to be true, the file handle must be independent of the > content that it processes. This is a bit of a subtle objection, but BitTorrent doesn't handle files as streams, it kinda downloads pieces in random order. The problem with reading files from the beginning is that it leads to downloaders which have less of the file having a strict subset of what downloaders which have more have, so those connections can only transfer in one direction. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From justin at chapweske.com Mon Jul 15 18:40:02 2002 From: justin at chapweske.com (Justin Chapweske) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a file in p2p References: <20020716110331.4554ef3f.bug1@optushome.com.au> Message-ID: <3D337958.9090608@chapweske.com> Glenn McGrath wrote: > Everything as a file is a mantra of the unix world. Everything as a file > doesnt mean everything is a file, its more like everything has a file > handle. For this to be true, the file handle must be independent of the > content that it processes. > > I think the Content Addressable Web (namespace based on content hash) > approach used by many systems hinders efforts to see everything as a file > becasue the file handle is derived from the hash of the content. It makes > every file read-only, if a file is modified it becomes a completely new > entry (sometimes this is wanted). The "Content Addressable Web" is a subset, or optimization of generic web architecture. It should really only be used in the context of generic web architecture, where everything is a URI-addressable web object. Indeed, it would be hard to write an application that supports only CAW, without supporting the the whole of URIs and web architecture, so in practice I don't that anything is hindered in its expressiveness. > > If we abstracting the transport layer from our p2p systems in a generic > way then individual p2p systems can implement there different > search/retrieval system ontop of that, you could have a CAW system ontop > of the generic transport layer, maping the hash based filename to an > independent file handle. > > The trasport layer would need properties such as content independence, > security, (limited?) anonymity, accountability, intelligent routing... > other ? > That generic transport layer already exists, its called HTTP. Add SSL/TLS for security, a mix network of HTTP proxies for anonymity, and a content delivery network for intelligent routing. Personally, I think the concept of a P2P transport layer is as vacuous as talking about a "P2P operating system". -- Justin Chapweske, Onion Networks http://onionnetworks.com/ From bug1 at optushome.com.au Mon Jul 15 18:57:02 2002 From: bug1 at optushome.com.au (Glenn McGrath) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a file in p2p In-Reply-To: <3D337505.8050907@neurogrid.com> References: <20020716110331.4554ef3f.bug1@optushome.com.au> <3D337505.8050907@neurogrid.com> Message-ID: <20020716115619.47966882.bug1@optushome.com.au> On Tue, 16 Jul 2002 10:21:09 +0900 "Sam Joseph" wrote: > I think the NeuroGrid project is trying to do this: > > http://www.neurogrid.net > > but also Semplesh and Alpine have similar goals: > > http://cubicmetercrystal.com/alpine/overview.html > http://semplesh.com/ > I had looked at alpine, searching is part of their network protocol, i think there should be a clean seperation between (finding hosts/establishing the network) and finding content on the overall network. neurogrid looks to be in a similar situation to alpine. Im not sure about Semplesh. > Actually if we're thining about overlaying CAW over reliable file > retrieval then you might be interested in a review of distributed > meta-data in general, which includes a categorisation of the search > process into three parts > > 1. Identification of desired resource through fuzzy search > 2. Identification of resource location or locations > 3. Download or interaction with resource > > http://www.neurogrid.net/Decentralized_Meta-Data_Strategies-neat.html > Interesting... ill have to digest this :) > I'm sure any of the above projects would be very interested to have you > on board, and new projects are always welcome, although they are > generally better received if you review what's currently being done and > try to avoid re-inventing the wheel :-) > I would rather work with an existing project, but i expect the network layer to be a hard thing to change if its part of a bigger system... any changes would certainly have to prove themselves first, which would almost make it a new project anyway.... apart from that i think it would be a hard thing to design, i'd rather work with others to achieve that. Glenn From sam at neurogrid.com Mon Jul 15 19:09:02 2002 From: sam at neurogrid.com (Sam Joseph) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a file .... Message-ID: <3D33819F.3070606@neurogrid.com> Glenn McGrath wrote: > On Tue, 16 Jul 2002 10:21:09 +0900 > "Sam Joseph" wrote: > > > >> I think the NeuroGrid project is trying to do this: >> >> http://www.neurogrid.net >> >> but also Semplesh and Alpine have similar goals: >> >> http://cubicmetercrystal.com/alpine/overview.html >> http://semplesh.com/ >> >> > > I had looked at alpine, searching is part of their network protocol, i > think there should be a clean seperation between (finding > hosts/establishing the network) and finding content on the overall > network. > > neurogrid looks to be in a similar situation to alpine. > > Im not sure about Semplesh. > Well semplesh runs on top of Chord, but NeuroGrid has a clean break between searching and retrieving. NeuroGrid can be run on top of Chord, Freenet, whatever you like, because it works with meta-data - key relations, so you could map your meta-data to chord addresses, http urls, of Freenet keys. And fortunately in the latest version of the software I've completely separated out persistence and transport, so you can add any database you want, and indeed any transport layer (for meta-data queries) you want. And on top of that the file retrieval can be handled by a completely separate system, e.g. chord. (The original system was commited to http) Well I say all these things, and it would probably me a little work to smoothly get all the above functionally, but NeuroGrid is commited to a clean (as possible) separation of the different components. CHEERS> SAM From bug1 at optushome.com.au Mon Jul 15 19:18:02 2002 From: bug1 at optushome.com.au (Glenn McGrath) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a file in p2p In-Reply-To: <3D337958.9090608@chapweske.com> References: <20020716110331.4554ef3f.bug1@optushome.com.au> <3D337958.9090608@chapweske.com> Message-ID: <20020716121737.7eba4e47.bug1@optushome.com.au> On Mon, 15 Jul 2002 20:39:36 -0500 "Justin Chapweske" wrote: > The "Content Addressable Web" is a subset, or optimization of generic > web architecture. It should really only be used in the context of > generic web architecture, where everything is a URI-addressable web > object. Indeed, it would be hard to write an application that supports > only CAW, without supporting the the whole of URIs and web architecture, > > so in practice I don't that anything is hindered in its expressiveness. > CAW is a subset on the internet that is restricted to static content, i do very much like the idea of CAW in that subset, but it is a subset. e.g. if your URI pointed to live streaming media then CAW wouldnt be applied. > > That generic transport layer already exists, its called HTTP. Add > SSL/TLS for security, a mix network of HTTP proxies for anonymity, and a > > content delivery network for intelligent routing. > Yea, the pieces are there, they just have to be put together in the right way. > Personally, I think the concept of a P2P transport layer is as vacuous > as talking about a "P2P operating system". > IMHO p2p is only about the transport layer. Glenn From bradneuberg at yahoo.com Mon Jul 15 20:13:02 2002 From: bradneuberg at yahoo.com (Brad Neuberg) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a page References: <20020716110331.4554ef3f.bug1@optushome.com.au> Message-ID: <3D338F28.4070301@yahoo.com> Glenn McGrath wrote: >Everything as a file is a mantra of the unix world. Everything as a file >doesnt mean everything is a file, its more like everything has a file >handle. For this to be true, the file handle must be independent of the >content that it processes. > >I think the Content Addressable Web (namespace based on content hash) >approach used by many systems hinders efforts to see everything as a file >becasue the file handle is derived from the hash of the content. It makes >every file read-only, if a file is modified it becomes a completely new >entry (sometimes this is wanted). > >If we abstracting the transport layer from our p2p systems in a generic >way then individual p2p systems can implement there different >search/retrieval system ontop of that, you could have a CAW system ontop >of the generic transport layer, maping the hash based filename to an >independent file handle. > >The trasport layer would need properties such as content independence, >security, (limited?) anonymity, accountability, intelligent routing... >other ? > >Does anyone know of any projects attempting to create such a network >layer, anyone interesting in trying to design such a beast if there is >nothing else around ? > > >Thanks > >Glenn > The alternative to the Unix file philosophy is the web philosophy: everything as a URI. You could call this the REST philosophy. When you are interacting with a URI, you can assume that most of the HTTP semantics work with it: GET, POST, PUT (maybe), etc. This URI could in fact be a file, an operating system process, a web page, an object, a distributed object, etc. Brad Neuberg From bradneuberg at yahoo.com Mon Jul 15 20:16:02 2002 From: bradneuberg at yahoo.com (Brad Neuberg) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] P2P HTTP References: <20020716110331.4554ef3f.bug1@optushome.com.au> <3D337958.9090608@chapweske.com> Message-ID: <3D338FDF.7040300@yahoo.com> Justin Chapweske wrote: > Glenn McGrath wrote: > >> Everything as a file is a mantra of the unix world. Everything as a file >> doesnt mean everything is a file, its more like everything has a file >> handle. For this to be true, the file handle must be independent of the >> content that it processes. >> >> I think the Content Addressable Web (namespace based on content hash) >> approach used by many systems hinders efforts to see everything as a >> file >> becasue the file handle is derived from the hash of the content. It >> makes >> every file read-only, if a file is modified it becomes a completely new >> entry (sometimes this is wanted). > > > The "Content Addressable Web" is a subset, or optimization of generic > web architecture. It should really only be used in the context of > generic web architecture, where everything is a URI-addressable web > object. Indeed, it would be hard to write an application that > supports only CAW, without supporting the the whole of URIs and web > architecture, so in practice I don't that anything is hindered in its > expressiveness. > >> >> If we abstracting the transport layer from our p2p systems in a generic >> way then individual p2p systems can implement there different >> search/retrieval system ontop of that, you could have a CAW system ontop >> of the generic transport layer, maping the hash based filename to an >> independent file handle. >> >> The trasport layer would need properties such as content independence, >> security, (limited?) anonymity, accountability, intelligent routing... >> other ? >> > > That generic transport layer already exists, its called HTTP. Add > SSL/TLS for security, a mix network of HTTP proxies for anonymity, and > a content delivery network for intelligent routing. > > Personally, I think the concept of a P2P transport layer is as vacuous > as talking about a "P2P operating system". > Justin, how would you layer a peer to peer network over HTTP? I know Magi does something like this, but I'm not completely satisfied with it's approach. I've been playing around with layering P2P over HTTP semantics, but it seems like it doesn't really result in any payoff other than complexity and political correctness. I'm interested in hearing how you'd do it. Brad Neuberg From jbone at deepfile.com Mon Jul 15 20:28:01 2002 From: jbone at deepfile.com (Jeff Bone) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a page In-Reply-To: <3D338F28.4070301@yahoo.com> Message-ID: On 7/15/02 10:12 PM, "Brad Neuberg" wrote: > The alternative to the Unix file philosophy is the web philosophy: > everything as a URI. You could call this the REST philosophy. Important to note: these are not exclusive. The similarity between files in distributed filesystems --- or more accurately, filelike resources that present a file-oriented generic interface --- and resources in REST are close almost to the point of trivial distinction. That having been said, URI should be used to address any and all objects of interest in distributed systems. Even "distributed" (or better, networked) filesystem such as NFS and CIFS/SMB have adopted a URI-based addressing scheme that dispenses with the traditional "mount" protocols and, in effect, creates a more conventional universal namespace for the objects referenced by those protocols. Fyi, Jb From bug1 at optushome.com.au Mon Jul 15 22:06:02 2002 From: bug1 at optushome.com.au (Glenn McGrath) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a page In-Reply-To: <3D338F28.4070301@yahoo.com> References: <20020716110331.4554ef3f.bug1@optushome.com.au> <3D338F28.4070301@yahoo.com> Message-ID: <20020716150516.55078255.bug1@optushome.com.au> On Mon, 15 Jul 2002 20:12:40 -0700 "Brad Neuberg" wrote: > The alternative to the Unix file philosophy is the web philosophy: > everything as a URI. You could call this the REST philosophy. When you > > are interacting with a URI, you can assume that most of the HTTP > semantics work with it: GET, POST, PUT (maybe), etc. This URI could in > fact be a file, an operating system process, a web page, an object, a > distributed object, etc. > Yes, URI fits better, it ties a file handle to specific machine(s). If URI's are what most p2p systems have in common, than why not have a URI (or transport) layer that tries to connecting URI's in a secure, anonymous, accountable way using some intellegent routing, leaving the processing of the content sent/received upto the system that uses such a library. Glenn From justin at chapweske.com Mon Jul 15 22:23:01 2002 From: justin at chapweske.com (Justin Chapweske) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] P2P HTTP References: <20020716110331.4554ef3f.bug1@optushome.com.au> <3D337958.9090608@chapweske.com> <3D338FDF.7040300@yahoo.com> Message-ID: <3D33AD85.9050104@chapweske.com> What do you want the P2P network to do? o If you want to allow back-connects through NAT, then use a multiplexing protocol underneath HTTP such as WebMUX or BEEP. o If you want to allow two NAT'd hosts to talk to each other, use a publicly accessible peer as an HTTP rendevous point, assigning part of its address space to the peer. This is what OpenCola's clerver allowed, it was quite nice. o If you want to do search over HTTP, use the Tristero APIs. o If you want a DHT, then implement a REST-based interface for it. o If you want P2P content delivery, then use CAW. o If you want file sharing, then combine search with WebDAV. The real value in using HTTP is that there is an enourmous amount of technology out there that supports HTTP, and it allows you to make more powerful, interoperable applications in a shorter amount of time. > Justin, how would you layer a peer to peer network over HTTP? I know > Magi does something like this, but I'm not completely satisfied with > it's approach. I've been playing around with layering P2P over HTTP > semantics, but it seems like it doesn't really result in any payoff > other than complexity and political correctness. I'm interested in > hearing how you'd do it. > > Brad Neuberg -- Justin Chapweske, Onion Networks http://onionnetworks.com/ From zooko at zooko.com Mon Jul 15 22:29:02 2002 From: zooko at zooko.com (Zooko) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] p2p resources In-Reply-To: Message from Glenn McGrath of "Tue, 16 Jul 2002 15:05:16 +1000." <20020716150516.55078255.bug1@optushome.com.au> References: <20020716110331.4554ef3f.bug1@optushome.com.au> <3D338F28.4070301@yahoo.com> <20020716150516.55078255.bug1@optushome.com.au> Message-ID: Folks: There are almost three hundred members of the p2p-hackers mailing list. Many of them have been studying or actively working on decentralized and dynamic systems for many years. In addition to writing software, many of the subscribers have written scientific articles, books, web pages, and so forth. Interestingly, the vast majority of subscribers post infrequently to the list. I think that this is because they have a high degree of respect for the expertise of the other posters, and do not wish to take up the time of their peers unless they have something specific and interesting to relate. For newcomers to the p2p "scene", it would be helpful to have a public list of resources with which to get acquainted with the "common knowledge" that is already shared by many p2p hackers. Here is a first stab at some such resources. The O'Reilly p2p book [1], the proceedings of the MIT Workshop on P2P [2], the archives of p2p-hackers [3], and the archives of bluesky [4], infoanarchy.org [5]. Regards, Zooko [1] http://www.oreilly.com/catalog/peertopeer/ [2] http://www.cs.rice.edu/Conferences/IPTPS02/ [3] http://zgp.org/pipermail/p2p-hackers/ [4] http://www.transarc.ibm.com/~ota/bluesky/ [5] http://infoanarchy.org/ From BufferOverRun at hotmail.com Tue Jul 16 00:24:01 2002 From: BufferOverRun at hotmail.com (Buffer.OverRun) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Mirror URIs References: <20020716110331.4554ef3f.bug1@optushome.com.au><3D338F28.4070301@yahoo.com> <20020716150516.55078255.bug1@optushome.com.au> Message-ID: i haven't RTFM'd on CAW or OCN yet, but i have thought of a URI scheme that is close to what you are suggesting. Original Thread: http://www.shouldexist.org/?op=displaystory;sid=2002/7/12/53049/1427;mode=mo derate (down ATM) may also be on ShouldExist.org in a few days. :) the XML files used for the mirror URIs can contain any type of contain. it is an extensible format. the client-side parsers will just need to know how to handle the different types of data tags in the XML file. p2p URIs such as gnutella://, ed2k://, etc. can be specified in the XML file. /* Mirror URIs - a URL Scheme for Handling Data Mirrors By Buff3r0v3rRun (BufferOverRun{at}users{dot}sourceforge{dot}net), Section Brainstorms Posted on Fri Jul 12th, 2002 at 12:30:49 AM EST Mirror URIs are intended to make it easy to specify mirrors for content such as data files and webpages. The goal is make mirrors of data and webpages easily accessible through an easy, user-friendly method. This will be achieved through the implementation of a new URI scheme (mirror://), XML data files, and client-side parsers. Original Thread: http://refl3xion.sourceforge.net/yabbse/index.php?board=2;action=display;thr eadid=40;start=0;boardseen=1 ---------------------------------------------------------------------------- ---- mirror URI syntax: mirror://|||| ex: mirror://server.com|file.txt.xml|https|282f697143b3f51b9caa090b4e43b59b0a0a4 7e6| mirror://|||| specifies the server that holds the file specified in it is recommended that the file portion be changed to reflect the name of the data that is expected to be retrieved including file extension. for example, if the file to be retrieved is file.txt, should be changed to file.txt.xml the xml file must include: [mirrors] - this section includes links to mirrors of the file [volatile-mirrors] - mirrors that are known to have low uptimes [highspeed-mirrors] - know high-speed mirrors [mirror-speed] - optional data tag that can be attached to each mirror. [filename] - filename of the file to be retrieved. must include file extension. [expiration] - must be specified for each mirror in section. specifies how long the mirrored content is expected to be available. [hashtype] - type of hash specified in [hash] - hash of mirrored content if no alternate scheme is specified for retrieving the client side parser will assume that will be retrieved via HTTP. can be any valid scheme such as FTP or HTTPS. hash is an optional string that can be added to the URI. this string is optional because must contain a file hash for the mirrored media. the hash specified in the URI must be an SHA-1 hash of the data file specified in including in a mirror URI will make the URI exceptionally long. a side effect of including in the URI is that URIs from several different servers can be identified as pointing to the same content. *NOTE: this is a brief abstract of mirror URIs. the intent is to garner ideas about how to improve mirror URIs and possibly catch the interest of a few devs. i have had this idea for several weeks. it is related to a larger project called Refl3xion, that i happen to be lead dev on. i am posting this here b/c i feel that ideas such as these should be Open Standards and not proprietary. < Recipe suggesting website (2 comments) | Open Source / Free Software Discussion Network (OSFSDN) (0 comments) > Mirror URIs - a URL Scheme for Handling Data Mirrors | 1 comments ( topical, 1 editorial, 0 pending) | Post A Comment OCN & CAW none (#1) by Buff3r0v3rRun (BufferOverRun{at}users{dot}sourceforge{dot}net) on Fri Jul 12th, 2002 at 12:39:27 AM EST (User Info) http://OpenP2P.tk i have not yet RTFM'd on OCN & CAW. it has been suggested before. i will as soon as i have time. i am also planning interop w/ BitTorrent. and yes, i am aware that the URIs i specify in this document are not compliant w/ the syntax specified in RFC 2396[1] and it's updates[2] & [3]. [1] http://www.rfc-editor.org/rfc/rfc2396.txt [2] http://www.rfc-editor.org/cgi-bin/rfcsearch.pl?searchwords=rfc1808&opt=All+f ields&num=25&format=ftp&orgkeyword=uri&filefmt=txt [3] http://www.rfc-editor.org/cgi-bin/rfcsearch.pl?searchwords=rfc1738&opt=All+f ields&num=25&format=ftp&orgkeyword=uri&filefmt=txt */ Buffer.OverRun OpenP2P.tk | p2pNG.tk | Refl3xion.tk ----- Original Message ----- From: "Glenn McGrath" To: Cc: Sent: Tuesday, July 16, 2002 1:05 AM Subject: Re: [p2p-hackers] Everything as a page > On Mon, 15 Jul 2002 20:12:40 -0700 > "Brad Neuberg" wrote: > > > The alternative to the Unix file philosophy is the web philosophy: > > everything as a URI. You could call this the REST philosophy. When you > > > > are interacting with a URI, you can assume that most of the HTTP > > semantics work with it: GET, POST, PUT (maybe), etc. This URI could in > > fact be a file, an operating system process, a web page, an object, a > > distributed object, etc. > > > > Yes, URI fits better, it ties a file handle to specific machine(s). > > If URI's are what most p2p systems have in common, than why not have a URI > (or transport) layer that tries to connecting URI's in a secure, > anonymous, accountable way using some intellegent routing, leaving the > processing of the content sent/received upto the system that uses such a > library. > > > > Glenn > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > From BufferOverRun at hotmail.com Tue Jul 16 00:28:02 2002 From: BufferOverRun at hotmail.com (Buffer.OverRun) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] the resolution of the reply-to issue (was: reply-to) References: <200207151634.g6FGYt517944@finney.org> <01bd01c22c2f$1b4d21c0$33094d8e@uunet.ca> Message-ID: my 2 cents: i prefer the reply-to sent to the entire group. if ppl can't figure out how to directly mail someone they shouldn't be using this list. ----- Original Message ----- From: "Zooko" To: Sent: Monday, July 15, 2002 4:26 PM Subject: [p2p-hackers] the resolution of the reply-to issue (was: reply-to) > > This isn't a democracy, but I did say that I would change my mind if faced with > a consensus. By my count there are four votes to switch to no-munging > (counting a private vote sent directly to me), five votes to continue munging, > and five votes for putting an end to this discussion. > > I've decided to keep the reply-to munging in place as it currently is. > > Please be extra careful when replying -- your replies go to the public list by > default. > > I have added a note to the welcome message which warns newcomers about this > setting. > > Regards, > > Zooko > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > From gojomo at usa.net Tue Jul 16 00:54:01 2002 From: gojomo at usa.net (Gordon Mohr) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a file in p2p References: <20020716110331.4554ef3f.bug1@optushome.com.au> Message-ID: <03b701c22c9d$e09899a0$640a000a@golden> I love content-hashes as URI identifiers, but you're right, they don't cover everything, like streams, series/events, or resources that may change in place. One of the best ideas in Freenet is the creation of content-keys (ie URIs) which mean "this name given by this principal (ie public key)". You can think of them like HTTP URLs where the "naming authority" is a key rather than a IP/DNS name. I think they're called Key-Signed-Keys, KSKs, but I could be getting the terminology wrong. They are the perfect complement to locationless content-hash names: they are locationless names for dynamic content with some measure of controlling-authority stability. I think someone should generalize the freenet:KSK approach to be a real URN type, independent of any one P2P system, so that even if Freenet goes nowhere, this concept lives & grows on its own as it deserves to. Or is there already such an URN type? I haven't run across one yet. Perhaps it could look something like: urn:kau:/// "kau" for "Key AUthority". The key-identifier should support parameterizable public-key algorithms. Resolvers would return the most-recent resource they can find which has an accompanying signed binding from asserting name . The name-assertion signed-bindings would be roughly tuples of: name public-key timestamp content-hash signature(name, timestamp, content-hash) - Gojomo ____________________ Gordon Mohr Bitzi CTO . . . describe and discover files of every kind. _ http://bitzi.com _ . . . Bitzi knows bits -- because you teach it! From jeff at platypus.ro Tue Jul 16 04:37:02 2002 From: jeff at platypus.ro (Jeff Darcy) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] the resolution of the reply-to issue (was: reply-to) References: <200207151634.g6FGYt517944@finney.org> <01bd01c22c2f$1b4d21c0$33094d8e@uunet.ca> Message-ID: <029501c22cbc$f59a5040$2002a8c0@jdarcyvaio> > i prefer the reply-to sent to the entire group. if ppl can't figure out how > to directly mail someone > they shouldn't be using this list. Ditto for people in the opposite scenario who can't figure out how to send to all. The "shouldn't be using this list" argument is great if you just want to sound condescending, but it's really not useful otherwise. From me at aaronsw.com Tue Jul 16 08:07:01 2002 From: me at aaronsw.com (Aaron Swartz) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a file in p2p In-Reply-To: <03b701c22c9d$e09899a0$640a000a@golden> Message-ID: <9736C73A-98CD-11D6-B6DA-0003936780B2@aaronsw.com> On Tuesday, July 16, 2002, at 02:53 AM, Gordon Mohr wrote: > I think someone should generalize the freenet:KSK approach to > be a real URN type, independent of any one P2P system, so that > even if Freenet goes nowhere, this concept lives & grows on > its own as it deserves to. > > Or is there already such an URN type? I haven't run across one > yet. This sounds something like the ESL proposal. It seems silly to abstract things like this because, unlike DNS, there is no central registry for KAUs. I doubt IANA would be eager to start one. It would be far simpler to have each KAU register their own scheme. http://lists.w3.org/Archives/Public/www-rdf- interest/2001Sep/att-0067/01-draft-palmer-esl-uri-00.txt There are some obvious mistakes in this draft (encoding whitespace) but I don't think anyone was really willing to push the scheme thru any further. -- Aaron Swartz [http://www.aaronsw.com] 4FAC4838B7D8D13FA6D92EDB4145521E79F0DF4B I will be in San Diego for the O'Reilly Open Source Convention the 24-26 July. From arma at mit.edu Tue Jul 16 09:15:01 2002 From: arma at mit.edu (Roger Dingledine) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Call for Papers, Workshop on Privacy Enhancing Technologies 2003 Message-ID: <20020716121438.J7433@moria.seul.org> Please re-distribute as appropriate... CALL FOR PAPERS WORKSHOP ON PRIVACY ENHANCING TECHNOLOGIES 2003 Mar 26-28 2003 Dresden, Germany Hotel Elbflorenz Dresden http://www.petworkshop.org/ Privacy and anonymity are increasingly important in the online world. Corporations and governments are starting to realize their power to track users and their behavior, and restrict the ability to publish or retrieve documents. Approaches to protecting individuals, groups, and even companies and governments from such profiling and censorship have included decentralization, encryption, and distributed trust. Building on the success of the first anonymity and unobservability workshop (held in Berkeley in July 2000) and the second workshop (held in San Francisco in April 2002), this third workshop addresses the design and realization of such privacy and anti-censorship services for the Internet and other communication networks. These workshops bring together anonymity and privacy experts from around the world to discuss recent advances and new perspectives. The workshop seeks submissions from academia and industry presenting novel research on all theoretical and practical aspects of privacy technologies, as well as experimental studies of fielded systems. We encourage submissions from other communities such as law and business that present their perspectives on technological issues. As in past years, we will publish proceedings after the workshop. Suggested topics include but are not restricted to: * Efficient (technically or economically) realization of privacy services * Techniques for censorship resistance * Anonymous communication systems (theory or practice) * Anonymous publishing systems (theory or practice) * Attacks on anonymity systems (eg traffic analysis) * New concepts in anonymity systems * Protocols that preserve anonymity/privacy * Models for anonymity and unobservability * Models for threats to privacy * Novel relations of payment mechanisms and anonymity * Privacy-preserving/protecting access control * Privacy-enhanced data authentication/certification * Profiling, data mining, and data protection technologies * Reliability, robustness, and attack resistance in privacy systems * Providing/funding privacy infrastructures (eg volunteer vs business) * Pseudonyms, identity, linkability, and trust * Privacy, anonymity, and peer-to-peer * Usability issues and user interfaces for PETs * Policy, law, and human rights -- anonymous systems in practice * Incentive-compatible solutions to privacy protection * Economics of privacy systems * Fielded systems and techniques for enhancing privacy in existing systems IMPORTANT DATES Submission deadline December 2, 2002 Acceptance notification February 7, 2003 Camera-ready copy for preproceedings March 7, 2003 Camera-ready copy for proceedings April 28, 2003 CHAIRS Roger Dingledine, The Free Haven Project, USA Andreas Pfitzmann, Dresden University of Technology, Germany PROGRAM COMMITTEE Alessandro Acquisti, SIMS, UC Berkeley, USA Stefan Brands, Credentica, Canada Jean Camp, Kennedy School, Harvard University, USA David Chaum, USA Richard Clayton, University of Cambridge, England Lorrie Cranor, AT&T Labs - Research, USA Roger Dingledine, The Free Haven Project, USA (program chair) Hannes Federrath, Freie Universitaet Berlin, Germany Ian Goldberg, Zero Knowledge Systems, Canada Marit Hansen, Independent Centre for Privacy Protection Schleswig-Holstein, Germany Markus Jakobsson, RSA Laboratories, USA Brian Levine, University of Massachusetts at Amherst, USA David Martin, University of Massachusetts at Lowell, USA Andreas Pfitzmann, Dresden University of Technology, Germany Matthias Schunter, IBM Zurich Research Lab, Switzerland Andrei Serjantov, University of Cambridge, England Adam Shostack, Zero Knowledge Systems, Canada Paul Syverson, Naval Research Lab, USA PAPER SUBMISSIONS Submitted papers must not substantially overlap with papers that have been published or that are simultaneously submitted to a journal or a conference with proceedings. Papers should be at most 15 pages excluding the bibliography and well-marked appendices (using 11-point font and reasonable margins), and at most 20 pages total. Committee members are not required to read the appendices and the paper should be intelligible without them. The paper should start with the title, names of authors and an abstract. The introduction should give some background and summarize the contributions of the paper at a level appropriate for a non-specialist reader. During the workshop preproceedings will be made available. Final versions are not due until after the workshop, giving the authors the opportunity to revise their papers based on discussions during the meeting. Submissions can be made in Postscript or PDF format. To submit a paper, send a plain ASCII text email to containing the title and abstract of the paper, the authors' names, email and postal addresses, phone and fax numbers, and identification of the contact author. To the same message, attach your submission (as a MIME attachment). Papers must be received by December 2, 2002. Notification of acceptance or rejection will be sent to authors no later than February 7, 2003, and authors will have the opportunity to revise for the preproceedings version by March 7, 2003. Submission implies that, if accepted, the author(s) agree to publish in the proceedings and to sign a standard copyright release, and also that an author of the paper will present it at the workshop. From gojomo at usa.net Tue Jul 16 11:08:02 2002 From: gojomo at usa.net (Gordon Mohr) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a file in p2p References: <9736C73A-98CD-11D6-B6DA-0003936780B2@aaronsw.com> Message-ID: <003801c22cf3$98b52a80$640a000a@golden> Aaron Swartz writes: > This sounds something like the ESL proposal. It seems silly to abstract > things like this because, unlike DNS, there is no central registry for > KAUs. I doubt IANA would be eager to start one. It would be far simpler > to have each KAU register their own scheme. > > http://lists.w3.org/Archives/Public/www-rdf- > interest/2001Sep/att-0067/01-draft-palmer-esl-uri-00.txt > > There are some obvious mistakes in this draft (encoding whitespace) but > I don't think anyone was really willing to push the scheme thru any > further. Yes, that's similar... but more than the hash used should be parameterizable: the signing algorithm should be as well, those things change for legal/technical reasons more often then the basic technique would need to be revised. Also, there's no need to include the actual signature of the name inside the URI. All you want in the URI is the public-key identifier: you're saying "I am referring to the resource, if any, which this key gave this name", not providing the additional proof-material that the given key ever used that name (or that a particular resource has that name). Are you suggesting that instead of a parameterized "kau" type, there be different URI types for each signing algorithm? That just pops the registration issue up a level, pollutes the URI-scheme namespace, and might prevent software from recognizing when a URI is a key-authority name, but from a yet-unknown algorithm. A software module need not understand the algorithms to be useful; a DHT-based library might have a rule for finding the nodes responsible for certain "kau:" entities without knowing the algorithms in use. You don't even really need a formal IANA-type registration procedure when your universe of possibilities is small, and all people who might be choosing conflicting tokens can easily find each other. So just to parameterize the hash names ("sha1", "sha256", "tiger", "tigertree", etc.) and signing algs ("rsa", "elgamal", "ecc", etc.) barely needs a new registry, or can piggy-back off existing registries for other purposes. [Tangent: Just like search engines such as Google have made the DNS registration system less important, do tools like Google and the Internet Archive make specialized collision avoidance registries, like IANA, less important? Now you can claim a name-token by widespread use, and others who come later can easily find out if prior uses exist, and in what contexts, and possibly even as-of-what-date. Of course, some people won't check Google, or be tactful about avoiding confusion, but those are the same people who won't check IANA and prior activity anyway.] - Gojomo From me at aaronsw.com Tue Jul 16 11:53:02 2002 From: me at aaronsw.com (Aaron Swartz) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a file in p2p In-Reply-To: <003801c22cf3$98b52a80$640a000a@golden> Message-ID: <391491DC-98ED-11D6-B6DA-0003936780B2@aaronsw.com> On Tuesday, July 16, 2002, at 01:07 PM, Gordon Mohr wrote: > Also, there's no need to include the actual signature of the name > inside the URI. [...] Oh, I guess I misunderstood you -- I actually had the same idea and started on a draft for this several days ago: http://www.aaronsw.com/2002/draft-swartz-pgp-urn-00.html (.txt, .xml, etc.) > Are you suggesting that instead of a parameterized "kau" type, there be > different URI types for each signing algorithm? That just pops the > registration issue up a level, pollutes the URI-scheme namespace, How is it pollution? > A software module need not understand the algorithms to be useful; a > DHT-based library might have a rule for finding the nodes responsible > for certain "kau:" entities without knowing the algorithms in use. I would hope such a library would be able to handle any URI, not just kau ones. If it doesn't understand the signature algorithm, why does it care if it's associated with a key or not? > You don't even really need a formal IANA-type registration procedure > when your universe of possibilities is small, and all people who might > be choosing conflicting tokens can easily find each other. This may be true, but sort of defeats the purpose of the URN standardization process. The idea is to have a central registry where people can get the correct answer and know that it's correct. Not just guess based on common techniques. Furthermore, they should be able to find the definitive specifications for all these hashes and formats by following links to specs. If you want something less formal, why not carve out a bit of HTTP space? > [Tangent: Just like search engines such as Google have made the DNS > registration system less important, do tools like Google and the > Internet Archive make specialized collision avoidance registries, like > IANA, less important? Now you can claim a name-token by widespread use, > and others who come later can easily find out if prior uses exist, and > in what contexts, and possibly even as-of-what-date. Of course, some > people won't check Google, or be tactful about avoiding confusion, but > those are the same people who won't check IANA and prior activity > anyway.] Google is simply another form of centralized storage and query, although the input method is different and less structured. Even if we switch to a totally decentralized system like a DHT, the fundamental need of having a clear way to state "X is controlled by Y and specified in Z" won't go away. I'm not the most fond of IANA or their "parent" ICANN, but they do provide a useful service. Using Google to see if anyone has registered a URI scheme called "the" is rather difficult without consulting a specific registry. BTW, was urn:sha1 ever registered? I don't see it at: http://uri.net/urn-nid-status.html -- Aaron Swartz [http://www.aaronsw.com] 4FAC4838B7D8D13FA6D92EDB4145521E79F0DF4B I will be in San Diego for the O'Reilly Open Source Convention the 24-26 July. From gojomo at usa.net Tue Jul 16 12:51:02 2002 From: gojomo at usa.net (Gordon Mohr) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a file in p2p References: <391491DC-98ED-11D6-B6DA-0003936780B2@aaronsw.com> Message-ID: <007901c22d02$112d2130$640a000a@golden> Aaron writes: > On Tuesday, July 16, 2002, at 01:07 PM, Gordon Mohr wrote: > > Also, there's no need to include the actual signature of the name > > inside the URI. [...] > > Oh, I guess I misunderstood you -- I actually had the same idea and > started on a draft for this several days ago: > > http://www.aaronsw.com/2002/draft-swartz-pgp-urn-00.html (.txt, .xml, > etc.) Yep, very similar. My two snap comments would be: - Use "//" -- it's actually valid here, each key *is* the top of a (potentially/usually) hierarchical namespace -- unlike in the world of thrown-together P2P URI-schemes (ed2k, sig2dat, gnutella) where people are just mimicking "http://" without considering the intended meaning. - Why artificially limit it to just PGP? (More below.) > > Are you suggesting that instead of a parameterized "kau" type, there be > > different URI types for each signing algorithm? That just pops the > > registration issue up a level, pollutes the URI-scheme namespace, > > How is it pollution? There are already a dozen or more public-key signing approaches. Why should simply wanting to swap in a new name-binding signing algorithm require the overhead of a URI-scheme registration? They'll all need the same basic namespace-specific-part syntax; encouraging independent registration increases the risk of drift/idiosyncratic specifications. Also, why use up short-name-tokens that could be valuable with other meanings? For example, it would also be plausibly useful to have a URN scheme named "pgp" which simply retrieves the key from its fingerprint. That is: urn:pgp:4FAC4838B7D8D13FA6D92EDB4145521E79F0DF4B ...would mean "the key with this fingerprint". Or perhaps, to have a "pgp" URN scheme which means "get me the signature for this content" (rather than "the content which is suitably signed as having this name). That is: urn:pgp:4FAC4838B7D8D13FA6D92EDB4145521E79F0DF4B:sha1:BCLD3DINKJJRGYGHIYAX7HG5HXSM3XNH ...would mean "get me any signatures of this content-hash by this public-key principal". Perhaps these sorts of uses could be mixed-into your proposal. (That last one would implies an interesting reverse-lookup capabilitiy.) But whether they are or not, they emphasize that the short string "pgp" could serve many uses as a URI-scheme; why not explicitly qualify its meaning as being the specification of a "key-named authority"? > > A software module need not understand the algorithms to be useful; a > > DHT-based library might have a rule for finding the nodes responsible > > for certain "kau:" entities without knowing the algorithms in use. > > I would hope such a library would be able to handle any URI, not just > kau ones. If it doesn't understand the signature algorithm, why does it > care if it's associated with a key or not? In some cases, it might be nice for such a library to treat all URIs as opaque identifiers. But in others, better behavior might be possible by understanding which class of identifiers a certain URI belongs to. For example, it might aid in maintaining locality of reference to recognize all the names related to a certain key-naming-authority, even if you don't interpret that key-type. And what if someone wants to build a system where all content must be key-named? They want to accept any and all "kau"ish URIs, no other URIs. That task is easier if all "kau"ish URIs are labelled as such, even if they are new signing algorithms unregistered when the software was deployed. > > You don't even really need a formal IANA-type registration procedure > > when your universe of possibilities is small, and all people who might > > be choosing conflicting tokens can easily find each other. > > This may be true, but sort of defeats the purpose of the URN > standardization process. The idea is to have a central registry where > people can get the correct answer and know that it's correct. Not just > guess based on common techniques. Furthermore, they should be able to > find the definitive specifications for all these hashes and formats by > following links to specs. If you want something less formal, why not > carve out a bit of HTTP space? I'd agree that's the ideal of a centralized registry. But people don't always respect (or share) that ideal, especially if there are few consequences to ignoring the authority and/or it's easier and sufficient to do things in a more slapdash way. Things fall apart... > Google is simply another form of centralized storage and query, although > the input method is different and less structured. Even if we switch to > a totally decentralized system like a DHT, the fundamental need of > having a clear way to state "X is controlled by Y and specified in Z" > won't go away. I'm not the most fond of IANA or their "parent" ICANN, > but they do provide a useful service. Using Google to see if anyone has > registered a URI scheme called "the" is rather difficult without > consulting a specific registry. Being a devil's advocate: then don't use "the", even if the registry says it's OK. Someone might be using it unregistered. And you'll want people to find your usage, even if they don't check central registries, so it's a bad name anyway. Actual usage -- and the "common knowledge" of prevalence -- counts more than formalities anyway. > BTW, was urn:sha1 ever registered? I don't see it at: > http://uri.net/urn-nid-status.html Not yet registered. Needs to be, but I don't know when I or someone else will get around to it. - Gojomo From me at aaronsw.com Tue Jul 16 13:10:01 2002 From: me at aaronsw.com (Aaron Swartz) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a file in p2p In-Reply-To: <007901c22d02$112d2130$640a000a@golden> Message-ID: >> http://www.aaronsw.com/2002/draft-swartz-pgp-urn-00.html (.txt, .xml, >> etc.) > > [...] > - Use "//" -- it's actually valid here, each key *is* the top of > a (potentially/usually) hierarchical namespace -- unlike in the > world of thrown-together P2P URI-schemes (ed2k, sig2dat, gnutella) > where people are just mimicking "http://" without considering the > intended meaning. What's the hierarchical namespace? I'm wary of using // without a DNS name or IP following. I had no comments on the rest of the message. -- Aaron Swartz [http://www.aaronsw.com] 4FAC4838B7D8D13FA6D92EDB4145521E79F0DF4B I will be in San Diego for the O'Reilly Open Source Convention the 24-26 July. From gojomo at usa.net Tue Jul 16 13:30:02 2002 From: gojomo at usa.net (Gordon Mohr) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a file in p2p References: Message-ID: <00a801c22d07$82759480$640a000a@golden> > > - Use "//" -- it's actually valid here, each key *is* the top of > > a (potentially/usually) hierarchical namespace -- unlike in the > > world of thrown-together P2P URI-schemes (ed2k, sig2dat, gnutella) > > where people are just mimicking "http://" without considering the > > intended meaning. > > What's the hierarchical namespace? I'm wary of using // without a DNS > name or IP following. Per RFC 2396: # 3.2. Authority Component # # Many URI schemes include a top hierarchical element for a naming # authority, such that the namespace defined by the remainder of the # URI is governed by that authority. This authority component is # typically defined by an Internet-based server or a scheme-specific # registry of naming authorities. # # authority = server | reg_name # # The authority component is preceded by a double slash "//" and is # terminated by the next slash "/", question-mark "?", or by the end of # the URI. Within the authority component, the characters ";", ":", # "@", "?", and "/" are reserved. You're definitely specifying a "naming authority", by public key, so this section applies. It's also the case that names of the form: : ...are trivially hirarchical (though only two-levels deep), and the examples you use in your spec are further suggestive of hierarchicial directories. So the use of '//' would certainly be allowable, probably even wise. You might even want to use a '/' to separate the authority from the assigned-name. - Gojomo From BufferOverRun at hotmail.com Tue Jul 16 15:58:02 2002 From: BufferOverRun at hotmail.com (Buffer.OverRun) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] the resolution of the reply-to issue (was: reply-to) References: <200207151634.g6FGYt517944@finney.org> <01bd01c22c2f$1b4d21c0$33094d8e@uunet.ca> <029501c22cbc$f59a5040$2002a8c0@jdarcyvaio> Message-ID: "to sound condescending" was not my intent. the *desired effect* was for ppl to realize that it's not that difficult to change the reply-to field manually. anyway, as zooko mentioned this is not a democracy and he has made his decision. can we get back to p2p hacking, please? thank you. ----- Original Message ----- From: "Jeff Darcy" To: Sent: Tuesday, July 16, 2002 7:35 AM Subject: Re: [p2p-hackers] the resolution of the reply-to issue (was: reply-to) > > i prefer the reply-to sent to the entire group. if ppl can't figure out > how > > to directly mail someone > > they shouldn't be using this list. > > Ditto for people in the opposite scenario who can't figure out how to send > to all. The "shouldn't be using this list" argument is great if you just > want to sound condescending, but it's really not useful otherwise. > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > From clint at TheStaticVoid.net Wed Jul 17 07:30:01 2002 From: clint at TheStaticVoid.net (Clint Heyer) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Questionnaire Results Message-ID: <200207171428.g6HESuv00591@trinity.cc.uq.edu.au> Hi All, A while back I posted a request for people to fill out a questionnaire I was running as part of my honours thesis. A few people from p2p-hackers asked for the results to be posted on this list, so here they are (in brief). Obviously, all questions are bent towards propping up my thesis (implementation still being coded), but there may be some value in here for others. If anyone has any questions about this questionnaire or my project, feel free to post to the list or directly to me. Q1. Emotions ------------ Q: "In this question, you are required to indicate your anger level towards another peer. The network consists of you and only the three other people, and the amount shared by each is listed in the table below." Peer Shared Content (MB) You 160 A 200 B 130 C 20 The average `anger level' towards peer C was 3, with 10 being the highest, and 1 being not angry at all. With the table changed slightly: Peer Shared Content (MB) You 50 A 30 B 70 C 25 With the average anger level towards C being 2 in this case. When the question is turned around, asking what anger people expect from peers, there is a more emotive response. The question was: "In this question, you are required to indicate the anger level you would expect to receive from another peer. Please give an anger feeling level between 1 and 10, with 10 being the most intense, and 1 being none. Considering the amounts below, and that all peers know the amounts, what would you expect the anger level from one of the peers to be, should you unexpectedly meet them?" Peer Shared Content (MB) A 140 B 160 C 180 You 20 The average result was 5. Again, with the ratios changed: Peer Shared Content (MB) A 300 B 500 C 700 You 200 The average result for this table was 3. Q2. Behaviour in File Sharing Communities ----------------------------------------- This question was designed to find out what people most dislike about other people's behaviours in community. Q: "This question is about finding out what behaviours people dislike the most in a file sharing community. Listed are seven possible behaviours, but please list and rate others that aren't present in the comments box. Please rate on a scale of 1-10." (I've listed them here in descending order) People who misrepresent content they have shared (e.g. naming a file to indicate it is something it is not) Average: 9.0 People who prematurely cancel other people's downloads Average: 7.7 People who send obnoxious chat messages Average: 7.0 People who have no content shared Average: 5.7 People who stay online only long enough for their own downloads to finish Average: 5.0 People who down multiple data streams simultaneously from the one person Average: 4.5 People who download proportionally much more than they have shared Average: 4.2 Q3. Community Values -------------------- This question was an attempt to identify what people really value in a file sharing community. Q: "Please rate on a scale of 1-10 (10 being the highest) the value you place on the following attributes of a peer-to-peer file sharing community. Rate the attribute '1' if it holds no value for you." (again, listed here in descending order) High content quality Average: 8.8 High content quantity Average: 8.4 High-speed content download Average: 8.2 Large network size Average: 7.4 Anonymity Average: 6.9 Like minded, interesting people to chat with Average: 3.4 Presence of authority figures who moderate environment Average: 3.5 Sorry there is no analysis in this e-mail. My final report will go into the results in more detail. There were 140 respondents, with the questionnaire running for two weeks. No demographic data was sought from participants. cheers, .clint ----- Clint Heyer Web: http://TheStaticVoid.net - Mobile: 0421011224 ----- From Louis-Eric at Simard.com Wed Jul 17 17:20:02 2002 From: Louis-Eric at Simard.com (Louis-Eric Simard) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Flyster: Looking for beta testers Message-ID: <5.1.1.6.0.20020717201454.0394c808@getmail.simard.com> Hello everyone, I'm finishing up work, done over the last three years, to build a P2P-based web anonymizer. Some basic details of the system are posted at www.flyster.com. The Alpha release is nearing completion, and I will be looking for beta testers early next week. If you'd like to join, please drop by the web site and sign up: I'd particularly appreciate feedback from other P2P developers ! Cheers, + Louis-Eric Simard Flyster From J.C.Bicarregui at rl.ac.uk Thu Jul 18 08:24:02 2002 From: J.C.Bicarregui at rl.ac.uk (Bicarregui, JC (Juan) ) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Research posts in Computer Science Message-ID: <350DC7048372D31197F200902773DF4C025EB374@exchange11.rl.ac.uk> Please see: http://www.cclrc.ac.uk/Activity/ACTIVITY=VNs;SECTION=2312 for details. Background The CLRC is the UK's leading multidisciplinary science laboratory, providing facilities and services to the UK science community. The Information Science and Engineering Group within the Business and Information Technology Department offers research and development expertise in the science and engineering of high quality information and software systems. It has active research projects in web technologies including XML and the Semantic Web, information modelling and knowledge management and software engineering including OO and formal methods. CLRC also hosts the UK Office of the World Wide Web Consortium (W3C) and is the UK member of the European Research Consortium in Informatics and Mathematics (ERCIM). BITD has recently been awarded five new EU funded Research projects and is looking for three Research Associates to join an established research and development team. The new projects are on: * Semantic Web Advanced Development for Europe * Grid architecture for Application Service Provision * An Agent Based Platform for Organisationally Mobile Public Employees * Trust Management in Dynamic Open Systems * E-Learning within a Grid environment Duties The main duties of these Research Associate posts would include: * Undertaking Research and Technology Development on EU funded projects * Liasing with project partners, attending project meetings, contributing to project deliverables * Dissemination of results of research through academic publications in journals and conferences Qualification and experience Successful candidates will have a good first degree and preferably a postgraduate qualification in Computer Science or a related subject, or equivalent relevant experience. A proven ability to undertake research and experience in one of the topics of the new projects would be advantageous. Knowledge of the following topics would also be an advantage: * Ontologies and metadata, Knowledge representation technologies (eg RDF, DAML+OIL ) * Web service technologies (eg WSDL,UDDI, SOAP, P3P ) and Grid architectures * Knowledge management based on Software Agents, knowledge bases, databases, document repositories, and adaptable user interfaces * Modelling Trust as a means of establishing security and confidence in the global computing infrastructure, introducing trust management into existing and emerging technologies, regulatory and legislative frameworks Training will be available to develop skills as appropriate, in accordance with CLRC's commitment to the Investors in People scheme. Salary Starting salaries will be between ?15740 and ?32,380 on a pay range from ?15,740 to ?35,620 dependant on qualifications, experience and the level of appointment An excellent index-linked pension scheme and a generous leave allowance are also offered. For further information please email Dr Juan Bicarregui j.c.bicarregui@rl.ac.uk Dr Juan Bicarregui http://www.bitd.clrc.ac.uk/Person/J.C.Bicarregui Information Science and Engineering Group http://www.bitd.clrc.ac.uk/Group/BITDEINISE Business and Information Technology Department http://www.bitd.clrc.ac.uk/Home CLRC Rutherford Appleton Laboratory http://www.clrc.ac.uk From me at aaronsw.com Sun Jul 21 15:06:02 2002 From: me at aaronsw.com (Aaron Swartz) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] zesty p2p-hackers Message-ID: [#] I just set up an archive of the p2p-hackers using Ka-Ping Yee's zest prototype. It uses commenting and criticons like [+] [-] [?] [/] [#] to provide a structured view of the mailing list: http://notabug.com/zest/p2p-hackers/ [?] Do people find this useful? It's not auto-updated but I suppose it could be. Mainly it's a demo to see if anyone finds it useful. Anyway, enjoy. -- Aaron Swartz [http://www.aaronsw.com] 4FAC4838B7D8D13FA6D92EDB4145521E79F0DF4B I will be in San Diego for the O'Reilly Open Source Convention the 24-26 July. From zooko at zooko.com Sun Jul 21 15:23:02 2002 From: zooko at zooko.com (Zooko) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] zesty p2p-hackers In-Reply-To: Message from Aaron Swartz of "Sun, 21 Jul 2002 17:05:15 CDT." References: Message-ID: AaronSw: Cool mailing list software! I see that all the messages were from "p2p-hackers". Wes Felter reports to me that his "From:" addresses are right, and the "From:" addresses that I see are right, too. Perhaps a mail agent of yours is munging "From:" to match the "Reply-To:" that it sees? Anyone else out there see "p2p-hackers" as the From: field? Regards, Zooko AaronSw wrote: > > [#] I just set up an archive of the p2p-hackers using Ka-Ping Yee's zest > prototype. It uses commenting and criticons like [+] [-] [?] [/] [#] to > provide a structured view of the mailing list: > > http://notabug.com/zest/p2p-hackers/ > > [?] Do people find this useful? It's not auto-updated but I suppose it > could be. Mainly it's a demo to see if anyone finds it useful. From me at aaronsw.com Sun Jul 21 15:27:01 2002 From: me at aaronsw.com (Aaron Swartz) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] zesty p2p-hackers In-Reply-To: Message-ID: On Sunday, July 21, 2002, at 06:22 PM, Zooko wrote: > Wes Felter reports to me that his "From:" addresses are right, > and the "From:" addresses that I see are right, too. Perhaps a mail > agent of > yours is munging "From:" to match the "Reply-To:" that it sees? [-] No, the mail headers I receive on my machine are fine but those stored on the website are not (presumably to foil spammers). Since I've not been on the list long (nor do I keep an mbox archive of posts) I grabbed the version from the website. Do you have any better ideas on how to get unmunged posts? -- Aaron [http://www.aaronsw.com] 4FAC4838B7D8D13FA6D92EDB4145521E79F0DF4B I'll be at the O'Reilly Open Source Convention in San Diego July 24-26. From gojomo at usa.net Sun Jul 21 17:40:01 2002 From: gojomo at usa.net (Gordon Mohr) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] zesty p2p-hackers References: Message-ID: <00b501c23118$46e71280$640a000a@golden> > [#] I just set up an archive of the p2p-hackers using Ka-Ping Yee's zest > prototype. It uses commenting and criticons like [+] [-] [?] [/] [#] to > provide a structured view of the mailing list: > > http://notabug.com/zest/p2p-hackers/ Interesting. Neat how well it separates out threads within single messages -- I suppose only so much as people use classic interspersed quoting. I know I'd glanced at some threads created by Ka-Ping Yee's tools before, but I'd never noticed that it worked on a finer-grain than full messages. However, if I thought most people would be skimming discussions this way, I might have to change my rhetorical style. As in this message, I tend to start out with an affirmation or recognition/restatement of some previous point -- but then move on to qualifications, exceptions, counterarguments, opposing refinements. Thesis and antithesis. But the current algorithm for choosing sentences to appear in the threaded-summary tends to lop off all the antitheses, conveying unqualified agreement when the jist of the message is 'yes, but...'. - Gojomo From blair at orcaware.com Sun Jul 21 20:59:01 2002 From: blair at orcaware.com (Blair Zajac) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] zesty p2p-hackers References: Message-ID: <3D3B82E9.34889486@orcaware.com> Aaron Swartz wrote: > > [#] I just set up an archive of the p2p-hackers using Ka-Ping Yee's zest > prototype. It uses commenting and criticons like [+] [-] [?] [/] [#] to > provide a structured view of the mailing list: > > http://notabug.com/zest/p2p-hackers/ Looks great when I load it in IE. However, in Netscape 4.79, I get the following error in both frames: The requested URL /zest/p2p-hackers/style.css was not found on this server. Best, Blair -- Blair Zajac Web and OS performance plots - http://www.orcaware.com/orca/ From me at aaronsw.com Sun Jul 21 21:23:01 2002 From: me at aaronsw.com (Aaron Swartz) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] zesty p2p-hackers In-Reply-To: <3D3B82E9.34889486@orcaware.com> Message-ID: On Sunday, July 21, 2002, at 10:58 PM, Blair Zajac wrote: > The requested URL /zest/p2p-hackers/style.css was not found on this > server. Oops, I accidentally deleted this file. Fixed. -- Aaron [http://www.aaronsw.com] 4FAC4838B7D8D13FA6D92EDB4145521E79F0DF4B I'll be at the O'Reilly Open Source Convention in San Diego July 24-26. From bram at gawth.com Wed Jul 24 22:01:02 2002 From: bram at gawth.com (Bram Cohen) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] minor meeting saturday Message-ID: At the last meeting we discussed having another meeting this saturday, on the theory that aaronsw and raph might be able to make it. As it turns out, neither of them will be in town, but I figure, hey, I'll show up anyway. As usual, 3pm, the metreon. Note that it's on saturday this time though. And, hey, stevej, I found the black book, I can hand it off to you there if you're coming. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From cefn.hoile at bt.com Mon Jul 29 02:46:01 2002 From: cefn.hoile at bt.com (cefn.hoile@bt.com) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a file in p2p Message-ID: Justin, What are your principal objections to the idea of a P2P operating system? Cefn >>>> -----Original Message----- From: Justin Chapweske [mailto:justin@chapweske.com] Sent: 16 July 2002 02:40 To: p2p-hackers@zgp.org Subject: Re: [p2p-hackers] Everything as a file in p2p Personally, I think the concept of a P2P transport layer is as vacuous as talking about a "P2P operating system". From bram at gawth.com Mon Jul 29 04:27:02 2002 From: bram at gawth.com (Bram Cohen) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a file in p2p In-Reply-To: Message-ID: cefn.hoile@bt.com wrote: > What are your principal objections to the idea of a P2P operating system? The problem with the p2p operating system is that whenever it swaps to disk all the computers in Texas stop working. Seriously, there are two possible meanings to 'internet operating system', literal and metaphorical, and both are deeply flawed. Taken literally, it's simply untrue - even in beowulf clusters each individual machine is still running its own operating system. As a metaphor, it is completely misleading - there are security boundaries and regions of great latency between machines which have no equivalent concepts on a single architecture. Don't take my actually arguing the point seriously as a legitimization of the term. 'Internet OS' is just as silly on its face as 'species organism' or 'skyscraper house' or 'interstate hallway', it's just a nonsensical juxtaposition of terms, and if this leads to an ongoing discussion I'm probably going to start mocking its users mercilessly again, probably by repeating their posts back with 'interstate hallway', and analogues silly terms substituted for 'Internet OS' -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From jeff at pl.atyp.us Mon Jul 29 05:02:01 2002 From: jeff at pl.atyp.us (Jeff Darcy) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a file in p2p References: Message-ID: <058201c236f6$cd27af60$407b9fa8@lss.emc.com> Of course, some people feel that "P2P" deserves exactly the same sort of derision. Does the possibility of mockery by people with limited vision invalidate a concept? From bram at gawth.com Mon Jul 29 07:46:01 2002 From: bram at gawth.com (Bram Cohen) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a file in p2p In-Reply-To: <058201c236f6$cd27af60$407b9fa8@lss.emc.com> Message-ID: Jeff Darcy wrote: > Of course, some people feel that "P2P" deserves exactly the same sort of > derision. Does the possibility of mockery by people with limited vision > invalidate a concept? Oh, I'm tempted to mock 'p2p' as well, especially when it's slung around as a hollow buzzword, but it does at least at least have some underlying meating - specifically, it's an adjective which refers to architectures whose connectivity is more mesh-like than tree-like. Unfortunately it's used as an absolute, rather than relative, term, making it sound very absurd at times. 'decentralized' is technically a better term, since it refers to something having been made made more meshy at some time in the past, but people use it as an absolute term anyway. Pundits aren't much for linguistic accuracy. That said, if someone asks me if BitTorrent is p2p I'll say yes, since it does do most of its transfers and coordination directly between peers. I am a little bit uncomfortable with it, but not nearly as uncomfortable as I am with how people insist on saying that BitTorrent is 'fast', which is true in some cases, but most definitely not true in all of them. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From justin at chapweske.com Mon Jul 29 18:13:01 2002 From: justin at chapweske.com (Justin Chapweske) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a file in p2p References: Message-ID: <3D45E80F.40105@chapweske.com> My principal objection is that it is a non-idea around which no meaningful discussion can occur. Its like a "personal democracy". It sounds like a thought provoking idea, but it really doesn't mean anything. I mean no disrespect. I just prefer real-meat conversations to punditacular un-words. -Justin cefn.hoile@bt.com wrote: > Justin, > > What are your principal objections to the idea of a P2P operating system? > > Cefn > > > > -----Original Message----- > From: Justin Chapweske [mailto:justin@chapweske.com] > Sent: 16 July 2002 02:40 > To: p2p-hackers@zgp.org > Subject: Re: [p2p-hackers] Everything as a file in p2p > > Personally, I think the concept of a P2P transport layer is as vacuous > as talking about a "P2P operating system". > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers -- Justin Chapweske, Onion Networks http://onionnetworks.com/ From cefn.hoile at bt.com Tue Jul 30 10:35:01 2002 From: cefn.hoile at bt.com (cefn.hoile@bt.com) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a file in p2p Message-ID: Bram, I have to disagree with the following... "there are security boundaries and regions of great latency between machines which have no equivalent concepts on a single architecture" ...since you mention one equivalent to network latency which does exist within a single architecture - the different latencies of on-disk memory, ram and cache memory. Single machine OSs have strategies for hiding this complexity from programmers whose programs are hosted by the OS. Here is another equivalent, related to security boundaries; Java VMs provide quite explicit boundaries of memory access for executing programs, (although I acknowledge some of them may have a few holes). Nevertheless, I agree that issues of terminology are perfectly valid, especially if they distract people from the real issue at hand. This happens all the time in my domain - nature inspired computing - arguing over 'emergence' (I personally don't care what it means, I just want systems which are decentralised and converge to appropriate behaviour through scalable, local interactions). Equally, I don't care to argue for what Internet OS means. So to redefine the question... What's wrong with the idea of something which does for a P2P network what an operating system does for a monolithic 'von Neumann' machine. In other words, why can't we think in terms of programs built to run across the P2P network where that network provides a runtime environment for these programs, without having to anticipate what those programs will be? Whatever people say about the Gates monster, widespread convergence in operating systems have led to a wide adoption of desktop computing, and consequently increases in funding and increases in available software. If we can have something which provides the same supporting role for P2P apps, (i.e. addressing the common problems which exist when hosting processes in a P2P network, and hiding this complexity from the programmer), we will be in clover. By the way I don't think that the Grid computing people are addressing this issue. They are all talking about scheduling, requiring the sort of petri-net predictable algorithms which can be explicitly managed. This is appropriate when managing dedicated resources for multi-million dollar proton bouncing exercises which are planned months ahead. Not so appropriate for managing a real-time P2P network. Cefn P.S. Issues regarding a minimal process hosting platform are also discussed at http://www.agentcities.org/Challenge02/Proc/Papers/ch02_20_hoile.pdf where the minimal approach is contrasted to complex and problem-specific agent toolkits. I think a lot of the reasoning in this document applies to over-specified P2P hosting platforms. -----Original Message----- From: Bram Cohen [mailto:bram@gawth.com] Sent: 29 July 2002 12:27 To: p2p-hackers@zgp.org Subject: RE: [p2p-hackers] Everything as a file in p2p cefn.hoile@bt.com wrote: > What are your principal objections to the idea of a P2P operating system? The problem with the p2p operating system is that whenever it swaps to disk all the computers in Texas stop working. Seriously, there are two possible meanings to 'internet operating system', literal and metaphorical, and both are deeply flawed. Taken literally, it's simply untrue - even in beowulf clusters each individual machine is still running its own operating system. As a metaphor, it is completely misleading - there are security boundaries and regions of great latency between machines which have no equivalent concepts on a single architecture. Don't take my actually arguing the point seriously as a legitimization of the term. 'Internet OS' is just as silly on its face as 'species organism' or 'skyscraper house' or 'interstate hallway', it's just a nonsensical juxtaposition of terms, and if this leads to an ongoing discussion I'm probably going to start mocking its users mercilessly again, probably by repeating their posts back with 'interstate hallway', and analogues silly terms substituted for 'Internet OS' -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers From bram at gawth.com Tue Jul 30 11:18:01 2002 From: bram at gawth.com (Bram Cohen) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a file in p2p In-Reply-To: Message-ID: cefn.hoile@bt.com wrote: > So to redefine the question... > > What's wrong with the idea of something which does for a P2P network what an > operating system does for a monolithic 'von Neumann' machine. What's wrong with the idea of something which does for an interstate highway what track lighting does for a hallway? Saying more words isn't going to make your argument any more coherent. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From jeff at platypus.ro Tue Jul 30 11:47:02 2002 From: jeff at platypus.ro (Jeff Darcy) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a file in p2p References: Message-ID: <060e01c237f9$55407ff0$407b9fa8@lss.emc.com> [Sorry if people see this twice. I'm at work and can't find the right magic formula to change my "official" email address so that I don't have to go through moderation.] cefn.hoile@bt.com wrote: > What's wrong with the idea of something which does for a P2P network what an > operating system does for a monolithic 'von Neumann' machine. "Bram Cohen" : > What's wrong with the idea of something which does for an interstate > highway what track lighting does for a hallway? > > Saying more words isn't going to make your argument any more coherent. Bram, I know you dislike the idea of a "P2P OS" but that's no reason to be an ass about it. You too, Justin. An OS provides an abstraction service, insulating applications from certain details of the underlying hardware and allowing that hardware to be multiplexed among apps. It's very easy to apply those same concepts of abstraction and multiplexing to networked resources and come up with a clear picture of what a net OS would be like. It would be a worthwhile thing, and the name would be appropriate. Or maybe it's the "P2P" of "P2P OS" that bothers you, rather than the more generic "net" part, but this is "p2p-hackers" so it would be kind of odd if that were the case. The true equivalent to OS services in your highway/hallway metaphor would be lighting on a transit facility, and you know what? That's actually a decent idea! Sometimes ideas *can* be transplanted from one domain to another, with positive results. Sometimes it's worth discussing what such a hybrid would/should really be like, instead of trying to shut down discussion with derision and intimidation. We have people here working on "open content networks" and "emergent systems" and other stuff that sounds like utter BS to people who first hear the terms; we as a group should perhaps hesitate at least for a single second before dismissing ideas that seem strange to us. From lgonze at panix.com Tue Jul 30 11:58:02 2002 From: lgonze at panix.com (Lucas Gonze) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a file in p2p In-Reply-To: Message-ID: > What's wrong with the idea of something which does for a P2P network what an > operating system does for a monolithic 'von Neumann' machine. You'd have to demonstrate that something like that is possible for a P2P network. not easy. The lesson that I learned from the past couple years worth of conversation about the internet OS is that I needed to get intimate with current science related to milgram/barabasi/etc -- basically that it's all about the graphs. can't say that I agree with Bram's point WRT the phrase IOS, but then again I think that the statement "there is no Internet OS" is exactly as vapid as the statement "I am building an Internet OS." From dstolarz at bluefalcon.com Tue Jul 30 13:23:01 2002 From: dstolarz at bluefalcon.com (Damien Stolarz) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Re: Everything as a file in p2p Message-ID: > What are your principal objections to the idea of a P2P operating system? > I understand the opposition to buzzwords; however, P2P OS or Internet OS actually is fairly descriptive. Now, we already have an acceptable term, a "network operating system" http://whatis.techtarget.com/wsearchResults/0,,sid9,00.html?query=networ k+operating+system Which includes things like Novell, unix, NT, etc. OS is supposed to include: - cpu control/process scheduling - disk control/ peripheral control / resource management - providing a hardware abstraction layer for application software Originally (and even now) people have protested even including this in the list: - GUI So one possible definition of an "internet operating system" is one that makes the whole internet look like it was one machine (although a web browser does this to a degree). Also, there is distributed computation, distributed, storage, distributed printing, distributed peripheral control, and distributed user interaction... and the web could be viewed as distributed user interface. So another definition would simply be "software that performs all of the traditional OS functions and provides a layer of abstraction" Per Tanenbaum (the books from which I studied CS): http://www.cs.vu.nl/~ast/ " An interesting development that began taking place during the mid-1980s is the growth of networks of personal computers running network operating sys-tems and distributed operating systems (Tanenbaum and Van Steen, 2002). In a network operating system, the users are aware of the existence of multiple computers and can log in to remote machines and copy files from one machine to another. Each machine runs its own local operating system and has its own local user (or users). Network operating systems are not fundamentally different from single-processor operating systems. They obviously need a network interface controller and some low-level software to drive it, as well as programs to achieve remote login and remote file access, but these additions do not change the essential struc-ture of the operating system. A distributed operating system, in contrast, is one that appears to its users as a traditional uniprocessor system, even though it is actually composed of multiple processors. The users should not be aware of where their programs are being run or where their files are located; that should all be handled automatically and efficiently by the operating system. True distributed operating systems require more than just adding a little code to a uniprocessor operating system, because distributed and centralized systems differ in critical ways. Distributed systems, for example, often allow applications to run on several processors at the same time, thus requiring more complex pro-cessor scheduling algorithms in order to optimize the amount of parallelism. Communication delays within the network often mean that these (and other) algorithms must run with incomplete, outdated, or even incorrect information. This situation is radically different from a single-processor system in which the operating system has complete information about the system state." So it's not that wacky to talk about these things, IMHO. -- Damien Stolarz Founder & Chief Software Architect Blue Falcon Networks http://www.bluefalcon.com (213) 617-6900 x102 (818) 554-1555 From rosser at qualia.org Tue Jul 30 13:41:01 2002 From: rosser at qualia.org (Rosser Schwarz) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a file in p2p In-Reply-To: References: Message-ID: <4.1.20020730153907.014ed5a0@concertina.rmta.org> At 11:17 AM 7/30/2002 -0700, Bram Cohen wrote: [...] >What's wrong with the idea of something which does for an interstate >highway what track lighting does for a hallway? isn't that exactly what we use arc sodium for? /rls From cefn.hoile at bt.com Tue Jul 30 13:47:01 2002 From: cefn.hoile at bt.com (cefn.hoile@bt.com) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a file in p2p Message-ID: > What's wrong with the idea of something which does for a P2P network what an > operating system does for a monolithic 'von Neumann' machine. You'd have to demonstrate that something like that is possible for a P2P network. not easy. CEFN: Yes, I think you need to get clear on what you want it to do. You're completely right to point out that there are many services which require a whole different way of thinking and additional compromises over the von Neumann type setup. However, the general characterisation of the function of an OS is roughly 'hiding the underlying gubbins', as reiterated by Jeff. In particular, an OS provides a set of well-defined hosting services for applications, which are available within any hosting environment with the same OS. E.g. a registry, a filesystem, a thread scheduler, or whatever, which each make certain commitments to their behaviour, and have certain well-defined modes of failure... You don't need to reinvent these things if you want to write an application. I am interested to know how far down this route we can go. What specific services should be in that common pool? Is it just the ad hoc naming and routing solutions? Is it data fragmentation? Is it memory allocation? Is there a registry? How much can we handle with an application/process hosting layer which is common to all apps, and a systematically modified approach to development (i.e. taking into account weak process mobility)? How simple can a developer's code be within such an environment? What changes in coding philosophy will be required? What are the biggest obstacles? The typical OS-type services might be a start, but I am not suggesting that they are necessary or sufficient. I am just interested in exploring the analogy. Existing work clearly contributes some of these components, but it seems to be fragmented into separate services, (a fine development philosophy), and does not foresee the value of establishing a common bundle of services, (a fine philosophy to lead to wide adoption and the emergence of de-facto standards). The lesson that I learned from the past couple years worth of conversation about the internet OS is that I needed to get intimate with current science related to milgram/barabasi/etc -- basically that it's all about the graphs. CEFN: I must admit, this is more or less where we have ended up. We should be laying down these nuggets of hard earned wisdom in libraries which interwork, and ideally which may be available through a generic peer software distribution, rather than allowing our application-specific needs and the obstacles that we have faced in deploying applications blind us to the fact that there may be a set of components which would be a suitable foundation for a general solution. can't say that I agree with Bram's point WRT the phrase IOS, but then again I think that the statement "there is no Internet OS" is exactly as vapid as the statement "I am building an Internet OS." CEFN: You may want to note that the use of OS for more than one von Neumann machine has a strong precedent, i.e. 'Distributed Operating Systems' Andrew Tanenbaum Prentice Hall 0-13-219908-4 _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers From cefn.hoile at bt.com Wed Jul 31 11:53:02 2002 From: cefn.hoile at bt.com (cefn.hoile@bt.com) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a file in p2p Message-ID: CEFN: Bram, Since your having potshots, I'm sorry to point this out, but when the words in a sentence change, sometimes the meaning does too. To reciprocate your advice, if your comprehension of the english language doesn't stretch to understanding the distinction between an "argument" and a question... >>>>> My Original Mail : "What are your principal objections to the idea of a P2P operating system?" BRAM:"Saying more words isn't going to make your _argument_ any more coherent." <<<<< ...or the distinction between 'is a' (definition) and 'is like a' (analogy)... >>>>> My Later mail : "So to redefine the question... What's wrong with the idea of something which does for a P2P network what an operating system does for a monolithic 'von Neumann' machine." BRAM:"_Saying more words_ isn't going to make your argument any more coherent." <<<<< ...then cutting down on pseudo-philosophical attacks against others might be one way to keep you out of the firing line. BRAM: "if this leads to an ongoing discussion I'm probably going to start mocking its users mercilessly again, probably by repeating their posts back with 'interstate hallway', and analogues silly terms substituted for 'Internet OS'" CEFN: I guess the first step along the way is admitting that you have a problem. Just take it one day at a time. From sah at thalassocracy.org Wed Jul 31 12:23:02 2002 From: sah at thalassocracy.org (Steven Hazel) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a file in p2p References: Message-ID: <3D483854.6082F670@thalassocracy.org> cefn.hoile@bt.com wrote: > > CEFN: Bram, Since your having potshots, I'm sorry to point this out, but > when the words in a sentence change, sometimes the meaning does too. To > reciprocate your advice, if your comprehension of the english language > doesn't stretch to understanding the distinction between an "argument" and a > question... Could we please end this flamewar before it gets out of hand? Pundits: Please realize that if you use metaphorical terms like "Internet OS" or "P2P OS" to describe exciting technology which does not yet (but probably will) actually exist, a bunch of technical people are going to think you sound really silly, and make fun of you. Remember "Information Superhighway"? Hackers: Please realize that mocking well-meaning pundits is not the best use of your time. Buzzwords are a force of nature. It doesn't matter what you think of them, because there's nothing you can do about them. Those of you who may be inclined to respond to this post: You nazis are all Adolf Hitler. -- Steven Hazel sah@thalassocracy.org From oskar at freenetproject.org Wed Jul 31 12:51:01 2002 From: oskar at freenetproject.org (Oskar Sandberg) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a file in p2p In-Reply-To: <060e01c237f9$55407ff0$407b9fa8@lss.emc.com> References: <060e01c237f9$55407ff0$407b9fa8@lss.emc.com> Message-ID: <20020731195410.GB347@sporty.spiceworld> If I may interject here, could we go into help the ignorant mode for a second and explain exactly what a "P2P OS" is supposed to be in more concrete terms. It seems to me that what you are saying is that you want to present an API to program developers that lets them easily utilize distributed networks. But while it may be "very easy" for you to see what this API would contain, it is a complete enigma to silly old me (beyond the good old "Eyeore's birthday"[1] model for the kind of networks I'm working with). Instead of wasting our time on yet another semantic flamewar, could one of the proponents go through exactly what they want the API to contain? I don't need technical documentation, just a rundown of the methods and their intended purposes. [1] http://www.machaon.ru/pooh/chap6.html "So it does!" said Pooh. "It goes in!" "So it does!" said Piglet. "And it comes out!" On Tue, Jul 30, 2002 at 02:45:53PM -0400, Jeff Darcy wrote: <> > Bram, I know you dislike the idea of a "P2P OS" but that's no reason to be > an ass about it. You too, Justin. An OS provides an abstraction service, > insulating applications from certain details of the underlying hardware and > allowing that hardware to be multiplexed among apps. It's very easy to > apply those same concepts of abstraction and multiplexing to networked > resources and come up with a clear picture of what a net OS would be like. > It would be a worthwhile thing, and the name would be appropriate. Or maybe > it's the "P2P" of "P2P OS" that bothers you, rather than the more generic > "net" part, but this is "p2p-hackers" so it would be kind of odd if that > were the case. -- Oskar Sandberg oskar@freenetproject.org From jeff at platypus.ro Wed Jul 31 13:23:01 2002 From: jeff at platypus.ro (Jeff Darcy) Date: Sat Dec 9 22:11:46 2006 Subject: [p2p-hackers] Everything as a file in p2p References: <060e01c237f9$55407ff0$407b9fa8@lss.emc.com> <20020731195410.GB347@sporty.spiceworld> Message-ID: <07ab01c238cf$f70a5370$407b9fa8@lss.emc.com> > If I may interject here, could we go into help the ignorant mode for a > second and explain exactly what a "P2P OS" is supposed to be in more > concrete terms. A pretty good start would be good old POSIX semantics, only applied to resources across networks instead of on a single machine. Open/close/read/write for files regardless of where they're located, in a single file namespace. Fork/wait/kill for processes regardless of whether they're they're located, in a single process namespace. Memory allocation, pipes, memory-mapped I/O, other forms of IPC that work the same regardless of location. Think of what had to happen to go from uniprocessors to shared-memory SMP, and imagine providing the same levels of functionality and integration for MP without the shared-memory hardware. Alternatively, imagine an OS that would take a program written today for some current OS and run it *unmodified*, taking productive advantage of resources on multiple machines. It's not that outlandish a goal, really. Some would claim it has even been done already - by Amoeba, by AEGIS, by VAXClusters, by Plan 9, by QNX. Do any of these run on "Internet scale" with high latency and low bandwidth/reliability? No, not really. Is there anything specifically "P2P" about it, as opposed to being more generically "distributed"? Again, no. But technology is getting there. Methods for dealing with the relatively crappy communications characteristics of the Internet are getting pretty advanced, and a lot of the location/topology/communications methods that comprise "P2P" could well find a home as building blocks for such a distributed OS. BTW, since I don't feel like spending a whole separate post responding to Steven Hazel: just because a legitimate jargon term has been coopted by marketroids does not mean that it loses its technical meaning or that only "pundits" could use it. Consider "NUMA", "zero-copy", "linear scaling", "P2P", "swarming", "censorship resistance" or dozens of other terms you probably use yourself. Are you a pundit, then? Did all the code you ever wrote just magically disappear because you used a forbidden term? Is that the kind of intellectual world you want to live in, where one person's abuse of a term poisons the concept that it represents even for hard-core technical people who've been using the term for years? That attitude disturbs and annoys me as much as any other kind of censorship - and make no mistake, censorship is what it is.