Pod recipes on Safe

I guess to put a pod on Safe (for example) (not as a pod server but as a recipe to create the pod or pod proxy on your localhost as either a copy of all the resources or leaving the resources in place wherever they are and just creating a proxy) you would need:

A pod server that could return a RDF description of the pod, something like Mapping http: and file: spaces- Design Issues (also see File system to Solid mapping · Issue #237 · solid/specification · GitHub) but with extensions to also map to whatever non local resources are in the pod such as Safe resources.

And a way to make such a description from scratch, without already having such a pod.

And a way to describe in RDF the functionality of the pod, which could be as simple as a pod server software version number, or as complicated as an API description in RDF.

I think using a server (e.g. a proxy) is feasible and in some ways may be more functional, as it amounts to using Safe purely as a storage backend but it also has drawbacks: you need a server, and to have access to that (or a local proxy) server on any device.

Solid on Safe was designed to avoid all of that, but putting the Solid API inside the client in the browser. This involved using a JS library which intercepts safe:// URLs and handles them (i.e. implements the Solid protocol) as if it was a server. So not a server, but an implementation of the Solid protocol in the client (browser).

In a proof of concept (demonstrated here), this was shown to work with several Solid applications that relied on a subset of Solid features, with no need to modify the application code, only to link it with a Solid client library (fork) that intercepted safe: URLs and provided the Solid protocol on top of the Safe API.

I remember Solid on Safe well, and it was a great proof of concept, but doing it that way has some disadvantages:

  • you don’t have the ability to adapt to different pod servers versions or pods that do extra things

  • you don’t get the advantage of all the http header information that can help with things like discovery and content negotiation

  • it is tied to a particular language and browser

  • it cannot be used by local software outside of the browser

  • it cannot accommodate multiple local clients at the same time

The idea is that you don’t need a server, you create proxies on local host and use Safe out in the world. The recipes are out there, but you can only cook in your local kitchen.

I wanted to add a recipe (Solid on Safe), rather than suggest using a proxy is ‘wrong’. I agree there are pros and cons but don’t think all those disadvantages are correct…

Depends what you mean here. You can do this, but there may be differences in approach, and I don’t see “pods that do extra things” as compatible with Solid.

To me “extras” (beyond the Solid protocol) are a flaw in the pod as a service model. It’s one way providers will try to tie people to their service, making it harder to move from one provider to another (when one of the aims of Solid is to make that easy).

Yes you do because the library intercepts the request and provides a response with suitable headers. The proof-of-concept only provided minimal headers, but that’s not a limitation of the approach.

It’s tied to Safe, and if you give up the safety of the Safe APIs by using a proxy you are leaving the security and privacy protections of Safe behind, making yourself more vulnerable to surveillance, tracking and malware. For web apps, a user will probably have the choice to use another browser at some point, but that will have the same downside.

Developers aren’t tied to a particular language (only in the proof-of-concept) because Safe APIs are available in many languages. Even in the browser you can compile to WASM and call JavaScript from there.

Outside the browser, the Safe APIs will be available in NodeJS and many other languages. A developer must again choose between the flexibility of HTTP or the security and privacy protections of the Safe API. The proof-of-concept was in JavaScript, so this would need to be available to the language of choice. More work for someone but if wanted it can be done.


Using a proxy and HTTP maintains flexibility (more ready-to-use apps, and for developers more freedom in implementation), but with the downside of relinquishing the security and privacy protections of the Safe API, and the inconvenience to the user of running a server on the device. That’s still tricky, particularly for mobile.

There will be different versions of pod server software that are compatible with different versions of Solid. Pod servers are also free to add other things, and this will done by lots of people, I think, not just for profit.

But this does not accommodate multiple server versions. See above.

But the language will have to be chosen when the API is chosen, which is less flexible than having a localhost server that can accommodate local clients written in potentially different languages.

You would use the Safe APIs within the localhost server, so you would not be leaving the security and privacy protections of Safe behind.

See above. You aren’t leaving the security and privacy protections of Safe.

I summarised several pros/cons that are likely to arise and we agree on most of them, just not necessarily on which are important which is fine. Those will be choices made first by developers and ultimately users.

I think you are likely to end up doing that because just using Safe APIs is not necessarily enough.

For web apps, if you use Safe browser you can be sure that a site or web app isn’t leaking information about you. For apps outside the browser you must trust the implementation, but using the Safe APIs directly means you only need to trust the developer and his code.

If those apps are communicating over HTTP there’s an increased danger of leaking data even if the app developer and his implementation are sound. (This approach was how the first version of the Safe API worked and was discarded because it is less secure).

With more concrete descriptions of specific implementation I think the pros and cons will be easier to catalogue and discuss.

Uh, I don’t think so…

I don’t understand the danger if its all on your local machine. If you’re local machine is compromised then using Safe API’s directly won’t be secure anyway.

I try to talk as much as possible before I have to actually do anything :stuck_out_tongue:

1 Like

I think that Pod recipes on Safe could be described with the DCAT vocabulary


A file or resource on Safe would be a collection of Safe resources that would be described with dcat:Catalog

A dcat:Catalog would have dcat:Resource’s, and also could have other dcat:Catalog’s.

Each dcat:Catalog would also have one or more dcat:DataService’s connected to it with the dcat:service predicate.

The dcat:DataService’s would be the Pod’s to be created.

Access rights would be tricky because they are not supposed to be public. Each resource in a pod would correspond to dcat datasets on Safe which would group together the resource and its metafiles. The dcat datasets and resources would be in linked lists on each branch in the tree of pod resources, and if there was not the correct permission for the next one in the list the building would end on that branch, so that resources and metafiles that should not be accessible are not built on localhost and don’t appear there.

This ‘building’ of the tree of containers, resources and metafiles on localhost would only copy the dcat wrapping files or resources to localhost so when the pod is used the gets and puts would still be forwarded to the actual resources on Safe.

maybe this is just tom-foolery,

but anyway the point of it is to be able to use Solid standards for interoperability on top of Safe, so for example shapes in metafiles would be respected, and to have Safe and its advantages as storage for Solid pods, and have it work on a localhost server that could be used more flexibly than fixed APIs in the browser.