One last gasp on security. There are lots of things we can do in the longer term, notably darknet enhancements and PISCES tunnels. But if I can't beat MAST I'll go mad.
ROUGH PRIORITY LIST: (For me; there are others working on WoT, UI enhancements etc) - Smallish usability fixes etc. (Including e.g. wrapper fix, Spider fixes) - First stage of bundles. (Fix MAST!) - Rip db4o out. (Major usability improvement IMHO) ==== If I'm lucky I'll be here by the time I leave ==== - Darknet enhancements. - New SSKs. (Important for lots of things) - ... - PISCES. - ... - Opennet: IP/bandwidth scarcity. - ...
--- Begin Message ---What about bundles? - Inserts are mainly slow because of the downstream nodes, right? Inserts go to 20+ nodes atm. - So the number of parallel bundles necessary, even to maintain full speed, may be relatively low? - Lets say we go 5 hops random routed as a bundle (i.e. without diverging). This should get us a significant distance from the originator. Then we random route individual requests for another 2 hops (line + starburst). Then we do normal inserts (but without the don't-cache-at-high-htl hack, since we don't cache up to starting the regular inserts). This would slow down inserts by roughly 1/3rd. If we can limit it to 4 or 5 such bundles, we can probably achieve performance close to not bundling at all, but going the same number of hops. - Short term: Accept the requests one at a time. No storage. Possibly check uptime before accepting, maybe option to accept on previous node if it goes down etc. - Medium term: Store the data (on disk!). Once sent committed, we will send the data even if we restart. Then insert it (as a local insert). Limit the number pending per peer etc. Fire and forget. Completion: Top block is a FEC'ed SSK/PSK splitfile (fetchable from a single URI, not too big, but divided up among the various bundle inserters), with a highish threshold, so it is completed collaboratively. Security/reliability tradeoff. Possibility of recovering data and doing a regular insert. - Long term we'd like to start a large number of inserts all at once at the destination, as this further reduces the possibilities for MAST. But it has load management implications. - 20 hops is probably too high anyway - but it may be problematic / significant testing etc to establish the correct HTL. Implement basic bundle protocol (no storage, relatively small bundles, probably need an uptime check before accepting), and tests to compare speed of different numbers of bundles vs regular inserts going the same distance. E.g. by a hack to use a lower HTL on starting so they both go the same number of hops. How many bundles do we need to get 80% of the performance of just sending the inserts? Even if we send a bundle to every single peer, we'd still have a significant security gain relative to the current situation... Various people have contributed to this idea's evolution over the years...
signature.asc
Description: This is a digitally signed message part._______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
--- End Message ---
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
