On 05/11/15 22:21, Bob Ham wrote: > On Thu, 2015-11-05 at 21:19 +0000, Matthew Toseland wrote: >> On 04/11/15 22:57, Bob Ham wrote: >>> That's all helpful, thanks. However, I'm still not entirely sure which >>> are the "fundamental" problems Toad spoke of >> Okay, I will give some here, since people are being a bit more civil. >> >> In brief: > I'm glad you answered, thanks. Could you possibly help clarify some of > the issues? > > (I'm disregarding opennet, social issues, implementation issues, > applications, etc.; my focus is on the fundamental technical and > theoretical possibility of the Freenet protocol, or a Freenet-like > protocol.) > >> -- Tunnels are possible > What kind of tunnels do you mean? Why is their possibility a problem? >> -- General Sybil problem: *Every* resource is cheaper for an attacker >> than a lowest common denominator new user. Unless we can e.g. charge for >> entry to opennet. > Is Sybil relevant outside of opennet? Sorry for my shorthand. These two were specifically related to opennet. Tunnels are possible on darknet, but would reduce invisibility. Tunnels are possible on opennet, but might interact with other opennet issues (e.g. assigning shadow nodes), and an attacker controlling more than 20% of the network is quite feasible. >> - Darknet security: Pitch Black (believed to be solvable). > Can you expand on the belief that this problem is solvable? Oskar has proposed a solution. There have been some simulations, which seemed positive, but thesnark wasn't confident enough to publish even to the mailing list. >> - Load management: Performance. Major mechanism design (incentives) >> problems: The Patch is actively used in practice. Will look into this >> this year. > I don't really understand any of this :-) Is this load management > within Fred (i.e. an implementation issue), or is this some part of the > protocol? It's both, just like it is in TCP. Currently load is managed primarily by the originator adjusting their send rate. This only works if everyone cooperates. The Patch effectively turns this off, stealing bandwidth. Ideally we would have a system that doesn't rely so heavily on voluntary cooperation. TCP is similar to our current approach and works because most people don't cheat. There is a whole field of Computer Science / micro-economics called Mechanism Design that deals with this sort of thing. >> - Darknet doesn't scale. > How so? Are you talking about an implementation issue, an issue with > the protocol, or a social issue? The current swapping algorithm, which is very much part of the protocol IMHO for darknet, appears to have super-linear convergence time. So for big darknets, especially if there is churn, it may be a problem. There has been some work, notably by Vilhelm Verendel, on this, but it hasn't been deployed. >> - Mobile code is fundamentally unsafe on Freenet (although tunnels may >> help here) > What do you mean by "mobile code" exactly? Javascript. Everything on the web is done with Javascript in the client talking to some server. On Freenet we don't get the server and we don't get the client. Building distributed systems is harder than centralised ones in general, but in addition we can't allow any client-side scripting apart from official, reviewed code, because the ability to time requests is sufficient to reveal a user's browsing habits and approximate location. So we have to provide everything as a plugin, e.g. to have comments on a freesite. And that's hard, partly because we don't have a proper plugin API.
The server-side stuff can in theory be done with things like fork-and-merge btrees, see e.g. Infocalypse Mercurial-over-Freenet and the various wiki's. They don't scale either, but there are ways to improve on that. This is close to the general area of search: Spam-proof, scalable, decentralised, anonymous search is a *hard problem*.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
