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). Insert on demand application should use the wot to be more interesting. sich
