It is trivial for a user to host their own ‘backend’ for UTR. All they need do is get a CouchDB instance. There are several free providers and setting up your own is simple. This is the case both for Identities and Conversations. The reference client implementation will aim to make it simple to use third-party endpoints.
Using PouchDB/CouchDB does wonders for the ability to write cross platform applications. For one, the API is open and well documented by Mozilla. PouchDB is also usable in the browser, in nodeJS (and node-webkit) and in Cordova across all major mobile platforms. I’ve been spending a lot of my day job lately writing applications that span OSX, Windows, iOS and Android while using largely the same codebase. Node-Webkit and Cordova are also good to go for Linux, Windows Phone, etc etc. This toolkit gives us a clear road to native apps on every major platform and a webapp for anyone else.
Using PouchDB for both the storage and transport layer also means there is vastly less code to write in the app itself. This neatly serves the goal of keeping the codebase small and simple to aid audits.
I intend all software I create in this endeavour to be FLOSS. Users will be free to build their own clients if they choose. I do intend, however, to support development and hosting of UTR via user contributions. There will be a donation apparatus, however there will also be built versions of the reference client in the various platform marketplaces that may have a reasonable cost associated with them. It will also be possible to seek payment for hosted Conversations. Users will be free to create databases, but at intervals a process can run checking for new databases and associating them with a bitcoin address. It can then post an (unencrypted) messages to the Conversation asking users to pay into the address, providing reminders, etc. These wallets can then be tapped for the agreed monthly fee in order to support the cost of running the Couch.
The default behaviour of the reference client is to use PouchDB to do a live replication on the remote. This keeps a long poll open and fetches any new documents as they’re available. This is fine, but will not work when the app is not active (looking at you, iOS) and is potentially problematic for battery life. Since the Conversations are publicly readable, however, providing push notifications becomes an orthogonal service. The user simply hands the Conversation URL to their Push Notification provider and asks to be notified when there is a new Message. I intend to provide one such service, but anybody who wishes to operate their own will be on a level playing field, regardless of which CouchDB provider is hosting the Conversation.