[freenet-dev] Not sure about key column is redundant
Bug 3040 suggests getting rid of the Key column and linking to the key from the filename column. We link to the key from the identifier column already but it isn't shown in simple mode. I am not sure I agree with p0s's logic: The purpose of the filename column is to show *where the file is being downloaded to*. Downloads to temporary space don't have one, although they are unusual. Sometimes the filename will be a full, absolute path, usually it will be downloads/blah. So out of filename, identifier, and key, which do we keep in simple mode? IMHO it makes more sense to keep the key than the identifier. We can make the key slightly more user friendly by decoding spaces and foreign characters in the visible version, and we already truncate the crypto stuff. For completed downloads, we could reasonably link to the file on disk in one of the columns. We also need to provide the link in case somebody else wants the file, and some way to fetch it through the node without going to disk. The last and the first could be the same, if we check the downloaded files before returning a DNF. So: Remove Key CHK at .../somefile.txt [ link can be copied, but also if clicked on it will return the data ] Size 5.5MB Type Plain text [ we will have a lookup table for common mime types to be translated into human readable strings ] Location on disk downloads [ just the directory name to save space, but the link has the full name ] [ links to a file:/// URL ] Persistence forever [ tooltip: The download will not be removed unless you click Remove; the other version is that it will be removed on restart ] For downloads in progress: Remove Key CHK at .../somefile.txt Progress 54% Size 5.5MB Type Plain text Location on disk [ tooltip: this is where the data will be stored when the download is complete ] downloads Thoughts??? Another option would be to handle downloads to temporary space in some other way, accepting that they are quite rare, and it is okay for them to be ugly... -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090603/9073d5a5/attachment.pgp>
[freenet-dev] Memory overhead of compression codecs
I propose to solve bug #3171 by having two compression threads, one for very small files (say up to 64K), and one for everything else. This relies on the assumption that compressing something very small uses very little memory. Is this a fair assumption? Do lzma or bzip2 allocate big tables up front which depend on the size of the window and not on the size of the file? Do we need to adapt the size of the window to the size of the file? -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090603/f8d2fdb5/attachment.pgp>
[freenet-dev] Insert of demand application design
ted over FCP with normal keys. > - We can begin to download the file before all the chunks are inserted. This > is a little more faster for the people who are downloading. This is true. It can be safe if the CHKs that make up each chunk are encrypted with a random key and are therefore not detectable until that chunk is announced. > - Using some preview system ? Maybe. > > WoT-based : > - Using WOT can limit the problem for the bootstrap when you have just > install the filesharing program. > - Using the security of the WOT can help to find people who are publishing > fake files. > > > > Please don't hesitate to comment. Are we missing some points, is that > feasable, will it be too slow, etc... -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090603/18a25e2d/attachment.pgp>
[freenet-dev] Getting rid of emu: an option
On Wednesday, 3. June 2009 19:08:07 Matthew Toseland wrote: > Mantis: We could run this ourselves using php+mysql on sourceforge servers, > but we would have to admin it ourselves. Their hosted apps service does not > currently support importing data, so we would not be able to use that to > host our existing bug tracker. Having to upgrade it manually would be a > major pain, from what nextgens has said... We could file a support request for that. Maybe they can update it themselves. Best wishes, Arne --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- - singing a part of the history of free software - http://infinite-hands.draketo.de -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090603/b287a0e3/attachment.pgp>
[freenet-dev] Getting rid of emu: an option
On Wednesday, 3. June 2009 19:08:07 Matthew Toseland wrote: > Web hosting (of static files). Sourceforge provide this, and it should > perform well. If there is no dynamic code there should be no administrative > overhead. They don't allow generating money from the webhosting, so SF can't solve static websites. But that can easily be found elsewhere, too. Best wishes, Arne --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- - singing a part of the history of free software - http://infinite-hands.draketo.de -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090603/a81dcb19/attachment.pgp>
[freenet-dev] Shutdown/restart always visible? was Re: Status line???
On Wednesday 03 June 2009 00:59:55 Daniel Cheng wrote: > On Wed, Jun 3, 2009 at 1:33 AM, Matthew Toseland > wrote: > > On Tuesday 02 June 2009 18:24:48 steve wrote: > >> What good is constantly displaying the security level, unless the user > >> would > >> like to change it frequently for some reason? > >> > >> The node already asks them which level they want at install time and it is > >> easily accessible from the config page, so what do they gain by being > >> constantly reminded which security level they are on? > > > > They might forget! :) > > > > Seriously, right now we constantly display the security levels on the > > homepage, and there's a reason for that: they are important, we want people > > to add friends and upgrade from NORMAL to HIGH. We used to have an explicit > > warning about running opennet for this reason, now we just show the > > security levels. > > If this is the case, the alert / status line should read: "if you add > some friends, your node would be faster, more secure, better, .." > > The current alert of "Security Level: LOW" have no this effect. Well it used to say that ... really I am not convinced that it is faster, although I can see it would be more stable ... all that we need users to know is that they do not have as good security as they could have, doesn't the security levels alert fulfill this purpose given that we explain the security levels during installation? -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090603/8e95b667/attachment.pgp>
[freenet-dev] usability testing
Its that time again. Grab your girlfriends, boyfriends, flatmates, friends etc, sit them down in front of a computer, and ask them to install and use Freenet. Take careful note of anywhere they get stuck and either report it here, or report a bug. DON'T HELP THEM! Any time they need to ask you a question, its a usability bug. Ask them to provide a running commentary on what they are seeing as they use Freenet, make a note of anything that confuses or misleads them. Freenet has long been derided for its poor usability, but if you can spend 10 minutes of your's and a friend's time, you can really help us ensure that newbies have a good experience when they try Freenet. Ian. -- Ian Clarke CEO, Uprizer Labs Email: ian at uprizer.com Ph: +1 512 422 3588 Fax: +1 512 276 6674
[freenet-dev] Getting rid of emu: an option
Sourceforge could solve some of these problems: Web hosting (of static files). Sourceforge provide this, and it should perform well. If there is no dynamic code there should be no administrative overhead. Mantis: We could run this ourselves using php+mysql on sourceforge servers, but we would have to admin it ourselves. Their hosted apps service does not currently support importing data, so we would not be able to use that to host our existing bug tracker. Having to upgrade it manually would be a *major* pain, from what nextgens has said... Wiki: Sourceforge can provide hosted MediaWiki, which will immediately solve the problem of our french wiki. However, our english wiki is using Wikka, which is nonstandard. We probably want to migrate it to MediaWiki at some point... Other stuff: Mailing lists: Past experience suggests we don't want to use sourceforge's mailing list services, so we will need to find somewhere else. https://checksums.freenetproject.org : We need SSL with redirects, so that the update scripts continue to work; and architecturally it's the Right Thing... Mailing list archives: We could rely entirely on third parties, quite a few providers archive our lists. Anywhere we get mailman from will probably provide basic non-searchable pipermail archiving. Some paid providers do free installation and upgrades of mantis, mediawiki etc. For example, godaddy hosting connection, which is included with their $6.99/mo 150GB space / 1500GB transfer deal; whether we would be able to import our existing data is not immediately clear. IMHO this would solve most of the above problems: - Web hosting. - https://checksums - Mantis. *Possibly* hosted (if we can import data), if not we could admin ourselves. - MediaWiki. - File hosting. (If it's over 1500GB for a release, then we use CoralCache that month). However, it doesn't solve the mailing lists issue. Neither does Sourceforge or Google in a satisfactory way. On Saturday 30 May 2009 11:55:17 Matthew Toseland wrote: > We need to get rid of emu. It costs us a significant amount of money and we > don't seem able to cost-effecitvely administer it. > > Basically what we need: > - PHP scripts. The website is built with PHP. > - Database-backed PHP for MANTIS. I don't think we should get rid of MANTIS. > - SSL. We need to serve checksums and signatures through SSL, although big > files will generally be served through HTTP. It would be nice to serve the > installer through SSL if we have a huge traffic limit, since code signing > certs are expensive, on the other hand if we get cheaper hosting we can > probably afford to buy a code signing cert with a fraction of the money > saved... > - IMAP accounts ideally, but at least aliases. > > What we do NOT need: > - Auto-build. This is difficult to secure, and not really compatible with a > secure git-based workflow. > > Anything I've missed? > > One option: > > http://www.uk2.net/web-hosting/ > > Includes SSL, IMAP, 1TB traffic per month (bandwidth is very expensive with > bytemark, even if we qualified for the 50% discount for the main distributor > of free software), domain hosting, and a (very basic) uptime SLA, for ?13.95 > to ?19.95/mo depending on how long we buy it for (2 years down to 1 month). > > Thoughts? -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090603/436b9e74/attachment.pgp>
[freenet-dev] Shutdown/restart always visible? was Re: Status line???
On Wed, Jun 3, 2009 at 1:33 AM, Matthew Toseland wrote: > On Tuesday 02 June 2009 18:24:48 steve wrote: >> What good is constantly displaying the security level, unless the user would >> like to change it frequently for some reason? >> >> The node already asks them which level they want at install time and it is >> easily accessible from the config page, so what do they gain by being >> constantly reminded which security level they are on? > > They might forget! :) > > Seriously, right now we constantly display the security levels on the > homepage, and there's a reason for that: they are important, we want people > to add friends and upgrade from NORMAL to HIGH. We used to have an explicit > warning about running opennet for this reason, now we just show the security > levels. If this is the case, the alert / status line should read: "if you add some friends, your node would be faster, more secure, better, .." The current alert of "Security Level: LOW" have no this effect. [..]
Re: [freenet-dev] Getting rid of emu: an option
Sourceforge could solve some of these problems: Web hosting (of static files). Sourceforge provide this, and it should perform well. If there is no dynamic code there should be no administrative overhead. Mantis: We could run this ourselves using php+mysql on sourceforge servers, but we would have to admin it ourselves. Their hosted apps service does not currently support importing data, so we would not be able to use that to host our existing bug tracker. Having to upgrade it manually would be a *major* pain, from what nextgens has said... Wiki: Sourceforge can provide hosted MediaWiki, which will immediately solve the problem of our french wiki. However, our english wiki is using Wikka, which is nonstandard. We probably want to migrate it to MediaWiki at some point... Other stuff: Mailing lists: Past experience suggests we don't want to use sourceforge's mailing list services, so we will need to find somewhere else. https://checksums.freenetproject.org : We need SSL with redirects, so that the update scripts continue to work; and architecturally it's the Right Thing... Mailing list archives: We could rely entirely on third parties, quite a few providers archive our lists. Anywhere we get mailman from will probably provide basic non-searchable pipermail archiving. Some paid providers do free installation and upgrades of mantis, mediawiki etc. For example, godaddy hosting connection, which is included with their $6.99/mo 150GB space / 1500GB transfer deal; whether we would be able to import our existing data is not immediately clear. IMHO this would solve most of the above problems: - Web hosting. - https://checksums - Mantis. *Possibly* hosted (if we can import data), if not we could admin ourselves. - MediaWiki. - File hosting. (If it's over 1500GB for a release, then we use CoralCache that month). However, it doesn't solve the mailing lists issue. Neither does Sourceforge or Google in a satisfactory way. On Saturday 30 May 2009 11:55:17 Matthew Toseland wrote: We need to get rid of emu. It costs us a significant amount of money and we don't seem able to cost-effecitvely administer it. Basically what we need: - PHP scripts. The website is built with PHP. - Database-backed PHP for MANTIS. I don't think we should get rid of MANTIS. - SSL. We need to serve checksums and signatures through SSL, although big files will generally be served through HTTP. It would be nice to serve the installer through SSL if we have a huge traffic limit, since code signing certs are expensive, on the other hand if we get cheaper hosting we can probably afford to buy a code signing cert with a fraction of the money saved... - IMAP accounts ideally, but at least aliases. What we do NOT need: - Auto-build. This is difficult to secure, and not really compatible with a secure git-based workflow. Anything I've missed? One option: http://www.uk2.net/web-hosting/ Includes SSL, IMAP, 1TB traffic per month (bandwidth is very expensive with bytemark, even if we qualified for the 50% discount for the main distributor of free software), domain hosting, and a (very basic) uptime SLA, for £13.95 to £19.95/mo depending on how long we buy it for (2 years down to 1 month). Thoughts? signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Shutdown/restart always visible? was Re: Status line???
On Wednesday 03 June 2009 00:59:55 Daniel Cheng wrote: On Wed, Jun 3, 2009 at 1:33 AM, Matthew Toseland t...@amphibian.dyndns.org wrote: On Tuesday 02 June 2009 18:24:48 steve wrote: What good is constantly displaying the security level, unless the user would like to change it frequently for some reason? The node already asks them which level they want at install time and it is easily accessible from the config page, so what do they gain by being constantly reminded which security level they are on? They might forget! :) Seriously, right now we constantly display the security levels on the homepage, and there's a reason for that: they are important, we want people to add friends and upgrade from NORMAL to HIGH. We used to have an explicit warning about running opennet for this reason, now we just show the security levels. If this is the case, the alert / status line should read: if you add some friends, your node would be faster, more secure, better, .. The current alert of Security Level: LOW have no this effect. Well it used to say that ... really I am not convinced that it is faster, although I can see it would be more stable ... all that we need users to know is that they do not have as good security as they could have, doesn't the security levels alert fulfill this purpose given that we explain the security levels during installation? signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Getting rid of emu: an option
On Wednesday, 3. June 2009 19:08:07 Matthew Toseland wrote: Web hosting (of static files). Sourceforge provide this, and it should perform well. If there is no dynamic code there should be no administrative overhead. They don't allow generating money from the webhosting, so SF can't solve static websites. But that can easily be found elsewhere, too. Best wishes, Arne --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- - singing a part of the history of free software - http://infinite-hands.draketo.de signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Getting rid of emu: an option
On Wednesday, 3. June 2009 19:08:07 Matthew Toseland wrote: Mantis: We could run this ourselves using php+mysql on sourceforge servers, but we would have to admin it ourselves. Their hosted apps service does not currently support importing data, so we would not be able to use that to host our existing bug tracker. Having to upgrade it manually would be a major pain, from what nextgens has said... We could file a support request for that. Maybe they can update it themselves. Best wishes, Arne --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- - singing a part of the history of free software - http://infinite-hands.draketo.de signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Insert of demand application design
On Tuesday 02 June 2009 19:41:51 clement wrote: Hello, Here is some try from Sich and myself to think about the design for some insert on demand application based on the WoT plugin. You should seriously consider working with infinity0, his searching plugin will provide distributed indexing. --- key structure : ssk/filesharing/updates/inserts/x/inserts ssk/filesharing/updates/requests/y/requests ssk/filesharing/z/index/ ssk/filesharing/filehash/n/index inserts file structure: filehashxxx/filehash chunkall or chunk number/chunk requests file structure: filehashxxx/filehash chunkall or chunk number/chunk index file structure: file namexxx/name sizexxx/size hashxxx/hash content typexxx/content type /file filehash index structure: commentcomment on this file/comment #one per chunk chunk hashxxx/hash sskxxx/ssk #if available chunk numberxxx/chunk number #necessary if all the chunks aren't listed /chunk Each file is splited into several chunks. Each chunks is inserted in is own SSK. Why are you inserting files as SSKs? Security? Why are you splitting the files up? Are you assuming that the key changes every time for security? If you are using CHKs you can simply reinsert the original file - we can provide an FCP option to only reinsert some blocks, this is not a big problem. The advantage is that if the data has been inserted, you can just download it, using the normal CHK key, and if it hasn't, and people start reinserting it, you will be able to pick up those blocks. The disadvantage is security: anyone who inserts predictable keys is vulnerable to attack. However, to avoid such vulnerability, you need to *encrypt the inserted data differently each time*! I am assuming you are using chunks consisting of many CHKs, maybe 1MB, with an SSK pointing to them? In which case the chunk will need to be encrypted before being inserted. We suscribe to every keys needed to know about updates (that is : ssk/filesharing/upadtes/inserts and ssk/filesharing/upadtes/requests) Search : Each people publish all the files that he is sharing in the ssk/filesharing/index file. When you search a file, you will look in each identity to find your file. Then you have a list of filename and corresponding filehash. When you have this you can choose to download a specific filehash. #Each people who have this file can begin to insert some chunk of the file and telling that they are currently inserting a part of the file. The chunk are randomly choose, then multiple people can insert #the whole file more faster. #When the chunk is inserted the SSK key of the chunk is published, then we can begin to download it. They only publish the SSK after they have finished inserting the chunk? Ok. Download: Once you found the file you want, you search for shared chunks in the keys of the identities sharing the file. If several ssk are available for one chunk, choose the one that appears the more. (during the search, when you see sskY for chunkXXX, just add 1 to the priority of sskY) If no ssk is available for one chunk, add a request in ssk/filesharing/requests We suscribe to the key : ssk/filesharing/filehash/ to know about all new chunks available, ... Insertion: If someone is requesting a chunk (see Download), we start inserting it. We publish that in the key under : ssk/filesharing/inserts, so other identities won't insert it. When it's finished, we indicate it under the same file. Healing : When you try to download a file who was already inserted, and if you can't download a specific chunk, a request is publish to ask for this chunk. People who have the original file can begin to insert this chunk and tell the other that they have begin to insert it in order to avoid multiple insert of the same chunk. Then the new SSK is published to download the missing chunk. WoT: If someone give us a wrong chunk or some fake, we mark it as bad. One question however : how can we detect a wrong chunk ? If we have multiple source for the file we can try to compare the chunk filehash index (ssk/filesharing/filehash/index). Yes, you need an overall hash of the file contents, and maybe for the chunks too, assuming they are big enough. advantage to split the file : - We can have multiple source to insert the whole file - If some chunk are no more available we can only ask to reinsert this chunk. This will limit the datastore use (no need to reinsert the whole file on a new SSK) These are advantages of selective reinsertion, which can be implemented over FCP with normal keys. - We can begin to download the file before all the chunks are inserted. This is a little more faster for the people who are downloading. This is true. It can be safe if the CHKs that make up each chunk are encrypted with
[freenet-dev] Memory overhead of compression codecs
I propose to solve bug #3171 by having two compression threads, one for very small files (say up to 64K), and one for everything else. This relies on the assumption that compressing something very small uses very little memory. Is this a fair assumption? Do lzma or bzip2 allocate big tables up front which depend on the size of the window and not on the size of the file? Do we need to adapt the size of the window to the size of the file? signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] Not sure about key column is redundant
Bug 3040 suggests getting rid of the Key column and linking to the key from the filename column. We link to the key from the identifier column already but it isn't shown in simple mode. I am not sure I agree with p0s's logic: The purpose of the filename column is to show *where the file is being downloaded to*. Downloads to temporary space don't have one, although they are unusual. Sometimes the filename will be a full, absolute path, usually it will be downloads/blah. So out of filename, identifier, and key, which do we keep in simple mode? IMHO it makes more sense to keep the key than the identifier. We can make the key slightly more user friendly by decoding spaces and foreign characters in the visible version, and we already truncate the crypto stuff. For completed downloads, we could reasonably link to the file on disk in one of the columns. We also need to provide the link in case somebody else wants the file, and some way to fetch it through the node without going to disk. The last and the first could be the same, if we check the downloaded files before returning a DNF. So: Remove Key c...@.../somefile.txt [ link can be copied, but also if clicked on it will return the data ] Size 5.5MB Type Plain text [ we will have a lookup table for common mime types to be translated into human readable strings ] Location on disk downloads [ just the directory name to save space, but the link has the full name ] [ links to a file:/// URL ] Persistence forever [ tooltip: The download will not be removed unless you click Remove; the other version is that it will be removed on restart ] For downloads in progress: Remove Key c...@.../somefile.txt Progress 54% Size 5.5MB Type Plain text Location on disk [ tooltip: this is where the data will be stored when the download is complete ] downloads Thoughts??? Another option would be to handle downloads to temporary space in some other way, accepting that they are quite rare, and it is okay for them to be ugly... signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Insert of demand application design
On Wednesday 03 June 2009 23:25:56 Matthew Toseland wrote: On Tuesday 02 June 2009 19:41:51 clement wrote: Hello, Here is some try from Sich and myself to think about the design for some insert on demand application based on the WoT plugin. You should seriously consider working with infinity0, his searching plugin will provide distributed indexing. Ah ok, I didn't remember if someone was working on a distributed indexing plugin or not. That could benefit to such an application indeed. - -- key structure : ssk/filesharing/updates/inserts/x/inserts ssk/filesharing/updates/requests/y/requests ssk/filesharing/z/index/ ssk/filesharing/filehash/n/index inserts file structure: filehashxxx/filehash chunkall or chunk number/chunk requests file structure: filehashxxx/filehash chunkall or chunk number/chunk index file structure: file namexxx/name sizexxx/size hashxxx/hash content typexxx/content type /file filehash index structure: commentcomment on this file/comment #one per chunk chunk hashxxx/hash sskxxx/ssk #if available chunk numberxxx/chunk number #necessary if all the chunks aren't listed /chunk Each file is splited into several chunks. Each chunks is inserted in is own SSK. Why are you inserting files as SSKs? Security? Yes. Why are you splitting the files up? Are you assuming that the key changes every time for security? If you are using CHKs you can simply reinsert the original file - we can provide an FCP option to only reinsert some blocks, this is not a big problem. The advantage is that if the data has been inserted, you can just download it, using the normal CHK key, and if it hasn't, and people start reinserting it, you will be able to pick up those blocks. The disadvantage is security: anyone who inserts predictable keys is vulnerable to attack. However, to avoid such vulnerability, you need to *encrypt the inserted data differently each time*! I am assuming you are using chunks consisting of many CHKs, maybe 1MB, with an SSK pointing to them? In which case the chunk will need to be encrypted before being inserted. Chunks are directly inserted in the SSK. The point is to prevent us to encrypt the chunks before reinserting. Each chunk is indexed in the ssk/filesharing/filehash/n/index file. We suscribe to every keys needed to know about updates (that is : ssk/filesharing/upadtes/inserts and ssk/filesharing/upadtes/requests) Search : Each people publish all the files that he is sharing in the ssk/filesharing/index file. When you search a file, you will look in each identity to find your file. Then you have a list of filename and corresponding filehash. When you have this you can choose to download a specific filehash. #Each people who have this file can begin to insert some chunk of the file and telling that they are currently inserting a part of the file. The chunk are randomly choose, then multiple people can insert #the whole file more faster. #When the chunk is inserted the SSK key of the chunk is published, then we can begin to download it. They only publish the SSK after they have finished inserting the chunk? Ok. Download: Once you found the file you want, you search for shared chunks in the keys of the identities sharing the file. If several ssk are available for one chunk, choose the one that appears the more. (during the search, when you see sskY for chunkXXX, just add 1 to the priority of sskY) If no ssk is available for one chunk, add a request in ssk/filesharing/requests We suscribe to the key : ssk/filesharing/filehash/ to know about all new chunks available, ... Insertion: If someone is requesting a chunk (see Download), we start inserting it. We publish that in the key under : ssk/filesharing/inserts, so other identities won't insert it. When it's finished, we indicate it under the same file. Healing : When you try to download a file who was already inserted, and if you can't download a specific chunk, a request is publish to ask for this chunk. People who have the original file can begin to insert this chunk and tell the other that they have begin to insert it in order to avoid multiple insert of the same chunk. Then the new SSK is published to download the missing chunk. WoT: If someone give us a wrong chunk or some fake, we mark it as bad. One question however : how can we detect a wrong chunk ? If we have multiple source for the file we can try to compare the chunk filehash index (ssk/filesharing/filehash/index). Yes, you need an overall hash of the file contents, and maybe for the chunks too, assuming they are big enough. Yes, each chunk is indexed with its hash and its ssk(s). advantage to split the file : - We can have multiple source to insert the whole file - If
[freenet-dev] usability testing
Its that time again. Grab your girlfriends, boyfriends, flatmates, friends etc, sit them down in front of a computer, and ask them to install and use Freenet. Take careful note of anywhere they get stuck and either report it here, or report a bug. DON'T HELP THEM! Any time they need to ask you a question, its a usability bug. Ask them to provide a running commentary on what they are seeing as they use Freenet, make a note of anything that confuses or misleads them. Freenet has long been derided for its poor usability, but if you can spend 10 minutes of your's and a friend's time, you can really help us ensure that newbies have a good experience when they try Freenet. Ian. -- Ian Clarke CEO, Uprizer Labs Email: i...@uprizer.com Ph: +1 512 422 3588 Fax: +1 512 276 6674 ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Shutdown/restart always visible? was Re: Status line???
On Thu, Jun 4, 2009 at 2:09 AM, Matthew Toseland t...@amphibian.dyndns.org wrote: On Wednesday 03 June 2009 00:59:55 Daniel Cheng wrote: On Wed, Jun 3, 2009 at 1:33 AM, Matthew Toseland t...@amphibian.dyndns.org wrote: On Tuesday 02 June 2009 18:24:48 steve wrote: What good is constantly displaying the security level, unless the user would like to change it frequently for some reason? The node already asks them which level they want at install time and it is easily accessible from the config page, so what do they gain by being constantly reminded which security level they are on? They might forget! :) Seriously, right now we constantly display the security levels on the homepage, and there's a reason for that: they are important, we want people to add friends and upgrade from NORMAL to HIGH. We used to have an explicit warning about running opennet for this reason, now we just show the security levels. If this is the case, the alert / status line should read: if you add some friends, your node would be faster, more secure, better, .. The current alert of Security Level: LOW have no this effect. Well it used to say that ... really I am not convinced that it is faster, although I can see it would be more stable ... all that we need users to know is that they do not have as good security as they could have, doesn't the security levels alert fulfill this purpose given that we explain the security levels during installation? The current alert just say hey, you are insecure!, but it does not tell the user what should he do. ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Getting rid of emu: an option
On Thu, Jun 4, 2009 at 3:21 AM, Arne Babenhauserheide arne_...@web.de wrote: On Wednesday, 3. June 2009 19:08:07 Matthew Toseland wrote: Web hosting (of static files). Sourceforge provide this, and it should perform well. If there is no dynamic code there should be no administrative overhead. They don't allow generating money from the webhosting, so SF can't solve static websites. But that can easily be found elsewhere, too. They do allow selling support via MarketPlace (http://sourceforge.net/services/buy/index.php). Best wishes, Arne ___ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
