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:
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 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.
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.
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.
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.