Serverless-wiki is a 'serverless' public wiki

This means most of the functionality can be accessed while serving static pages, and only for updates is any custom server-side code required.

In a nutshell:

• Pages are mostly static
  • gh-pages is convenient, but changes are slow to propagate
  • an s3 bucket seems to work
  • a traditional webhost with scp/rsync could also be an option
• Page sources are stored as markdown in a git repository (e.g. github)
• Logging in stores your credentials in your browser, and checks whether your password is 'plausible' (based on a high-collision hash)
• Update pages with a POST with new markdown, which:
  • is 'properly' authenticated
  • commits the new markdown to the git repo
  • generates new HTML and commit it to the CDN

See http://serverless-wiki.s3-website-eu-west-1.amazonaws.com/

'logging in' is initially a usability feature rather than a security feature: the password is put though a non-cryptographic, high-collision hash function.

The 'real' authentication happens when POSTing new markdown.

Design space:

• We want to have a public user database (in git)
• We don't want an attacker to be able to do an offline dictionary attach on the password, so we use a nonce only known to the lambda
• We don't want to have access to the plaintext password, not even in the lambda, so we also hash (using a public seed) in the browser.

To be fair an attacker could still first brute-force the private nonce and then do a dictionary attack after all, but especially for a public wiki this seems sufficient.

The actual HTML generation takes wiki templates and markdown sources as input, and generates HTML output.

We expect a low throughput (after all we hope to be mostly serverless, so also keep Lambda invocations to a minimum), so we'd like a platform that has fast cold start times. While the JDK can be a fine choice for high-throughput Lambda functions, it might not be great for us. Nodejs and python are comparable, and given that choice I prefer python.