I apologise for replying before I at least had a proper look at the website! This is in fact fascinating and there may well be things we can do together or at least inspiration we can draw from one another.
Lets get detailed, technical, and concise, about what would be involved in Freenet working with Unhosted, as one of many options for transport etc. Sorry for the general waffle last time, it's worth reading though. The basic principle of Unhosted from a freenet-ish angle is: - Websites are static and therefore can be hosted absolutely anywhere. - The website is a (large?) javascript applet. The client trusts the author of the website, within reason. - Data is encrypted by the client. - Data is stored on a separate storage server. - CORS allows this (this requires relevant request headers) - The PKI sounds very strange! On Freenet we always pass the hashes of the pubkeys... :| Now, compare to Freenet: - Freenet is reasonably good at hosting static content. - It strips out javascript in order to preserve security. This happens at the fproxy level; if the app is trusted it could be whitelisted or something. - Data is stored by clients for themselves, which is easy on Freenet, or it is routed between clients via queues, which is somewhat harder: Because of spam problems, we need to announce identities and establish a web of trust between them, or at least that's how current stuff works; we could use CAPTCHAs or some similar scarcity mechanism directly on a per message basis, but once a relationship is established it is unnecessary, and there are serious worries about the long term viability of CAPTCHAs. - Your PKI sounds rather strange... We could probably provide a WoT-based lookup service and be API-compatible though... There are some interesting sandboxing options. The big difficulty preventing Freenet from allowing Javascript is not the difficulty of writing a javascript filter (although that is a hard problem it is a solvable problem); it is the difficulty of defining a safe API for it to call. Freenet only provides request and insert - fetch and put - but with that alone, a malicious app author can do a lot of mischief. I wonder if we could build a usable sandbox based on Unhosted principles, i.e. an app can download and upload data specific to its user, and can talk to other users. We could even provide a confirmation mechanism per-user for more paranoid users, which could smoothly integrate into the app's UI if we are really good, including CAPTCHA-based introductions ... hmmmm, there could be something in this ... might need API changes though, how do you deal with introductions now? Such principles may be valuable to Freenet even if we have to break compatibility with Unhosted... Thoughts?
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org http://freenetproject.org/cgi-bin/mailman/listinfo/devl
