2008/12/31 Matthew Toseland <toad at amphibian.dyndns.org>: > #1: 41 votes : release the 20 nodes barrier > > "most of the users nowadays have a lot of upload-bandwith available. Myself > has about 3Mbits upload, but the limit to connect to not more than 20 nodes > results in about 50kb/s max. Please release the limit or use a dynamic system > that offers more connections if the node has a high bandwith upload limit > (scaling). Thx" > > I'm not sure what to do about this. The original rationale for the 20 peers > limit was that we didn't want to disadvantage darknet nodes too much on a > hybrid network, since they will not often have large numbers of peers. > Combined with experience on 0.5 suggesting that more peers is not always > better, a security concern over over-reliance on ubernodes, and the fact that > we should eventually be able to improve bandwidth usage through better load > management. However, there's a limit to what we are able to achieve through > better load management, and it's a difficult problem. > > Thoughts?
I'd say lets raise the threshold, perhaps to 40. The arguments against it seem a bit handwavey to justify denying functionality that our user's clearly want. Upload bandwidth is the life-blood of P2P networks, we should use every scrap of it we can get. > #2: 38 votes : one GUI for all > > "For new (non-technical) users it may be very difficult to understand what > they really need, how to do it and how to use it. > > The entry point of an application plus its visible style, the user interface > aso. are playing the biggest role for acceptance nowadays. > > Therefore there may be the need of a GUI (I imagine one written in XUL, so it > runs on all plattforms, easily extensible, aso., we are already using a > custom firefox profile so why don't write our own user interface?) that > provides all mechanisms that are available throughout the freenet network. > File sharing, messaging, flogs, identity management and others." > > IMHO part of this is simply an endorsement of the current not yet implemented > policy to move everything possible into the web interface. A well designed > web interface could be easy to use and responsive. There is an argument that > we need an actual XUL app ... but this will be a huge amount of work to > little benefit IMHO. True, I'd mark this one as "Planned". This is good as its a nice visible demonstration that we are listening to our users. > #3 tied: 33 votes : show a progress screen when loading a page (Filed by me) > > "Is this a good idea? Would it make Freenet more user friendly if it didn't go > off into limbo while loading a link?" > > This is planned. IMHO we should implement it before releasing 0.8.0, it would > be a significant enhancement even without real time updates with javascript > support, provided it is not shown unless we have reason to believe the > download will take more than 5 seconds. It is especially interesting if > combined with some new content filters for e.g. audio files. Agreed, it would also solve (or alleviate) the browser connection limit problem, which would be great. > #3 tied: 33 votes : dynamic pages > > "I would like to see the ability to host dynamicly changing pages in freenet, > I have tried to implement it myself and found it verry hard. Possibly > integration with apache would be perfect." > > This may happen eventually, but probably post 1.0. Sandboxed plugins are > probably the best approach, but even with a defined API and sandboxing, there > are a lot of security issues innate in Freenet itself e.g. timing attacks on > the datastore. Yes, this is very hard. > #3 tied: 33 votes : add a 'pause' feature > > "It would be cool if it was possible to 'pause' a freenet node. I mean, stop > all network traffic, warn peers that we are on pause, but keep the node > alive. > > That would allow short downtimes for online gaming without the hassle of > having to restart the node and wait for it becoming usable again." > > IMHO offline mode is a good idea, especially when combined with a systray > icon. It would also help with e.g. connections that are throttled or billed > severely at certain times of day. Agreed, we should mark it as planned and transfer to Mantis. Ian. -- Ian Clarke CEO, Uprizer Labs Email: ian at uprizer.com Ph: +1 512 422 3588 Fax: +1 512 276 6674
