2015-08-22 Peer app notes

After getting starting with ClojureScript, I am thinking about whether and how to make applications, that are the same on server, and client side, where the app itself is a distributed network.

Basic concepts:

  • Homogeneous API, – same stack for “client” and “server”. Essentially daemon processes as well as user applications should be the same kind of peers. Not just the same language, as with html5+node.js, but truly peer-oriented, where even the libraries are the same.
  • Offline, – peers might disconnect from the network, and return back online later on.
  • Distributed, – instead of thinking about an application running on a computer, we should try to think about the computer as a large network of peers.
  • REST-configurable

So what I need in addition to standard HTML5

  • Message queues
    • Communication between peers
    • Logging
    • Offline-support
  • Database, with offline support and syncing
    • Offline support
    • Also host resources
  • User authentication
  • Caching and REST-support
  • Daemons
  • WebRTC-connection server
  • Search/discovery

The message queue, database, auth and daemons are the important once, the rest can be added later.

Database can be solved PouchDB, (CouchDB or CouchBase+Sync+proxy for replication/serverside)

Auth is done through a combination between the database and the mesage queue.

Daemons are just daemonised headless browsers, – possibly with access to extra APIs, – but they connect as any other peer, and you can communicate with them through. Daemons can also be used for email, non-cors http, etc.

The message queue is interesting. These are some thoughts about it:

  • Channels are one-way, and have a unique send and receive endpoint, ie. it is random, and if you do not know the endpoint you cannot send or receive.
  • A message consist of the following:
    • Timestamp, when arrived in the common db
    • Session-id for the sender/client
    • Message content
  • API
    • Create a new channel, – returns two endpoints (send/receive)
    • Get authenticated user-id for a given session id
    • Subscribe to messages on a channel since a given point in time, – or only new ones
    • Send message to a channel
  • Underlying database
    • map from send-id to receive-id (not exposed)
    • session-id to user-id
    • messages (channel recieve-id, timestamp, message-content)