[CIMC-working] (content server topologies) FW: [Imc-strategies] distributed systems, bomb proofing our resources

Chris Kaihatsu ckaihatsu at myrealbox.com
Thu, 16 Jan 2003 00:12:26 -0600


------ Forwarded Message
From: Michel <mine@reimon.net>
Date: Sun, 12 Jan 2003 17:17:16 +0100
To: <imc-strategies@lists.indymedia.org>, <imc-tech@lists.indymedia.org>
Subject: Re: [Imc-strategies] distributed systems, bomb proofing our
resources

hi.

Am 12.01.2003 5:25 Uhr schrieb "anarch3m" unter <anarch3m@lycos.com>:

> I have before asked about the feasability of developing some bombproofing for
> our wires.  I am again concerned that the period we are entering will bring us
> trolls and worse.  I am concerned that we will be hacked.
> 
> I had a short talk with a fellow here today.  He said that what I was
> describing was, or was very similar to Gnutella (spelling?)  I am wondering if
> there is any merit/plausability to the tought of distributing our wire in what
> I have read described as a "nearly un- removable from the web" system (wired
> mag) 
> 

SUMMARY:
there are some possible solutions to this, which are already in development.
but they have serios disadvantages, too. basically: systems with more safety
offer less accessability. with some applications like swaping music that's
no problem. if you don't find this wonderful new song today in the
gnutella-network, you may find it tomorrow. but a NEWS-wire has to be up to
date and provide easy access to news.

for those who are interested in this technologies i'd like to explain three
examples as brief as possible, just to give non-techies an overview. it's
important that such an discussion is not left to the programming community
but also picked up by those who provide the content.




1. freenet distributes files across the participating users (called nodes).
whenever nodes are online, files may be saved on their harddisk or retrieved
from there. nodes don't know what kind of data they store (which means we
would probably also store some nazi stuff and child porn). often requested
files are duplicated on more nodes, which increases accessability and
safety.
submission of a file to the system is anonymous. on submission you get an
id-key, which allows you to find the file again. links work.
so we could advertise the key of our main site like a homepage and publish
the links to our articles on this site. very much like the www works.
but: it's incredible slow. i mean really   s    l    o    w. and without the
right key you'll never find any information.
furthermore users have to download the freenet-software, which might be
undesireable in some countries.
conclusion: freenet might be a solution to save our data and retrieve it
AFTER a raid, but it's no way to keep readers informed DURING an attack.


2. gnutella is the technology behind music-swapping-software like limewire,
KaZaA and morpheus. here too every user is a node which stores data on his
harddisk. but with gnutella the user has control over the content, he hosts
all files in a dedicated directory and can delete or manipulate this data
and add new files.
nodes connect automatically with other nodes they find online "out there",
called neighbors. that's a random process, you never know who you'll connect
to. if the user requests a file, the node asks its neighbors. if they don't
have the file stored, all of them ask their other neighbors, and all of them
ask their neighbors and so on - for a maximum of seven hops. if the file
hasn't been found then, the search stops to prevent flooding of the net. so
the song you're looking for might be out there, but outside your range. if
you connect a little bit later, you find new neighbors, they have new
neighbors, the net has changed and you may find a dozen copies of the
song...
this works pretty good if a song or an article is popular and downloaded and
then provided very often. but if there are only one or two copies around, it
might be impossible to find them.
but the biggest disadvantage: you have to know what you are looking for. you
need something to search for. if for example a country would invade iraq or
north korea or venezuala right now, you would never get this information
unless you search for it - but you wouldn't search for it, because you don't
know it happend. 
it's possible to create a "table of content-file" and distribute it. but
after each update there would be hundreds of old versions on various
harddrives all over the world.
conclusion: gnutella is a good thing to share background data and distribute
backups, but it's not possible to run a newswire.


3. good old napster. killed by the music industry, but it might be a good
solution for us. 
napster worked with a central database. connecting nodes told this database,
which files they provided on their harddisk. someone looking for a specific
file asked the central database and got a list of nodes providing this file.
it would be possible to connect to such a database with an id like "global
indymedia main node", where an updated table of content could be offered.
the weak point is obvious: the central database. knock it out, and the
system is down (like napster). but napster is a company and there are
solutions for a network like us. first we could switch to a new server in
another country. within seconds indymedia would be accessible again.
even if "they" take out all servers, we're not lost: the servers may be
confiscated - but the information itself, the articles and pictures, are
stored on thousands of harddisks in dozens of countries. and then, when
surviving the moment is more important than easy access, we could use
gnutella technology.
conclusion: music was the wrong content for this wonderful idea. together
with a gnutella backup system it's perfectly suited for subversive
journalism.




discussion on this topic should go on. walt is right: we will be hacked one
day. if not, we're doing something wrong... ;)

respect,
michel








_______________________________________________
Imc-strategies mailing list
Imc-strategies@lists.indymedia.org
http://lists.indymedia.org/mailman/listinfo/imc-strategies


------ End of Forwarded Message