I’ve only looked at a few SOLID Server implementations, but the ones I’ve seen run pretty “down-to-earth” I would say. Is there anything preventing a user from building a SOLID server on top of an existing Framework, like Laravel for PHP or Flask for Python?
My guess (without much research and any server implementation experience) is, that these frameworks don’t provide much utility for solid servers, because the endpoints for pods are dynamic, based on which files are stored (contrary to well-defined API endpoints which are known in advance).
For a pod, a typical request could be:
- Incoming request /some/path/file.txt
- Check if resource /some/path/file.txt exists
- Check if method is allowed for this type of resource
- Check if the request is authorized to do this action
- Return response
If I take flask, you would have to make one single wildcard endpoint for all possible routes and methods (as we don’t know in advance which routes are allowed). Then, it would probably help a bit at parsing the body, setting response headers, etc. But imo one main point of these frameworks is the structure they provide through the routing, splitting the different requests into multiple functions, which doesn’t seem possible for Solid pods to me.
Actually, NSS uses the Express framework. Though the usage of it doesn’t seem too much either:
The create-app.js and ldp-middleware.js files are probably most important, as they setup the routes for the pod content (eg
router.get('/*', index, allow('Read'), header.addPermissions, get), where index and co are custom middleware functions).
That makes sense to me, having the pre-defined regexes isn’t great when most of the content generated is at dynamic endpoints. In that case, rather than a full web app framework, a better building point may be on some lower level HTTP server? Something that can handle an HTTP(S) request but doesn’t really have a defined muxer. Or maybe you could write your own custom implementation of a router at that point?
I’m not sure what you mean with “down-to-earth”? But regarding
Is there anything preventing a user from building a SOLID server on top of an existing Framework, like Laravel for PHP or Flask for Python?
The answer is: there is nothing preventing you!
At this point, it might be important to remember that a Solid Server or “Pod” consists of three parts:
- An Identity described by a Solid WebID Profile, with links to an Identity Provider and a Storage Provider
- An Identity Provider to authenticating the WebID using Solid OIDC
- Storage Provider to store linked-data and regular files (like images, videos, etc.) related to the WebID using the Solid Protocol
You do not need to support all three parts. For instance, you could opt to only support the storage part and require users to have a WebID (and authentication thereof) elsewhere.
The only “must have” route is a
/.well-known/openid-configuration URL for authentication, if you provide an Identity Provider.
The WebID Profile is well-defined, but the actual file can live at any URL.
Everything beyond that (i.e. storage URLs) you can define yourself, as long as they are properly linked to from the WebID profile.
So, even if you already have an existing application, you can make it “Solid Enabled” by defining a URL Endpoint (for instance
/storage/) and route everything underneath that to the Solid part of your application.
This is exactly how the Solid-Nextcloud plugin works, of which I am one of the developers.
The relevant PHP code lives in separate Composer packages. Both the storage package and the authentication package use PSR-7 Request and Response objects to guarantee interoperability with any PHP framework.
Part of the original plan was to create Symfony and Laravel bundles/packages, but this is postponed until funding is available.
Thanks for the insightful response, that cleared a lot of questions I had about the ecosystem up. I guess one question I have then is really how does someone with a webId initiate a storage space on a resource server? The two solutions I’m the most familiar with are the node solid server and the community solid server, and both of them provide you with a pim#storage object that is created for you. How would a rogue user with an IdP and a web ID go about registering with a solid resource server not at web ID creation? In my mind, this is just a POST to the resource server and a new base URI + resource uri is created for them, but I Am wondering if there is another or better approach.
The registration process is not standardized, so you can do it as you wish. The pim:storage should be part of the WebID profile (Solid WebID Profile)
I think reasonable would be:
- (user already has the WebID my.id/user)
- user registers to my.pod and gets my.pod/user (via UI)
- user goes to their WebID provider and adds the pim:storage predicate pointing to my.pod/user (via UI)
iirc, the pod server must add some kind of storage predicate to the my.pod/user path (the root of the storage), but I don’t remember how exactly this looks like. This would be part of the server-side pod setup, after the user registered.