On Friday 09 May 2008 16:11, Dan Bruce wrote:
> I have two idea's to add the first is increased usage, bundling this with a
> secondary tool that would have more universal use would expand the network
> function.
Possibly, however bundling Freenet with anything is problematic, because of
the overhead (in every sense):
- Exchanging noderefs.
- CPU/disk/memory usage. (CPU usage is low, memory usage will improve
significantly in 0.7.1).
- The political/ideological overhead is IMHO rather significant: Your computer
could have encrypted child porn / encrypted terorrist training manuals /
encrypted Tibettan photographs etc on it.
However, I'm by no means opposed to finding Killer Apps for Freenet.
> Part of the system depends on the number of users to help with
> obscurity; the more people in the network the less likely to be able to
> track a single source.
True, more users is always better.
>
> Adding in an "add to the cause tool" that the everyday user can run being
> able to donate both cpu - drive and bandwidth would expand the function. The
> concept is basically Gramma and Grampa may not be using the system as a free
> net assured of the privacy but would be fairly willing to run a background
> process that gives them something upfront in terms of data - weather report,
> a PRIVATE IM that is secured to talk with the grand kids etc and also
> provide both the space and bandwidth to the cause. The distributed
> processing projects have generated some of the largest Super Computer ideas
> on earth, people will give to a cause even if they are not using it.
Perhaps. Most grandparents' politics would likely exclude Freenet though.
Certainly not all, judging by even some folk who've been active on this list.
>
> The "Add To The Cause" factor as long as it remained in the back ground was
> clean a single icon in the tray with a focus on trying to remain as minimal
> impact on the persons machine and internet as possible. Something that is
> able to limit its use to off times as to not impact the users, and able to
> keep bandwidth limits in mind (off peak and not exceeding the max up/down)
> for the people willing to add to the cause.
We should have a systray icon. One focus of 0.7.1 will be to reduce the memory
usage significantly, and this should also help with CPU usage etc. More
accurate bandwidth limiting, and auto-detection of bandwidth usage, is also
planned. Bandwidth scheduling is being actively worked on.
>
> A secure chat tool (mod the Jabber Client and Server to run on the freenet)
> would give the user something back for adding to the cause if they are not
> fully participating. The secure IM would also be likely something that would
> see increased people using it for the secure chat functions alone.
IM between darknet peers is feasible, it's just nobody's done it yet. Having
said that, the only real benefit to doing it over Freenet is the fact that
your conversations are not visible on passive traffic analysis (because
Freenet is using lots of bandwidth for other things).
>
> The second is with regard to the long term storage issue.
>
> The Hash functions being used in the other P2P tool breaking a file into
> 128k chunks doing a hash and the file ID being a Hash of the Hash has great
> advantage, both in ID of the file and being able to identify and distribute
> clear ID'd chunks.
>
> Including a means to allow adding in the older materials requested from
> CD/DVD copies users have burned would give the project hard storage in
> the form of sectors that are CD or DVD sized. The addition of a tool that
> helps with off line storage and location for users would increase the use of
> the feature. For the user to be able to scan in a CD/DVD for use in a
> location database (generating the file hashes and such) as well as the users
> cd/dvd numbering to locate gives the user an incentive.
>
> What this would give is the ability for the system to request OLD
> information from the freenet drive, having 100 or 1000 people protected by
> the anonymous factors would see a willingness to insert the media for
> upload, also in terms of protection the system having 100 or 1000 copies
> available the speed on file transfer increases along with the obscurity.
Okay so we are talking about either:
- High latency insert on demand, whether manual or client layer.
- Some network level mechanism that equates to the same thing ("inverse
passive requests" for example, although they assumed lower latency).
Basically this becomes a manually operated offline storage system (non-manual
systems have robots and libraries of tape drives).
It *might* be possible to implement such a thing within the context of
Freenet, however it's probably not something that we'll see within the 0.7 or
0.8 timeframe. For the time being, manual insert on demand is probably it:
somebody asks on FRost for a given file, and somebody else inserts it.
>
> It does essentially become a double blind function the request for an older
> File can see 1000 copies where it actually comes from at the source level is
> unable to be defined, if 300 blocks are needed and 1000 copies are put into
> Rom Drives around the world not only is the speed present the 1000 people
> putting in the older CD/DVD would not even know if their copy was used.
Of course they would know, they only put it in the drive because the system
asked them to.
>
> It would be asking the user to put up a CD size or DVD size or both temp
> drive cache, and the other further blind function is with the system being
> able to ask for DVD #8 from the users archives there is no way to know even
> what file was requested unless it is a 4 gig file on the DVD
I'm not sure this is cost effective right now. DVD-R is cheap, but bulky, and
relatively small (4G for the cheap ones, 8G for the big ones). Blu-ray disks
are too expensive for this sort of usage. Hard disks are online, cheap, and
large.
>
> The advantage this offers is not having to re-propagate an old file into the
> system if 100 copies can be brought online by request not only has the speed
> amplified 100X the bandwidth savings also have in being able to distribute
> it so the source is obscured.
>
> I have some idea's on implantation and indexing though I have not
> programmed in years to be able to add to this in coding at this time.
>
> For now its just a concept that the group will likely be able to add to
> before trying to nail down the specifics.
>
> Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/tech/attachments/20080513/16f80093/attachment.pgp>
