So the difference between a pod description and a pod is that the pod description is not a live thing. It is just a resource or file in rdf. It has a checksum that can be verified and it’s state is known and it can be trusted. It may reference other pod descriptions but they can be similarly trusted.
A server is a live thing and it’s state is unknown and it can’t be trusted.
So on your local OS you would have to get all the pod descriptions you need and build those pods before they’re used. You’re not importing the data in those pods, that’s left on the web. If someone else is using the “same” pod, they only started from the same description and they also had to build those pods locally. But the data referenced by pods with the same description is shared and stays somewhere on the web.
That’s my interpretation of what it would mean to use Solid on Safe without servers.
I don’t know how parts of pods would remain hidden that way, though. How would wacl permissions and things in pod descriptions not be readable by everyone? I guess they would have to be encrypted within the pod description.
I don’t think I understand why you’re taking about about descriptions etc or why this is necessary for Solid on Safe.
Solid at its core is not a particular kind of pod, but a protocol which includes LDP which allows data to be stored on something we call a pod. A pod does not have to be implemented using a server, what’s needed is something that implements the Solid protocol, however that is achieved.
To put Solid on Safe (without servers) you need to implement the Solid protocol, and I demonstrated how this can be done for LDP, a subset of the protocol with Safe rather than a server providing the storage.
I’ve made a presentation and demo of this, so maybe that’s useful for understanding the approach I used, and understanding how it works. This enabled me to take more than one Solid app and run it without a pod server, using Solid on Safe instead. See:
I am investigating abstracting a higher Solid layer from a lower decentralized foundation as well, but how do you regard this part of the Solid spec considering your citation of your Safe example (are you using an HTTP proxy server which abstracts the Safe layer?):
Solid-Rest has a plugin-system that should support any storage backend. Rather than re-inventing the wheel in terms of making the requests and responses to the backend Solid compatible, you might consider making a solid-rest plugin. I’m glad to advise if this is of interest. In terms of the spec, solid-rest aims to implement the entire spec except WAC and the http requirements you mention. At the moment I believe the only things missing (coming soon I hope) are etags, vary, JSON-LD support, support for Accept header. It is fully compatible with rdflib and mashlib so anything implemented with it should support the core Solid technologies. If you need changes in solid-rest to make it work the way you need it to, I’m open to that also.
I don’t know much about a lot of things (Fuse, BrowserFS, Solid-Rest, IPFS, Safe, or even http) so this might not make a lot of sense, but…
I think of a network like Safe or IPFS as just a kind of content addressable storage, so the resource or ‘file’ names would just be a hash of the contents. So for Solid they have to be organized into a file system. How that’s done is mainly what I mentioned as a pod ‘description’, but a description would include other things too like permissions, shape constraints, and choices a pod server might make for header responses. Those could be different for every pod. Not all pods would use the same file organizing code like Fuse.
So those descriptions would be marshaled into something accessible either as a local http server or Solid-Rest plugin. But the data ‘inside’ the ‘pod’ would just be references to the content addressable resources with hashes for names that live out there in IPFS or Safe.
The aspects your describing here I am interested in exploring as well regarding what I would describe as a abstracting/reifying/virtualizing of the “pod”.
This is definitely along the lines of what I am looking to explore further regarding almost a Solid-as-a-Wrapper/Interface (as compliant as possible or as needed) which can abstract other layers of implementation.
@markjspivey you are describing Solid-Rest. Currently the backend implementations it supports are the local file-system, in-browser and cloud spaces via BrowserFS (indexedDB, etc.).
Well, I might implement it eventually, but what is the point of me checking to see if I have access to my own files? And nothing stops the underlying backend plugins from implement its own privacy controls or WAC if it wants.
Just references to files on the web? You’ve lost me. Solid-Rest provides access to, for example your local file system. Folders are returned as turtle representation, etc. so it is used to read & write local files, it can point to files on remote pods, but to access those you follow the WAC rules of the server on which they are located, not solid-rest rules.
Pointing to files is what I mean but also mimicking everything: wac, header responses. So you don’t have to access an external server, because servers are bad.
Solid-rest supplies wac headers, and can read and write ACLs. The only thing it doesn’t do is enforce access control of local files.
Let me give you an example. Tim’s gitter-solid app grabs a gitter chat channel and stores it on your pod. It does that by looking at your profile, finding where your prefs file is, patching in a location for your gitterConfiguration file into your prefs file, then uses that configuration file to find where to store the chat channel. This all works (or will when I submit some PRs) locally too - it looks for your local profile, finds the prefs file, inserts the gitterConfiguration, and stores the channel locally where the config tells it too. So everything works locally the same as the on the server pod. On the server pod you need to login to write, but not on your local pod because it’s yours and you are altering it from your own machine. It is able to do the local part with the same follow-your-nose methods as on a server pod because it uses solid-rest.
Does it set up a local http server to mimick an external pod? And could it do that from an rdf description of the pod, complete with the things that would be internal to the pod like shape constraints? Basically something that acts just like whatever pod is described in an rdf description, only a local server instead of remote.
You could set up a local http server, but if you’re going to do that, why not just install NSS. But no, solid-rest does not use any kind of server. You access it from a client app like solid-node-client or rdflib, or mashlib or solid-shell or solid-file-client or basically any Solid app.
Solid-File-Client can copy an entire pod (include shape files, acls, etc.) to a local file system using solid-rest transparently behind the scenes. So it doesn’t need a description, you just say “copy remoteURL localURL” and you have a duplicate of your pod locally.
I guess it would be a little bit like nss, except that it would do everything, reject or accept requests, but when it came to reading and writing the resource it would just be a proxy. There would be some other differences, like it would only be one pod, unless that pod uses other pods then it would mimick those too, which could get pretty complicated.
It treats your entire file system as a pod, so you can access any part of it you want. Or you could declare several differnt pods and have them interact. The interactions should be the same as in a server based pod so no more complex than that.
