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:
- 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.
- Sign in with something that looks like an email address.
- Transition seamlessly from local only to cloud synced.
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.