O'Reilly's Peer-to-Peer Summit Synopsis: Transcript
Pages: 1, 2

Sims: Jon, you've talked about this. You work remotely a lot of the time. Working remotely is sort of stitching together in your mind a hodge-podge of tools. If you're like me you've got AIM running, you've got IRC running, you're checking your e-mail, you're using voice mail, you're using the phone. All this seems like -- the higher vision is a way to sort of be able to stitch all of this together.

Udell: Well, you have all those communication channels going, and that's part of the difficulty, but another big part of the difficulty is that you have those channels going in multiple contexts. I think in terms of project contexts, and in each project I have a set of documents. I have a set of preferred communication channels, I have a set of documents, and I expend an awful lot of energy every day trying to assemble those things into a coherent context. I'm desperate for some kind of software system to help me do that more easily. So I think that the reason that this doesn't happen a lot of the time is that it's exactly the case that the artificial centralization has created these terrible IT bottlenecks. It's quite typical, and whether or not you work independently as I do or whether you work in a company, it's almost routinely the case that a project is going to involve people in different situations: people in other companies, people in your company who are working from home today, people in your company who are working in the office on the other coast, etc. This is the norm. So to say that we have to get in line at the IT queue for the administrator to carve out the space in which we can do these ad hoc collaborations -- well, it just isn't happening.

This is actually why so much stuff ends up flowing through e-mail, and why I argue in some sense that e-mail is actually conceptually a peer-to-peer application to the extent that it is perhaps the only thing which empowers users today to form these ad hoc collaborations. And so we use it, but we abuse it, because it really isn't capable of dealing with a lot of the things that we'd like to have handled more seamlessly. One of the key ones -- and this gets to the instant messaging as a platform idea -- is this notion which somebody I guess has called Presence Management, which I think is a great thing -- the idea that it's my presence, my availability, not in voice mail, not in stored and forwarded e-mail, but my actual presence in real time, which is this resource which needs to be understood and transmitted through the network and then woven into applications, so that you might use a presence management technology to determine that I'm really there but then you might choose to contact me through some other preferred channel. That's going to be a really powerful business tool.

O'Reilly Can I go in a completely different direction here? And that is just thinking about applications of systems like FreeNet, looking forward in areas that, for example, are about intellectual property sort of escaping from the hands of people who want to keep it private. In a different context, I've been talking a lot with Kevin Lenzo, who's one of the leading researchers in open source speech synthesis. Kevin is working on Festival and Festvox, which are projects for allowing people to effectively build high-quality synthetic voices. This is a voice that can read arbitrary text, for example. I was talking with Kevin and with Scott Miller, one of the Free Net developers who was at the meeting, and Scott described how he works with Festival and IRC, for example. While he's coding, he is listening to an IRC channel, Pipe to Festival, as a way of transmitting that into voice. But one of the things that's very exciting: As voice synthesis becomes more widespread, you could imagine hearing that IRC channel not in one voice but in the voice of each participant. Well, how would those voices be distributed? Would you want them to go along every time? No, you'd want them to be cached in some way locally. And you think about the Free Net type of architecture, and that's a wonderful way for that to happen. Here's some kind of data that's fairly large that you want to be distributed, but you want it to be distributed naturally to the people who use it and not --

Sims: -- it's not a library --

O'Reilly: It's not a library but it's a way of using a distributed file system for a kind of data that wants to be naturally cached in some location where it's accessible to the people who use it.

Udell: There are lots of applications for distributed caching which don't suffer the Napster syndrome. Another one we heard about was Bob Knighten at Intel pointing out that, although Hollywood is pretty upset about the idea of the Napsterization of movies themselves, they'd very much like to get out of the business of having to host all these trailers on their sites, because there's a huge bandwidth cost associated with that. They're very interested in looking at ways to enable users themselves to propagate these trailer files back and forth amongst themselves and kind of shift the bandwidth cost to the users, although actually it shifts the costs to the user's ISP, when you think about it, which gets into another set of issues which I think weren't fully explored right, but the notion that --

Sims: It eventually gets back to the user, I would imagine --

O'Reilly The old Chinese curse, "May you live in interesting times" -- it's not necessarily a bad thing for there to be a lot of unsolved problems. It just makes life interesting.

Sims: It's like being slash-dotted -- what a great problem. How come I can't get to my server? Well, you'll love the answer to that.

I guess my last question would be the connotation -- the public connotation with peer-to-peer has been around Napster, and in a way some people argue that that's sort of hurt the technology. And I wonder what the consensus around the group was about this: If Napster's done more for peer-to-peer by getting it on 22 million people's radar screen, or if it's done less by connoting peer-to-peer so directly with piracy, if you will.

O'Reilly: I would say right off that Napster's done us all an enormous service. It really brought home very powerfully the power of that fully distributed model. Actually, it's not even fully distributed, but just the idea of distributing content and caching it in a variety of locations and effectively passing around the metadata that points to it rather than passing around the data. I think that that idea has so many implications for so many applications that it's worth the pain that's it's caused to the industries that are having to understand the implications. We've just go to wrestle with it. It's a powerful technology with powerful beneficial uses, and we'll just need to figure out how to figure out the things that are not working about it.

Udell: I guess if I have any concerns about the effect of Napster it's that it has imprinted this idea of specifically file sharing so forcefully on a lot of people right now that it may not be obvious what are some of the other kinds of applications, and there are many. Napster is dealing with a specific data type, with specific characteristics. There are other kinds of file types, but much data on the Web isn't a file. It's dynamically generated, so really, I'm looking for a whole variety of other kinds of services and data-aware processes and people-aware processes to emerge from this. And I hope that people are thinking about those and not just about file sharing.

Return to the Open Source Roundtable.

Discuss this article in the O'Reilly Network Forum.

Return to the O'Reilly Network Hub.