Skip to Content.
Sympa Menu

bluesky - Re: Test message

bluesky AT lists.ibiblio.org

Subject: Global-Scale Distributed Storage Systems

List archive

Chronological Thread  
  • From: Wei Dai <weidai AT eskimo.com>
  • To: bluesky AT franklin.oit.unc.edu
  • Subject: Re: Test message
  • Date: Thu, 8 Feb 2001 23:13:56 -0800


I've changed the list HELLO message to include the list address.
Apparently the email server at ibiblio.org hasn't been set up to forward
bluesky AT ibiblio.org to bluesky AT franklin.oit.unc.edu, so please use the
latter address until we get that sorted out.

On Thu, Feb 08, 2001 at 03:34:41PM -0500, Hal Finney wrote:
> One of the issues which has been discussed on the Freenet mailing list is
> the difficulty of engineering a system suitable for use in a country where
> the government is restricting access to the net. A good example today is
> China, but of course in the future more countries may have restrictions.

I believe the solution to this problem is regulatory arbitrage and
onion-routing type techniques. If we have a system where the owner of the
storage hardware can decide what to store, censored data will migrate
to nodes where they are not controlled. For people who are inside the
controlled areas, the question is how to communicate with nodes that are
blocked by the government firewalls. If the system is popular enough so
that the government cannot afford to block every single node that's part
of it, people inside can always reach any outside node by connecting to a
non-blocked node and tunnel to the target node through it.
So basicly we can present the censors with a binary choice:
either block the entire system or none of it.

You can consider this as an argument for building a general purpose
global-scale distributed storage system that happens to be censorship
resistant, rather than one that's designed to be censorship resistant at
the cost of efficiency. The latter will not become popular enough to make
it too expensive to block entirely.




Archive powered by MHonArc 2.6.24.

Top of Page