As an APP developer, I don’t have control of SoLiD POD. However, I need some server-side feature that is not part of current specification.
For example, my subscriber app needs a corn-job that run 4 times a day on the server to crawl some certain websites and save the result to user POD.
And there may be a middleware that does some postprocessing on user files, that do some NLP parsing on server side.
And some application may want to cache data into the DGraph database and perform graph pattern search.
Node-Solid-Server can’t meet of those demands by itself.
I think there are two ways to support third-party services:
allow server plugins and middlewares, though this will cause customized solid-servers to have lots of non-standard POST API, make Solid App works on these servers can’t work on other standard solid servers. But in this way, we can add things like IPFS cache to solid-server. And ass support for Zapier.
allow Personal access tokens as Github App does. A user can generate a token on POD admin, and every token is associated with a set of ACL, so third-party services can easily be integrated into user POD.
These two potions have their own drawback, so it’s better to support them all. So we can use server plugin to support custom DB backend for scaling up (storage layer), and use Personal access tokens to support custom pre and post-processing (application layer).
Hoping NSS can expose more internal lifecycle hooks to the config. In this way, custom DB support will be easier.
And currently, the only way to access data is through OIDC, which only works for the web app. If there were a Personal Access Token system which allows a 3rd-party server-side app to access user data with ACL control, complex app likes cronjob-crawler may become possible.
It seems to me that this is just one of the areas where we need to count on the file system that is serving Solid. The file system can support things like ftp, ssh, tar, zip, etc. as well as processing apps and languages. To be in the full Solid spirit, these processing apps should not themselves be served by Solid, only used for pre and post processing. Solid providers like inrupt and solid.community will need to offer those other services and in the future we will be able to choose Solid providers who keep well-provisioned file systems. At least that’s what makes sense to me.
NSS is using the file system as storage, but this is not a requirement for Solid Servers. I contrary, Solid providers that want to scale to thousands of users and millions of triples need to be backed by quite a good database. Nevertheless any provider could offer any form of pre/post processing of data. Another option would be third-party services, that can access your pod to process whatever the user has in mind.
I actually want a way to affect user’s POD, one way is use personal access token to affect POD out side of solid-server, another way is use server plugin to affect POD directly on solid-server.
But I think the best circumstance is that solid providers are symmetrical. So user on different POD provider can use same APP. Otherwise, every APP will provide their own custom POD provider to support a set of pre and post processing that they think is useful.
Could you clarify “server plugin”? Do you mean just an application you install on your server, like would do with curl? Or do you mean a plugin for the solid server?
I mean a plugin on solid server, just like how you use middle ware on express server.
When programmatically starting a solid-server, you can pass in a middleware, so solid server will start using IPFS as backend, or use NLP to preprocess all text file adding semantic metadata.
In this way we can customize solid-server without forking it’s code.
I think the support of Personal access tokens could also be a server plugin for solid-server.
Nice! Would be nice to have something like that. I could imagine some plugin that automatically processes certain notifications, without the need for the user application to be active.
I understand the reasoning and I’d like to hear from those who designed Solid about this because I think their philosophy is to keep the server simple and put the complexity in the client, though I’m not sure what their reasons are.
I share that goal - keep the server simple and put the complexity in the client, but not necessarily for the same reasons.
My reason is that any server is hard to maintain, and the more complex the harder that becomes, which in turn undermines decentralisation. I think the pod as a service, server model is already vulnerable to centralisation and that additional complexity in the server makes that worse.
I do understand the desire for server side features from developers, partly because it is what we know, what we have tooling for etc, and partly because some things will either be much harder or not practical client side. At least until we figure out alternative technical solutions.
I see development of client side solutions and eliminating the server as the best way to ensure decentralisation because the pressure to centralise service provision is powerful, and the more onerous the service, the stronger that pressure becomes.
I’ve started yesterday new thread - Push Notifications (Push API) - to get feedback on how people envision such features where need to run ‘somewhere in the cloud’. Thinking that solid servers like NSS should stay generic, I would imagine writing some kind of bot that would take such custom responsibility. Any app that can run on someone’s device could also have component that runs in a cloud as a bot service.
Services implemented as such bots could already use Solid Websockets API and build their functionality around that subscription. AFAIK @codenamedmitri did most of the work on WebID-OIDC and maybe could share some insights on best practices for having such services (aka bots) authenticated.
I also see need that as Progressive Web Apps get traction and more and more people will run Solid apps on their mobile devices, sometimes to optimise for battery usage and mobile data usage applications will need to offload some work to server side components running ‘in the cloud’, I think twinql agent could come as one of possible examples: https://dan-f.me/twinql/
.
Cheers!
Since we often talk about ‘smart clients’ we can think of such bot running as service ‘in the cloud’ as such ‘smart client’ just not part of application running on someone’s local device. Actually some folks working at Google explore building PWAs following Actor model - https://github.com/PolymerLabs/actor-boilerplate where some actors run on the main thread of the browser, other actors in Web Workers and yet other actors can run ‘in the cloud’, one could compose an application execution in different ways depending on specific requirements
I think currently the simpliest solution is to use https://github.com/jeff-zucker/solid-auth-cli and give your server-side service a WebID, then let it do what a human can do automatically.
I was wondering why all of the Solid Pods on https://solid.auting.cn are automatically set to private and requires a user to login in order to see what is supposed to be a public homepage? Also, can you tell me why we are not able to use Solid-Ide on your site? i have no problem signing into your site with Solid-ide but, no changes are allowed to be made using this app, is that a bug or intentional?
I was wondering why all of the Solid Pods on https://solid.auting.cn are automatically set to private and requires a user to login in order to see what is supposed to be a public homepage? Also, can you tell me why we are not able to use Solid-Ide on your site? i have no problem signing into your site with Solid-ide but, no changes are allowed to be made using this app, is that a bug or intentional?
