Slashdot Mirror

I'm a bit surprised that no p2p project has tried to do UDP connection splicing
to allow two peers, both behind internet connection sharing (NAT) to talk to
each other.

Check out the UDP based messaging protocol used in the alpine search communication. It supports dual NAT communication between peers and reliable/unreliable transport of datagram packets.

For bulk transport (most apps use UDP for messaging only) you would need to use something like AirHook to handle retransmission and high throughput transfer.

These guys have been talking about the same thing only with wireless access points. Check out this story to see what they intend to do with it.

I like the idea of aggregate bandwidth, and I think it is something we *will* see en masse very soon.

These guys have been talking about the same thing only with wireless access points. Check out this story to see what they intend to do with it.

I like the idea of aggregate bandwidth, and I think it is something we *will* see en masse very soon.

3com's wireless page doesn't list any 802.11g equipment yet. The only 802.11g cards I've seen in person were the Linksys WPC54G & WMP54G.

I was looking for compatibility between Linux and 802.11g last night; I found someone saying "long story short, Broadcom doesn't work" (Note: That link is down, and checking nearby files pop up errors about "vulnerable Internet Explorer version," closes the window, and probably fucks up my computer. Thanks a lot guys. Um. The upshot is, people have tried the Broadcom stuff on Linux, it doesn't work, and it's suggested you request documentation from Broadcom. Later.)

For those attending codecon there will also be a WiFi Caravan traveling from Portland OR to San Francisco which all are welcome to participate in.

We will be out and about on the evenings after the conference precedings if you dont feel like driving all the way to portland :-)

As one last FYI, be sure to bring your wireless gear to codecon! There will be lots of A/V streaming going on, and lots of wireless enabled presentations in addition to other fun stuff.

Check out the InfoAnarchy CodeCon 02 coverage if you would like a better feel for what this conference is all about...

Yep. There are two arguments in the quoted passage: First, that Congress has abused the meaning of "limited time"; second, that retroactive extensions of "existing terms" are prohibited. I'm sympathetic to the second, and think the first is for Congress not the courts.

I do sort of wish the Court would intervene to say the term has gotten too long, but don't want a precedent like that for the Court to do so in other cases. Historical experience has been that although unchecked power of Congress is bad, the unreviewable power of the Court can be worse, as when it was busy invalidating the New Deal. Given precedent, I don't think th Court will, and I'd prefer we petition Congress, as has happened with the DMCA.

But who cares what I think -- here is the transcript of the Oct. 9 oral argument, which discussion well describes the essentially simple dipute.

PureFiction writes "Peer networks are gaining some attention these days given advances in much more decentralized search architectures and swarming distribution networks. Research has indicated that these decentralized networks are resistant to legal and technological attacks. The continued proliferation of broadband and wireless networking will ensure pervasive deployment of distributed peer networking infrastructure that will drive significant innovations in personal and community digital communications services."

PureFiction writes "Peer networks are gaining some attention these days given advances in much more decentralized search architectures and swarming distribution networks. Research has indicated that these decentralized networks are resistant to legal and technological attacks. The continued proliferation of broadband and wireless networking will ensure pervasive deployment of distributed peer networking infrastructure that will drive significant innovations in personal and community digital communications services."

If you had clicked through a few of the links you would have come across BitTorrent which is currently running a widescale distribution of the latest RedHat release ISO images using a decentralized swarming distribution network.

For a limited picture of what future decentralized peer networks can accomplish you need only use your imagination.

This is still relatively new technology with a lot of room for growth and extensible uses.

AND FOR THOSE OF YOU IN A HURRY... A- R- T- I- C- L-
E-. -- S-
U- M- M-
A- R-
Y-

AND FOR THOSE OF YOU IN A HURRY... A- R- T- I- C- L-
E-. -- S-
U- M- M-
A- R-
Y-

Who else do you know with a mobile wifi hotspot van ?

One thing Cringley hints at is a coming boom in popularity and capability of truly decentralized peer networks. It is the fully and highly decentralized network architectures that the Microsoft group credits most with resilience against any kind of legal, technological or political attacks.

We are starting to see some of these technologies emerge, awaiting integration into flexible infrastructure that allows fast, easy and efficient distribution of data, content or otherwise, between peers on a local and global scale.

The end result will be a combination of a number of technologies seamlessly interoperating like:

- distributed hash tables

- decentralized search

- swarming distribution

- wireless networks ... and many others.

It is nice to see the word get out: You cannot control the flow of digitial information in decentralized peer networks!

One thing Cringley hints at is a coming boom in popularity and capability of truly decentralized peer networks. It is the fully and highly decentralized network architectures that the Microsoft group credits most with resilience against any kind of legal, technological or political attacks.

We are starting to see some of these technologies emerge, awaiting integration into flexible infrastructure that allows fast, easy and efficient distribution of data, content or otherwise, between peers on a local and global scale.

The end result will be a combination of a number of technologies seamlessly interoperating like:

- distributed hash tables

- decentralized search

- swarming distribution

- wireless networks ... and many others.

It is nice to see the word get out: You cannot control the flow of digitial information in decentralized peer networks!

are there other open P2P networks out there?

Yes, the ALPINE Network uses a UDP based social discovery mechanism to implement fast, effective searches with minimal bandwidth and dual NAT support.

Some of the features include:

- High concurrent connection support (over 10,000).
- Adaptive configuration for enhanced accuracy and quality of responses.
- True peer to peer network. No hierarchy, no central servers.
- Low communication overhead (small UDP packets, no forwarding).
- Module support to allow extensions to query and transport operations.

You can read an overview of how alpine works here . There is also a frequently asked questions and plenty of developer information .

Enjoy!

are there other open P2P networks out there?

Yes, the ALPINE Network uses a UDP based social discovery mechanism to implement fast, effective searches with minimal bandwidth and dual NAT support.

Some of the features include:

- High concurrent connection support (over 10,000).
- Adaptive configuration for enhanced accuracy and quality of responses.
- True peer to peer network. No hierarchy, no central servers.
- Low communication overhead (small UDP packets, no forwarding).
- Module support to allow extensions to query and transport operations.

You can read an overview of how alpine works here . There is also a frequently asked questions and plenty of developer information .

Enjoy!

are there other open P2P networks out there?

Yes, the ALPINE Network uses a UDP based social discovery mechanism to implement fast, effective searches with minimal bandwidth and dual NAT support.

Some of the features include:

- High concurrent connection support (over 10,000).
- Adaptive configuration for enhanced accuracy and quality of responses.
- True peer to peer network. No hierarchy, no central servers.
- Low communication overhead (small UDP packets, no forwarding).
- Module support to allow extensions to query and transport operations.

You can read an overview of how alpine works here . There is also a frequently asked questions and plenty of developer information .

Enjoy!

are there other open P2P networks out there?

Yes, the ALPINE Network uses a UDP based social discovery mechanism to implement fast, effective searches with minimal bandwidth and dual NAT support.

Some of the features include:

- High concurrent connection support (over 10,000).
- Adaptive configuration for enhanced accuracy and quality of responses.
- True peer to peer network. No hierarchy, no central servers.
- Low communication overhead (small UDP packets, no forwarding).
- Module support to allow extensions to query and transport operations.

You can read an overview of how alpine works here . There is also a frequently asked questions and plenty of developer information .

Enjoy!

I still have this old DeCSS source mirror online from way back when this fight started.

I think they have quickly come to realize that the more they persue this software the more it spreads. Remember when 2600 was forced to remove their copy of the software? It immediately sprouted up on hundreds of hundreds of sites, all listed in a number of different forums (including /.)

The DMCS provides some nice protections against liability for ISP's, but the anti-reverse engineering aspects of it relating to copyright content controls are rediculous and need to be nullified ASAP.

There are a number of other interesting wireless projects which provide some cool / usefull features to 802.11 wifi networks:

NoCat Networks which implement QoS controls on user traffic giving priority to authenticated users.

Janus Wireless is working to improve mobile IP connectivity and integrated peer network services

IRIS which was mentioned recently and is perfectly suited for integration itno wireless networks for large amounts of reliable, distributed data storage.

MIT's GRID routing project which is probably the most similar.

The really cool uses will come when the integrated peer network / wireless network applications become popular an tandem with pervasive 802.11 deployment in homes and offices.

A quick Google search reveals these tidbits on DHT vulnerabilities:

This is a great example of how pervasive, open wireless hotspots can empower individual communication in unexpected ways.

It will not be long before this kind of saturation is common in all the metropolitan areas (previous studies have placed wireless growth at double the current deployment by 2005)

The biggest potential uses and applications are centered around peer network integration that support the style of personal, interactive communication people crave.

There are a few projects working towards this goal like the Janus Wireless Project . This will provide not just increased internet access reliability and throughput (using multiple AP's and simultaneous associations) but also tight integration with common peer network services, like file sharing, music broadcasting using a broadcast FEC transport and playlists, even Voice over IP.

This kind of infrastructure has to be built by philantropist coders, as the business model is lacking, however, this makes it all the more tuned to what users will want, and the resulting networks in full control of those who generously provide the hardware and network connectivity (such as the Personal Telco Project .

I can only begin to imagine the possible applications of a robust, open wireless network coupled with integrated peer network services and good internet connectivity. This will be one of the most interesting and innovative areas of growth in the near future.

I doubt that developers of those free p2p applications have gave much thought to efficiency

Some of us have. Search is much of the bandwidth in peer networks is wasted (downloads are downloads, but search can eat up a lot of bandwidth for little return)

There are some efficient, effective peer network search apps currently in development. Hopefully we can eventually leave gnutella and kazaa in the past and move on to more open, efficient networks...

This is news? People have been
scanning wireless
networks
for a long time now...

I am seeing a lot of confused comments in this thread, so I will throw in my $0.02.

Disclosure: I wardrive on occasion. I keep a list of access points that I find while driving. Currently in excess of 1,000 for the Portland, OR area.

1. Why wardriving? Everyone has their reasons. Mine are security related. Myself and a small group of other local wifi enthusiasts enjoy passive monitoring to identify security weaknesses. We also inform insecure node operators of the fact that their networks are wide open.

We have found a number of extremely sensitive, wide open access points operated by city and state governments, corporations, and home users. By this I mean networks that are obviously not intended to be public.

If your government has weak security on sensitive information, this can affect you directly (which means Us, the wardrivers too). So we like to notify them of the vulnerabilities and give them information on fixing the holes. Sometimes we get paid to do this.

[You will notice the results page is missing GPS coordinates. This is intentional, as there are those out there who would take advantage of unsecured networks]

This is also usefull for identifying trends and generating usefull statistics.

2. How do you really secure a wireless network? You have a few options: Basic security and high security.

Basic Security: Enable MAC ID restrictions, allowing only those cards with a specific MAC id to connect to the network. Also turn on 128bit WEP encryption. You can switch to a lesser used channel, like 1 or 11 if you wish.

Please note that this is still easily circumvented with the right tools, like AirSnort and MAC ID spoofing. Despite this, most people will find a network in this state and move on. It significantly raises the barrier to entry.

High Security: Install a VPN with very good passwords or preferably something like SecureID cryptographic tokens. This is the only way to be truly secure, where truly secure is as good as the firewall VPN combo you use at work.

The problem is that gnutella's reliance on broadcast forwarding and indirect communication will always allow rogue peers to exploit bandwidth or queries in the network.

There are a number of alternative discovery mechanisms which do not suffere from these kinds of architectural problems.

For example, NeuroGrid and alpine both use social discovery and peer profiling to prevent bandwidth hogging or query spamming.

There are also hybrid network that use super peers like the Kazaa and Grokster clients.

There is only so much you can do to improve a flooding broadcast architecture. Gnutella will always have some kind of bandwidth and query problems no matter how optimized the clients become.

Use a non random walk (i.e. tuned to a specific domain or set of preferences) and let it walk the network with a lightweight UDP protocol:

cubicmetercrystal.com/alpine/

The conservative use of bandwidth with an intelligent search mechanism can provide scalable decentralized search for peer networks of any size.

A copy of the Flash animation is now available as well:

http://cubicmetercrystal.com/eff_tinsel.swf

I have a copy at:

http://cubicmetercrystal.com/eff_tinseltown_club.m p3

The EFF is getting /.'ed pretty good, so try to use some kind of mirror if possible.

There are pleny of other open p2p products.

Freenet scaleable, not vaporware, very much beta.

Alpine.
based on trust
Gnunet. Sounds very open. based on electonic money. also seach for gnet.

chord Very efficient to find files.

distrinet At this stage: vaporware.(there is code....) But if you look at the description it beats any p2p software!

But in the end the network with the most data (gnutella/kazaa) will be used. Note that users will switch networks very quickly. Look what happened to napster.

There is a Google Experiment underway to see if search results for Scientology can be reclaimed.

Only a few thousands links more needed... :-)

Circle is cool, but it is really a subset of Chord, with searching kind of hacked on top of a hashing index system (i.e. search is implemented by tying keywords to hashes and distributing this hash space.)

This means that high peer churn rates, hot spots in popular keywords, spamming keywords, etc, all make this a rather vulnerable and fragile implementation of searching. It probably is better than gnutella, but that isnt saying much, and it certainly does not mean it is 'infinitely scalable'. The real world is a harsh place...

If you want a scalable, distributed search/discovery mechanism for large peer networks here is your recipe:

1. Build on a base of juicy lightweight UDP messaging. This allows you to send messages directly to peers, circumvent NAT's, and handle many thousands of virtual connections.

2. Sending queries to many thousands of peers is still a large task, even if only small packets are sent directly. Must optimize this.

3. Optimize by using a social discovery mechanism to keep track of which peers are good at answering your queries. Query them first and more often than other peers. Call this peer ranking the 'relative quality' of the peer.

4. Optimize further by halting the query once a sufficient number of matches are found. This way you only need to query a handfull of peers (maybe 10, maybe 200) to complete a query.

5. Finally, perform transitive introduction using the high quality peers in your group. This way you use peers with a high quality to find new peers, and it is highly likely that they will be high quality peers as well.

This is how the ALPINE Network works, and it scales. The number of connections any peer may have is solely up to their discretion, based on bandwidth and memory resources. All communication is direct, and every peer is in direct control over his own resources, which makes for a very robust environment.

There are a number of details, the above simply a 30,000ft description. If you are interested you can read more in the ALPINE Overview and the ALPINE FAQ .

One last comment, this stuff is no longer vaporware :-)

Circle is cool, but it is really a subset of Chord, with searching kind of hacked on top of a hashing index system (i.e. search is implemented by tying keywords to hashes and distributing this hash space.)

This means that high peer churn rates, hot spots in popular keywords, spamming keywords, etc, all make this a rather vulnerable and fragile implementation of searching. It probably is better than gnutella, but that isnt saying much, and it certainly does not mean it is 'infinitely scalable'. The real world is a harsh place...

If you want a scalable, distributed search/discovery mechanism for large peer networks here is your recipe:

1. Build on a base of juicy lightweight UDP messaging. This allows you to send messages directly to peers, circumvent NAT's, and handle many thousands of virtual connections.

2. Sending queries to many thousands of peers is still a large task, even if only small packets are sent directly. Must optimize this.

3. Optimize by using a social discovery mechanism to keep track of which peers are good at answering your queries. Query them first and more often than other peers. Call this peer ranking the 'relative quality' of the peer.

4. Optimize further by halting the query once a sufficient number of matches are found. This way you only need to query a handfull of peers (maybe 10, maybe 200) to complete a query.

5. Finally, perform transitive introduction using the high quality peers in your group. This way you use peers with a high quality to find new peers, and it is highly likely that they will be high quality peers as well.

This is how the ALPINE Network works, and it scales. The number of connections any peer may have is solely up to their discretion, based on bandwidth and memory resources. All communication is direct, and every peer is in direct control over his own resources, which makes for a very robust environment.

There are a number of details, the above simply a 30,000ft description. If you are interested you can read more in the ALPINE Overview and the ALPINE FAQ .

One last comment, this stuff is no longer vaporware :-)

Circle is cool, but it is really a subset of Chord, with searching kind of hacked on top of a hashing index system (i.e. search is implemented by tying keywords to hashes and distributing this hash space.)

This means that high peer churn rates, hot spots in popular keywords, spamming keywords, etc, all make this a rather vulnerable and fragile implementation of searching. It probably is better than gnutella, but that isnt saying much, and it certainly does not mean it is 'infinitely scalable'. The real world is a harsh place...

If you want a scalable, distributed search/discovery mechanism for large peer networks here is your recipe:

1. Build on a base of juicy lightweight UDP messaging. This allows you to send messages directly to peers, circumvent NAT's, and handle many thousands of virtual connections.

2. Sending queries to many thousands of peers is still a large task, even if only small packets are sent directly. Must optimize this.

3. Optimize by using a social discovery mechanism to keep track of which peers are good at answering your queries. Query them first and more often than other peers. Call this peer ranking the 'relative quality' of the peer.

4. Optimize further by halting the query once a sufficient number of matches are found. This way you only need to query a handfull of peers (maybe 10, maybe 200) to complete a query.

5. Finally, perform transitive introduction using the high quality peers in your group. This way you use peers with a high quality to find new peers, and it is highly likely that they will be high quality peers as well.

This is how the ALPINE Network works, and it scales. The number of connections any peer may have is solely up to their discretion, based on bandwidth and memory resources. All communication is direct, and every peer is in direct control over his own resources, which makes for a very robust environment.

There are a number of details, the above simply a 30,000ft description. If you are interested you can read more in the ALPINE Overview and the ALPINE FAQ .

One last comment, this stuff is no longer vaporware :-)

Circle is cool, but it is really a subset of Chord, with searching kind of hacked on top of a hashing index system (i.e. search is implemented by tying keywords to hashes and distributing this hash space.)

This means that high peer churn rates, hot spots in popular keywords, spamming keywords, etc, all make this a rather vulnerable and fragile implementation of searching. It probably is better than gnutella, but that isnt saying much, and it certainly does not mean it is 'infinitely scalable'. The real world is a harsh place...

If you want a scalable, distributed search/discovery mechanism for large peer networks here is your recipe:

1. Build on a base of juicy lightweight UDP messaging. This allows you to send messages directly to peers, circumvent NAT's, and handle many thousands of virtual connections.

2. Sending queries to many thousands of peers is still a large task, even if only small packets are sent directly. Must optimize this.

3. Optimize by using a social discovery mechanism to keep track of which peers are good at answering your queries. Query them first and more often than other peers. Call this peer ranking the 'relative quality' of the peer.

4. Optimize further by halting the query once a sufficient number of matches are found. This way you only need to query a handfull of peers (maybe 10, maybe 200) to complete a query.

5. Finally, perform transitive introduction using the high quality peers in your group. This way you use peers with a high quality to find new peers, and it is highly likely that they will be high quality peers as well.

This is how the ALPINE Network works, and it scales. The number of connections any peer may have is solely up to their discretion, based on bandwidth and memory resources. All communication is direct, and every peer is in direct control over his own resources, which makes for a very robust environment.

There are a number of details, the above simply a 30,000ft description. If you are interested you can read more in the ALPINE Overview and the ALPINE FAQ .

One last comment, this stuff is no longer vaporware :-)

PureFiction is coordinating this convention. There seems to be a mentions of Alpine. There was a story about it before with threads containing a little history of PureFiction.

Some would call it "shameless self promotion".

I'd just call it being stoked about what you're doing

What I find most interesting are the kinds of projects that have sprung up in Gnutella's wake. Many of these started out as attempts to improve Gnutella, and have since moved on (the Gnutella Next Generation working group never really materialized into anything)

We had napster and one extreme, gnutella at the other, and in the middle a re a number of partially centralized systems with super peers like Fast Track, such as:
Open FT
JXTA Search
GNet
NEShare

and many others...

Then there are the alternative projects that use an entirely different mechanism. For example, social discovery as implemented in:
NeuroGrid
ALPINE

Or distributed keyword hash indexes like:
Chord
Circle
GISP
JXTA Distributed Indexing

And many others as well.

The coming year(s) will see a lot of maturity in these areas, and searching large peer networks will become ever more efficient over time. Gnutella showed us the possibilities of a fully decentralized model, and refinements of its underlying architecture can produce vastly better solutions.

2002 will be an interesting year for peer networking applications...

There is another method for ensuring cooperation and fair behavior in peer networks. And it works the same was as the method described.

It is called social discovery, and it works by having each and every peer create a view of the network that suits their interests and needs. In such an environment, the freeloading peers will not be viewed as valuable peers and will be dropped from your peer group(s); no longer used, and no longer using your resources.

On the flip side, there is a strong incentive to become a better, more reliable peer yourself, as the quality of peers you can associate with is directly related to how they perceive *your* quality to them.

If you want to be able to tap better, higher quality peers, then you should keep your node available longer, more often, and also share more resources (whatever they may be).

The project I am working on that implements this social discovery mechanism is called the ALPINE Network and there is also another social discovery based project called NeuroGrid.

I am biased towards this kind of approach, but I think it provides the best long term solution to resource discovery / searching in large peer networks.

In the future, I imagine most peer to peer systems will use node discovery systems like ALPINE to discover nodes listening on any port and possibly even using any of the major layer 4 protocols.

All we need to compliment Freenet is a decentralized resource discovery/search infrastructure.

Then all arguments in the afore mentioned article disappear. The sole remaining thorn will be port blocking / filtering by ISP's.

And even this is a technicality, not a show stopper.

The ALPINE Network uses a flat direct connection network for searching/discovery operations.

There are a few tweaks which improve the efficiency of this type of network, such as a reputation/affinity value attached to peers to keep you connected to the best, while quickly filtering out the worst or dissimilar.

The communication is multiplexed over a single UDP port and can handle hundreds of thousands of concurrent connections at the lowest layer. (higher level ALPINE connections require more overhead, and are restricted to 10,000 to 100,000 depending on user preference)

At any rate, my point is that you can use a simple packet routing architecture like IP to accomplish a flat, large, directly connected network that is usable.

If you want higher performance, more efficiency, and greater throughput you would need to start experimenting with some of the advanced network architectures you mention. However, the chance of such a network reaching the masses any time soon is pretty slim. :/

OTOH, the bandwidth usage of gnutella searches vs. the total bandwidth available is a very small ratio.

This is probably true. Most gnutella clients would be on smaller DSL or modem links. These would have a hard time overwhelming bandwidth.

In most cases the problem occurs between different ISP level routers or at the client's link itself.

If the traffic on the multicast channel was greater than 56k consistently, the modem clients TCP connections would starve, which would not be good from an end user perspective.

If the traffic was such that a small ISP was using most of their bandwidth (probably outgoing for the multicast to destinations) then all clients of that ISP would be having problems as well.

It really does get pretty tricky quickly. however, there is good progress being made in this area, and perhaps with IPv6 we will begin to see multicast working on a larger scale (I hope so!)

The project I am working uses unicast to multiple destinations that acts very similiar to a multicast. However, I had to build some very elaborate mechanisms into the protocols to keep congestion and TCP starvation from occuring as well as allowing varied bandwidth links the ability to communicate without the fast ones overwhelming the slower ones.

This is the ALPINE Network and the more extensive information about congestion avoidance is here

OTOH, the bandwidth usage of gnutella searches vs. the total bandwidth available is a very small ratio.

This is probably true. Most gnutella clients would be on smaller DSL or modem links. These would have a hard time overwhelming bandwidth.

In most cases the problem occurs between different ISP level routers or at the client's link itself.

If the traffic on the multicast channel was greater than 56k consistently, the modem clients TCP connections would starve, which would not be good from an end user perspective.

If the traffic was such that a small ISP was using most of their bandwidth (probably outgoing for the multicast to destinations) then all clients of that ISP would be having problems as well.

It really does get pretty tricky quickly. however, there is good progress being made in this area, and perhaps with IPv6 we will begin to see multicast working on a larger scale (I hope so!)

The project I am working uses unicast to multiple destinations that acts very similiar to a multicast. However, I had to build some very elaborate mechanisms into the protocols to keep congestion and TCP starvation from occuring as well as allowing varied bandwidth links the ability to communicate without the fast ones overwhelming the slower ones.

This is the ALPINE Network and the more extensive information about congestion avoidance is here

Another great site is Peertal at http://www.peertal.com/ for all sorts of news about peer to peer projects and news.

Ben Housten has a good page with ideas and links at http://www.exocortex.org/p2p/index.html

The Peer to peer working group has their site at http://www.peer-to-peerwg.org/

You may also want to check out the Orielly OpenP2P page at http://www.oreillynet.com/p2p/

And of course, I need to shamelessly plug my open source decentralized searching network, the ALPINE Network

I am working on a project that may satisfy a number of the intended features you mention.

For exmaple...

As a straight-peer-to-peer network grows, it becomes saturated with traffic. Requests are sent, propagated, and choke the entire network of peer-to-peer clients, usually at the lowest bandwith level.

I saw this first hand when using a modified Gnutella client to monitor the types and number of queries occuring on the network. The vast majority was crap or outright maliscious, and it brought my 1.5Mbps downstream DSL line to a crawl.

But it is possible to have a fully decentralized network that is bandwidth friendly. I am working on it now.

If you try to run this through an established client server system, lawyers decend like flocks of carrion birds.

Another important asecpt of this network is that searching and actual transfer are decoupled. When you find some hits to your query, you are returned a list of locators for that resource. These may be simple HTTP style, or they may be Freenet SHA-1 hash keys. Which means that you can find the content you seek in an open, decentralized network. And the obtain it (if it is senstive data in your country, etc) via a secure, anonymous manner like Freenet.

And finally, the most important aspect of this network is that it is adaptive to your preferences. A very large problem with Gnutella and other peer based networks is spam and irrelevant results. With this network you continually add peers who respond with relevant, quality information, and drop other peers who provide no value.

At any rate, if you are interested, you can read more about this project. It is called the ALPINE Network and the main page is at http://cubicmetercrystal.com/alpine/

I am working on a project that may satisfy a number of the intended features you mention.

For exmaple...

As a straight-peer-to-peer network grows, it becomes saturated with traffic. Requests are sent, propagated, and choke the entire network of peer-to-peer clients, usually at the lowest bandwith level.

I saw this first hand when using a modified Gnutella client to monitor the types and number of queries occuring on the network. The vast majority was crap or outright maliscious, and it brought my 1.5Mbps downstream DSL line to a crawl.

But it is possible to have a fully decentralized network that is bandwidth friendly. I am working on it now.

If you try to run this through an established client server system, lawyers decend like flocks of carrion birds.

Another important asecpt of this network is that searching and actual transfer are decoupled. When you find some hits to your query, you are returned a list of locators for that resource. These may be simple HTTP style, or they may be Freenet SHA-1 hash keys. Which means that you can find the content you seek in an open, decentralized network. And the obtain it (if it is senstive data in your country, etc) via a secure, anonymous manner like Freenet.

And finally, the most important aspect of this network is that it is adaptive to your preferences. A very large problem with Gnutella and other peer based networks is spam and irrelevant results. With this network you continually add peers who respond with relevant, quality information, and drop other peers who provide no value.

At any rate, if you are interested, you can read more about this project. It is called the ALPINE Network and the main page is at http://cubicmetercrystal.com/alpine/

• Alpine - Adaptive Large-scale Peer2peer Information NEtworking
• ANAP -- Anonymous Napster
• AudioGalaxy Satellite
• Bearshare -- Powerful Gnutella client
• Blocks -- open source distributed sharing client with encryption
• Carracho -- MacOS file sharing program
• CuteMX
• Direct Connect
• DFSI -- Distributed File Sharing over IRC
• Espra
• FileSwap
• Filetopia
• FreeNet
• Gnutmeg -- peered file sharing system
• gnutella -- distributed P2P file sharing tool
• Hotline
• IMesh
• Jungle Monkey -- open source
• KaZaA - Windows Media Desktop
• Konspire -- open source distributed client in java
• OFSI -- Open File Sharing Initiative
• ProjectELF -- anonymoys distributed sharing system
• SongSpy
• Spin Frenzy
• Splooge -- P2P file sharing by file extension
• Swapoo -- Napster like service for sharing video game ROMs
• Swaptor -- Online File Sharing Community
• VNN - secure file sharing app

One of the weak points of the multi-tool strategy may be the search engine. The RIAA may be able to convince a judge that searches could be filtered based on songs.

Good point, and I have been working for months on a fully decentralized, open source searching network called the ALPINE Network which performs searching, and only searching.

The actual transfer of resources is done via other networks, like Freenet or Swarmcast, FTP, etc.

The previous poster had the same ideas in mind, namely, provide a decentralized, legally safe peer based searching network, and then use whatever you wish to actually get content/resources.

The searching is the most vulnerable part, and hence the reason I am pushing a fully decentralized network so hard.

This was an excellent article, and towards the end, which some of you may have missed, is a list of things you can do as a peer-to-peer developer or designer to prevent legal liability. These are very interesting suggestions...

1) Your two options: total control or total anarchy.

So, either a secure and monitored Napster or an efficient Gnutella are the two most resistant architectures. This has pretty broad implications.

2) Better to sell stand-alone software products than on-going services.

Assuming that you are using a decentralized model. A centralized service is by nature an ongoing service.

3) Can you plausibly deny knowing what your end-users are up to?

Only in a decntralized or mostly decentralized network. If you try to intentionally make it hard to know what your users are doing, you're again opening yourself up to liability.

4) What are your substantial noninfringing uses?

This applies mainly to a centralized service. And in fact, you really need to have ONLY noninfringing uses if you are turning a profit from the network. (vicarious liability)

5) Disaggregate functions.

For example, use one service to locate content. Use another service to transfer content, preferably in an anonymous, secure fashion. Etc. This is what the ALPINE Network is designed to accomplish.

6) Don't make your money from the infringing activities of your users.

The section on vicarious infringement which this relates to, is rather troubling. If you are a centralized service making money from its popularity (i.e. Napster) you need to have very stringent controls on what your users are doing. Filename filtering is only the very first step, and proactive monitoring is required.

7) Be open source.

Nuff said!

8) Do not be a direct infringer: make and store no copies.

This includes caching content! The DMCA safe harbor rules will not apply to you unless you have gone through a number of hoops to do so. (After reading through the requirements, only ISP's can do this. Anything riding on top of an ISP is pretty much screwed.)

9) Do not build any "circumvention devices" into your product.

Like including a DeCSS filter for downloaded movies.

So, in short, I think a lot of the peer based network that have sprung into recent existance need to chew on this for a while, as many of them do not comply with what is need to be truly safe from legal attack.

Also, this is assuming that current laws remain unchanged. There is a very real possiblity that parts of the DMCA or copyright law will be modified in a more linient manner. Don't hold your breath ;)

You mean, if I were to Post a Link to the DeCSS Source Code online then I could be charged with distributing illegal content?

Well, you know what? If no one posts links and provides the content then they have already won without a battle.

I may or may not suffer severe repercussions from my actions, but it will be worth providing the information, and perhaps showing my disdain for severely unconstitutional laws passed in congress.