I understand your points. I was not on the techlist before 2 months, thats why I ask now.
After reading your text I think Frost has no hit if this behaviour is changed. Frost will just provide an empty "TargetFilename=" and it will never use a filename for requests or inserts, Frost will only request the pure CHK@ key. As I understood this continues to work, an application can still use an empty TargetFilename??? And this will work forever, true? As long as this works as is nice for me... Thanks for your clarifications. > Why should Freenet URIs behave so radically differently to any other > kind of URI in the known universe? imho this was a big advantage of freenet. In freenet all is free and you can't trust noone. But if someone gained some trust e.g. on Frost or over a freesite, and this person provides a CHK key, everyone always knows that the data behind this key are ok (theoretically). Now, if there are different keys for the same file, this does not work any longer. Sample: a trusted person uploads a CHK with a filename. Someone downloads the file and archives it, but he renamed it. After months the original trusted uploader is wasted, and the downloader reinserts the file because someone asked for it. If he use thaw (for example), then the file gets another CHK key because of the different filename. Then the reinserter provides the key to the public, but noone can verify that the reinserted file is really the same file as uploaded by the trusted person... Maybe some checksum would help, but I don't know how and where to add it... On 10/27/06, toad <toad at amphibian.dyndns.org> wrote: > On Fri, Oct 27, 2006 at 08:37:56AM +0200, bbackde at googlemail.com wrote: > > I heard that you want to make "CHK with filename" mandatory. What does > > this mean ... > > It means that IF you specify a filename when you insert a CHK, that > filename becomes a necessary part of the URI. If you don't, it doesn't. > > > > I have to insert a file with URI=CHK@ and TargetFilename=abc. Then I > > must request this file with URI=CHK at bla/abc? the CHK key itself is not > > enough? > > > > The same file, but with different names, get another CHK key? > > Yes. Although beyond the top splitfile level they will share all blocks. > > > > What is the sense of this? You said it would be easier to find the > > file in store, but why is this easier, the CHK is already unique? The > > filename just adds another abstraction layer and you have to deal with > > files of same name, but different content. Because of this you would > > always have to use key+filename for lookups, why is'nt the key itself > > enough for this? > > The CHK is not unique. Here is the problem: > > CHK at blah,blah,blah - is invalid, or is a simple key > CHK at blah,blah,blah/something - could be a simple key, or could be "fetch > CHK at blah,blah,blah then look up the file called something in the > manifest" > CHK at blah,blah,blah/something/else - could be > a) a simple key (CHK at blah,blah,blah) > b) a single container lookup (lookup something in CHK at blah,blah,blah) > c) a double container lookup (lookup something in CHK at blah,blah,blah > then else in the returned manifest) > > You see the problem? A slash delimits a directory, in virtually all URI > schemes. You should not be able to add arbitrary subdirectories to a URI > while still returning the original file. Being able to do so means that > you cannot compare two URIs with any level of confidence, as well as > being counter-intuitive. Also, there is additional ambiguity if we > support implicit containers (something.zip/filename-in-zip). > > Thus, there is a two-stage solution: > > 1. If the user specifies a filename, insert the file as a single-file > manifest so that the filename is required to fetch the file. > 2. Stop accepting superfluous path components. > > Then we have no ambiguity. A slash always indicates a manifest lookup - > or a part of an SSK or USK url, which is much the same thing for our > purposes (an SSK always has one path component before the manifests, a > USK always has two). > > > > IMHO this concept leads to problems. > > The current situation leads to problems. > > > I know that same files with > > different names only have another key because the manifest is > > different, the (hidden) datablocks itself have the same key. But how > > should applications for file sharing and insert-on-demand work with > > this concept? > > Having read my explanation above, you really think the current (well, > older) situation is better? > > > We share the file with a unique SHA identifier. If 2 > > users have the same file, but with different names, this works well. > > Now if there are the same files, but with different CHK keys because > > the filename is different, the application would have to maintain a > > list of all known CHK keys for a file with same SHA checksum, and it > > would have to try to download one key after the other until a download > > is successful. > > Or you could just not use a filename. > > > > As you see, this concept adds more complexity to FCP2, with a > > questionable benefit. > > It reduces ambiguity and complexity by making keys behave the same way > as any other URI for any other protocol. > > Really, what is the alternative? As far as I can see these are our > options: > > 1. Make CHKs not have filenames at all. > PRO: Easy, unambiguous > CON: Not exactly user-friendly > > 2. CHKs may have any filename, we ignore it. > > The first path component is always ignored. > PRO: Easy, unambiguous > CON: Breaks existing CHK freesites > CON: Counterintuitive: part of URI can be tampered with > > 3. If a filename is specified on insert, it is enforced. > (Currently working towards this) > > PRO: Easy, unambiguous > CON: See above > > 4. Make CHKs have optional filenames. > > PRO: Makes Frost work > CON: Ambiguous: any number of bogus pathname components can be appended > to a URI and it still work > > Unless you have any better ideas? > > Now, I would be willing to include an enforced checksum in a key, if > that helps you. I might even be willing to always insert a separate > block for the data itself and the MIME type, and then have a redirect to > this to add on the filename. However this would reduce performance by > introducing an extra block fetch. So I'm not sure it's a good idea. > > Could you explain the usage scenario here in a bit more detail? > > > Simple applications that count on this concept > > would have problems later if there are alot of files from many users > > floating around... they should respect that only the CHK key is the > > URI for a file. This worked great on 0.5, everyone understand this and > > its easier for all... > > Everyone who has several years of experience with Freenet understood > this. Nobody else did. URIs should behave like URIs. I'd rather have > option 1 than option 4! > > > > Please don't make this mandatory. > > Why should Freenet URIs behave so radically differently to any other > kind of URI in the known universe? > > > > rgds, bback. > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.5 (GNU/Linux) > > iD8DBQFFQe+nA9rUluQ9pFARAtHdAJ0VnNXyk/SVOpqI1NvjNNSaTPWkYwCeNZUi > baZto3+Gpm92nqZpUQ2rGQE= > =+aYc > -----END PGP SIGNATURE----- > > > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > >
