Weekly report #18: "Asynchronous Synchronization" for offline web apps

[Michiel de Jong]

Hi!

To move forward a bit on the 'web app' concept, I've been working on 'syncStorage'. It's like localStorage and sessionStorage which you know from html5, but there are a few differences:

- you instantiate syncStorage with initSyncStorage(onStatus), where onStatus is a callback that gets called whenever the synchronization status changes. for now it's mainly 'working' and 'ready'.

- additionally to the normal methods of the Storage interface, it offers pullFrom(params), to connect as a slave to a remote storage as specified in params, as well as syncItems(), which serves to put the items mentioned 'in sync'. it will put syncStorage into 'working' status for a bit, and then back into 'ready' when everything is in sync.

- instead of clear(), there's flush. My intuition is that people use clear() when they want to clear the local cache, not when they want to wipe out a user's data for ever more. So to avoid people accidentally calling syncStorage.clear() and triggering the deletion of all remote data, I did not provide this method. Instead, I'll provide flush(), which you can use to remove all local cache. that's good for cleaning up when you close a session.

- i've thought about how to do multiple windows or devices synced to the same storage at the same time, like CouchApps generally can, but i've though that for now it's too complicated. I did leave open a place where we could add it though: for now, it will always be in status 'lock = true', which can be interpreted as 'local is master'. That means you can go offline, and come back online, and overwrite whatever happened in the meantime.

For now, I've based https://myfavouritesandwich.org/ on BrowserId. There are two principal worries about BrowserId, as I see it: whether we'll be able to ever get rid of the centralized browserid.org, and whether there will be good ways to log out remotely. For logging out remotely, we discussed a possible solution yesterday evening in the #identity channel on irc.mozilla.org. Basically, an app should display to a user which other devices they have a session on, and give the user the option to log them out from within the app. The app could also warn at login, or even force a remote logout when you login from somewhere else.

The good thing about using BrowserId here, is it solves our two-password problem. When browsers support this, you'll be able to use one password at your identity provider, to log in to the encryption layer at every app, as well as to your unhosted storage. this was a big UI problem so far, and BrowserId is a good solution for it.

The problem, obviously, is the centralized browserid.org domain. Right now, you're giving the sysadmins at browserid.org access to all your sandwich ingredients. I think as soon as at least two browsers offer native BrowserId, we should stop supporting browserid.org on myfavouritesandwich.org, and tell users 'either upgrade your browser, or use good old user-remembered passwords'.

Discussion on the BrowserID topic welcome. As well as on the concept of single-window asynchronous synchronization.

Oh yes, I also added an appcache manifest to it. The code is in the 'syncStorage' branch of https://github.com/unhosted/unhosted

This week, I'll work on documentation a little bit, so it will all become a bit clearer what the current state of the project is. Specifically, I would like to publish 3 Howto's on unhosted identity (WordPress, StatusNet, Diaspora), and three on unhosted storage (mod_dav, OwnCloud, CouchDb), and then document and publish syncStorage as the recommended way to link an in-browser app to unhosted storage.

You can't really test https://myfavouritesandwich.org/ right now if you don't have BrowserId-enabled unhosted storage, so it temporarily sort of loses its value as a demo, but i'm thinking about how to fix that. maybe i'll set up federoni.org so that you can register working test accounts there.

If you have an unhosted storage node yourself, then simply install an MX record on that domain, with postfix behind it to forward all incoming mail to somewhere where you can read it. Then register on browserid.org, and then you should be able to use https://myfavouritesandwich.org/ again.

Cheers,

Michiel 

[Max Ogden]

worth noting http://github.com/mikeal/pouchdb

[Michiel de Jong]

Hi Max!

On Wed, Jul 20, 2011 at 2:29 AM, Max Ogden <maxo...@gmail.com> wrote:

worth noting http://github.com/mikeal/pouchdb

yes! good point. that's actually part of the inspiration for starting to do this this way.

I also saw you're already offering BrowserId for CouchDb. So the only part that I think is missing there would be the link from browserid to knowing which remote couch PouchDb should replicate to. it would be an interesting experiment to put webfinger into there. so you're using a pouchdb app, then decide you want to save your work in case you need it later. so you log in with BrowserId, and somehow magically, the CouchApp knows that the instance to replicate to is http://mich.iriscouch.com 

in fact, if iriscouch were to offer couchmail, or directly skip that step and become a BrowserId IP without smtp, then mi...@iriscouch.com could become my BrowserId identity, and whenever i use that identity on a CouchApp, it could automatically replicate a copy of the document to my instance...

could that work? just brainstorming here. :)

cheers!

Michiel