I want to write a Solid Pod server in Python from scratch. I’m doing this so I can deploy it to cloud computer functions like AWS’s Lambda or GCP’s Cloud Functions coz they are cheap (don’t charge when not being called) and can connect to cloud storage (buckets) which are also the cheapest online storage. I think these practicalities need to be considered if this tech stack is ever going to take off.
So I’ve wrapped my head around some of the Solid spec(s) to the point that i realised that a read-only, public Pod is just something that servers a WebID endpoint (Tuttle and/or HTML+RDFa) and some link to public data described by RDF. This WebID might include a public key for ID verification. There are conventions as to URL paths for where things should be I.e. /profile/ or /settings/ but this is all laid out in the WebID so stuff can be at any URL.
At least that is my mental model so far. I just want to check this is correct so far before i go into Auth and CRUD operations on this stuff. I assume that CRUD ops are just standard web verbs like GET, POST, PUT, DELETE etc on the RDF documents in the pod (plus (up/down)loading binary files I guess?)? So does this mean that a read-only, public Pod could be published on a static site like github pages?
Yes, you’ve got the basic outline. However you should check with each spec panel to see what changes have happened or are in the pipeline. The web verbs have some very specific Solid qualities having to do with the permissioning system (PUT always needs write control, POST only needs append control, etc.). There are also a number of headers the server is responsible for sending - location for POSTs, information about auxiliary files, ownership of the pod and others.
You could host a read-only public pages on github or anywhere. I’ve actually written a client-side server that allows you to basically have a minimal pod on any file system.
Good Show @jeffz !
I might try and write a S3 plugin(?) for your Solid-Rest library and see if I can get to working behind a lambda function. In any case its great to have more code examples to work from, thank you!
I feel it is important that anyone can throw up a Pod and/or write their own, the same way that anyone could publish some HTML in the early days of the internet with just a text editor and an FTP client.
Yep I agree on the ease of pod thing. It relates to my work on Solid Rest and also to Data Kitchen which is basically of combination of SolidOS and CSS to provide an easy-install “Solid in a Box”.
I mentioned in another thread but forgot to mention in this one - @kushal_das was working on a python Solid server at one time, it might be worth contacting him.
I gave up trying to implement this as I became increasingly confused with the detailed bits of the specifications -especially sections that were not fully decided.
Which i fear is part of the reason Solid hasn’t taken off amongst developers. The OAuth + DPoP + OIDC is tricky enough (but if its standard stuff there is probably a module for it) but Web Access Control looks scary (I’ve only had a quick skim of the spec).
Thanks for the links they are very helpful in exploring this space.
The two main access control systems ACP and ACL are both well specified and documented so that part is not as messy other than that there are two systems. I believe Inrupt has a library which handles both.
I hear your trepidation about the lack of specs. You might look at the Ghent Community Server (CSS) approach which is basically only implement what is spec’d and ignore the rest. In a way that makes writing a server simpler.