Inspired by @jeffz 's solid-rest-browser I am wondering whether or not it is possible to “host” a private pod inside the browser (e.g. via a web extension). I will try to write down my ideas and a possible very high level implementation suggestion. If you have suggestions, if you think something isn’t feasible the way I proposed or even think the idea itself is not desirable, I would be glad to hear your thoughts
General idea
First of all a private pod is a bit contrary to the idea of linked data. It couldn’t be used to host a blog, chat with other people, or share any other kind of data easily with others.
In essence I see a private pod as an extension to the file system, which allows to specify which files can be accessed by different apps in the browser. This would allow to view, process and manage files stored locally through apps inside the browser or installed software.
Advantages of local pods
User won’t need to install applications which can run in the browser
No need to trust a server
Less bandwidth usage (not unnecessarily uploading and downloading files) -> less energy usage and higher accessibility
Offline use
Easy to install (if it is possible with service workers, doesn’t apply for web extension implementation) -> attracts new users
Disadvantages of local pods
No possibility to share data
(likely) no valid webid
Could lead to unexpected behavior if the app thinks it uses a public pod (e.g. sending sending an invalid url to another pod/server)
Maybe browser lock-in (it seems hard to share the local pod between e.g. Chrome and Firefox)
Implementation
My proposal is to implement private pods within the browser, so they work on all OS and are easy to install. It could be done with a web extension and probably a service worker would be possible too (I think ipfs did something similar, but I am not sure what their limitations regarding scope and availability are). The web extension/service worker would be responsible for:
Intercept requests to the private pods (e.g. pod://podA.solid/foo/bar.ext)
Allow POST/GET/… as specified by the solid API-specification
Implement as many parts of the solid server specification as possible (I think most things should be feasible, but I guess not all)
Summary
In the same way the file systems gives multiple installed apps to access local data, a local pod could give online apps a controlled access to local pod data. This means that online apps can more easily read and store data locally (which in turn has several advantages as highlighted above). The main disadvantage I see, is the lack for linked data, but as people could have a local and a online pod and transfers between those could be easily implemented I think the benefits would outweigh the disadvantages by far.
Just thinking but maybe it would be possible in theory to give others a proxy to the pod(s) in your browser. Then in their browser they would talk to it just like a pod, but under the hood it would send linked data notifications to your pod(s) resources to access things.
I’ve already thought about using WebRTC to communicate with other browsers. But I don’t think it would be possible to mimic the standardized server behavior (in particular hosting a domain which others can link to just like they could for https://mypod.com/foo/img.png). This would highly likely require both, the local pod owner and the other user to have specific addons installed and probably needs a server which connects them (i don’t know much about WebRTC, so I’m not sure about latter). Also it would require both to be online at the same time.
What I can imagine though is, to create an app which could be used for file transferring similar to instant.io (e.g. for directly sending files to friends or cloning the local pod). With an addon installed in the other users browser, it could (!) work to mimic server behavior, but it still wouldn’t be useful for a “general audience”, only for your peers. Hence blogs and co won’t work with this.
Also uploading from a local pod to a pod on a real server seems rather easy (both manually and automatically), so I would suggest that approach as an alternative in the beginning.
I was thinking that proxies to pods in your browser would be something you would have to grant, not make generally available. So for example you could grant proxies to the calendar pod in your browser to a few airlines, and tell them to find a flight that fits your schedule. If your browser is closed their proxies would just have their scheduling wait until it’s open again. Underneath a proxy would just be generic and turn gets, puts and patches into linked data notifications. I don’t see why it couldn’t work in real time if your browser is open.
I think we are talking about different things. What I meant is, that it doesn’t seem possible to make a local pod publicly available (like a blog) without any new standards and tools.
If I understood you correctly, you mean that if both parties agree on a connection between a local pod and a server/user, that they can use it like a normal pod. From my point of view this would require solid apps to have additional tools for this, not something that is possible without any changes to current apps. I don’t know how these tools would look like, but it seems possible. I agree with you if that is what you mean. If not, could you try to explain it again?
Yes, sorry I’m not being clear. I’m thinking of a different kind of Solid server, one that meets the spec but underneath uses linked data notifications and asks for inboxes of target resources and then sends requests for changes to those inboxes. Thats what I’m calling a proxy, which would have to be somehow installed on a remote machine. I’m thinking it could somehow be sent and installed from your browser. Then in your browser you would need an adaptor to handle those requests and create the inboxes, but your pod in the browser would be the same. Also the apps in your browser and the apps on the remote machine would be the same. You could use a whitelist for the inboxes, and only send the proxy to those on the whitelist. Yes, both parties would have to agree. Anyway I guess additional tools would be needed for others to access in-browser pods, sorry for my digression.
Ok, thanks for the explanation. I also believe that this is possible and would be useful, but in my opinion it is not the highest priority when creating local pods. I think the main benefit of local pods are, that solid apps could be used with local data. Actively sharing data with others (like instant.io) comes next and then sharing data with others in a way, they can use normal solid apps on it as a third. Do you agree with this or would you set the priorities differently?
Thanks for your response. I don’t really know what the priorities should be, I can only tell you where I personally am coming from. It may not be the right approach for Solid, its just my view of it.
I sort of like the idea of using something like the SAFE network and having no servers if its possible. I like that because I don’t think I can administer a reliable server myself and I wouldn’t be sure who to trust to do it for me. I’m no expert on SAFE either, though.
Anyway, as I understand it, with such a network the boundary between local and remote files is blurred. The files could be anywhere on the network, including on your machine, but hopefully close if they’re used a lot. I think SAFE has plans to implement something like events or ‘smart contracts’ and that could help reduce the need for servers, but servers will still be needed, I think.
So how those servers will work and where they will run are big questions but if there isn’t a boundary between local and remote files then it seems to me that servers could just as well run in the browser. Then the browser could hopefully help with the administration of the server(s), and hopefully that’s not a step backwards.
Then I could have a solid server running in my browser that would be just like a shared file system with permissions for users, groups of users, and as has been implemented more recently, app domains. Thats my hope, anyway. But I’m pretty fuzzy on the details
I’m working to make a Solid app able to work on SAFE as far as that’s possible as I think you know. I’m a good way to being able to do this with apps that are just storage based, which means websites/apps like blogs, forums, commerce etc. More complex apps/sites may need some changes, but the nice thing is that because the core of Solid has the same philosophy as SAFE (complexity and ’business’ logic in the front end / simple back end), the core of any website/app will just work on either.
I’m not sure why you think SAFE will require servers.
The whole design is based on eliminating servers as we know them, which is why it is going to be so much easier for people to own and control their data than any system reliant on servers, and why it can be very much more secure and reliable.
With respect to keeping frequently accessed data close, there will be opportunistic caching by nodes along the path from client to vault. I’m very interested to see how the architecture will perform on real world tasks. I’m sure in some cases it will be worse, and we’ll work around that or not use it for particular things, while there will I believe be things it is better at too.
So, as I understand it, your version of Plume for example, is the same as one that would work with a Solid server except for using a different solid-auth-client. Then your version of solid-auth-client for SAFE doesn’t use a Solid server? I was thinking that underneath it was using something like a Solid server in the browser. Could you describe that more?
Sorry, I haven’t looked at the code. When I said I thought SAFE needed servers, I meant Solid servers to give a file directory like and LDP interface to users and developers.
Sometimes I think I understand something about this stuff and sometimes it seems like it all dissolves in confusion for me
Indeed, no server in the browser or on SAFE. That might be a good solution, but it isn’t what I’m doing.
My solid-auth-client fork replaces fetch so that I can check if a client request is for a safe:// URI, and if it is I handle it using SafenetworkJS. In a way this is like having a server in the browser, but I’m not sure that’s technically correct, or if it is I think it is a bit misleading (to me at least).
I do the same with an rdflib.js fork so any Solid app or website written using these standard libraries can work with Solid or SAFE Network by dropping in the SAFE compatible version.
With a Private Data POD you will not have to be a server admin, our podCONNECT technology takes care of all those details like DNS, OS updates and patches, certificate renewals and all those other details that keep servers humming along on the internet, it really will be as easy as “Plug it in, take control of your data”
@A_A, you wrote " The main disadvantage I see, is the lack for linked data". I am unclear what you mean by this. RDF can be parsed by rdflib regardless of whether it is from a file on the file system, a string , or a remote file. I am also unclear about where you are thinking of storing the data. AFAIK the fileSystem API is not standardized across browsers and it writes to a files that are only accessible in the browser and are not seen by the actual file system. Also AFAIK, there is no easy way for a browser extension to write to the file system. Maybe I’ve got something wrong about browser capabilities or your approach though.
I assume you do know that solid-rest-file queries, reads, and wrties from/to the local file-system with file:// requests, returning LDP containers and resouces including HTTP headers which can be parsed as linked data with rdflib the same as if they came from a pod.
With this I meant, that it wouldn’t be possible to link to resources of the local pod from the outside. The data is only available from my computer, so it wouldn’t make sense to link to it from other computers. Using RDF would still work on the own computer. (Like a pod without a “public” mode)
My initial idea was to store the data inside the browser. The disadvantage is, that this would limit the visibility to only the same browser. I currently tend to the storage api for webextensions, maybe encrypted with a password, or IndexedDB (it was suggested here for web extensions, but I don’t yet know about security and reliability of it).
Does it require node for running? If yes, I don’t see much of a benefit creating a local pod with it over creating a local pod with the NSS. It would require the user to install several things, whereas a goal of this project would be to keep it simple to install (e.g. one browser addon) so non-tech-savy can use it too.
I guess I see all RDF as linked data since it provides a way to semantically link information data regardless if the data is in the same file, a different file on the same computer, or a file on a separate computer. But yes, if it only refers to linking to remote documents, you’re right that an in-browser-pod can’t do that on its own.
You’re also right that solid-rest-file depends on node and therefore is not as easy as a browser extension. However it has the advantage of working with local files accessible by other means. So different use-cases for the two approaches.
One other drawback to an in-browser pod : AFAIK most browsers do not provide a sync method for local storage i.e. you will only have the data on the device you created it on, not on the same browser on other devices. Syncing to a pod could provide that I guess.
In terms of the advantages to an in-browser pod, everything you mention is available or can fairly easily be made available in solid-rest-browser and your upcoming solid-rest-cache with the added advantage of not needing to install an extension.
However, a browser-extension pod has some other potential advantages, mostly in that it can directly access the browser and pages displayed by it. This gives the possibility for example to store bookmarks, passwords, forms, etc. in RDF through the browser’s own mechanisms. That could be very exciting, especiallly combined with cloud sync such that browsers could be synced across devices without depending on the browser manufacturer.
In any case, I think it’s a great idea and would be glad to help out in any way I can.
