eof-dev — Only join this if you want to code.

Re: [Eof-dev] EOF Mail config

[David F. <dav...@ya...>]

On Monday 23 July 2001 21:00, David Findlay hit his keyboard with his head 
and the result was this:
> Could someone please send me a complete eof mail config. Like what to put
> in poprc and smtprc etc. Also is anyone using Fmail now?

Anyone - could someone who has eof mail working please email me what their 
config is in .poprc and smtprc please? I want to get this thing going.

David

[Eof-dev] EOF Mail config

[David F. <dav...@ya...>]

Could someone please send me a complete eof mail config. Like what to put in 
poprc and smtprc etc. Also is anyone using Fmail now?

David

Re: [Eof-dev] Beowolf/Distributed processing

[toad <ma...@to...>]

On Thu, Jul 19, 2001 at 10:35:06AM -0700, Jesse Wolfe wrote:
> greetings, all.
> 
> i'm not sure if there's been any thought about it, but
> i'd like to work on distributed processing over
> freenet.
> any thoughts?
Brute force DES-40 over freenet for helping people crack
encrypted Office docs anonymously?
> 
> --AJW (jes5199)
> 
-- 
Always hardwire the explosives
        -- Fiona Dexter quoting Monkey, J. Gregory Keyes, Dark Genesis

Re: [Eof-dev] Beowolf/Distributed processing

[Timm M. <har...@ru...>]

You know that you're insane, right?  Welcome to the club.

----- Original Message ----- 
From: "Jesse Wolfe" <je...@ya...>
To: <eo...@li...>
Sent: Thursday, July 19, 2001 12:35 PM
Subject: [Eof-dev] Beowolf/Distributed processing


> greetings, all.
> 
> i'm not sure if there's been any thought about it, but
> i'd like to work on distributed processing over
> freenet.
> any thoughts?
> 
> --AJW (jes5199)
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail
> http://personal.mail.yahoo.com/
> 
> _______________________________________________
> Eof-dev mailing list
> Eo...@li...
> http://lists.sourceforge.net/lists/listinfo/eof-dev
> 
> 

[Eof-dev] Beowolf/Distributed processing

[Jesse W. <je...@ya...>]

greetings, all.

i'm not sure if there's been any thought about it, but
i'd like to work on distributed processing over
freenet.
any thoughts?

--AJW (jes5199)


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

[Eof-dev] Gaming

[<ms...@st...>]

Heya all.  I'm interested in doing some work on eof, but information on the
website is sparse.  I'm not sure where work is needed or where the various
projects are in terms of completion.

The gaming framework caught my eye, but I didn't see any files in cvs.  Am I
missing something, or is it still in the planning stages?  Also, I saw an
article a while back detailing what needed to be done to get a game working over
freenet.  I seem to have lost it; can someone point me to it? 

Thanks,
Mike Terry

[Eof-dev] My $0.02

[David F. <dav...@ya...>]

It appears to me as if most of the members of the EOF project now have no 
time to work on it. Maybe what should be concentrated on is creating 
standards, not implementations. If we create a standard for mail, news and 
other apps via freenet, others like Rob will do implementations. This will 
firstly ensure that all apps can interoperate together and that the project 
remains viable.

David

Re: [Eof-dev] Where do I get Javax

[David F. <dav...@ya...>]

On Thu, 19 Jul 2001 17:43, Brandon K. Wiley hit his keyboard with his head 
and the result was this:
> > Where do I get javax and activation.jar? And can we get some newsgroups
> > going?
>
> javax is just one the prefix for the various java extensions. What you
> actually want is probably javax.mail, the JavaMail extension.
>
> That and the activation jar are available from java.sun.com. Just select
> Products and APIs from the menu on the left and then select the things you
> want from the pulldown (JavaMail and Java Activation Framework (JAF)).
>
> I don't have time to devote to this project these days, but I'll be happy
> to keep doing any administrative stuff that people want with the mailing
> lists, giving people CVS access, and such. I think it would be great if
> somebody got something going, but I don't have time to code myself.

Well, I'd like to see Usenet on freenet going, so I will try and encourage 
things to get going a bit.

David

Re: [Eof-dev] Where do I get Javax

[Brandon K. W. <cy...@az...>]

> Where do I get javax and activation.jar? And can we get some newsgroups going?

javax is just one the prefix for the various java extensions. What you
actually want is probably javax.mail, the JavaMail extension.

That and the activation jar are available from java.sun.com. Just select
Products and APIs from the menu on the left and then select the things you
want from the pulldown (JavaMail and Java Activation Framework (JAF)).

I don't have time to devote to this project these days, but I'll be happy
to keep doing any administrative stuff that people want with the mailing
lists, giving people CVS access, and such. I think it would be great if
somebody got something going, but I don't have time to code myself.

[Eof-dev] Where do I get Javax

[David F. <dav...@ya...>]

Where do I get javax and activation.jar? And can we get some newsgroups going?

David

Re: [Eof-dev] Fw: More on apt-get

[toad <ma...@to...>]

On Thu, Jul 05, 2001 at 07:20:26PM -0500, Brandon Wiley wrote:
> 
> > ***WAVEING HANDS***  Will one of the admins please give Matt developer CVS
> > accsess???  ***WAVEING HANDS***
> 
> Sure thing. Username?
As shown in the above emails, my sourceforge username is amphibian
> 
> 
> 
> _______________________________________________
> Eof-dev mailing list
> Eo...@li...
> http://lists.sourceforge.net/lists/listinfo/eof-dev

-- 
Always hardwire the explosives
        -- Fiona Dexter quoting Monkey, J. Gregory Keyes, Dark Genesis

Re: [Eof-dev] Fw: More on apt-get

[Brandon W. <bl...@bo...>]

> ***WAVEING HANDS***  Will one of the admins please give Matt developer CVS
> accsess???  ***WAVEING HANDS***

Sure thing. Username?

Re: [Eof-dev] Fw: More on apt-get

[toad <ma...@to...>]

On Thu, Jul 05, 2001 at 10:36:01AM -0500, Timm Murray wrote:
> I spent my time yesterday (in between watching the Outer Limits marathon on
> the Sci-fi channel) writing up a few of the scripts needed.  They're all in
> the attached tarball.  I haven't tested them yet, and I'm rather new to
> programing Perl, so please don't laugh if I've done something really stupid
> :)
> 
> ***WAVEING HANDS***  Will one of the admins please give Matt developer CVS
> accsess???  ***WAVEING HANDS***
:)
> 
> More below:
> 
> ----- Original Message -----
> From: "toad" <ma...@to...>
> To: <eo...@li...>
> Sent: Wednesday, July 04, 2001 5:01 PM
> Subject: Re: [Eof-dev] Fw: More on apt-get
> 
> 

> > > > packages on Freenet.  It would require two shell scripts.  The first
> would
> > > > generate the CHK value of each package and set a redirect from a given
> SSK
> > > > to that CHK.  The second would allow the other members to insert the
> > > > packages under the CHKs themselves (each taking a seperate section of
> the
> > > > packages).  One advantage of this(besides distributing the load) is
> that
> > > > only one person has to have the SVK private key even with mutiple
> people
> > > > working on it.
> > Nod, inserting under a CHK is essential for goodish performance.
> > > >
> > >
> > > (This is from a formal proposal I'm writing up)
> > >
> > >
> > >
> > > Apt-Freenet
> > >
> >
> > --------------------------------------------------------------------------
> --
> > > ----
> > >
> > > This document describes ideas for creating a Freenet meathod for
> Debian's
> > > apt-get.
> > >
> > >
> >
> > --------------------------------------------------------------------------
> --
> > > ----
> > >
> > >
> > > Introduction
> > > The first meathod of getting Debian packages through Freenet was a hack
> > > exploiting the fact that apt-get could already use HTTP as a meathod of
> > > downloading packages, and as such could use FProxy to get packages. This
> > > meathod works, but it hits limitations in scaleability, especialy in
> keeping
> > > up with Debian unstable. It would be preferable to have an entrily new
> apt
> > > meathod for getting these packages.
> > >
> > Most importantly, apt-freenet could use 25 simultaneous fetch connections,
> and
> > automatically retry.
> > >
From there, we can not only save Debian bandwidth and hence $, and make debian
users anonymous and possibly harder to MITM, we can also get better bandwidth
than is possible from a central server, albeit with crap latency.
> >
> > --------------------------------------------------------------------------
> --

> > > The advantage to this system is that it minimizes the number of files
> that
> > > require constant updating. Under the FProxy system, a Freenet mirror
> admin
> > > would need to insert the file under a CHK, a redirect to that CHK, and
> the
> > > various meta files (such as Packages). This system would system only
> makes
> > > it necessary to upload any new or updated packages (a job that can be
> safely
> > > distributed among many people) and for the mirror admin to get the CHK
> > > values and update the Packages file with date-based updating (a job that
> > > could be done even on a dial-up connection, provided they can always be
> 
> > > online to insert at the update interval).
> > I am on a dialup connection :). Granted it's a 24x7 dialup, but it's still
> only
> > a 56/33 modem. The main problem is the scripts and the network, not lack
> of
> > bandwidth. Having said that I only do potato/woody non-free/contrib for
> x86.
> 
> I remember once an insert of the entire stable (main, contrib, and non-free)
> i386 distro on a DSL connection and it took ages.  I was half expecting to
> get an angry call from the ISP telling me to never do that again (it never
> came).  I would much rather distribute the load as much as possible.
It won't take much more total bytes than FTPing it in the first place. I have a
(daily) local mirror of ftp.debian.org potato|sid|woody non-free|contrib|main
|non-US. It will however take a lot longer than FTPing it - but this can be
mitigated by using parallel inserts.
> 
> > >
> > >
> >
> > --------------------------------------------------------------------------
> --
> > > ----
> > > Security Issues
> > > If we aim for allowing anybody to insert Freenet packages into CHKs,
> then we
> > > always run the risk of a malicious attacker coming into play. Mallory
> could
> > > create a trojaned package, insert it into a CHK, and send off his list
> of
> > > CHK values to the mirror admin, who blissfuly puts the CHKs in for the
> evil
> > > packages.
> > >
> > > One meathod to counteract this is for the admin to independently get the
> > > packages and generate the CHKs values herself (but doesn't insert). If
> the
> > > CHK she came up with differs from the one that was sent, she'll know
> > > something foul is afoot. However, this requires that the admin get each
> and
> > > every package, which will require lots of bandwidth. This won't scale
> well.
> > It's what I'm doing now. It could be done for the whole repository on a
> cable
> > modem IMHO - if you exclude non-x86 stuff, which shouldn't be on freenet
> ATM
> > due to insufficient demand. Maybe it would need to be limited to one
> > distribution on one platform - woody on x86 and its dependancies, say.
> 
> Yes, the i386 stable distro is the distro that could benifit most from
> Freenet (in terms of file percistance and the ammount of load it takes off
> Debian servers), with unstable/i386 right behind it (files won't often stay
> around as long, but the ammount of bandwidth saved should be enormous).
> 
> > >
> > > A second, and more scaleable approach, is to make use of the "MD5Sum"
> field
> > > still in the control file (so it's not useless after all!) The plugin
> for
> > > Freenet could run an md5sum on the package BEFORE installing and noting
> any
> > > discrepency between what was generated and what was in the Packages
> file.
> > > The "MD5Sum" feild would not have been touched by the admin, and thus
> > > doesn't contain any information Mallory could alter (unless he breaks
> into
> > > the system the Packages file was gotten from in the first place, which
> is
> > > beyond our scope to deal with).
This is still a DoS, though - unless the admin verifies the packages, Mallory
can quickly and easily cause many many (hopefully :)) people to think apt over
freenet is useless because all the packages they just got were corrupt.
Essentially, we end up with
a) Admin verifies packages
or
b) Admin trusts insertors
Granted there is little reason for the users to trust the admin beyond his 
volunteering and being involved in the code, but if the admin trusts the
insertors, it's easy enough for the users to trust the insertors by just
having each insertor have his own subdistro to manage, under a different SSK,
as a line in /etc/apt/sources.list or whatever. Given working automation
of the act of adminning a distro, we could have 2(?) trusted insertor/admins
right now :) - me (on a friggin modem!) and that other guy we lost. If Timm
is also doing uploading, that's 3. As regards daily updates, relatively few
packages change from day to day even in unstable. One admin for woody/non-free,
one for woody/contrib, one for sid/non-US, etc, would be reasonably fine grained
distribution; we just have to make sure apt-freenet can handle this (apt over
freenet over HTTP can trivially handle it).
> > Nod. Fetching is going to be at least as costly as inserting, although the
> > admin then does not have to fetch all the packages from ftp.debian.org. If
> the
> > connection to freenet is much faster (re bandwidth) than the connection to
> > debian, this is a net gain.
> > >
> > >
> >
> > --------------------------------------------------------------------------
> --
> > > ----
> > >
> > > Summery of What is Needed
> > > --New apt meathod that requests the Debian meta files via an SSK, but
> gets
> > > the packages themselves through a CHK value noted in each package's
> > > "filename" entry in the Packages file.
> > Yes yes yes! It should also fetch in a manner consistent with freenet's
> > architecture (like GJ's GetFiles - many parallel requests, HTL increases
> from
> > 15 to 100 as progressively retry failed files). It could in fact be built
> atop
> > GJ's manifest utils - would require a debian package for manifest-tools
> that
> > apt-freenet could depend on.  Should be done in some scripting language -
> shell,
> > perl, etc (please take flamewars off list or at least mark them OT: in the
> > subject line; I know perl and shell and C++ :)).
> 
> >From what I can tell, many of the existing Debian meathods are already built
> in Perl.
> 
> > Requires that somebody go find
> > out how to implement a custom apt/dpkg method. There are probably docs all
> over
> > debian.org :)
> 
> I found this:  "apt-get install libapt-pkg-dev libapt-pkg-doc".  The
> "dpkg-perl" package may also be useful.
> 
> Apparently they use communication through STDIN, STDOUT, and STDERR for
> interfacing with APT itself.
Yay. Will install, investigate.
> 
> > >
> > > --A script which will insert a given set of packages into Freenet. It
> will
> > > then compile the CHK values of the packages into a list that can be
> parsed
> > > by the program noted below.
> > Nod, this is easy. Finding the CHK requires a) getting freenet devs to
> finally
> > implement an option to find the CHK of something without inserting it, b)
> using
> > libfreenet or c) parsing the output of the insertion script. Since the
> insertion
> > script will likely be PutFiles, it probably doesn't tell you what CHK it
> has
> > inserted under. As with the custom fetch method, it is not worth
> reimplementing
> > this stuff in C; freenet is slow enough, and the manifest tools are
> reasonably
> > good, fast, stable (if no nasty things like mapfiles), especially fast if
> you
> > can use the new use-FCP option. There is the issue of memory usage of
> course;
> > but the manifest tools using FCP probably use far less than the node they
> are
> > talking to. When there's a small-footprint node to talk to, then I'll care
> > about insertor/requestor footprints. And RAM is CHEAP.
> 
> The script I made to do this (see attached) is built around parsing the
> output of freenet_insert, but if you want to build it another way, thats
> cool.
Implies you insert 1 file at a time, as your original script did. This is really
SLOWWWWW. Can be mitigated by running them in parallel, you will need to do
retrying too. All in all, you'd be reimplementing PutFiles, only in perl, and
slower.
The alternatives:
libfreenet:
echo "Content-Type=application/x-debian-package">.1; echo "End" >> .1; cat $x >> .1; testclient -i -f .1 freenet:CHK@CxnLMc~RfDCIooExc25ke7nfRyUOAwE -h 0 -m 46 | sed -n "s/freenet://p"
This is a fast way to find the CHK of a file without actually inserting it.
a) is impractical
c) is also impractical if using PutFiles last I heard.
> 
> > >
> > > --A program which can parse a stock Packages file off a Debian mirror
> and
> > > replace the "filename" fields with the associated CHK value from the
> list
> > > generated above. Also, a new list containing the CHKs of updated
> packages
> > > can be merged into an already converted Packages file. (Perl makes a
> good
> > > language for this).
> > Nod. Definitely a perl job.
> 
> And a bit of Perl to do just that is attached :)
Oooh. Will look, haven't gotten to it yet.
> 
> > >
> > > --Another script which will take the resulting Packages file and other
> > > Debian meta files (such as Release) and continously use date-based
> redirects
> > > for updating the file. This could be run from cron to keep insure the
> > > Packages file is updated regularly (probably daily).
> > It is debatable that the effort of distribution is necessary. Eventually
> we
> > would like to run it on a debian.org server i.e. centralized. And it's
> easy
> > enough to have one person maintain each distribution. But we *absolutely
> need*
> > a way to just insert CHKs, without an SSK redirect *per file*, and the
> modified
> > Packages, per day, and we also absolutely need a better fetch mechanism.
> >
-- 
Always hardwire the explosives
        -- Fiona Dexter quoting Monkey, J. Gregory Keyes, Dark Genesis

Re: [Eof-dev] Fw: More on apt-get

[Timm M. <har...@ru...>]

I spent my time yesterday (in between watching the Outer Limits marathon on
the Sci-fi channel) writing up a few of the scripts needed.  They're all in
the attached tarball.  I haven't tested them yet, and I'm rather new to
programing Perl, so please don't laugh if I've done something really stupid
:)

***WAVEING HANDS***  Will one of the admins please give Matt developer CVS
accsess???  ***WAVEING HANDS***

More below:

----- Original Message -----
From: "toad" <ma...@to...>
To: <eo...@li...>
Sent: Wednesday, July 04, 2001 5:01 PM
Subject: Re: [Eof-dev] Fw: More on apt-get


> On Wed, Jul 04, 2001 at 09:54:34AM -0500, Timm Murray wrote:
> > Sent this to the wrong address.  I also have something more to add below
(a
> > system which I think will be one better then the one from Don Marti; see
> > below).
> >
> > ----- Original Message -----
> > From: "Timm Murray" <har...@ru...>
> > To: <eof...@li...>
> > Sent: Tuesday, July 03, 2001 10:10 AM
> > Subject: More on apt-get
> >
> >
> > > As long as we're on this subject:
> > >
> > > Don Marti suggested to me a way of distributing the load of mirroring
> > Debian
> > > packages on Freenet.  It would require two shell scripts.  The first
would
> > > generate the CHK value of each package and set a redirect from a given
SSK
> > > to that CHK.  The second would allow the other members to insert the
> > > packages under the CHKs themselves (each taking a seperate section of
the
> > > packages).  One advantage of this(besides distributing the load) is
that
> > > only one person has to have the SVK private key even with mutiple
people
> > > working on it.
> Nod, inserting under a CHK is essential for goodish performance.
> > >
> >
> > (This is from a formal proposal I'm writing up)
> >
> >
> >
> > Apt-Freenet
> >
>
> --------------------------------------------------------------------------
--
> > ----
> >
> > This document describes ideas for creating a Freenet meathod for
Debian's
> > apt-get.
> >
> >
>
> --------------------------------------------------------------------------
--
> > ----
> >
> >
> > Introduction
> > The first meathod of getting Debian packages through Freenet was a hack
> > exploiting the fact that apt-get could already use HTTP as a meathod of
> > downloading packages, and as such could use FProxy to get packages. This
> > meathod works, but it hits limitations in scaleability, especialy in
keeping
> > up with Debian unstable. It would be preferable to have an entrily new
apt
> > meathod for getting these packages.
> >
> Most importantly, apt-freenet could use 25 simultaneous fetch connections,
and
> automatically retry.
> >
>
> --------------------------------------------------------------------------
--
> > ----
> >
> > Control File Modifications
> > Currently, a control file contains both a filename (where the file can
be
> > located on any Debian mirror) and an MD5Sum. If we were building an apt
> > system that would only work over Freenet, only one field would be
necessary
> > for both, via a CHK.
> >
> > Since we're not building a pure Freenet apt-get, we can leave the fields
as
> > they are and modify the control file (actualy, we modify the Packages
file
> > that all the control files are pooled into) so that the "filename" field
> > contains the CHK value.
> Yes. Essential.
> >
> > The advantage to this system is that it minimizes the number of files
that
> > require constant updating. Under the FProxy system, a Freenet mirror
admin
> > would need to insert the file under a CHK, a redirect to that CHK, and
the
> > various meta files (such as Packages). This system would system only
makes
> > it necessary to upload any new or updated packages (a job that can be
safely
> > distributed among many people) and for the mirror admin to get the CHK
> > values and update the Packages file with date-based updating (a job that
> > could be done even on a dial-up connection, provided they can always be

> > online to insert at the update interval).
> I am on a dialup connection :). Granted it's a 24x7 dialup, but it's still
only
> a 56/33 modem. The main problem is the scripts and the network, not lack
of
> bandwidth. Having said that I only do potato/woody non-free/contrib for
x86.

I remember once an insert of the entire stable (main, contrib, and non-free)
i386 distro on a DSL connection and it took ages.  I was half expecting to
get an angry call from the ISP telling me to never do that again (it never
came).  I would much rather distribute the load as much as possible.

> >
> >
>
> --------------------------------------------------------------------------
--
> > ----
> >
> > URI for the Freenet Meathod
> > Each meathod for apt-get has its own URI. The URI for the Freenet
meathod,
> > adopted from the Freenet URI standard (or at least what used to be the
> > Freenet URI standard), is this:
> >
> > freenet://[keytype@][public/private key],[key]
> >
> > "keytype@" is not required for KSKs (but we're not using KSKs, so
basicly
> > it's always required). "public/private key" is required for SVKs and
SSKs.
> > "Key" is either the KSK value, the guessable part of an SSK, or the CHK
> > value. For CHKs, "key" is not required when inserting, but is required
when
> > requesting.
> >
> > When entering the "filename" field into the control file, one does not
have
> > to put in an entire Freenet URI. You only the value of the CHK.
> >
> >
>
> --------------------------------------------------------------------------
--
> > ----
> >
> > Security Issues
> > If we aim for allowing anybody to insert Freenet packages into CHKs,
then we
> > always run the risk of a malicious attacker coming into play. Mallory
could
> > create a trojaned package, insert it into a CHK, and send off his list
of
> > CHK values to the mirror admin, who blissfuly puts the CHKs in for the
evil
> > packages.
> >
> > One meathod to counteract this is for the admin to independently get the
> > packages and generate the CHKs values herself (but doesn't insert). If
the
> > CHK she came up with differs from the one that was sent, she'll know
> > something foul is afoot. However, this requires that the admin get each
and
> > every package, which will require lots of bandwidth. This won't scale
well.
> It's what I'm doing now. It could be done for the whole repository on a
cable
> modem IMHO - if you exclude non-x86 stuff, which shouldn't be on freenet
ATM
> due to insufficient demand. Maybe it would need to be limited to one
> distribution on one platform - woody on x86 and its dependancies, say.

Yes, the i386 stable distro is the distro that could benifit most from
Freenet (in terms of file percistance and the ammount of load it takes off
Debian servers), with unstable/i386 right behind it (files won't often stay
around as long, but the ammount of bandwidth saved should be enormous).

> >
> > A second, and more scaleable approach, is to make use of the "MD5Sum"
field
> > still in the control file (so it's not useless after all!) The plugin
for
> > Freenet could run an md5sum on the package BEFORE installing and noting
any
> > discrepency between what was generated and what was in the Packages
file.
> > The "MD5Sum" feild would not have been touched by the admin, and thus
> > doesn't contain any information Mallory could alter (unless he breaks
into
> > the system the Packages file was gotten from in the first place, which
is
> > beyond our scope to deal with).
> Nod. Fetching is going to be at least as costly as inserting, although the
> admin then does not have to fetch all the packages from ftp.debian.org. If
the
> connection to freenet is much faster (re bandwidth) than the connection to
> debian, this is a net gain.
> >
> >
>
> --------------------------------------------------------------------------
--
> > ----
> >
> > Summery of What is Needed
> > --New apt meathod that requests the Debian meta files via an SSK, but
gets
> > the packages themselves through a CHK value noted in each package's
> > "filename" entry in the Packages file.
> Yes yes yes! It should also fetch in a manner consistent with freenet's
> architecture (like GJ's GetFiles - many parallel requests, HTL increases
from
> 15 to 100 as progressively retry failed files). It could in fact be built
atop
> GJ's manifest utils - would require a debian package for manifest-tools
that
> apt-freenet could depend on.  Should be done in some scripting language -
shell,
> perl, etc (please take flamewars off list or at least mark them OT: in the
> subject line; I know perl and shell and C++ :)).

From what I can tell, many of the existing Debian meathods are already built
in Perl.

> Requires that somebody go find
> out how to implement a custom apt/dpkg method. There are probably docs all
over
> debian.org :)

I found this:  "apt-get install libapt-pkg-dev libapt-pkg-doc".  The
"dpkg-perl" package may also be useful.

Apparently they use communication through STDIN, STDOUT, and STDERR for
interfacing with APT itself.

> >
> > --A script which will insert a given set of packages into Freenet. It
will
> > then compile the CHK values of the packages into a list that can be
parsed
> > by the program noted below.
> Nod, this is easy. Finding the CHK requires a) getting freenet devs to
finally
> implement an option to find the CHK of something without inserting it, b)
using
> libfreenet or c) parsing the output of the insertion script. Since the
insertion
> script will likely be PutFiles, it probably doesn't tell you what CHK it
has
> inserted under. As with the custom fetch method, it is not worth
reimplementing
> this stuff in C; freenet is slow enough, and the manifest tools are
reasonably
> good, fast, stable (if no nasty things like mapfiles), especially fast if
you
> can use the new use-FCP option. There is the issue of memory usage of
course;
> but the manifest tools using FCP probably use far less than the node they
are
> talking to. When there's a small-footprint node to talk to, then I'll care
> about insertor/requestor footprints. And RAM is CHEAP.

The script I made to do this (see attached) is built around parsing the
output of freenet_insert, but if you want to build it another way, thats
cool.

> >
> > --A program which can parse a stock Packages file off a Debian mirror
and
> > replace the "filename" fields with the associated CHK value from the
list
> > generated above. Also, a new list containing the CHKs of updated
packages
> > can be merged into an already converted Packages file. (Perl makes a
good
> > language for this).
> Nod. Definitely a perl job.

And a bit of Perl to do just that is attached :)

> >
> > --Another script which will take the resulting Packages file and other
> > Debian meta files (such as Release) and continously use date-based
redirects
> > for updating the file. This could be run from cron to keep insure the
> > Packages file is updated regularly (probably daily).
> It is debatable that the effort of distribution is necessary. Eventually
we
> would like to run it on a debian.org server i.e. centralized. And it's
easy
> enough to have one person maintain each distribution. But we *absolutely
need*
> a way to just insert CHKs, without an SSK redirect *per file*, and the
modified
> Packages, per day, and we also absolutely need a better fetch mechanism.
>
> --
> Always hardwire the explosives
>         -- Fiona Dexter quoting Monkey, J. Gregory Keyes, Dark Genesis
>
> _______________________________________________
> Eof-dev mailing list
> Eo...@li...
> http://lists.sourceforge.net/lists/listinfo/eof-dev
>
>

Re: [Eof-dev] Fw: More on apt-get

[toad <ma...@to...>]

On Wed, Jul 04, 2001 at 09:54:34AM -0500, Timm Murray wrote:
> Sent this to the wrong address.  I also have something more to add below (a
> system which I think will be one better then the one from Don Marti; see
> below).
> 
> ----- Original Message -----
> From: "Timm Murray" <har...@ru...>
> To: <eof...@li...>
> Sent: Tuesday, July 03, 2001 10:10 AM
> Subject: More on apt-get
> 
> 
> > As long as we're on this subject:
> >
> > Don Marti suggested to me a way of distributing the load of mirroring
> Debian
> > packages on Freenet.  It would require two shell scripts.  The first would
> > generate the CHK value of each package and set a redirect from a given SSK
> > to that CHK.  The second would allow the other members to insert the
> > packages under the CHKs themselves (each taking a seperate section of the
> > packages).  One advantage of this(besides distributing the load) is that
> > only one person has to have the SVK private key even with mutiple people
> > working on it.
Nod, inserting under a CHK is essential for goodish performance.
> >
> 
> (This is from a formal proposal I'm writing up)
> 
> 
> 
> Apt-Freenet
> 
> ----------------------------------------------------------------------------
> ----
> 
> This document describes ideas for creating a Freenet meathod for Debian's
> apt-get.
> 
> 
> ----------------------------------------------------------------------------
> ----
> 
> 
> Introduction
> The first meathod of getting Debian packages through Freenet was a hack
> exploiting the fact that apt-get could already use HTTP as a meathod of
> downloading packages, and as such could use FProxy to get packages. This
> meathod works, but it hits limitations in scaleability, especialy in keeping
> up with Debian unstable. It would be preferable to have an entrily new apt
> meathod for getting these packages.
> 
Most importantly, apt-freenet could use 25 simultaneous fetch connections, and
automatically retry.
> 
> ----------------------------------------------------------------------------
> ----
> 
> Control File Modifications
> Currently, a control file contains both a filename (where the file can be
> located on any Debian mirror) and an MD5Sum. If we were building an apt
> system that would only work over Freenet, only one field would be necessary
> for both, via a CHK.
> 
> Since we're not building a pure Freenet apt-get, we can leave the fields as
> they are and modify the control file (actualy, we modify the Packages file
> that all the control files are pooled into) so that the "filename" field
> contains the CHK value.
Yes. Essential.
> 
> The advantage to this system is that it minimizes the number of files that
> require constant updating. Under the FProxy system, a Freenet mirror admin
> would need to insert the file under a CHK, a redirect to that CHK, and the
> various meta files (such as Packages). This system would system only makes
> it necessary to upload any new or updated packages (a job that can be safely
> distributed among many people) and for the mirror admin to get the CHK
> values and update the Packages file with date-based updating (a job that
> could be done even on a dial-up connection, provided they can always be
> online to insert at the update interval).
I am on a dialup connection :). Granted it's a 24x7 dialup, but it's still only
a 56/33 modem. The main problem is the scripts and the network, not lack of
bandwidth. Having said that I only do potato/woody non-free/contrib for x86.
> 
> 
> ----------------------------------------------------------------------------
> ----
> 
> URI for the Freenet Meathod
> Each meathod for apt-get has its own URI. The URI for the Freenet meathod,
> adopted from the Freenet URI standard (or at least what used to be the
> Freenet URI standard), is this:
> 
> freenet://[keytype@][public/private key],[key]
> 
> "keytype@" is not required for KSKs (but we're not using KSKs, so basicly
> it's always required). "public/private key" is required for SVKs and SSKs.
> "Key" is either the KSK value, the guessable part of an SSK, or the CHK
> value. For CHKs, "key" is not required when inserting, but is required when
> requesting.
> 
> When entering the "filename" field into the control file, one does not have
> to put in an entire Freenet URI. You only the value of the CHK.
> 
> 
> ----------------------------------------------------------------------------
> ----
> 
> Security Issues
> If we aim for allowing anybody to insert Freenet packages into CHKs, then we
> always run the risk of a malicious attacker coming into play. Mallory could
> create a trojaned package, insert it into a CHK, and send off his list of
> CHK values to the mirror admin, who blissfuly puts the CHKs in for the evil
> packages.
> 
> One meathod to counteract this is for the admin to independently get the
> packages and generate the CHKs values herself (but doesn't insert). If the
> CHK she came up with differs from the one that was sent, she'll know
> something foul is afoot. However, this requires that the admin get each and
> every package, which will require lots of bandwidth. This won't scale well.
It's what I'm doing now. It could be done for the whole repository on a cable
modem IMHO - if you exclude non-x86 stuff, which shouldn't be on freenet ATM 
due to insufficient demand. Maybe it would need to be limited to one
distribution on one platform - woody on x86 and its dependancies, say.
> 
> A second, and more scaleable approach, is to make use of the "MD5Sum" field
> still in the control file (so it's not useless after all!) The plugin for
> Freenet could run an md5sum on the package BEFORE installing and noting any
> discrepency between what was generated and what was in the Packages file.
> The "MD5Sum" feild would not have been touched by the admin, and thus
> doesn't contain any information Mallory could alter (unless he breaks into
> the system the Packages file was gotten from in the first place, which is
> beyond our scope to deal with).
Nod. Fetching is going to be at least as costly as inserting, although the 
admin then does not have to fetch all the packages from ftp.debian.org. If the
connection to freenet is much faster (re bandwidth) than the connection to
debian, this is a net gain.
> 
> 
> ----------------------------------------------------------------------------
> ----
> 
> Summery of What is Needed
> --New apt meathod that requests the Debian meta files via an SSK, but gets
> the packages themselves through a CHK value noted in each package's
> "filename" entry in the Packages file.
Yes yes yes! It should also fetch in a manner consistent with freenet's
architecture (like GJ's GetFiles - many parallel requests, HTL increases from
15 to 100 as progressively retry failed files). It could in fact be built atop
GJ's manifest utils - would require a debian package for manifest-tools that
apt-freenet could depend on. Should be done in some scripting language - shell,
perl, etc (please take flamewars off list or at least mark them OT: in the
subject line; I know perl and shell and C++ :)). Requires that somebody go find
out how to implement a custom apt/dpkg method. There are probably docs all over
debian.org :)
> 
> --A script which will insert a given set of packages into Freenet. It will
> then compile the CHK values of the packages into a list that can be parsed
> by the program noted below.
Nod, this is easy. Finding the CHK requires a) getting freenet devs to finally
implement an option to find the CHK of something without inserting it, b) using
libfreenet or c) parsing the output of the insertion script. Since the insertion
script will likely be PutFiles, it probably doesn't tell you what CHK it has
inserted under. As with the custom fetch method, it is not worth reimplementing
this stuff in C; freenet is slow enough, and the manifest tools are reasonably
good, fast, stable (if no nasty things like mapfiles), especially fast if you
can use the new use-FCP option. There is the issue of memory usage of course;
but the manifest tools using FCP probably use far less than the node they are
talking to. When there's a small-footprint node to talk to, then I'll care
about insertor/requestor footprints. And RAM is CHEAP.
> 
> --A program which can parse a stock Packages file off a Debian mirror and
> replace the "filename" fields with the associated CHK value from the list
> generated above. Also, a new list containing the CHKs of updated packages
> can be merged into an already converted Packages file. (Perl makes a good
> language for this).
Nod. Definitely a perl job.
> 
> --Another script which will take the resulting Packages file and other
> Debian meta files (such as Release) and continously use date-based redirects
> for updating the file. This could be run from cron to keep insure the
> Packages file is updated regularly (probably daily).
It is debatable that the effort of distribution is necessary. Eventually we
would like to run it on a debian.org server i.e. centralized. And it's easy
enough to have one person maintain each distribution. But we *absolutely need*
a way to just insert CHKs, without an SSK redirect *per file*, and the modified
Packages, per day, and we also absolutely need a better fetch mechanism.

-- 
Always hardwire the explosives
        -- Fiona Dexter quoting Monkey, J. Gregory Keyes, Dark Genesis

[Eof-dev] Fw: More on apt-get

[Timm M. <har...@ru...>]

Sent this to the wrong address.  I also have something more to add below (a
system which I think will be one better then the one from Don Marti; see
below).

----- Original Message -----
From: "Timm Murray" <har...@ru...>
To: <eof...@li...>
Sent: Tuesday, July 03, 2001 10:10 AM
Subject: More on apt-get


> As long as we're on this subject:
>
> Don Marti suggested to me a way of distributing the load of mirroring
Debian
> packages on Freenet.  It would require two shell scripts.  The first would
> generate the CHK value of each package and set a redirect from a given SSK
> to that CHK.  The second would allow the other members to insert the
> packages under the CHKs themselves (each taking a seperate section of the
> packages).  One advantage of this(besides distributing the load) is that
> only one person has to have the SVK private key even with mutiple people
> working on it.
>

(This is from a formal proposal I'm writing up)



Apt-Freenet

----------------------------------------------------------------------------
----

This document describes ideas for creating a Freenet meathod for Debian's
apt-get.


----------------------------------------------------------------------------
----


Introduction
The first meathod of getting Debian packages through Freenet was a hack
exploiting the fact that apt-get could already use HTTP as a meathod of
downloading packages, and as such could use FProxy to get packages. This
meathod works, but it hits limitations in scaleability, especialy in keeping
up with Debian unstable. It would be preferable to have an entrily new apt
meathod for getting these packages.


----------------------------------------------------------------------------
----

Control File Modifications
Currently, a control file contains both a filename (where the file can be
located on any Debian mirror) and an MD5Sum. If we were building an apt
system that would only work over Freenet, only one field would be necessary
for both, via a CHK.

Since we're not building a pure Freenet apt-get, we can leave the fields as
they are and modify the control file (actualy, we modify the Packages file
that all the control files are pooled into) so that the "filename" field
contains the CHK value.

The advantage to this system is that it minimizes the number of files that
require constant updating. Under the FProxy system, a Freenet mirror admin
would need to insert the file under a CHK, a redirect to that CHK, and the
various meta files (such as Packages). This system would system only makes
it necessary to upload any new or updated packages (a job that can be safely
distributed among many people) and for the mirror admin to get the CHK
values and update the Packages file with date-based updating (a job that
could be done even on a dial-up connection, provided they can always be
online to insert at the update interval).


----------------------------------------------------------------------------
----

URI for the Freenet Meathod
Each meathod for apt-get has its own URI. The URI for the Freenet meathod,
adopted from the Freenet URI standard (or at least what used to be the
Freenet URI standard), is this:

freenet://[keytype@][public/private key],[key]

"keytype@" is not required for KSKs (but we're not using KSKs, so basicly
it's always required). "public/private key" is required for SVKs and SSKs.
"Key" is either the KSK value, the guessable part of an SSK, or the CHK
value. For CHKs, "key" is not required when inserting, but is required when
requesting.

When entering the "filename" field into the control file, one does not have
to put in an entire Freenet URI. You only the value of the CHK.


----------------------------------------------------------------------------
----

Security Issues
If we aim for allowing anybody to insert Freenet packages into CHKs, then we
always run the risk of a malicious attacker coming into play. Mallory could
create a trojaned package, insert it into a CHK, and send off his list of
CHK values to the mirror admin, who blissfuly puts the CHKs in for the evil
packages.

One meathod to counteract this is for the admin to independently get the
packages and generate the CHKs values herself (but doesn't insert). If the
CHK she came up with differs from the one that was sent, she'll know
something foul is afoot. However, this requires that the admin get each and
every package, which will require lots of bandwidth. This won't scale well.

A second, and more scaleable approach, is to make use of the "MD5Sum" field
still in the control file (so it's not useless after all!) The plugin for
Freenet could run an md5sum on the package BEFORE installing and noting any
discrepency between what was generated and what was in the Packages file.
The "MD5Sum" feild would not have been touched by the admin, and thus
doesn't contain any information Mallory could alter (unless he breaks into
the system the Packages file was gotten from in the first place, which is
beyond our scope to deal with).


----------------------------------------------------------------------------
----

Summery of What is Needed
--New apt meathod that requests the Debian meta files via an SSK, but gets
the packages themselves through a CHK value noted in each package's
"filename" entry in the Packages file.

--A script which will insert a given set of packages into Freenet. It will
then compile the CHK values of the packages into a list that can be parsed
by the program noted below.

--A program which can parse a stock Packages file off a Debian mirror and
replace the "filename" fields with the associated CHK value from the list
generated above. Also, a new list containing the CHKs of updated packages
can be merged into an already converted Packages file. (Perl makes a good
language for this).

--Another script which will take the resulting Packages file and other
Debian meta files (such as Release) and continously use date-based redirects
for updating the file. This could be run from cron to keep insure the
Packages file is updated regularly (probably daily).

Re: [Eof-dev] games architecture

[Brandon W. <bl...@bo...>]

> It might be tolerable as a one-to-one communication, but it's best to treat
> it as one-to-many.  If you want one-to-one communication, you're probably
> better off using anonymizing proxies and such then Freenet.

But, if you happen to want to write a one-to-one application over Freenet,
for whatever reason, insane or otherwise, it will probably actually work,
despite the fact that it's clearly a silly idea.

Re: [Eof-dev] games architecture

[Timm M. <har...@ru...>]

----- Original Message -----
From: "Brandon Wiley" <bl...@bo...>
To: <eo...@li...>
Sent: Wednesday, June 27, 2001 8:01 AM
Subject: Re: [Eof-dev] games architecture

<>

> I've found that, in practice, one-to-one communication works tolerably
> well. F-mail messages usually get through, for instance.

It might be tolerable as a one-to-one communication, but it's best to treat
it as one-to-many.  If you want one-to-one communication, you're probably
better off using anonymizing proxies and such then Freenet.

Re: [Eof-dev] games architecture

[Warner O. <wa...@wa...>]

----- Original Message -----
From: "Timm Murray" <har...@ru...>
To: <eo...@li...>
Sent: Tuesday, June 26, 2001 9:03 AM
Subject: Re: [Eof-dev] games architecture


> Freenet works best if you treat it as a one-to-many protocol.  This is why
> e-mail (a many-to-one job) probably won't work as well as news (a
> one-to-many job).
>
> So the answer to your question is:  It depeds on the game.  A game with
just
> two players (e.g., Chess, Checkers, etc.) probably won't work too well
over
> Freenet (with one exception, see below).  However, a game with many
players
> (like Monopoly) would work better, provided that you aren't bugged too
much
> by high latency.

For this game the latency will be about a day to week depending on settings,
it's not designed to be a fast-moving game.

> What you could do with two-player games is offer a format that holds the
> game in storage and then have many people downloading it.  For instance,
> with Chess, there is an ASCII file format called "PGN" that holds each
move
> in storage which could then be transfered to a computer for parsing and
> eventualy displaying them to the user. (You know those books like "100
> Greatest Chess Games of All Time"?  Think of having those on Freenet).

Once I figure out the freenet arch. and how the game arch will work over it
I will have to have some kind of configurable database solution for storing
ongoing games.

> (I was thinking a while back of modifying PalmPGN (see
> palmpgn.sourceforge.net) so that it could get Chess games off Freenet, but
I
> haven't gotten around to it.  Too much to do, too much to do . . . )

No kidding =). I've got about three other projects besides actually working
before I can get to this (but most of them are ons-shot deals and hopefully
shouldn't take too long =).

-warner

> ----- Original Message -----
> From: "Warner Onstine" <wa...@wa...>
> To: <eo...@li...>
> Sent: Friday, June 22, 2001 1:49 PM
> Subject: [Eof-dev] games architecture
>
>
> > Hi guys,
> > I saw the slashdot article and this got me to thinking about another
> > turn-based game that I have been thinking about for a few years. The
thing
> > with this turn-based game is that it would need to be able to store
> > long-term information about the game (think Play by mail games), would
> > freenet be able to do this?
> >
> > I'll admit that I'm not that familiar with Freenet, but I have just
> > downloaded everything and will begin to investigate it this weekend.
> >
> > -warner
> >
> >
> > _______________________________________________
> > Eof-dev mailing list
> > Eo...@li...
> > http://lists.sourceforge.net/lists/listinfo/eof-dev
> >
> >
>
>
> _______________________________________________
> Eof-dev mailing list
> Eo...@li...
> http://lists.sourceforge.net/lists/listinfo/eof-dev
>

Re: [Eof-dev] games architecture

[Brandon W. <bl...@bo...>]

> Freenet works best if you treat it as a one-to-many protocol.  This is why
> e-mail (a many-to-one job) probably won't work as well as news (a
> one-to-many job).
> 
> So the answer to your question is:  It depeds on the game.  A game with just
> two players (e.g., Chess, Checkers, etc.) probably won't work too well over
> Freenet (with one exception, see below).  However, a game with many players
> (like Monopoly) would work better, provided that you aren't bugged too much
> by high latency.

I've found that, in practice, one-to-one communication works tolerably
well. F-mail messages usually get through, for instance.

Re: [Eof-dev] games architecture

[Timm M. <har...@ru...>]

Freenet works best if you treat it as a one-to-many protocol.  This is why
e-mail (a many-to-one job) probably won't work as well as news (a
one-to-many job).

So the answer to your question is:  It depeds on the game.  A game with just
two players (e.g., Chess, Checkers, etc.) probably won't work too well over
Freenet (with one exception, see below).  However, a game with many players
(like Monopoly) would work better, provided that you aren't bugged too much
by high latency.

What you could do with two-player games is offer a format that holds the
game in storage and then have many people downloading it.  For instance,
with Chess, there is an ASCII file format called "PGN" that holds each move
in storage which could then be transfered to a computer for parsing and
eventualy displaying them to the user. (You know those books like "100
Greatest Chess Games of All Time"?  Think of having those on Freenet).

(I was thinking a while back of modifying PalmPGN (see
palmpgn.sourceforge.net) so that it could get Chess games off Freenet, but I
haven't gotten around to it.  Too much to do, too much to do . . . )

----- Original Message -----
From: "Warner Onstine" <wa...@wa...>
To: <eo...@li...>
Sent: Friday, June 22, 2001 1:49 PM
Subject: [Eof-dev] games architecture


> Hi guys,
> I saw the slashdot article and this got me to thinking about another
> turn-based game that I have been thinking about for a few years. The thing
> with this turn-based game is that it would need to be able to store
> long-term information about the game (think Play by mail games), would
> freenet be able to do this?
>
> I'll admit that I'm not that familiar with Freenet, but I have just
> downloaded everything and will begin to investigate it this weekend.
>
> -warner
>
>
> _______________________________________________
> Eof-dev mailing list
> Eo...@li...
> http://lists.sourceforge.net/lists/listinfo/eof-dev
>
>

Re: [Eof-dev] games architecture

[Brandon W. <bl...@bo...>]

> Wow, thanks for the reply. When I get some free time I'll start working on
> the architecture of my game. It was pretty well fleshed out on index cards
> with a mapping system (think Risk with a twist =), now I just need to get it
> into Java. In addition it will have a nice visual front-end that will take
> some work.

While I am personally fond of Java, I should point out that since the
client API is exposed via XML-RPC, you can write clients in 13 different
languages. Other languages you might consider writing your game in are
Python, Perl, and C, depending on your language preferences.

Re: [Eof-dev] games architecture

[Warner O. <wa...@wa...>]

Wow, thanks for the reply. When I get some free time I'll start working on
the architecture of my game. It was pretty well fleshed out on index cards
with a mapping system (think Risk with a twist =), now I just need to get it
into Java. In addition it will have a nice visual front-end that will take
some work.

-warner

----- Original Message -----
From: "Brandon" <bl...@ut...>
To: <eo...@li...>
Sent: Sunday, June 24, 2001 10:27 PM
Subject: Re: [Eof-dev] games architecture


>
> > I saw the slashdot article and this got me to thinking about another
> > turn-based game that I have been thinking about for a few years. The
thing
> > with this turn-based game is that it would need to be able to store
> > long-term information about the game (think Play by mail games), would
> > freenet be able to do this?
>
> Freenet is a plausible medium for play-by-mail style games. In fact, the
> acid test for whether a game is playable over Freenet is simply is it
> playable by mail. If it's not then it will probably run too slowly over
> Freenet to be worthwhile.
>
> Freenet cannot, however, store long-term information in any meaningful
> sense. Maybe it will stick and maybe it won't. There's no way of telling.
> However, all of the information is publically available. Someone could
> choose to make permanent archives available. Communicating with them via
> in-Freenet mail, archives of old information could be requested from them
> and delivered over Freenet. This could even by automated by an archive
> bot. You could even have multiple archive bots.
>
> This scheme does take away some of the benefits of decentralization in
> that some person or group of people must provide archives. However, that's
> the best you're going to get.
>
> I'd love to see you program some games over Freenet. You are welcome to
> use this project's CVS, mailing lists, and web hosting. When you decide on
> a game you'd like to implement, let me know your sourceforge username and
> I'll add you to the project.
>
> I don't have much time for applications over Freenet at the moment, but
> I'm happy to serve an administrative role in organizing other people that
> want to write applications over Freenet.
>
>
>
> _______________________________________________
> Eof-dev mailing list
> Eo...@li...
> http://lists.sourceforge.net/lists/listinfo/eof-dev
>

Re: [Eof-dev] games architecture

[Brandon <bl...@ut...>]

> I saw the slashdot article and this got me to thinking about another
> turn-based game that I have been thinking about for a few years. The thing
> with this turn-based game is that it would need to be able to store
> long-term information about the game (think Play by mail games), would
> freenet be able to do this?

Freenet is a plausible medium for play-by-mail style games. In fact, the
acid test for whether a game is playable over Freenet is simply is it
playable by mail. If it's not then it will probably run too slowly over
Freenet to be worthwhile.

Freenet cannot, however, store long-term information in any meaningful
sense. Maybe it will stick and maybe it won't. There's no way of telling.
However, all of the information is publically available. Someone could
choose to make permanent archives available. Communicating with them via
in-Freenet mail, archives of old information could be requested from them
and delivered over Freenet. This could even by automated by an archive
bot. You could even have multiple archive bots.

This scheme does take away some of the benefits of decentralization in
that some person or group of people must provide archives. However, that's
the best you're going to get.

I'd love to see you program some games over Freenet. You are welcome to
use this project's CVS, mailing lists, and web hosting. When you decide on
a game you'd like to implement, let me know your sourceforge username and
I'll add you to the project.

I don't have much time for applications over Freenet at the moment, but
I'm happy to serve an administrative role in organizing other people that
want to write applications over Freenet.

[Eof-dev] games architecture

[Warner O. <wa...@wa...>]

Hi guys,
I saw the slashdot article and this got me to thinking about another
turn-based game that I have been thinking about for a few years. The thing
with this turn-based game is that it would need to be able to store
long-term information about the game (think Play by mail games), would
freenet be able to do this?

I'll admit that I'm not that familiar with Freenet, but I have just
downloaded everything and will begin to investigate it this weekend.

-warner