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: Suggestion for ease of use.. (Brandon)
2. RE: negative trust (Benjamin Coates)
3. Re: KHK Metadata Proposal (Brandon)
4. Re: Forwaeding a message from freenet-chat (Brandon)
5. Re: Meaningless hits on metadata (Brandon)
6. Re: Re: KHK Metadata Proposal (Scott G. Miller)
7. Re: KHK Metadata Proposal (Scott G. Miller)
8. Re: Meaningless hits on metadata (Daniel Phillips)
9. Re: KHK Metadata Proposal (Brandon)
10. Re: KHK Metadata Proposal (Oskar Sandberg)
11. Re: Meaningless hits on metadata (Alex Barnell)
12. Re: A Metadata Filtering Proposal (Alex Barnell)
13. 0.3 Todo List (Alex Barnell)
14. 0.3 Todo List (Alex Barnell)
15. Re: KHK Metadata Proposal (Rick Dietz)
16. Re: KHK Metadata Proposal (Scott G. Miller)
17. Re: KHK Metadata Proposal (Henry Hemming)
18. Re: 0.3 Todo List (Scott G. Miller)
--__--__--
Message: 1
Date: Sat, 24 Jun 2000 14:15:33 -0500 (CDT)
From: Brandon <bl...@uts.cc.utexas.edu>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Suggestion for ease of use..
Reply-To: freenet-dev at lists.sourceforge.net
> 1) Encourage people to setup a CNAME or A record called
> freenet.yourdomain.yourtopdomain and run the freenet node
> on the default port. For people who are too lazy to run their
> own node, this could point to someone elses node..
>
> 2) Encourage freenet clients use "freenet:19114" as a default
> node if no node is specified and no node answers on
> "localhost:19114".
This would make things easier, but it's also bad for two reasons. The
first is bad because it relies on dns, but as long as it's just a
convenient and we're not dependent on it to work then that's okay. Both
solutions have the problems that they make it easier to find Freenet
nodes. This is, of course, your point because easier to find nodes means
an easier to find network, but it also means easier to persecute node
runners. So I should say that people should be encouraged to do this only
with a lot of disclaimers about how it's more dangerous but will make
everything easier to use for everyone else.
--__--__--
Message: 2
Date: Sat, 24 Jun 2000 15:18:47 -0400
From: Benjamin Coates <coa...@mailandnews.com>
To: freenet-dev at lists.sourceforge.net
Subject: RE: [Freenet-dev] negative trust
Reply-To: freenet-dev at lists.sourceforge.net
> From Greg Titus <toon at omnigroup.com>
>> B trusts C.
>> C trusts D.
>> D stops being trustworthy, and starts spamming.
>> B puts D on a negative-trust list to stop the spam.
>> (time passes)
>> A begins trusting B.
>> A gets a bunch of D`s spam.
>I wouldn't call it a negative-trust list, because there is no negative in
>your system, but maybe a "do-not-care-after-all list". The difference between
>a do-not-care list and a blacklist is, in a blacklist you immediately discard
>anything by that key while in a do-not-care list, you only ignore that single
>link in the trust chain. If that key is trusted through some other link in
>your trust tree, you use those results after all.
>In the case quoted above, B puts "C except for D" in his trust list, which
>A's client sees when A is generating his whitelist. The reason why, IMHO,
>this doesn't have any censorship implications is because B explicitly names
D,
>giving A the opporunity to decide for himself whether to trust C or D
>directly and continue to get results from D.
I put another in another mail today where B revokes meta-trust for C until C
stops trusting D. This is effectively a secret local blacklist of D: No one
who trusts D, known spammer, is to be meta-trusted (obviously they don't know
how to trust effectively) C (and only C) would be told about this, and if C
agreed that trusting D was a bad idea and took her off, C would be
automatically put back on B's list.
This isn't really B "threatening" C with anything, because unless C is a very
insecure individual, he won't care whether or not B trusts him. He may wish
to know that he is (probably accidentally) trusting a spammer, however.
> BTW, as a suggestion: I think it is very likely with a system like this that
> "expert trust lists" will arise where key X is widely known as an authority
on
> mp3's (for example) and there end up being many many users that add X to
> their trust list. It may make sense to be able to rate the importance of
> trusted keys on your client (or categorize your trusted keys to make X most
> important when you are looking for that type of content) and send the N most
> trusted keys along with your search query. Then the node where search
results
> are found can give priority to those results which are signed by the keys
you
> include. If you want more results than that, it can also continue to pass
back
> other matches, but only the matches that were explicitly asked for by
> signature key would be cached on nodes on the way back to the client.
> This would have the advantage of doing more work on the node to reduce
> bandwidth heading back to the client, plus it solves the problem where spam
> gets replicated over all the nodes - only the metadata signed by keys you
> explicitly asked for would get cached closer to you.
> On the other hand, it has the disadvantage of doing more work on the node.
> You'd probably want to actually do the signature verification on the node to
> keep spammers from faking signature's by popular trusted keys (caching those
> results all over, and only having it be discovered on each individual
client).
> Doing the signature verification does, however, have the advantage that you
> could immediately discard that signature from the node entirely if it
doesn't
> verify.
>
> --Greg
Hmm... that's a good idea, I was afraid we'd have to throw out
search-by-signer to use my proposal, but this would work, as long as we keep
the number of keys under some sane limit (I was thinking that heavily used
clients might keep a whitelist on the order of 1 million or more keys). But
if the client had some sort of logic to match queries to likely metadata
signers, and sent the top dozen (or so?) with the request, that could
potentially save a lot of bandwidth.
--
Benjamin Coates
--__--__--
Message: 3
Date: Sat, 24 Jun 2000 14:23:06 -0500 (CDT)
From: Brandon <bl...@uts.cc.utexas.edu>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK Metadata Proposal
Reply-To: freenet-dev at lists.sourceforge.net
> Honestly I don't see the point of having a KHK involved in this. It
> allows for collisions, which is kind of silly. Why not just have a
> descriptive, non-key name in the metadata. Then the client can bookmark
> the CHKs and SVKs it points to under that name.
It allows for collisions but that's not that big a deal because you're
getting the information through searching the metadata or typing in the
key, so you can easily come up with a unique key. It doesn't even
technically need to be descriptive, it just needs to be easy to remember,
though descriptive is better.
The need for KHK is so that there is a human readable key which you can
use to pass references around. Bookmarks don't work because you can't take
them with you, speak them, or write them on a napkin easily.
But I think this solution will be fine and have and not really have any
bad effects. It requires only 1 extra message at insert time. It requires
only one message to retrieve by KHK, and we've already written all the KHK
code. It also requires no protocol changes. It only requires some new
conventions for the clients and those are just going to be included in the
conventions for handling metadata, which haven't been written yet, so we
don't even have to change anything which we weren't going to change
anyway.
--__--__--
Message: 4
Date: Sat, 24 Jun 2000 14:27:48 -0500 (CDT)
From: Brandon <bl...@uts.cc.utexas.edu>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Forwaeding a message from freenet-chat
Reply-To: freenet-dev at lists.sourceforge.net
> I don't like the idea of using Freenet as a network with visible services
> or servers on it. In all honesty, Freenet is a datastore. Applications
> that want to be more complicated should only use freenet as such. There
> are a lot of very good client-side applications that could be written
> without any server side support, and anything more complicated could be
> done out of band.
I see Freenet as a way to anonymously get information. A lot of the
anonymous network design could be used apart from the caching of static
content. I would like to be able to use Freenet to get web pages. It would
be a very good caching, anonymizing proxy. This a really far away though
and is just an idea at this point.
--__--__--
Message: 5
Date: Sat, 24 Jun 2000 14:30:33 -0500 (CDT)
From: Brandon <bl...@uts.cc.utexas.edu>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Meaningless hits on metadata
Reply-To: freenet-dev at lists.sourceforge.net
> Some things are just too obvious to see right away. If the user originates
> the
> data request through the same server as the search (the normal case) then that
> server can easily associate the metadata with the data, and can "touch" the
> metadata at the appropriate time.
Metadata is routed differently from data so that such association is
avoided.
--__--__--
Message: 6
Date: Sat, 24 Jun 2000 14:51:36 -0500
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Re: KHK Metadata Proposal
protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X"
From: "Scott G. Miller" <scgmi...@indiana.edu>
Reply-To: freenet-dev at lists.sourceforge.net
--LZvS9be/3tNcYl/X
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
> aprox 10,000 path of variable length, even concidering that some of the=
=20
> nodes will be the same it does affect freenet on the large.
No, you misunderstand. The data would be cached to the edge of the
network closest to the company/entity. It would *not* affect the entire
path of the request.
--LZvS9be/3tNcYl/X
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
iD8DBQE5VRFIpXyM95IyRhURAoJ/AKCXjxUBNLnIRAlaqU3L6pUSXlU9VACg13QN
dYeLwO4vKn6L2NpPh2J5zwg=
=BwA2
-----END PGP SIGNATURE-----
--LZvS9be/3tNcYl/X--
--__--__--
Message: 7
Date: Sat, 24 Jun 2000 14:58:50 -0500
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK Metadata Proposal
protocol="application/pgp-signature"; boundary="gatW/ieO32f1wygP"
From: "Scott G. Miller" <scgmi...@indiana.edu>
Reply-To: freenet-dev at lists.sourceforge.net
--gatW/ieO32f1wygP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
>=20
> But I think this solution will be fine and have and not really have any
> bad effects. It requires only 1 extra message at insert time. It requires
> only one message to retrieve by KHK, and we've already written all the KHK
> code. It also requires no protocol changes. It only requires some new
> conventions for the clients and those are just going to be included in the
> conventions for handling metadata, which haven't been written yet, so we
> don't even have to change anything which we weren't going to change
> anyway.
Alright, I can buy that.
--gatW/ieO32f1wygP
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
iD8DBQE5VRL6pXyM95IyRhURAraxAJ0fM9LrABdEVBmY/Zfk4FAQViGvoQCgzA4w
C7But6Ac/Uy6bZ+tM6YtXM8=
=MJwJ
-----END PGP SIGNATURE-----
--gatW/ieO32f1wygP--
--__--__--
Message: 8
From: Daniel Phillips <phill...@bonn-fries.net>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Meaningless hits on metadata
Date: Sun, 25 Jun 2000 02:50:36 +0200
Reply-To: freenet-dev at lists.sourceforge.net
On Sat, 24 Jun 2000, Brandon wrote:
> > Some things are just too obvious to see right away. If the user originates
> > the
> > data request through the same server as the search (the normal case) then
> > that
> > server can easily associate the metadata with the data, and can "touch" the
> > metadata at the appropriate time.
>
> Metadata is routed differently from data so that such association is
> avoided.
I was talking about the server from which both the search and the data request
orginate.
--
Daniel
--__--__--
Message: 9
Date: Sun, 25 Jun 2000 04:11:45 -0500 (CDT)
From: Brandon <bl...@uts.cc.utexas.edu>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK Metadata Proposal
Reply-To: freenet-dev at lists.sourceforge.net
> Alright, I can buy that.
Yay! Then I'm going to consider this proposal accepted until I hear
otherwise (nothing is really accepted until it's in the code and
released). So the next item to work out, proposal wise, is
searching. Which brings me to the 0.3 todo list.
- searching
- GUI
- metadata
- node to node encryption
- file encryption
This is in order of difficult to get done. While CHKs and SVKs are
incredibly important, I think that these items are more important to get
into the next release. Mainly it's searching and GUI. We've suddenly
acquired all these darn users and I think we need to get something out to
them that they can actually use. It's okay if we rewrite everything
underneath them and make them upgrade to an new and incompatible version
every month but we need to get them something that they can use. The
encryption stuff is pretty much done so we should push that out there,
too. I don't consider the simulator to be so much part of the release
because most users probably won't use it, mainly developers.
So please add other important 0.3 stuff to this list and I'll try to come
up with some sort of organization, put it in the bug/task manager or
something.
We can expect, with the 60 minutes this, whenever it airs, to get a whole
slew of new users that don't understand command lines. And of course that
should be happening now, too, with the Time article.
--__--__--
Message: 10
Date: Sun, 25 Jun 2000 13:38:26 +0200 (MET DST)
From: Oskar Sandberg <md98-...@nada.kth.se>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK Metadata Proposal
Reply-To: freenet-dev at lists.sourceforge.net
On Sun, 25 Jun 2000, Brandon wrote:
> > Alright, I can buy that.
>
> Yay! Then I'm going to consider this proposal accepted until I hear
> otherwise (nothing is really accepted until it's in the code and
> released).
Exactly what? I have not been reading these discussions very
carefully, because by and by lrge they seem to be based on premises I
don't accept, and I certainly have not seen any ideas I particularly
like in what has been described.
Could you some up the idea that has been "accepted"?
> So the next item to work out, proposal wise, is
> searching. Which brings me to the 0.3 todo list.
>
> - searching
Not yet.
> - GUI
Who gives? There is already a gui client.
> - metadata
already done by Scott.
> - node to node encryption
this is done by Scott.
> - file encryption
this is done by Scott.
When I get done with Serapis I am going to code in support for
different keytypes and CHKs. That HAS to go in the next release.
> This is in order of difficult to get done. While CHKs and SVKs are
> incredibly important, I think that these items are more important to get
> into the next release. Mainly it's searching and GUI. We've suddenly
> acquired all these darn users and I think we need to get something out to
> them that they can actually use. It's okay if we rewrite everything
> underneath them and make them upgrade to an new and incompatible version
> every month but we need to get them something that they can use. The
> encryption stuff is pretty much done so we should push that out there,
> too. I don't consider the simulator to be so much part of the release
> because most users probably won't use it, mainly developers.
Serching is by the far the most difficult problem, and it is not
going to happen just like that.
A GUI shell for the node can be coded by everyone. If you are
reacting to the latest bunch of "I tried clicking on everything but
it just said bad command", then consider that these people do not
even have a JRE installed, so getting a GUI will hardly help them
(unless somebody feelslike writing and installshield type thing that
dls and installs a JRE).
> So please add other important 0.3 stuff to this list and I'll try to come
> up with some sort of organization, put it in the bug/task manager or
> something.
KeyTypes and there first usage for CHKs. Then SVKs (without
updating), and the more secure SVK-like KHKs.
Searching and updating, the "big two" will have to wait.
> We can expect, with the 60 minutes this, whenever it airs, to get a whole
> slew of new users that don't understand command lines. And of course that
> should be happening now, too, with the Time article.
I had a standing promise from you people that we would not let the
press attention control us.
That said, I wish I had gotten more work done this last month then I
did. A series of unexpected events (getting drunk, getting sick, and
then having go to the country) has kept me from the computer. That
means I no longer believe in a June 30th 0.3 as I had been hoping - I
need 2 more weeks.
>
> _______________________________________________
> Freenet-dev mailing list
> Freenet-dev at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/freenet-dev
>
--__--__--
Message: 11
Date: Sun, 25 Jun 2000 01:59:54 +0100
From: Alex Barnell <ae...@doc.ic.ac.uk>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Meaningless hits on metadata
Reply-To: freenet-dev at lists.sourceforge.net
Brandon wrote:
>
> > > Of course the way it's looking now, we're going to be able to actually
> > > encrypt the metadata, too. Even so, they'll be routed differently so nodes
> >
> > Er, which type of metadata can we encrypt? I know we can encrypt private
> > metadata routed attached to the document.
>
> Well yeah but that's not relevant because we can't search that. I'm just
> talking about the searchable metadata.
>
> We were thinking that with your search method you could encrypt all
> metadata by the search term.
>
I don't see how. Nodes need the plain-text of values to perform fuzzy
matching (and fuzzy routing). Nodes need the plain-text of fields to allow
matches to be performed in the case where the request includes just fields
A and B, but the node has something matching in its store with fields A, B
and C. If the fields were encrypted, there would be no way of knowing it
was a match.
--__--__--
Message: 12
Date: Sun, 25 Jun 2000 01:38:51 +0100
From: Alex Barnell <ae...@doc.ic.ac.uk>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] A Metadata Filtering Proposal
Reply-To: freenet-dev at lists.sourceforge.net
Benjamin Coates wrote:
> It's somewhat simpler than Alex's proposal in that extent because there are no
> levels of trust, and therefore no math to do regarding how much to trust
> someone who is trusted 0.8 by someone you trust 0.7, etc.
>
The reason I included 'levels' of trust in my proposal was so if we verifiy
two pieces of Metadata by some author as being correct, but not a third, then
it is difficult to say whether we trust them or not. In this example case, the
client could automatically give a trust value of 2/3 to that author. I think
this
would be on the whole more useful than yes or no.
But then again, I see your point about negative trust being fairly useless. A
compromise could be that we trust someone iff, say, over 90% of the metadata
they have published has been correct. And this trust would be a yes/no thing,
simplifying the maths tremendously (and probably the usefullness of results)
Very good proposal, I wish I was that good with words.. perhaps you could
write up some of mine :)
--__--__--
Message: 13
Date: Sun, 25 Jun 2000 13:10:01 +0100
From: Alex Barnell <ae...@doc.ic.ac.uk>
To: freenet-dev at lists.sourceforge.net
Subject: [Freenet-dev] 0.3 Todo List
Reply-To: freenet-dev at lists.sourceforge.net
Brandon wrote:
> Yay! Then I'm going to consider this proposal accepted until I hear
> otherwise (nothing is really accepted until it's in the code and
> released). So the next item to work out, proposal wise, is
> searching. Which brings me to the 0.3 todo list.
>
> - searching
> - GUI
> - metadata
> - node to node encryption
> - file encryption
>
- some standard for splitting/interleaving files.
This will allow larger files to be stored, and goes someway to hinder
the problem of interrupted downloads (since it limits the amount you
can lose). It also speeds up the rate at which nodes find out about
other nodes (because a 16-part file can return up to 16 unique
DataSources). Downloading from different routes should improve load
balancing across Freenet, because there is less chance of any
particular node being unused.
I have written the code to split and interleave files (almost ready to release),
but we
need a standard format for the header file, so that all clients can understand
it. We would also need to decide on a strategy for nodes hiding the fact they
hold all parts to a file (which could be done by a client instruction to
not cache all parts of a multi-part download).
--__--__--
Message: 14
Date: Sun, 25 Jun 2000 13:17:17 +0100
From: Alex Barnell <ae...@doc.ic.ac.uk>
To: freenet-dev at lists.sourceforge.net
Subject: [Freenet-dev] 0.3 Todo List
Reply-To: freenet-dev at lists.sourceforge.net
Oskar Sandberg wrote:
> A GUI shell for the node can be coded by everyone. If you are
> reacting to the latest bunch of "I tried clicking on everything but
> it just said bad command", then consider that these people do not
> even have a JRE installed, so getting a GUI will hardly help them
> (unless somebody feelslike writing and installshield type thing that
> dls and installs a JRE).
>
This is a great idea, but is it legal to just grab and install the JRE?
Perhaps if we included a copy of the JRE disclaimer in the install
program, with Sun's permission.
> Searching and updating, the "big two" will have to wait.
>
I agree, and propose that a preliminary-metadata search facility should
be setup in a similar way to the web-key-informing we have now. This will
allow us to start developing clients with search facilities, will
please end-users, all without us committing ourselves to a potential
flawed search mechanism. When we do implement proper search, the change
will be transparent to end-users, since the client will look the same.
Having such a facility will be a good investigation into the kinds
of metadata people are inserting and requesting, which could be
emulated in a simulator.
--__--__--
Message: 15
Date: Sun, 25 Jun 2000 09:04:28 -0500
Subject: Re: [Freenet-dev] KHK Metadata Proposal
From: Rick Dietz <r...@oacea.com>
To: <freenet-dev at lists.sourceforge.net>
Reply-To: freenet-dev at lists.sourceforge.net
> We can expect, with the 60 minutes this, whenever it airs, to get a whole
> slew of new users that don't understand command lines. And of course that
> should be happening now, too, with the Time article.
It may be worth while to put a visually unavoidable warning of some sort on
the website index page or download section to indicate this at the outset
until .3 is released.
-Rick
> _______________________________________________
> Freenet-dev mailing list
> Freenet-dev at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/freenet-dev
>
--__--__--
Message: 16
Date: Sun, 25 Jun 2000 10:20:17 -0500
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK Metadata Proposal
protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh"
From: "Scott G. Miller" <scgmi...@indiana.edu>
Reply-To: freenet-dev at lists.sourceforge.net
--jI8keyz6grp/JLjh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
> - node to node encryption
> - file encryption
Both of these have been done for quite some time.
>=20
> So please add other important 0.3 stuff to this list and I'll try to come
> up with some sort of organization, put it in the bug/task manager or
> something.
I really don't want to put 0.3 out the door until we have CHKs. I'd
*like* SVKs too, but that implies updating.
--jI8keyz6grp/JLjh
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
iD8DBQE5ViMxpXyM95IyRhURAp2dAJ9PrQRrI/kbgACZJAOsJ07TOpDmKQCfVZvJ
75l6UdXkszF8oZdOkRg+rLU=
=zViX
-----END PGP SIGNATURE-----
--jI8keyz6grp/JLjh--
--__--__--
Message: 17
From: "Henry Hemming" <hemming_he...@hotmail.com>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK Metadata Proposal
Date: Sun, 25 Jun 2000 17:27:19 CEST
Reply-To: freenet-dev at lists.sourceforge.net
>A GUI shell for the node can be coded by everyone. If you are
>reacting to the latest bunch of "I tried clicking on everything but
>it just said bad command", then consider that these people do not
>even have a JRE installed, so getting a GUI will hardly help them
>(unless somebody feelslike writing and installshield type thing that
>dls and installs a JRE).
Doesnt applets have an install shield type automatic installation inbuilt,
so that if you try to run an applet without a jre present it will
automatically prompt the user if he wants to install the latest jre. Couldnt
something along the line be done for freenet. A applet running on the local
machine doesnt have much limitations, to couldnt the GUI be done as an
applet, that talks to the local server, and when the applet would be run jre
wouldn be installed automatically..
I'm not too familiar with java capeabilities, I only know how to code, so my
excuses if there is something wrong with my line of reasoning.
--typo
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
--__--__--
Message: 18
Date: Sun, 25 Jun 2000 10:31:59 -0500
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] 0.3 Todo List
protocol="application/pgp-signature"; boundary="ZoaI/ZTpAVc4A5k6"
From: "Scott G. Miller" <scgmi...@indiana.edu>
Reply-To: freenet-dev at lists.sourceforge.net
--ZoaI/ZTpAVc4A5k6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
> - some standard for splitting/interleaving files.
>=20
> This will allow larger files to be stored, and goes someway to hinder
> the problem of interrupted downloads (since it limits the amount you
> can lose). It also speeds up the rate at which nodes find out about
> other nodes (because a 16-part file can return up to 16 unique
> DataSources). Downloading from different routes should improve load
> balancing across Freenet, because there is less chance of any
> particular node being unused.
I agree that we need this, but not necessarily for the 0.3 release.
> I have written the code to split and interleave files (almost ready to re=
lease),
> but we
> need a standard format for the header file, so that all clients can under=
stand
> it. We would also need to decide on a strategy for nodes hiding the fact =
they
> hold all parts to a file (which could be done by a client instruction to
> not cache all parts of a multi-part download).
You're right. We need to start specifying the format of these documents
that are supposed to specify things like CHK redirects, SVK version
stacks, and multipart files.
I propose something like the following, in BNF
head NEWLINE type NEWLINE (url NEWLINE)*
head: "Freenet Metadocument"
type: "Redirect" | "Multipart" | "Version Stack" | "Document list"
NEWLINE: \r\n
Redirect would cause the client to automatically request the single
(1) Freenet URI that follows
Multipart would cause the client to request all the parts in the url list,
assembling them as they return.
Version Stack would cause the client to request the first url from the
list (unless the client is requesting a previous version.
Document list wouldn't cause any really well-defined behavior. Perhaps
the client would present the user with the list, and he/she could select
from the list. Its different from a Version Stack, because they can be
completely unrelated documents (not versions of the same one), and
different from Multipart in that its not a single file.
Also, I think that this Metadocument data should be stored in the private
metadata field, *not* the document field. The data field would be
considered a comment, much like README is displayed if it appears in an
FTP directory.
--ZoaI/ZTpAVc4A5k6
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
iD8DBQE5ViXvpXyM95IyRhURAmnZAKC1CVJhk498b2XmqOLK2KjGTHzx3QCg1l4g
+C0wJ53D6SMGJLGbPpQvhyg=
=9dQ6
-----END PGP SIGNATURE-----
--ZoaI/ZTpAVc4A5k6--
--__--__--
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
End of Freenet-dev Digest
