[107350] in Cypherpunks
Re: Eternity implementation features wish list?
daemon@ATHENA.MIT.EDU (Bill Stewart)
Tue Jan 12 00:36:04 1999
Date: Mon, 11 Jan 1999 21:23:49 -0800
To: ryan@venona.com, cypherpunks@algebra.com, gsstark@mit.edu,
eternity@internexus.net
From: Bill Stewart <bill.stewart@pobox.com>
In-Reply-To: <19990110184412.A1395@llyr.systemics.ai>
Reply-To: Bill Stewart <bill.stewart@pobox.com>
At 06:44 PM 1/10/99 -0400, Ryan Lackey wrote:
>Recent events have caused me to very very much wish there were a working
>Eternity system in place (losing my two primary hard drives in 6 months,
>government crackdown on many kinds of information, etc.)
Of course, it'd be far simpler and cheaper to do a good automated
backup system than an Eternity network, especially as disks get cheaper :-)
(though tape is _still_ really cheap, albeit annoying.)
A network-based version can give you physical off-site backups,
and becomes much more practical as DSL and cable modems provide
cheap always-on medium-speed connectivity.
The broadcast nature of cable and the high-downstream low-upstream bandwidths
could be a good match for a "neighborhood backup service" business,
while DSL is better suited to ISP-run disk/tape farms, but both would strongly
benefit from customer-managed crypto to create trust and prevent the
backup service from becoming a target for both crackers and cops.
> The thing I'm working on will be quite useful for an Eternity implementation
Er, the alleged thing that allegedly is being worked on could
allegedly be useful, in a totally independent open-source
non-conspiratorial way, to some alleged developer of some alleged
somewhat-Eternity-like implementation :-)
>What I'd like to know is what functionality people would want from
>an Eternity implementation written by someone who is actually a good
>programmer with a bit of spare time right now :)
I think there are two basic models that could drive feature selection
- fast Eternity - getting stuff back in quasi-real-time
- slow Eternity - getting stuff back in tomorrow's Usenet/email/etc.
The fast model gives you more choices of protocols, e.g. http,
but makes it easy to trace where the communications are going,
unless you piggyback on some sort of Pipenet. It's fine for
neighborhood backup businesses, but won't keep the FBI from finding you.
The slow model is less convenient, but more securable,
and a system doing very-long-term storage will probably have
slower access to older material.
I suppose you could do hybrids, using a slow background system
to store the data and a fast web-based system to retrieve cached versions,
or a fast convenient http storage with slow propagation,
maybe to a fast retrieval.
>Accepts (key, data) over the network and spits back (data) in response to (key)
>Should use some kind of vague standard like HTTP, maybe DAV extensions?
>Ideally a java client is provided too so one can just give it an object
>or serialized object and have it handle the storage.
It's valuable to make the interfaces simple and portable -
you want something usable on Win95/98/00 as well as Linux and *BSD,
at least for the client, and preferably also the server,
so protocol extensions and some java stuff are risky.
>Some kind of payment protocol (key, data, coin) where coin gets spent in
>time according to some formula.
There are at least three events that might need paying for:
- Initial Deposit
- Storage - either until-retrieved, per-year, or forever,
and "forever" isn't much more expensive than 1-2 years.
- Retrieval - Realistic models include multiple-retrieval as well as
retrieve-once-only, so this needs to be paid for separately.
Under current Internet business models, it may be feasible to
pay for web-based retrieval using advertising banners,
but that may be a losing long-term proposition,
as well as having some security implications.
>Potential features for future versions (should be extensible to include...)
>- ---------------
>replication/distribution across eternity nodes
>secure multiparty computation to split computation done by users of the
>Eternity system across multiple servers to protect from monitoring by
>the operators of eternity nodes
I don't think multi-party computation is the way to manage this;
the client probably needs to do secret-sharing herself rather than
trusting it to the servers (even if they also secret-share.)
(That may be more applicable to the retrieve-once model or at least
the retrieve-with-password model than the public-access model.)
But you do need to think carefully about this when designing
storage/retrieval/naming issues.
>computation/bandwidth too, supporting arbitrary code/execution in a java
>sandbox on the server
That's a really different business, and susceptible to infinite loops,
and other entertaining denial of service attacks,
and it's much harder to figure out how to charge for.
Thanks!
Bill
Bill Stewart, bill.stewart@pobox.com
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
