Is there an API that hide all the Solid server and RDF things and could allow simple requests such as
. login(user, pwd)
. storeDocument(json stream, location)
. getDocuments(criteria)
etc…
Then using this API it could be easy to create applications or interface existing ones
And if not - what I guess - could some people be interested in creating it?
No, not presently, that I’m aware of.
I can guarantee you that there’ll never be a login(username, password) API, so long as authentication is based around OIDC (OpenID Connect, an extension of oAuth).
The RDF principles that power Solid can only be hidden so far, but usually that comes with a trade-off. There is active research into other ways to query a pod, e.g., @jeswr doing experiments that translate graphql schemas & operations into comunica operations.
You may also find the idea of QPF or sparql interesting, as they would be closest to querying a knowledge graph (Solid is more a graph than a set of documents)
1 Like
My Solid-File-Client supports simple commands like login, readFile, createFolder, etc. which allow you to store and retrieve data from Solid pods with no knowledge of RDF and little or no knowledge of the Solid protocol. Works in browser and from command-line against all servers I am aware of.
I’ve been seeing some pretty awesome APIs that use various authentication schemes just to get a token, and from there they allow you to work with existing protocols like MQTT, by putting the token in place of a password or username.
New APIs seem like a really promising way to make solid the obvious choice for a ton of apps.
It would be amazing if Solid had something like this. If WebDAV and MQTT over WebSockets were mandatory parts of every pod, porting many existing apps would be close to trivial.
Going a bit further, pods could act as gateways for some kind of distributed hash table, the way that OpenDHT provides a standard HTTP gateway. That way, you could have a bootstrap between WebRTC nodes that works both fully offline as a pure DHT in an app, or through the pod gateway.
Or, how about an API to embed the application directly in the pod? Have a document that can contain a link to a subdomain at which you can access it, which contains some pod-specific unique value that can’t be changed by the user.
When you go to it, you get the HTML content, isolated in it’s own domain like anything else, only able to make relative URL requests to stuff that document explicitly specifies as part of the app, you log into it like anything else.
There could even be some kind of specific protocol for installing apps so you could install with just a few clicks straight from another website.
That way, you not only never lose your data, you never lose access to it, because the app is portable like the data.
Plus, a solid server hosted on a local machine would become a really cool format for shipping local apps that could work locally and on the web all the same.
What about allowing arbitrary new APIs to be added via a caching proxy/CDN type feature? You could use existing CDNs without adding a point of failure or letting the CDN track your users, since the pod could offer a shared cache and the ability to remap requests to a different provider.