Send Freenet-dev mailing list submissions to
freenet-dev at lists.sourceforge.net
To subscribe or unsubscribe via the web, visit
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
or, via email, send a message with subject or body 'help' to
freenet-dev-request at lists.sourceforge.net
You can reach the person managing the list at
freenet-dev-admin at lists.sourceforge.net
When replying, please edit your Subject line so it is more specific than
"Re: Contents of Freenet-dev digest..."
Today's Topics:
1. Re: Masada interview? (Oskar Sandberg)
2. Re: Masada interview? (Brandon)
3. Re: Meaningless hits on metadata (Daniel Phillips)
4. Re: Masada interview? (Scott G. Miller)
5. Forwaeding a message from freenet-chat (Muzzle)
6. Re: Self Censorship (Muzzle)
7. Re: Forwaeding a message from freenet-chat (Oskar Sandberg)
8. Re: Self Censorship (Oskar Sandberg)
9. Re: Self Censorship (Jason Marshall)
10. Re: Self Censorship (Oskar Sandberg)
11. Re: Hello all, here is my (minor) contribution.. :) (Fredrik Hubinette)
12. Re: KHK Metadata Proposal (Benjamin Coates)
13. Re: Re: KHK Metadata Proposal (Benjamin Coates)
14. Re: Re: KHK Metadata Proposal (Benjamin Coates)
15. Re: KHK Metadata Proposal (Benjamin Coates)
16. Re: Hello all, here is my (minor) contribution.. :) (Scott G. Miller)
--__--__--
Message: 1
Date: Thu, 22 Jun 2000 21:07:49 +0200 (MET DST)
From: Oskar Sandberg <md98-...@nada.kth.se>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Masada interview?
Reply-To: freenet-dev at lists.sourceforge.net
I got something from some TV-show a couple of days ago that seemed to
be sent to just about everybody. Did anyone answer that?
Haven't gotten anything by a Masada though.
I'm guessing that the reason that some press is spiling over unto the
rest of us is that Ian has been on the road and not answering is
email. I would just forward it to Ian's temporary mail and/or tell
the reporter to fuck off (I really love journalists), but if you want
to do an interview, who is going to stop you?
Oskar Sandberg
md98-osa at nada.kth.se
On Thu, 22 Jun 2000, Scott G. Miller wrote:
> Did anyone else get contacted by a Drew Masada about an interview? I
> don't mind granting one, but I'd rather have some backup for those things
> that I'm not incredibly eloquent about.
>
>
>
--__--__--
Message: 2
Date: Thu, 22 Jun 2000 14:20:32 -0500 (CDT)
From: Brandon <bl...@uts.cc.utexas.edu>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Masada interview?
Reply-To: freenet-dev at lists.sourceforge.net
> I got something from some TV-show a couple of days ago that seemed to
> be sent to just about everybody. Did anyone answer that?
Nah, TV reporters are the worst. They want a 20 second sound byte.
> Haven't gotten anything by a Masada though.
Apparently this was the same person that e-mailed me because she just
called me and said her name was Drew Masada. She's not a real journalist,
though, but a journalism student working for a university newspaper (I
think). Anyway, I told her I'd talk to her tonight.
> > I'm guessing that the reason that some press is spiling over unto the
> rest of us is that Ian has been on the road and not answering is
> email.
I agree, that's probably the reason.
--__--__--
Message: 3
From: Daniel Phillips <phill...@bonn-fries.net>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Meaningless hits on metadata
Date: Thu, 22 Jun 2000 17:56:13 +0200
Reply-To: freenet-dev at lists.sourceforge.net
On Wed, 21 Jun 2000, Brandon wrote:
> Metadata is dropped like normal data based on the number of hits it
> gets. I'm somewhat concerned about the number of naive hits that might
> results from searches. Which is why server-side signature validation would
> be good. A metadata unrequest mechanism would also work.
Why not ignore all hits directly on metadata and just propagate hits on the
underlying data back to the metadata. This be pretty simple and hard to
exploit.
--
Daniel
--__--__--
Message: 4
Date: Thu, 22 Jun 2000 16:15:23 -0500
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Masada interview?
protocol="application/pgp-signature"; boundary="wq9mPyueHGvFACwf"
From: "Scott G. Miller" <scgmi...@indiana.edu>
Reply-To: freenet-dev at lists.sourceforge.net
--wq9mPyueHGvFACwf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
>=20
> Never heard of the man. Some guy with the e-mail Rainraven e-mailed
> yesterday asking for an interview. It might be the same guy. I said sure,
> why the heck not, let's talk about Freenet, but he hasn't gotten back to
> me.
Thats the guy. Want to try to get him/her on IRC at the same time so we
can tag-team him?
--wq9mPyueHGvFACwf
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE5UoHrpXyM95IyRhURAs3uAJ9BseTSO4LsGZ0o8IXyVJ4JfDdQeQCeLUqr
2540jEpAJS/I9FlebIv0aFo=
=hL/F
-----END PGP SIGNATURE-----
--wq9mPyueHGvFACwf--
--__--__--
Message: 5
From: "Muzzle" <muz...@freemail.it>
To: "Freenet-dev" <freenet-dev at lists.sourceforge.net>
Date: Mon, 19 Jun 2000 11:38:55 +0200
Reply-To: "Muzzle" <muzzle at freemail.it>
Subject: [Freenet-dev] Forwaeding a message from freenet-chat
Reply-To: freenet-dev at lists.sourceforge.net
Here is a message sent some time ago on freenet-chat.
I'm sorry if you already read it, I think it is an interestig
proposal.
Michele
---------------------------------------------------------------
1. Pinned data
This tells your own server never to de-cache a given key. For when
you know you want to serve content onto freenet, whether or not anyone
wishes to read it. Of course, if they don't, it won't migrate beyond
your own machine. Pinned status is not sent with data when it's
requested, it only applies to the local server.
2. Dynamic
This marks the data as not to be cached. In practise, that means it's
put into the stack below the "threshold", as routing data only, once
it's ben successfully sent. This is for CGIs and other dynamic content
where the sender doesn't mind it being destructible, but would still
want it not to be traceable. The "dynamic" marker should be sent with
the data all the way to its destination.
3. Transient
This is for data being served in a "napster" style fashion from a
transient client/server program. All it does is warn intervening
servers that the source may be going away soon, so caching more
aggressively might be worthwhile. This transmits with the data, but
could perhaps be stripped off by the first non-transient server to
cache it.
---------------------------------------------------------------
--
Muzzle, Flatline, Zero on IRC; ICQ# 36124438
Key fingerprint: 5881 356B DDA7 115B 6FAF C529 34ED 70A8 7E52 D805
www.internations.net/it/muzzle
"We are, we can, we will"
--__--__--
Message: 6
From: "Muzzle" <muz...@freemail.it>
To: "freenet-dev at lists.sourceforge.net" <freenet-dev at
lists.sourceforge.net>
Date: Thu, 22 Jun 2000 21:34:04 +0200
Reply-To: "Muzzle" <muzzle at freemail.it>
Subject: Re: [Freenet-dev] Self Censorship
Reply-To: freenet-dev at lists.sourceforge.net
What if we span the files in 64Kb encrypted data blocks each one
pointing to the next one? (and only the first one have the metadata)
-Nearly impossible traffic analysis
-You don't have illegal material, you have just a piece of it (how does
law deal with it?)
-You cant decrypt a file and see its content without having it whole.
Who is expected to collect each piece of each first block of file he
has?
The firs block could be in a secure node and the other ones elsewhere
around even in us or china nodes.
I think its time to split file. It has lots of advantages, many more
than those I wrote here, and little or none side effects.
see ya
Michele
--
Muzzle, Flatline, Zero on IRC; ICQ# 36124438
Key fingerprint: 5881 356B DDA7 115B 6FAF C529 34ED 70A8 7E52 D805
www.internations.net/it/muzzle
"We are, we can, we will"
--__--__--
Message: 7
Date: Fri, 23 Jun 2000 00:04:01 +0200 (MET DST)
From: Oskar Sandberg <md98-...@nada.kth.se>
To: Freenet-dev <freenet-dev at lists.sourceforge.net>
Subject: Re: [Freenet-dev] Forwaeding a message from freenet-chat
Reply-To: freenet-dev at lists.sourceforge.net
On Mon, 19 Jun 2000, Muzzle wrote:
> Here is a message sent some time ago on freenet-chat.
> I'm sorry if you already read it, I think it is an interestig
> proposal.
>
> Michele
>
> ---------------------------------------------------------------
> 1. Pinned data
>
> This tells your own server never to de-cache a given key. For when
> you know you want to serve content onto freenet, whether or not anyone
> wishes to read it. Of course, if they don't, it won't migrate beyond
> your own machine. Pinned status is not sent with data when it's
> requested, it only applies to the local server.
This doesn't work. I have explained why at least dozen times now, so
I am getting a little tired of it (making data available is not the
issue, finding it is).
Maybe marrying Freenet to an Eternity type permanent data storage
solution will make sense down the line, but trying this is not the
way to do it.
> 2. Dynamic
>
> This marks the data as not to be cached. In practise, that means it's
> put into the stack below the "threshold", as routing data only, once
> it's ben successfully sent. This is for CGIs and other dynamic content
> where the sender doesn't mind it being destructible, but would still
> want it not to be traceable. The "dynamic" marker should be sent with
> the data all the way to its destination.
How can you generate dynamic content when it is not being sent from
your own machine? I'm guessing you meant this to go with the first
thing, which makes it irrellevant. You seem to think that there is a
way to locate somebodies server on Freenet: there is not, only data
can be located.
Note also that even were it possible, this would be a huge security
hole. Anything that sends the routing information and not the data
allows an attacker to home in and disable nodes where information is
stored, without in effect spreading it elsewhere.
> 3. Transient
>
> This is for data being served in a "napster" style fashion from a
> transient client/server program. All it does is warn intervening
> servers that the source may be going away soon, so caching more
> aggressively might be worthwhile. This transmits with the data, but
> could perhaps be stripped off by the first non-transient server to
> cache it.
Transient nodes already exist. They simply never mark data as
originating from them, and will therefore not get any requests.
> ---------------------------------------------------------------
>
>
> --
> Muzzle, Flatline, Zero on IRC; ICQ# 36124438
> Key fingerprint: 5881 356B DDA7 115B 6FAF C529 34ED 70A8 7E52 D805
> www.internations.net/it/muzzle
> "We are, we can, we will"
>
>
>
> _______________________________________________
> Freenet-dev mailing list
> Freenet-dev at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/freenet-dev
>
--__--__--
Message: 8
Date: Fri, 23 Jun 2000 00:11:00 +0200 (MET DST)
From: Oskar Sandberg <md98-...@nada.kth.se>
To: "freenet-dev at lists.sourceforge.net" <freenet-dev at
lists.sourceforge.net>
Subject: Re: [Freenet-dev] Self Censorship
Reply-To: freenet-dev at lists.sourceforge.net
Splitting up data is a good idea. Probably we should use serveral
part sizes, maybe 32,64,256,1024, and 4096 kbytes (most web pages
fit in 32, but you don't want a movie to be in 16,000 parts).
Note that each part should not link to the next, but rather that an
index of the parts should come first. Freenet's model means rather
bad performance for each download, but the ability to request as many
parts as one pleases in parrallel, hindered only by ones own
connection.
Also note that even if all things were padded/split to a uniform part
size, this does not defeat traffic analysis, which looks at other
factors like timing as well. It certainly makes things more difficult
though.
Oskar Sandberg
md98-osa at nada.kth.se
On Thu, 22 Jun 2000, Muzzle wrote:
> What if we span the files in 64Kb encrypted data blocks each one
> pointing to the next one? (and only the first one have the metadata)
>
> -Nearly impossible traffic analysis
> -You don't have illegal material, you have just a piece of it (how does
> law deal with it?)
> -You cant decrypt a file and see its content without having it whole.
>
> Who is expected to collect each piece of each first block of file he
> has?
> The firs block could be in a secure node and the other ones elsewhere
> around even in us or china nodes.
> I think its time to split file. It has lots of advantages, many more
> than those I wrote here, and little or none side effects.
> see ya
>
> Michele
>
>
> --
> Muzzle, Flatline, Zero on IRC; ICQ# 36124438
> Key fingerprint: 5881 356B DDA7 115B 6FAF C529 34ED 70A8 7E52 D805
> www.internations.net/it/muzzle
> "We are, we can, we will"
>
>
>
> _______________________________________________
> Freenet-dev mailing list
> Freenet-dev at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/freenet-dev
>
--__--__--
Message: 9
From: Jason Marshall <jason@george.localnet>
Subject: Re: [Freenet-dev] Self Censorship
To: freenet-dev at lists.sourceforge.net
Date: Thu, 22 Jun 2000 15:04:28 -0700 (PDT)
Reply-To: jmarsh at serv.net
Reply-To: freenet-dev at lists.sourceforge.net
> Splitting up data is a good idea. Probably we should use serveral
> part sizes, maybe 32,64,256,1024, and 4096 kbytes (most web pages
> fit in 32, but you don't want a movie to be in 16,000 parts).
Hrmm.. I think 4M might be a bit large at this point in time. In
practice, people will probably come up with rules of thumb for what
block sizes get the transfer done fastest. I suspect it'll be more in
the 64-256k range. I would also suggest you just do all powers of two
>= 4k. As the network grows, optimal block size will change slowly,
and you may want to have that extra bit of granularity, plus, if
some breakthrough in networking accelerates bandwidth, you don't want
to be caught with servers refusing really big files. Connecting and
sending lots of small files is generally a better DOS attack anyway,
since setting up and tearing down transactions frequently cost as
much as the transaction itself. So I'm not sure what a file size cap
will do to harden the system. (NB that some of this sentiment may
be in direct conflict with earlier statements on my part).
> Note that each part should not link to the next, but rather that an
> index of the parts should come first. Freenet's model means rather
> bad performance for each download, but the ability to request as many
> parts as one pleases in parrallel, hindered only by ones own
> connection.
The slower of your connection, or the transfer time for the slowest
server that delivers a chunk. If it's a 4M piece, that could be very
significant.
> Also note that even if all things were padded/split to a uniform part
> size, this does not defeat traffic analysis, which looks at other
> factors like timing as well. It certainly makes things more difficult
> though.
True. But most security mavens like to have any extra edge they can get.
Even if it only lessens an evil without destroying it.
-Jason
--__--__--
Message: 10
Date: Fri, 23 Jun 2000 01:07:20 +0200 (MET DST)
From: Oskar Sandberg <md98-...@nada.kth.se>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Self Censorship
Reply-To: freenet-dev at lists.sourceforge.net
On Thu, 22 Jun 2000, Jason Marshall wrote:
> Hrmm.. I think 4M might be a bit large at this point in time. In
> practice, people will probably come up with rules of thumb for what
> block sizes get the transfer done fastest. I suspect it'll be more in
> the 64-256k range. I would also suggest you just do all powers of two
> >= 4k. As the network grows, optimal block size will change slowly,
> and you may want to have that extra bit of granularity, plus, if
> some breakthrough in networking accelerates bandwidth, you don't want
> to be caught with servers refusing really big files. Connecting and
> sending lots of small files is generally a better DOS attack anyway,
> since setting up and tearing down transactions frequently cost as
> much as the transaction itself. So I'm not sure what a file size cap
> will do to harden the system. (NB that some of this sentiment may
> be in direct conflict with earlier statements on my part).
I meant 4 megs mostly for the future. I don't know if it is too
unreasonable, even a fairly slow connection (ISDN say) can pump that
in about 5 minutes. Though I agree that all powers of two is probably
better.
> > Note that each part should not link to the next, but rather that an
> > index of the parts should come first. Freenet's model means rather
> > bad performance for each download, but the ability to request as many
> > parts as one pleases in parrallel, hindered only by ones own
> > connection.
>
> The slower of your connection, or the transfer time for the slowest
> server that delivers a chunk. If it's a 4M piece, that could be very
> significant.
The speed of each piece is limited by the slowest connection on the
transfer route. The number of pieces you can get in parrallel only
depends on your own capacity though, since the paths will most
probably diverge after your own node.
> > Also note that even if all things were padded/split to a uniform part
> > size, this does not defeat traffic analysis, which looks at other
> > factors like timing as well. It certainly makes things more difficult
> > though.
>
> True. But most security mavens like to have any extra edge they can get.
> Even if it only lessens an evil without destroying it.
Actually, true security is an all or nothing thing...
>
> -Jason
>
> _______________________________________________
> Freenet-dev mailing list
> Freenet-dev at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/freenet-dev
>
--__--__--
Message: 11
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Hello all, here is my (minor) contribution.. :)
From: Fredrik Hubinette <hu...@hubbe.net>
Date: 22 Jun 2000 16:56:27 -0700
Reply-To: freenet-dev at lists.sourceforge.net
I've been fiddling around with my PCP freenet support and I have a bunch
of requests/reports/suggestions.
1) some nodes seems to reply with "HandshakeReplyDepth=1\r\n", ie.
no newline afte the HandshakeReply. Looks like a bug to me.
2) It would be very nice to be able to re-start an aborted file
request. This requires something similar to the ftp REST command.
3) Could it be possible to add a crc32, md5 or sha1 checksum to the
headers returned with the DataReply? This would be especially
important while the project is still in development. I also need
this to be able to determine weather the spurious errors I see in
some files are because of my client, because of some node, or because
the errors were in the file when it was inserted.
/Hubbe
--__--__--
Message: 12
To: freenet-dev at lists.sourceforge.net
Date: Thu, 22 Jun 2000 18:14:32 -0700
Subject: Re: [Freenet-dev] KHK Metadata Proposal
From: Benjamin Coates <coatesforh...@juno.com>
Reply-To: freenet-dev at lists.sourceforge.net
From: Joseph Solbrig <jsolb...@webcom.com>
> One person's
> spam is another person's useful information. Majority
> votes mean nothing since then it's the tyranny of the majority.
I agree. That's why a transitive trust system is useful -- You have
control over what you see and don't see. One would tend to trust others
who shared the same definitions of relevancy as you. The system itself
makes no value judgements whatsoever, and the mess of general / average
opinion would not have any influence on what I see.
Any individual could, of course, choose to see everything and not employ
the trust system at all.
--
Benjamin Coates
________________________________________________________________
YOU'RE PAYING TOO MUCH FOR THE INTERNET!
Juno now offers FREE Internet Access!
Try it today - there's no risk! For your FREE software, visit:
http://dl.www.juno.com/get/tagj.
--__--__--
Message: 13
To: freenet-dev at lists.sourceforge.net
Date: Thu, 22 Jun 2000 17:21:54 -0700
Subject: Re: [Freenet-dev] Re: KHK Metadata Proposal
From: Benjamin Coates <coatesforh...@juno.com>
Reply-To: freenet-dev at lists.sourceforge.net
From: "Scott G. Miller" <scgmi...@indiana.edu>
>> Why even bother with unsigned metadata? It doesn't appear to
>> have any great use (if signed metadata were available), and it
>> would be a simpler protocol and easier to code if there was
>> only one kind instead of two.
> Because if you have to sign it, you lose anonymity. Freenet
> should cater to both parties.
You can sign it with an anonymous key. If you're way paranoid and are
afraid of that, then just don't post metadata. Unsigned metadata will
get lost in the spam and be useless anyway.
Oh yeah: Generating a one-time key, signing the metadata, and throwing
away the key is still better than unsigned metadata, because then other
people who happen across your metadata can publicize their trust for it
(the one-use key) and it will have a chance to spread through people that
trust them. Making this work for unsigned metadata would require a whole
new layer of complexity (trusting individual metadata instead of signers)
--
Benjamin
________________________________________________________________
YOU'RE PAYING TOO MUCH FOR THE INTERNET!
Juno now offers FREE Internet Access!
Try it today - there's no risk! For your FREE software, visit:
http://dl.www.juno.com/get/tagj.
--__--__--
Message: 14
To: freenet-dev at lists.sourceforge.net
Date: Thu, 22 Jun 2000 16:45:56 -0700
Subject: Re: [Freenet-dev] Re: KHK Metadata Proposal
From: Benjamin Coates <coatesforh...@juno.com>
Reply-To: freenet-dev at lists.sourceforge.net
From: Brandon <bl...@uts.cc.utexas.edu>
> Some people might not want to sign metadata. You could generate
> a new random key to sign it with and that would be about the same
> as not signing it. But it would actually be easier to code with
optional
> metadata. I don't like to generate random values when you could just
> make the field optional and give no value.
I suppose that makes sense. I'm just concerned that unsigned metadata
will be mostly spam.
> That would be fine. It's just a question of is the save in bandwidth
> great enough to justify the increased CPU usage from having
> servers check signatures. I think so, but it's open to debate.
I was thinking more along the lines of having a standard metadata entry
like "metadata-signer"=<public key or fingerprint>. The server would
just assume that the signature was valid, so it doesn't have to spend CPU
time checking it. The client would do the actual work of confirming that
the signature was what it claimed to be.
On a related note, should anyone be allowed to post metadata, or just the
inserter of the document in question? Could one document have multiple
metadata? If the answers are "just the inserter" and/or "no", does the
proposal address how we enforce this?
--
Benjamin Coates
________________________________________________________________
YOU'RE PAYING TOO MUCH FOR THE INTERNET!
Juno now offers FREE Internet Access!
Try it today - there's no risk! For your FREE software, visit:
http://dl.www.juno.com/get/tagj.
--__--__--
Message: 15
To: freenet-dev at lists.sourceforge.net
Date: Thu, 22 Jun 2000 17:09:51 -0700
Subject: Re: [Freenet-dev] KHK Metadata Proposal
From: Benjamin Coates <coatesforh...@juno.com>
Reply-To: freenet-dev at lists.sourceforge.net
From: Alexander Barnell <ae...@doc.ic.ac.uk>
> There's no point in having automatic serverside authentication of
> Metadata, it would harm efficiency.
But we could do unverified "search-by-signer" almost for free, like in my
previous post.
> A better way is to let the client take most of the work. There are
> two ways in which this is possible:
> A more advanced technique would be for a message to be sent
> back to the nodes to the effect "hey guys, this metadata is bogus:
> delete it please". Any nodes detected as trying to elliminate
> valid data can be added to the ignore list of nodes, to prevent
> further communicaition with them.
I like it. Since a signature can be objectively verified, there is no
censorship concern, and if the server was too busy to worry about such
things, it could just ignore the request to delete.
> 2. I envisage a web-of-trust Metadata search, where the client
> software will sort search results based upon not only how
> well the Metadata matches the request in
> fuzzy-string/substring/whatever terms, but also how much
> trust the user has in the authors of the Metadata.
I'm a big proponent of a web-of-trust backed search system. (Though I
hate that name, we've gotta get that "web" out of there)
> The details of the transitive trust calculations are unimportant
> - it is possible in many ways.
I would just go for a two-list system: one list is people you
trust/distrust to post good metadata, the other is a list of people you
trust to manage their trust-lists well. I don't think you can really
have negative transitive trust, though: If I distrust person A, and they
trust person B, that does *not* mean I distrust person B.
> Anyway, back to the point: Any metadata being returned that is
> not trusted by the user can be immediatly unrequested,
> although still displayed to the user. This gives the user the
> opportunity to trust previously untrusted authors, whilst
> gradually elliminating metadata that never gets trusted
> (spam, for example!) If a user trusts a just-unrequested piece
> of Metadata, the metadata can be re-requested to elliminate
> the effect of the unrequest.
I don't like unrequests. They seem like trouble waiting to happen.
> I believe these two methods will be effective in elliminating
> the obvious threat of spam in any searching mechanism.
> Censorship of 'valid' data by majority is something to consider
> in more detail.
I don't think that will be a problem, as a good web-of-trust system would
not concern itself with any generalized "public opinion" value. If a
bunch of spammers got together and signed up to trust each other, then
they'd all get spam, but that shouldn't make the spam metadata considered
"trusted" from some sort of general viewpoint. Likewise, If a group of
Hubologists got together and marked everything not written by the great
Elron '-1.0', it should have no effect at all on anyone else.
--
Benjamin Coates
________________________________________________________________
YOU'RE PAYING TOO MUCH FOR THE INTERNET!
Juno now offers FREE Internet Access!
Try it today - there's no risk! For your FREE software, visit:
http://dl.www.juno.com/get/tagj.
--__--__--
Message: 16
Date: Thu, 22 Jun 2000 22:14:37 -0500
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Hello all, here is my (minor) contribution.. :)
protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH"
From: "Scott G. Miller" <scgmi...@indiana.edu>
Reply-To: freenet-dev at lists.sourceforge.net
--7JfCtLOvnd9MIVvH
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
> 1) some nodes seems to reply with "HandshakeReplyDepth=1\r\n", ie.
> no newline afte the HandshakeReply. Looks like a bug to me.
Probly.
> 2) It would be very nice to be able to re-start an aborted file
> request. This requires something similar to the ftp REST command.
Yep.
> 3) Could it be possible to add a crc32, md5 or sha1 checksum to the
> headers returned with the DataReply? This would be especially
> important while the project is still in development. I also need
> this to be able to determine weather the spurious errors I see in
> some files are because of my client, because of some node, or because
> the errors were in the file when it was inserted.
Being done. CHKs (the actual data documents) will be inherently
verifyable with a hashing scheme. Ask oskar for more (oh Oskar!)
--7JfCtLOvnd9MIVvH
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE5UtYdpXyM95IyRhURAq+fAKDMhTs+1VcTLZBzpRC8oCHpa2bM5wCffOOK
mmBu5FGkpdDJvbwUCudeaps=
=hcVF
-----END PGP SIGNATURE-----
--7JfCtLOvnd9MIVvH--
--__--__--
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
End of Freenet-dev Digest
