I’ve recently thought about how we could make solid apps work with other projects as a backend, like Dropbox, RemoteStorage, the SAFE network, IPFS, browser storage, etc. This would allow people to start using Solid Apps without requiring them to store the data in a Solid Pod.
Here are some thoughts from me, not that structured yet and likely I’m missing some points. If I find some time I will try to put it into practice, but that won’t be in the near future.
Limitations
- Features
Most backends will only be able to support a subset of the api spec. In particular, I think that GET/POST/PUT/… requests will work, but features like Websockets and SPARQL requests likely won’t. Access Control would probably be hard to implement, likely not possible for some.
- Making apps compatible
This could be done either by modifying the code of the app (e.g. adding different libraries), by making a browser extension which replaces libraries (e.g. solid-auth-client-compatible instead of solid-auth-client) or by running a mini-server on localhost which provides a solid pod endpoint.
- Usability
Installing browser extensions or running a mini-server isn’t very user friendly. Making the apps include compatibility libraries seems rather good, the main problem is how to select the backend (e.g. creating a configuration menu).
Ideas for implementation
0. Making libraries which provide login and fetch methods for specific backends
I think for all implementations it would be useful to have libraries which do authentication and implement a subset of solid api-rest. They could use a common library for making solid-like responses (e.g. solid-rest). For example “solid-proxy-dropbox” and “solid-proxy-localstorage” libraries.
1. Including a special libraries
We could create a solid-auth-client-interoperable library and then use this in apps. It would need a way to set the preferred backend (e.g. auth.setBackend(SAFE)
), a modified login method, and a modified fetch method. The fetch and login method would be specific to the chosen backend and could be dynamically loaded (import('./solid-proxy-dropbox')
) to minimize loading time.
The solid-auth-client-compatible library could then be used inisde other libraries, or as parameter if the library allows it (like in the new solid-file-client). If necessary one could also override the window.fetch method to the compatible one.
2. Running a localhost
We could create a mini-server which serves a solid-pod endpoint locally which forwards to the specific backends. When it gets a request, it would make a request to the specific backend (e.g. dropbox), make the response solid-compatible, and then return it. Authentication would be over a local webpage.
3. Using Web Extension to replace libraries
We could create a web extension which replaces requests to import solid-auth-client with a solid-auth-client-compatible version. The user could choose the preferred storage and login in the web extension, and the web extension could use a content-script to update the settings in the app. When the app makes a request, it uses the fetch from solid-auth-client-compatible without knowing it.
Overview/Summary
Implementaion | Usability | Modify apps | Install | Starting | Access Control |
---|---|---|---|---|---|
Including library | good | yes | no | no | no |
Web Extension | ok | no | yes | no | no |
Local Server | bad | no | yes | yes | possible |
I think that if we want to do this, my current suggestion is to do it in this order. This will probably change depending on discussions.
- Think about an interface for solid-proxy-dropbox and co
- Make such an interface for one or two backends
- Make solid-auth-client-compatible library which can switch between these proxies
- Make user guide how to make something compatible
- Make Web Extension which injects solid-auth-client-compatible
For this, I think the proxies and the authentication part will be the hardest things (regarding implementation and design).