mich-unhosted

fair enough, still, it never hurts to have free software alternatives to commercial software. in installed software, we are already used to having the option to use linux, OpenOffice, mysql, etcetera. in hosted software, currently, the only alternatives to commercial websites are other commercial websites. with unhosted, we're simply trying to copy free software's success from installed software to the web, and that way we hope to expand people's options to vote with their traffic.

i can see your point, but there are some differences. the main one is that freenet is anonymous, and unhosted is not. i think unhosted is, if anything, most similar to SMTP: a protocol with which an application, that is inherently 'hosted' (uses persistence on online servers), can be 100% decentralized (bar its dependence on DNS). Instead of centralized, as is the default these days for internet apps. All its weaknesses apart, we should thank SMTP for being an alternative to a centralized facebook-messages. ;) Unhosted wants to create a decentralization layer for web apps to run on.

you would need decentralized search algorithms. i haven't looked at that much myself, but there are some projects out there that seem interesting. to give an idea: when my friend is logged in, his browser could run algorithms that send me recommendations. think about how you receive information on twitter: not through centralized algorithms, it works through peer-to-peer retweeting. at least as a research topic, it is very interesting :) but you are right, there is stuff that's hard to do. i think the most challenging one would be google search.

yes, that's a good point. in cloud services there are at least 3 options, and no monopoly (yet). also, we understand the big value that SaaS if offering people. that's exactly why we want to offer free software alternatives in that area. if MS Windows would not have been valuable to people, then there wouldn't have been a need to develop linux as a free software alternative to it. As I sometimes say about Google, "it wouldn't be so bad, if it weren't so good". while pleading guilty on the count of sensationalism ;) that line was more about monopolies like facebook, youtube, google docs, where there is only one provider.

it is definitely full of complicated issues, but we have already found solutions for some of them (not all yet). please join our mailing list and help think about the remaining ones. it will at least be interesting to have a place where people talk about these things. i can also recommend the p2p-hackers mailinglist to you in that respect.

like in PGP, you would use a session key: symmetric encryption of the thread, then encrypt that symmetric key once for every thread- or forum member. you can only add people to this; to remove people from a thread you would need to send the remaining people a new session key. that's the rough idea we have, we are still waiting for someone to implement a research app so we can test how well this works.

I hadn't even thought of that angle! i guess businesses also have civil rights online. :) and mainly: it might help us bootstrap the ecosystem. thanks!

it means we should write the unhosted storage node in AWS, GoogleApps, etc, because that is what these businesses will want, right? should be trivial, i'll put this on the tasks list :)

i updated www.unhosted.org/manifesto.html to include some more info on how it works.

the code does not claim to be anything more than a proof of concept. As you say, it's a silly 100-line php script, nothing more than that. it is also not very well-written, especially the unhosted.js and hutch.js files (i didn't have any JavaScript background when i started the project, nor did i try, at all, to write production-grade code). But we hope it does, as it were, 'proof the concept'.

i will make the link to the github page (as opposed to the tarball) more prominent, sorry for that.

> Nice, seeding a cryptographic! PRNG with math.random(). that file is part of the JavaScript Big Numbers library by Tom Wu, which unhosted builds on top of. sorry if that wasn't clear, maybe i should create subdirs to better indicate code provenance. it is not something we did ourselves! It looks very difficult to us. ;)

> browser plugin that's mentioned on the page but not in the tarball? sorry! misunderstanding - we originally worked on a plugin, then found Tom Wu's library, and switched to that. It works without a plugin and aims to be "zero-UX" for the end-user. It was an old text - I updated the page to correct this.

> Crypto-in-Javascript is kind of a red flag yes, we are aware of this issue. but our case is different - the updated manifesto page mentions this (sorry, if i knew we would be on HN i would have made sure the web was more current first! ;). The idea is I trust the publisher of the source code. Be it the author, an app channel, etcetera. But I do not trust the storage node that holds my data. The ajax calls are cross-origin resource sharing (CORS). You trust the URL you visit (along with the DNS pointing to it, and unless it's https, all hops inbetween). the encryption only comes into play when your browser does the CORS calls to the unhosted storage nodes.

> why'd anyone ever run a server? One of the most important questions, and one we discovered several possible replies to. If you offer an unhosted facebook, your main worry will be if end-users will use it at all, rather than too much, so quite the opposite. Once it's up and running with a small number of nodes, end users will have a need for unhosted storage nodes, and various parties could be willing to provide that.

The author of an app might have reasons to do so. If all app-authors provide their own resources then we did not gain anything yet, because there still is the connection between app author and hosting costs. But the apps could peer, and gain scalability with pooling. 100 startup companies could share 5 or 6 unhosted storage node in the building they share, and if one company becomes successful, it will scale because of the pooling. After that, altruists could step in for apps with no startup company behind them (look at wikipedia running 300 servers off donations), as may whoever provides connectivity: a university, an employer, an ISP, etcetera. Whenever unhosted becomes more successful than the number of existing nodes, the end-user will experience fail-whales, and ask around for faster and more responsive nodes.

Ask yourself: who runs your mailserver? Why do they volunteer to give you an email address? Different reasons. But taken together, email forms a distributed application, way more desirable than one centralized facebook-messages. When email started, universities were the ones installing the first servers. It didn't cost much, because there wasn't any traffic yet. If traffic on unhosted storage nodes grows, it is because somewhere, an end user is enjoying the service. That is useful.

Imagine I get a free unhosted storage node with my cornflakes. I might remember how slow HN was yesterday evening, and buy those cornflakes. Then people will see mich@acmeflakes.com appear on HN as my guid. Or people would see me use my HN account on slashdot. Every guid contains a well-deserved advertising space behind the @-symbol. It would all (hopefully) become an ecosystem.

Communication between app and unhosted storage node is over HTTP, yes. In the current version. But the unhosted storage node wouldn't care if it's a browser or a desktop app / phone app / tablet app that's talking to it.

We updated the page this links to, but added a link to the previous version for reference.