Decentralizing Mozilla Services, and integrating per-user sync more deeply into Firefox OS

[Michiel de Jong]

Hi!

Just as a write-up of some ideas we discussed yesterday at the Decentralize Hack Day in Paris.

# Decentralizing Mozilla Services

Mozilla offer a whole bunch of services: https://wiki.mozilla.org/Services/. It would be nice to have one package which you can deploy to your own server, and then have one place in Firefox settings where you can enter the domain name of your "personal Mozilla server", so that all your data will go there instead of to Mozilla.

We worked on this and made quite a bit of progress. We'll keep on working on both this server image, and the dialog for this central "use my own server" setting. The simplest way would probably to write an addon for this.

# Making Mozilla Services (specifically, Sync) use remoteStorage [cancelled]

We talked about this, but concluded it was probably both undoable and useless. Given the number of other services, making Sync use remoteStorage hardly helps anyone; at most, some people would need to install maybe 7 services instead of 8, to get their "own Mozilla server" complete. Since it's impossible to move all Mozilla services onto remoteStorage, moving only one of them is pointless. So this idea was cancelled.

# Integrating remoteStorage more deeply into Firefox OS

There are several ways this would make sense.
(1) At the lowest level, you can simply make an app that (with elevated privileges) takes a backup of your phone and stores it on your remoteStorage account.

(2) A bit more high-level, would be an functionality that uses a remoteStorage account to sync IndexedDB, localStorage, and Cookie data between devices, so that if you have the same app open on two devices, it acts like you have it open in two tabs or windows on the same device.

(3)And at the highest level, the device could include (3a) sync/cache and (3b) widget functionalities of the remotestorage.js library.

(3a) Doing the sync/cache at the device level instead of inside each app has the advantage that data is stored only once, and is already available locally when you open a new app that is based on remotestorage.js. This saves both bandwidth and storage space.

(3b) Moving the widget functionality (connecting / disconnecting your remoteStorage server, and displaying sync status and errors) from the app down to the device itself has the advantage that it frees up valuable screen space in the app.

CC-ing Alexis and Tarek. Comments welcome!

Cheers,
Michiel.

[Sebastian Kippe]

Hi,

Thanks for the write-up! Sounds like you were pretty productive in Paris. :)

> (3b) Moving the widget functionality (connecting / disconnecting your remoteStorage server, and displaying sync status and errors) from the app down to the device itself has the advantage that it frees up valuable screen space in the app.

I think this is not a great argument, because using our stock widget in mobile apps can never be a great solution, both with or without device-level sync. That means we have to make it as easy as possible to use the library without the widget and integrate it’s functions completely into your app’s UI. Ideally you only connect once from the settings, until you want to change the account, and for all the rest you should be able to use events from the library, e.g. for online/offline state or sync errors.

Still, albeit device-level sync not being *the* solution for our mobile UI problems, I think it’s still a cool idea, and especially performance-wise it would indeed make sense for a lot of use cases (thinking about stuff like pictures, contacts, etc., which you only want to sync and store once).

Cheers
Basti

[Michiel de Jong]

On Fri, Aug 1, 2014 at 2:00 PM, Sebastian Kippe <sebasti...@gmail.com> wrote:

Thanks for the write-up! Sounds like you were pretty productive in Paris. :)

Yes, we were! In fact, the day before the workshop I met up with Romain from Cozy, and that was equally productive: we added remoteStorage support to Cozy, and packaged Cozy for Docker.

We even did most of it while talking French, for extra bonus points. :)

> (3b) Moving the widget functionality (connecting / disconnecting your remoteStorage server, and displaying sync status and errors) from the app down to the device itself has the advantage that it frees up valuable screen space in the app.

I think this is not a great argument, because using our stock widget in mobile apps can never be a great solution, both with or without device-level sync. That means we have to make it as easy as possible to use the library without the widget and integrate it's functions completely into your app's UI. Ideally you only connect once from the settings, until you want to change the account, and for all the rest you should be able to use events from the library, e.g. for online/offline state or sync errors.

Right, so the user address input field and the connect/disconnect buttons should move to the settings, and the state indication can be exposed as WebAPI, that makes sense.

 

Still, albeit device-level sync not being *the* solution for our mobile UI problems,

Why not? The app could use colors or icons to signal what parts of what you see on the screen has not been written out to the server yet, and in which places you can expect incoming data to show up as it arrives, or where there is no (complete) data due to lack of connectivity. What else would you change? Maybe we can move this specific discussion about sync UI to https://github.com/offlinefirst/research/issues

 

I think it's still a cool idea, and especially performance-wise it would indeed make sense for a lot of use cases (thinking about stuff like pictures, contacts, etc., which you only want to sync and store once).

Cheers
Basti

--

---
You received this message because you are subscribed to the Google Groups "Unhosted Web Apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to unhosted+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sebastian Kippe]

Still, albeit device-level sync not being *the* solution for our mobile UI problems,

Why not?

Because it’s only *one* solution, but we need to solve the problem for all mobile environments and OSs – especially popular proprietary ones, where we can’t get device-level sync (yet).

[Michiel de Jong]

right, ok.

--