Webnative parity with remotestorage.js

Developers ODD SDK
1

My previous reflections on supporting Fission in my apps led me to think that I needed to wrap the Webnative library to create a standardized API that also works with remotestorage.js, but I have some other thoughts now.

Consider these fundamental aspects of the current experience:

  1. Start using the app without needing to identify yourself and store everything in local storage. I understand that progressive accounts are on your roadmap as well as maybe wrapping local storage APIs.
  2. Sign in with something that looks like an email address.
  3. Transition seamlessly from local only to cloud synced.

These characteristics are made possible because of the way that the remoteStorage Javascript library works, and it’s the only thing I’ve seen that seems to nail the progressive web app UX for the people using the app. I think this is how it should work whether the person is using Fission, remoteStorage, SOLID, or any other 0data system.

Another thing for me to consider is that there are people already using my apps with a different protocol. Although it might be a small number of people, some of whom I can contact and some not, I would like to to avoid breaking the experience for them. I also want to avoid having a “choose your storage protocol” moment, which I believe would short circuit the kind of people I am serving.

Earlier I was encouraging Fission to adopt the remoteStorage protocol or maybe become a provider, but another alternative could be to make the Webnative library mimic the remotestorage.js library with respect to the above behaviours. This would make it possible to maintain what I consider to be the fundamental aspects of the current experience while supporting the use of Fission accounts. I think this would imply also ‘handling’ remoteStorage accounts in your library, which would be non-trivial and add complexity, but it might be simpler than modifying any server architecture (it’s isolatable to the client library). I believe it would also be fairly bounded in scope: you may not need to change anything even if the remoteStorage spec evolves.

Not sure if this is practical for you, but it’s another possibility.

2

Thanks for writing this up @rosano!

This is up to the app builder. Eg Moon Forge doesn’t do sign up until you want to store.

Local storage is already wrapped (caching, sync) but not in a progressive way.

Progressive Accounts as a feature would be just make this all really great with the webnative SDK.

We have 1 username = 1 email address so that would be pretty easy to do, although it does immediately expose email address to the app dev. I actually like this and it could be a short term option.

I’m a fan of this user format but actually think that USER@EXAMPLE.COM that isn’t a real email address that the user uses isn’t easier than a username.

For federation of multiple Fission platforms we’ll need to figure this out.

As I said for 1, this is already in place but maybe you can add more details of what you mean?

Publish / writing has to happen to commit the cloud sync with WebNative.

We’re very interested in having great UX for end users and great DX for app devs, so happy to learn from remoteStorage libraries.

We do have some set constraints that we’re unlikely to change, that we’re still discovering ourselves and getting feedback from folks like you. Thank you!

SOLID is an interesting example. They don’t have an approach to OCAP or encryption / private files, so adopting some of the Fission building blocks might make sense for that protocol. Lots of different ways to mix and match these things.

In your case I don’t think retrofitting your existing apps makes sense. Consider making your next app with WebNative to experiment!