It would be more like making a proxy that would act like an exact replica.
Not sure why you are using “it would” rather than “it does” since it’s been doing these things for two years now. Suppose solid-rest gets a HEAD request - it first asks the backend to read the resource which if it’s a file is a basic file read, if it’s an in-browser indexedDB, it does an indexedDB read. Then solid-rest takes the info from having read it (content type, etc.) puts those into a Header and sends it back as if it had been sent by a server.
Sure, thanks for the interesting questions. Ask more after sleep :-).
1 Like
Safe is not just content addressable, it has a domain style addressing (NRS or name resolution system) so you can address it like a normal website URL, as well as having the option to bypass that and address a file by its Safe/XOR address.
For the proof of concept I modified solid-auth-client and rdflib.js so safe:// URIs could be intercepted in the Solid app, so there was no need for a proxy or http. I just modified the LDP requests to access Safe storage, which includes a filesystem API making it easy to implement LDP storage on top. If you want more detail this is explained in the presentation and in more depth in the presentation slides which you can download (see link in second post in this topic).
This was before @jeffz’s solid-rest, so when I return to this I will look at using that rather than solid auth client.
1 Like
A general way to take a description of any server out there beyond your local trusted system and recreate it within your local trusted system would still be a nice thing to be able to do.
That way you could be told what a server out there is doing and do the same thing yourself.
It wouldn’t necessarily mean that you would be able to see within the files that that server handles. Just like that server would be able to move around encrypted files it doesn’t know the contents of, you would also.
A general way to do that would be useful, to reproduce Solid servers locally, because they might have other functions besides just get and put and post and standard Solid functions. Or they might add things like some special kind of logging or something to standard Solid functions.
Reproducing those non-standard Solid functions would also be possible, although I’m not sure exactly how. You could at least read in code and build instructions and do it that way. It could be done somehow.
But what I don’t think could be done is reproducing something locally, an algorithm, that is intended to be secret. That wouldn’t be possible, but then, that’s exactly why you would want to avoid servers in the first place, right?
Servers have many downsides and are one of the main reasons we are where we are. If it was trivial for anyone to run an always connected server with whatever services they needed, and all secure, things would be much better. But it is anything but, which creates pressure towards centralisation, which in turn creates vulnerabilities and incentives to exploit them (legal and illegal, commercial and otherwise).
It’s why people have put so much effort into peer to peer protocols, so there’s not one reason but many. But building a better internet this way is hard, and that’s why we don’t have it yet. Fingers crossed this will happen because the need for it is great.
Probably the process of visiting any kind of server (except those insisting on secret algorithms) in a Safe or IPFS world would eventually be made transparent to the developer.
When a method or function on the server is first invoked, its read-only signed description would be copied locally and a local version created. After that the copying and creating wouldn’t need to be done again.
Keeping all the local server copies consistent, if that is necessary at all, would be more complicated and might be done through shared resources. The sharing of the resources might be done with smart contracts that are simpler than the servers and are built into the network.