On Thursday 17 January 2008 22:31, Florent Daigni?re wrote: > * Matthew Toseland <toad at amphibian.dyndns.org> [2008-01-15 19:57:47]: > > Ok, let's chime in as noone else does... > > I won't comment on time-requirement evaluated by toad: only on the > priority ranking. > > > [0] Enough seednodes to survive a MAJOR slashdotting. That probably means some > > form of auto-harvesting. (1-3 weeks) > > I'm not convinced that we need auto-harvesting at that point... > Depending on how big the network gets with rcs and alphas we will see... > but keep in mind that bundling a *large* file doesn't make sense either.
Well, if we can get 20 or so contributed noderefs, this will save a lot of work. > > > [0] Ultra Lightweight Passive Requests. Essential for web of trust based chat > > applications, and generally useful. (2 weeks) > > I'm not convinced that implementing that hack contributes to make any step > forward... as it will harm "real passive requests" on the long run. > > If we do it we *need* to do it soon. Right after alpha 2 IMHO. And alpha 2 should be soon. > > > [1] Finish Echo, or customize and bundle thingamablog (1 week) > > I would give a higher priority to that task. We release to get more > users and more specifically more content: releasing before we have decent > insertion tools doesn't make much sense to me (jSite can't handle > persistent requests, pyfreenet doesn't support testdda, ...) I agree that it's important. > > > [1] Tunnels. Michael Rogers and I have had some fruitful discussions about > > security, it looks like some form of (optional) tunnels may greatly improve > > security at little code cost and some performance cost. (2 weeks) > > I would decrease the priority of that one (on the basis that we can't > higher all priorities). It wasn't on the roadmap a few weeks ago... we > can probably wait a bit for ideas to settle before we implement it. The latest thinking is we can gain significantly by replacing HTL with probabilistic drop. This would reduce the local threat significantly and the remote threat somewhat; HTL and best-so-far are *bad* for security. Tunnels would be an additional step, which would greatly reduce risk against a distant but mobile attacker; the details are not fully agreed yet, so it might be post 0.7.0, although IMHO if we can come up with a good, simple design it might be worth it; my main worry is that we might be tweaking it for a long time due to performance questions, and I dunno whether it would work well with our current load management. > > > [1] Make big sites work well (multiple container inserts) (2 weeks) I assume you're happy with this? > > [2] Full download resuming (2 weeks) > > I'm opposed to having that implemented at all. Now that the database is > preserving the LRU table I don't see any good reason why that should be > implemented. We need incentives for users to keep their node running. Most users aren't that clever or knowledgeable. If every time they start the node up it thrashes their hard disk and slows down their system for hours on end, and if downloads are consequently very slow, they will simply uninstall Freenet. Also it has an impact on load balancing. However, if you don't want to do it, that's fine, I can do it. But it's not critical for 0.7.0. > > > [2] Plugin versioning and auto-update-over-freenet (1 week) > > [2] Finish API and implement the new plugin system (3 weeks) > > I regard it as an important piece of the puzzle. IMHO we need APIs to be > "frozen" before any release so that 3rd party apps can be built. In an ideal world yes. Ian?? > > > [2] Simulate alternate load management schemes, and deploy (4 weeks??) > > [2] Low-level rewrite (packet format, congestion control, etc) (3 weeks?) > > [2] Datastore rewrite (to use any SQL engine e.g. Derby, or external e.g. > > mysql), some people have been having major problems (2 weeks, I'd like to > > postpone it, if it behaves I will) > > I'm still awaiting for proofs that it's useful. No relational database can > have better performances than BDB... and I don't see why they would be > more corruption proof. Well, we recover correctly now, so hopefully it won't be necessary. I'm very happy to postpone it if we don't have big problems. > > > Other stuff: > > > > NODE: (2 days good-if-possible) > > [2] Per-node failure tables / route around nodes that fail for a specific key. > > Easy extension of ULPRs. (2 days) > > If we implement ULPRs it's a must have imo. I agree on that one. > > > INSTALLER(S): (1 week good-if-possible?) > > [2] Linux packages. (??) > > [2] Install a startup script on Linux. (1 week?) > > I would put [1] here... but it's far from being a simple to solve > problem. :| It's not essential for 0.7.0. > > > XMLLIBRARIAN: (1 week important, 3 days good-if-possible) > > [1] Integrate cleanly and easily with freesites. (2 days) > > [1] Search box on home page. (1 day) > > [1] More usability work (All Indexes folder, etc) (3 days) > > [2] Adjacent word matching support. (1 day) > > [2] Filtered HTML in summaries. (1 day) > > [2] Negative match support. (1 day) > > I regard Librarian as a 3rd party software... and would assign at most 2 > to all of those tasks. It has the enormous advantage that we can put a Search Freenet box on the homepage. This IMHO makes it worth it. > > > NETWORK PROFILING: (3 days important) > > [1] Simple threaded probe requests. (3 days) > > I do think that those would be useful... and that they should have been > implemented a while ago when the network topology was simpler (before > opennet and the periodic location randomization thingy). > > > FPROXY: (1 week important, 3 weeks good-to-have) > > [1] RSS filter. (important for blogging) (3 days) You agree with [1] for this? > > [2] Rewrite CSS2 filter (better standards support, better security). (1 week) > > [1] Support XHTML 1.1, 2.0, HTML 5.0 (3 days) > > I would put 2 here as well > > > [2] Support SVG including embedded in XHTML. (1 week) > > [2] ogg vorbis, ogg theora filters (1 week) > > > > CLIENT LAYER / FCP LAYER: (3 days essential, 2w3d important, 4w1d > > good-to-have) > > [0] TestDDA working and mandatory for direct directory uploads. (3 days) > > I never got around implementing something for directories because we > never agreed on how that should be done :) I don't regard it as urgent > nor must-have as no tool is currently using TestDDA as it should (and no > fcp client author has expressed the need of such a functionality) I thought you said you wanted a stable API before 0.7.0? > > > [1] Much less disk space usage for uploads (various optimisations). (1 week) > > [2] tar.gz support for packing containers. (2 days) (ASL2 licensing issues) > > [2] tar.bz2 support for packing containers. (2 days) (ASL2 licensing issues > > with .tar) > > [2] Or use cpio or something to avoid licensing issues. (2 days) > > [1] Fix >2GB uploads (2 days) > > As I told you on IRC that's a must have. Freenet is likely to perform > way better on "large" files as the impact of latency will be reduced... > And that's good for benchmarks/publicity/credibility. I'm working on that now. > > > [2] Revocable Subspace Keys and an official project freesite (1 week) > > I do regard that as important too. Would give 1 there. IMHO the latter is icing, the former is useful infrastructure long term but nobody's really asking for it atm. > > > [2] Fix implicit containers subdirs support. (2 days) > > [1] Don't report internal error on an invalid key. (1 day) > > [2] FCP API for Node to Node Messages so Thaw etc can talk with Thaw on nearby > > darknet nodes. (3 days) > > [1] Cut disk space usage *significantly* in uploads. (1 week) > > [2] Client-cache. (3 days) > > [2] Redirects to USKs. (1 day) > > [2] Insert-time charset detection. (2 days) > > [2] Memory optimise splitfile inserts as did with requests. (4 days) > > > FROST ETC RELATED: (2w good-to-have) > > [2] ?filename= parameter to fproxy/clients, so we can go back to CHK's being > > invariant for different filenames. (2 days) > > [2] Enforced whole-file hash and prevent DDA data from changing during > > insertion. (1 week) > > I would raise the priority of that one as it can lead to > incomprehensible bug reports. > > > [2] Selective reinsertion / indicate what blocks can't be fetched. (3 days) > > > > DARKNET: (2w4d good-to-have) > > [2] One-time invites. (4 days) > > [2] Short-noderef invites. (1 week) > > [2] Distribution mechanism - installer-invite-bundle generator. (1 week) > > > > DATASTORE: (1d important, 1w4d good-to-have) > > [2] Better datastore shrinking, on the fly with accurate LRU. (3 days) > > [1] Datastore histogram. (1 day) > > [2] Option to encrypt datastore. (3 days) > > [2] Option to put temp files in datastore. (3 days) > > [2] option to put persistent requests in datastore > > > CLIENTS: (~~ 1 week good-to-have) > > [2] We should have some sort of client that supports uploading freesites > > persistently. Bombe was going to fix jSite to do this. If not that, then > > maybe a WebDAV plugin. (1 week for webdav plugin) > > IMHO That's a must have for a release ... we need content... and that's > also the point of releasing. Well, what is the objective here? [1] A user friendly way to upload large freesites: Either a webdav plugin, jSite fixed to support persistent uploads, etc etc. [1] A user friendly way to create a blog (preferably without manual HTML editing). Echo, Thingamablog, etc. > > > [1] ULPRs are essential for any spam-proof messaging system. We should give > > the Frost devs any *reasonable* assistance e.g. architecture review. > > You've already put that one at the beginning... my position still > stands; either soon or never. > > > LINK LAYER: (3 days good-to-have) > > [2] Debug not-forwarded-detection and turn off assumeNATed by default. (3 > > days) > > > > TEMP FILES: (1 day important) > > [1] Split temporary files into subdirs. (1 day) > > I would lower the priority of that one unless there is a reason I'm > missing. I'd rather integrate them to the db than spending time creating > YetANewCustomStorageFormat. [first two hex digits] / [ rest of key ] is pretty standard actually e.g. squid uses it. And we could auto-migrate without too much trouble. > > > Postponed for 0.8: (unless somebody does it before that) > > - Premix routing. > > - Full passive requests. > > - Swapping must resist an active clustering attack. > > - Better support for fragmented networks. > > - NAT-PMP plugin. > > Well, I would rank that one [2] and wouldn't postpone it. > > > - AVI, PDF, MP3 filters. MP3 should actually be relatively easy. PDF is feasible but the spec is enormous and depends on various sub-standards, it would take a long while. AVI presumably depends on the codec. These IMHO are important for 1.0. > > - Transport plugins. > > - Polymorphic UOM-based micro-installer. (nextgens) > > - Client layer coalescing. > > - Faster FEC decode especially on AMD64. (nextgens) > > I hope that helps. Thanks. > > NextGen$ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080118/7b6bbaf7/attachment.pgp>
