On Wednesday 11 Jan 2012 21:36:54 Steve Dougherty wrote: > Three more options: > > * Complete modularization of freenet-ext, allowing for wrapper upgrade. > * Add a dismissable "release notes/news" pane to the front page upon upgrade.
This is a trivial release-process hack. It would be very little work, but would be tricky for an outsider. > * Move bandwidth limit questions for the presets out of the wizard and > replace with a notification/UserAlert to address them after the node > has been set up, starting out assuming low rates. This is trivial too but is a policy issue. And as a matter of policy IT IS WRONG. What would really help would be to be able to detect them automatically. We can do this from UPnP much of the time, and in that case we should nag the user afterwards - but even there I'm not sure, many more sophisticated users will get mad at us for not asking, so maybe we need an advanced mode - but that's supposed to be the full wizard ... All very tricky but not *technically* tricky. What would be both technically challenging and useful would be auto-detection on the fly based on e.g. latency. > > On Mon, Jan 9, 2012 at 3:53 PM, Steve Dougherty <steve at asksteved.com> > wrote: > > It might be reasonable to do darknet invitations: a file which allows > > someone to connect with another node over darknet without exchanging > > noderefs. (I can't think of how this would work, though.) This could > > also, perhaps more conveniently, come baked into a generated > > installer. There's a largish web of bugs about this on the bug tracker. The worry about out-sourcing it for money is that somebody would do a half-assed implementation which doesn't do most of what is actually needed. A full implementation would be a lot more work than a bad implementation, and somebody would have to judge this. And it will probably need to evolve somewhat with deployment. > > In a similar vein, generated installers could include > > additional plugins as well. I agree that it should be possible to include a wide range of customisations e.g. different bookmarks, different plugins, etc. > > When I helped someone set up Freenet, FRED > > itself was fast, but all the plugins (WoT, Freetalk, FMS, Sone) took a > > while to download. Sure, I can carry the .jars/.zips around with me, > > but that's annoying and not streamlined. That's because they are not fully official yet. When they are they will be bundled. > > > > More extensively, which probably falls outside the scope and intent of > > gun.io, it would be very nice to have code cleanup, review, and > > documentation. One cleanup task that occurs to me is separating FProxy > > and the rest of the UI from - I'm not sure what to call it: the core? > > Such work could involve using FCP to interact with the backend and > > using an established templating engine like Apache Velocity Engine. > > Review could catch bugs and inform any possible cleanup and > > documentation. Documentation would allow others to add Freenet support > > to their existing products, or write their own Freenet daemons. It'd > > also be good for FRED to have a protocol and load balancing > > specification to work from. > > > > These projects are probably still be too large, and I'm not sure about > > putting them on gun.io as I'd like to do them myself, but I'm > > interested in realtime public chat using WoT for identities, and more > > chat programs/plugins which are compatible with FLIP. I'm hoping to > > work on that myself in the form of additions to my chat plugin. There > > have also been many posts about a filesharing plugin, which I think is > > a great idea, but I haven't noticed reports of progress on any of them > > so far. Most recently, f?nfnull's "What Freenet really needs" in > > eng.freenet on Freetalk mentions this. > > > > How about posting subtasks for cleaning up WoT/Freetalk? Posting subtasks is useful regardless of whether they can be funded. You can e.g. put them on the wiki. -------------- 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/20120116/5645d0ce/attachment.pgp>
