On Monday 20 April 2009 17:12:23 sich wrote: > Matthew Toseland a ?crit : > > Top 5 suggestions on freenet.uservoice.com. Two are performance, and three are > > usability. > > > > 1. (200 votes) Release the 20 nodes barrier > > > > Interesting that the top issue is essentially a plea for more performance! > > Some of this will clearly be from frustrated long-term node operators with > > fast links that Freenet doesn't use, but imho it represents a more general > > problem: Freenet is slow! > > Freenet is not slow ! The speed is good on my opinion. We are talking > about protecting privacy and anonymity, not to have the new fast > download software... > > Popular content are generally easy to fetch. Other is little more > difficult yes. > > > > 2. (150 votes) One GUI for all > > > > Theoretically this is a demand for a new non-web GUI, but IMHO the important > > aspects are integrating more functionality and improving the web UI > > generally; people are quite happy in general with web applications, nobody > > uses a real email client any more except geeks. > > hum, "real email client" is not only for geeks please (I am not a geek > damn :) ). > > > 5. (73 votes) Implement reinsert on demand > > > > This is about more reliable filesharing. Broadly, the concern here is that > > inserted content does not remain fetchable for very long - if it is not > > requested, typically 2 weeks or so. IMHO this is bad: clearly we will not be > > able to cache everything, but given the average datastore size (big) and the > > average bandwidth limit (small), content ought to last longer than that. We > > need to be able to quantify this with regular automated tests, we need to > > investigate to what degree it is caused by newbie nodes, churn etc, fix the > > uptime estimate code to not only update on connect, implement Bloom filter > > sharing (which should help significantly imho), and maybe investigate with > > simulations. Much of the time the problem is that the top block has > > disappeared; once found the rest of the data can be found relatively quickly. > > So duplicating the top block is fairly important. Another weakness is that > > the last segment in a splitfile may have much less redundancy than the rest; > > this can be fixed by making the last 2 segments the same size. Also, we > > should consider whether to further increase the level of redundancy, > > especially in the store: the 3 nodes (on average) which stored (not cached) > > the data may very well be offline when we fetch it, so unpopular content will > > frequently not be fetchable. Persistent requests may help in the long term. > > IMHO Freenet ought to be good at somewhat unpopular content. > > > > To deal with the issue itself more specifically: infinity0's SoC will be to > > implement a distributed file indexing/searching system. This might eventually > > support insert on demand, however insert on demand has serious anonymity > > issues. In 0.9 we will scramble the splitfile insertion keys in order to > > prevent this vulnerability, however arguably this will exacerbate the > > underlying problem, so we may want to reinsert under random keys and then > > have some of the recipients insert under non-scrambled keys. Obviously, > > metadata including the hash(es) of the file contents as well as its length > > will help here; this will probably be a post 0.8 feature, realistically. > > Perhaps can you searching about a new sort of key... Some key who are > not going into the datastore, or only for few days (4/5 perhaps). This > keys can go in cache... > This can permit perhaps to use insert on demand on random keys, then if > you reinsert many times the same files you don't use to much datastore > space. > > Insert on demand is used for filesharing, but this consume a lot of disk > space in the datastore. > Perhaps should we find something who permit filesharing but don't use to > much datastore space (only caching the keys, not storing, or something > like this).
IMHO the first point of call should always be to try to fetch the keys, and currently persistence for unpopular content sucks, and hopefully can be improved significantly. > > Insert on demand application should use the wot to be more interesting. Yes. -------------- 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/20090420/fae4b9f9/attachment.pgp>
