On Thu, Jan 13, 2011 at 8:35 PM, Daxter <xovatdev at gmail.com> wrote: > On Jan 7, 2011, at 7:17 AM, Alex Rollin wrote: >> I'd like to share my uses cases for a Darknet in a neighborhood >> wireless network. ?Please feel free to tear them apart. ?I'm wondering >> where and how Freenet can be "the filesharing program" of choice, > I just wanted to say thank you for trying to set something like this up.
Thanks for your response! This is a generalized solution, in a sense, but it is specifically for countries where the connection to trans-oceanic or inter-continental fiber is prohibitively expensive. One country I had in mind is Indonesia. Average speed down from US or Europe is 20Kbps. It's previous bandwidth, so locating files in distributed storage in a national and redundant network seems sensible. > > >> >> Use Cases >> >> Use Case: Adding a new Video and Updating the Index >> >> The Trainer signs into their file sharing program >> They choose a video to share and load the video >> They receive a key that is a reference link to the video >> The user stores this key in an html file >> The user shares the new version of the html file > > This should work just fine. If a Trainer wants their files to be available to > the outside world, they should publish a Freesite with links to them. If the > bandwidth usage is too great, however, then some other way to host the file > links must be used. One possibility is to run a simple web server that loads > the plain html site for anyone that connects to the wifi network so that they > can copy/paste the file refs into their Freenet node and download the files. > With this set-up there would be no chance of the outside world consuming your > bandwidth because they wouldn't have the file refs to download them. So, let's assume that the cafe owner has this box upon which he can insure that regular requests are made for certain files. Perhaps he could script regular access to the files to insure they are available on this machine. The machines in the cafe where a user requests a file are basically wiped every day. However, they are Very close to the cafe server and could request files from that server as needed and get them quickly. The friend key for this server would be permanently loaded to the cafe user machine. > > The admin account should be the only one that has access to Freenet, both > starting up and shutting down, and changing preferences. Unfortunately, I do > not know of a way to prevent guest users from changing the node's > preferences. Currently anyone that has access to 127.0.0.1:8888 (any user of > that computer) can do serious damage to the node (Freenet software, not the > OS or hardware ((( I hope))) ). I vaguely remember that some of us are > pushing to create "accounts" on a node so that multiple people can use it. At > any rate, it would be useful to create an admin account to secure control of > the node's preferences. > Admin options seem like a useful thing. And local accounts. > > This is a big problem that needs to be fixed before you or anyone else try > setting up a Freenet cafe. Agreed. > Currently, to my understanding, a new user must connect to 10 friends before > they can implement the maximum security setting. Though with such a > tight-knit community that shouldn't really be necessary. > Yes, and "guaranteed availability" is part of the design. It's got potential for failure, as do all systems, but it's one way of doing it, to have a "server". > Earlier you mentioned "a few trusted individuals" that everyone would connect > to. Would new users get their friend code as well? > Yes, in general. These would be the "cafe server with 2TB" and anyone else who wanted to put one up. I was looking into DC++ and a few other services. I'm still working out the best way to do this. Ideas welcome! The goal is to make sure files that are needed are available and to "decouple" the clients and servers so that they are as anonymous as possible. They are certainly related through a key, and limiting it to that is deal. I'll need to think more about the addressing, too. Alex
