Hi everyone,
An important feature currently missing in Cristal is the option to let users define their own configurations, and connect to backends they want without requiring for the instance administrator to add them globally for every user (e.g., their own personal XWiki instance, or GitHub repository).
These custom configurations will need to be persisted between browser sessions, and ideally between Cristal instances as well (if we want to let users share their configurations between a browser instance and the electron client, for example).
From a technical point of view, a generic way to manage that would be to add the concept of “Personal Storages” to Cristal, that could be used to not only store configurations but also user settings that we may need to handle in the future.
A first Personal Storage implementation could use the browser’s local storage, and its content could be later synchronized with other remote implementations.
The point of this proposal is two-folds:
- First, decide if it’s the right approach.
- Second, choose the implementations we should focus on initially.
There will be a second proposal for the UI later.
Possible backends for Personal Storage:
XWiki
Storing personal user settings in XWiki is a logical choice. For XWiki admins that also deploy a Cristal instance, this makes a remote storage solution available out of the box. The data could easily be stored as XObjects on the user profile page. My only concern in making this our first target is that it forces users of other backends to also make an account on an XWiki instance just to synchronize their configurations, even if they don’t plan on using it as a backend.
Solid pods
Solid pods are a way of offering a decentralized storage solution for web applications. Anyone can make an account on a pod provider service, or self-host their own provider service, and get a pod that an application can then use to read/store data. Users can also easily migrate their pod from a provider to another. There is, however, a concern in asking users to make an account on an external service in order to sync their data, which could be mitigated if an administrator also offers a pod provider service but it’s still extra steps.
remoteStorage protocol
The remoteStorage protocol offers basically the same feature as Solid pods. An added benefit is that it supports data scoping. Their library also supports several backends, such as Google Drive and Dropbox, and should include Solid in the end (they have an active PR for that). In theory, this should be the most flexible way to handle personal data storage, but at this point I have no idea how hard it would be for an administrator to set-up support for the other backends.
Personally, I would lean into remoteStorage as a first target since I believe it gives us the most flexibility with minimal work, but WDYT?
5 posts - 3 participants