Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/cloudant-labs/welcome-to-the-future

For those moments of techno-{dys,u}topian elation, confusion, wonder, and disappointment.
https://github.com/cloudant-labs/welcome-to-the-future

Last synced: 5 days ago
JSON representation

For those moments of techno-{dys,u}topian elation, confusion, wonder, and disappointment.

Awesome Lists containing this project

README 

        
# Welcome to the Future (WttF)



[demo]: http://lolcomingsoon.com



Like [My Life is Average](http://mylifeisaverage.com/), but for those moments of techno-{dys,u}topian elation, confusion, wonder, and disappointment. Example:



    "Can you keep a secret?" they asked.

    I replied, "You, me, and the NSA makes three."



N.B.: EXPERIMENTAL. Coming soon.



Built with love, and [Express-Cloudant](http://express-cloudant.herokuapp.com/) <3



## How does it work?



### When the app starts...



1. It checks to see if the `base`, `master`, and `_replicator` databases exist. If they don't, it creates them.

2. It checks to see if the `base` database is continuously replicating to `master`. If it isn't, it inserts a document into `_replicator` to begin that replication.



### When a user visits the homepage...



**In development**



1. They see recent posts, sorted by a function like `created_date * votes`, so popular posts sort higher, but ultimately float down as they age. (The specifics: The most recent 20 posts are sorted by votes * timestamp. TODO: Make it Reddit-like sorting, rather than this hogwash)

2. If an anonymous user tries to vote or post, they're prompted with a signup form.



### When a user signs up...



1. Server adds that to a `_users` database. (If the user already exists, reject the signup)

2. Server creates a database called `user_{username}`

3. Server sets the security on the database to give the user `_reader` and `_writer` permissions.

4. Server adds a doc to the `_replicator` database to continuously replicate the `setup` database to the new user's database.

5. Server adds a doc to the `_replicator` database to continuously replicate the user's database to the `master` database.



### When a user adds a post...



1. The user writes the `post` document to their `user_{username}` database.

2. It gets replicated to the `master` database, where others can vote on it.



A post looks like this:



    {

        type: 'post',

        created_at: timestamp,

        text: content_of_post_in_markdown,

        user: username

    }



A `validate_doc_update` ensures that the document being inserted is up to spec. For example:



* `type` must equal 'post'.

* Users cannot set the `user` field to anything but their own usernames.

* The JavaScript `Date` function must be able to parse `created_at`.

* `text` cannot be empty.



### When a user casts a vote...



1. The user writes the `vote` document to their `user_{username}` database.

2. It gets replicated to the `master` database, where it affects the sorting of recent posts.



A vote looks like this:



    {

        _id: {username}-{post_id},

        type: 'vote',

        user: username,

        post: post_id

    }



The `_id` ensures that there is only one vote per username-post pair, so folks can't vote on something more than once. A `validate_doc_update` function further ensures conformity:



* `type` must equal 'vote'.

* `_id` must split at the rightmost hyphen such that the substring left of the split is the submitting user's username, and the substring right of the split is equal to `post`.

* `user` must equal the submitting user's username.



## License



[MIT](http://opensource.org/licenses/MIT), yo.