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! 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. 3. (120 votes) Add a 'pause' feature This is a remarkably high ranking. It suggests we have a lot of gamers, and some easy way to tell the node to go into a mode where it uses as little bandwidth as possible, while still being able to get back into the network quickly when it is restored, is very popular. Maybe we should expedite this, post 0.8-beta1? 4. (101 votes) Show a progress screen when loading a page This is a surprisingly low ranking IMHO. Anyway it will be implemented soon. Hopefully similar measures for pages with images on will help too, they are most likely part of sashee's GSoC. 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. -------------- 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/760a2ffc/attachment.pgp>
