continued testing and writing the README file. it's ready for someone…

… else to test it now, i think

README

@@ -1,3 +1,6 @@
+- First of all: This is alpha software so it's likely there are still one or two security holes in it. So please only use it on the localhost of your devbox, and not in production. If you find any of the security holes, then please submit an analysis to our mailing list, and if it's still in 2010, you can maybe even win our Hacky Holidays competition with your bugfix.
+- Also please submit any unhosted apps you create, big or small, to the Hacky Holidays competition. Even if a small app, that maybe only serves to say 'hello world' backwards, may not win, it's nice to create a rich showcase, it makes us feel like a popular project. :) The deadline is 1 January 2011, details are on www.unhosted.org.
+
 INSTRUCTIONS:
 -this assumes you will run both the clientside and serverside on your devbox localhost, and that you have a working webserver installed there, with php and mysql (if you don't have these, there should be plenty web documentation on how to easily install them on your operating system.
 -download the tar file from:
@@ -35,11 +38,10 @@ INSTRUCTIONS:
 -in firebug you should see it post a GET command to example.unhosted.org, then the js will check the PubSign signature, decrypt the content, and assign the blog post text to the <div> tag in bootloader.html.
 -Now open up bootloader.html and editor.html, and have a look at the source code. They only have 4 lines of code each. So hopefully you can see how easy it is to program unhosted websites using the "unhosted.get(user, key)" and "unhosted.set(user, key, value)" commands.
 - Behind the scenes, the text you typed was first encrypted with 's', using symmetric Rijndael. This was formed into the UJ/0.1 GET-command, which plays the role here of the "Pub", the publication in the pub/sub-model. Then this was signed with 'd', using RSA, to create "the PubSign that Signs the Pub". Writecaps 'w' were used to access unhosted account 'r@c'. The unhosted server allows CORS via the Access-Control-Allow-Origin header, and the HTTP OPTIONS command, but the HTTP referer of the POST is used to identify the app, so that browsers can enforce same-origin policies. On the subscriber end, upon retrieval of the blogpost from 'r@c' (again with CORS-AJAX and same-origin separation via the referer), the PubSign is checked against public key 'n', then the same Rijndael 's' is used for decryption, and the result is displayed. However, all of this is done inside the unhosted JS library, and you as the app developer only have to make sure you fill in all the correct bits you got from genkey, call unhosted.set and unhosted.get, and it just works!
--so far you have run this test on localhost, but obviously you would make us very happy if you blog about Unhosted, and what would be more convincing than "an unhosted blogpost about unhosted". Just make sure that you
-	- change the chans list to something only you know, and not the ones that are in the source code,
-	- do not (obviously) publish the file "PublishingPassword.js" or the admin directory
-	- understand both the php and js code you are publishing, and do so at your own risk and make sure you don't get hacked.
-	- This is alpha software so it's likely there are still one or two security holes in it. When in doubt, don't.
--the second example is wappmail. it's a bit cumbersome to try it out, because it requires you to create multiple users, cut-and-paste their addresses and passwords into the interface, log in as one, send an email, log in as the other, check your email, etcetera. In part the example is useful for showing how cumbersome public keys are. But it is also a working example of the "unhosted.send(from, to, key, body)" and "unhosted.receive(user, key)" commands.
--the third example is a bit advanced; it's called wappbook because it's an addressbook, and demonstrates the StarSign pki. All it does is establish trust through a behind-the-scenes fabric-based pki. All there is to see is that after your friend logged in, in your addressbook he will change from 'pending' to 'ok'. The algorithms behind that it runs before it gets to put 'ok' there are, I think, the best part of the unhosted library. But it's mainly there for people who are interested in the geeky details.
--if you have any improvements to make this demo more user-friendly, or anything else you wish to share with us, please contribute! We're at http://groups.google.com/group/unhosted. We're a friendly bunch, and your contribution is more than welcome.
+
+-the second example is wappmail. it's a bit cumbersome to try it out, because it requires you to create multiple users, cut-and-paste their addresses and passwords into the interface, log in as one, send an email, log in as the other, check your email, etcetera. In part the example is useful for showing how cumbersome public keys are. But it is also a working example of the "unhosted.send(from, to, key, body)" and "unhosted.receive(user, key)" commands. Unlike with the first get/set-based example, the symmetric encryption key 's' is not used here. If you send someone (r@c:n) a message, you need to know his public key n. Anybody can send messages to anyone, provided you include a valid PubSign (signifying you are the real sender), and you encode it against their public key. Since you signed your message with your own r@c:n, they can reply easily by clicking the sender address in their inbox.
+-whereas the first (wappblog) example is pub/sub-based, this one, wappmail, is (obviously) message-based. A lot of things you might possibly want to do with unhosted would be more naturally message-based than pub/sub-based, so I'm curious what people come up with to build on top of this. If you open up wappmail/bootloader.html, you see there are only 4 functions there, of about 8 lines each. The receive command has an optional boolean parameter 'andDelete'. If you edit the php, you could maybe add an 'andWait' parameter, so the receiver can sit with an open connection, waiting for messages to arrive. That would give you a real-time message-based paradigm. I'm curious to see what people will hack together in the Hacky Holidays competition!
+
+-the third example is a bit advanced; it's called wappbook because it's an addressbook (no reference to Facebook, obviously;), and demonstrates the StarSign pki. All it does is establish trust through a behind-the-scenes fabric-based pki. All there is to see is that after your friend has logged in, in your addressbook he will change from 'pending' to 'ok'. The algorithms behind that it runs before it gets to put 'ok' there are, I think, the best part of the unhosted library. But it's so new that even I don't really understand how it works, and it's mainly there for people who are interested in the geeky details. Unless you're into that sort of thing, it's probably better to start by expanding either the pub/sub- or message-based examples.
+
+-if you have any improvements to make this demo more user-friendly, or anything else you wish to share with us, please contribute! We're at http://groups.google.com/group/unhosted. We're a friendly bunch, and your contribution is more than welcome. And as I said earlier, please hack together an unhosted app these holidays, even if it's just to get a feel for it. Hacky Holidays, everybody!