solid / solid/specification

Server-side scripts registration

Open
#390 6 comments 5 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

topic: computation
Dominant language
HTML
Stars
563
Forks
108
Avg merge
4d 13h
Merged PRs (30d)
3

Description

I know this is a long shot, but I thought it'd be interesting to get the conversation started about running scripts in a POD.

So far, I've been building apps entirely on the client, and that's worked for my use-case. But I can see a point where I'll need to run some code in the server. The current solution for doing something like that is either to use a purpose-built POD with additional functionality, or to use a non-Solid server to perform the computation and communicate with the POD like any other client. Whilst both solutions can be viable, I think it would be great if there was something in the protocol to handle these use-cases without relying on special PODs or a centralized server. One way to achieve this would be to allow registering scripts on the POD.

For example, imagine that I'm building an RSS reader in Solid. I could upload a file /scripts/rss-update.js to my POD and configure it to run once a day. This script would fetch all the RSS sources and update the related documents. It could be configured using something similar to unix cron jobs:

@prefix solid: <http://www.w3.org/ns/solid/terms#> .

<#job-1>
	a solid:CronJob ;
	solid:schedule "0 0 * * *" ;
	solid:script </scripts/rss-update.js> .

Another idea would be to run scripts whenever some resources change. I started thinking about this looking at @srosset81's presentation in last month's Solid World. This is what ActivityPod's bots could look like:

@prefix solid: <http://www.w3.org/ns/solid/terms#> .
@prefix as: <https://www.w3.org/ns/activitystreams#> .

<#events-bot-1>
	a solid:Hook ;
	solid:on solid:ResourceCreated ;
	solid:resourceType as:Invite ;
	solid:script </scripts/update-event-acls.js> .

<#events-bot-2>
	a solid:Hook ;
	solid:on solid:ResourceCreated ;
	solid:resourceType as:Join ;
	solid:script </scripts/update-participants.js> .

<#events-bot-3>
	a solid:Hook ;
	solid:on solid:ResourceCreated ;
	solid:resourceType as:Update ;
	solid:script </scripts/notify-participants.js> .

<#mailer-bot-1>
	a solid:Hook ;
	solid:on solid:ResourceCreated ;
	solid:resourceType as:Invite ;
	solid:script </scripts/email-invitation.js> .

<#mailer-bot-2>
	a solid:Hook ;
	solid:on solid:ResourceCreated ;
	solid:resourceType as:Join ;
	solid:script </scripts/email-participant-joined.js> .

In any case, I know there are many questions and concerns that arise from doing something like this. But I also believe it goes in line with Solid's vision, an even if this isn't going to happen any time soon I thought it'd be interesting to discuss.

Here's some open questions I have:

  • How could this be done preventing abuse?
  • What are the security concerns of doing something like this?
  • What language should scripts use? (not all PODs are written with JavaScript)
  • What could the API look like for these scripts? (something like AWS Lambda comes to mind)
  • How would users authorize these scripts?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the cron-job and resource-hook examples in the issue, then review the linked AWS Lambda documentation and Solid World presentation for context. This is a design discussion rather than an implementation task; done would require an agreed protocol, execution model, security approach, authorization model, and script API.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
backend, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
18/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.