Solid-Plugins: pod WASM runtime interface for plugins, running jobs unfit for browser client

One of the core concepts of Solid, is having all application logic in the client (browser), whilst the Pod mostly serves as a DB + Auth machine. This model works fine for many types of apps, but it leaves some usecases unsolved: when the back-end needs to do jobs on its own.

For example, assume I want to build a chat app (think Slack) that works with solid pods. It stores not just my own chat messages, but also the messages of my team. If I want to link it to other services (say, github issues) I might need some webhook functionality.

It would be really nice if I could write and add plugins to my solid pod that function as background processes, or perhaps middlewares. This would give developers an extremely powerful API to build any type of app.

However, it is essential that these plugins run in a sandboxed runtime - they should not (at least not by default) have access to all user data, the disk, or even the internet.

Luckily for us, two new technologies are emerging that help to achieve this: WASM (Webassembly, a binary format that runs everywhere) and WASI (a universal system interface that makes it possible to let various programing languages talk to each other and access system features). Several runtimes already exist (Wasmtime, Wasmer), and they provide APIs for various programming languages that could function as a host.

How could this work? Well, the plugin itself can be written in any language that compiles to WASM (which is a rapidly growing list). The plugin module might use some functions exposed by the host (your pod), for example a Triple Pattern Fragment function that returns some statements. It might also import some callbacks, e.g. onResourceChange, which is called every time a resource changes. This enables middleware-like patters. You could use this to add functionality to your pod, such as a custom notification system, or a fulltext search interface. A plugin might also register a couple of routes for your pod, which the Pod needs to route to.

Some pseudocode that shows how a plugin might look like:

// This function has some custom validations that are run for new BlogPosts
function OnResourceWillChange((store, Resource) => {
  if isABlogpost(Resource) && isValid(Resource) {
    return Ok
  } else {
    return Error
  }
});

// Or a callback that you can use periodically, to scrape content or build some index for something external
funtion OnRunPeriodically('day', (store) => {
  const newthing = fetchSomeAPI();
  store.add(newthing);
})

The plugin will be compiled to .wasm, and will be referred to some RDF resource, for which we will need an ontology.

@prefix runtime: <https://w3c.org/solid-runtime/>.

:myplugin a runtime:Plugin;
  schema:name "CoolioPlugin";
  runtime:path "/coolioplugin";
  runtime:wasmBinary "https://example.com/plugin.wasm";

Perhaps this is a bit unconventional, and perhaps it is not the solid-way of doing things, but I think it has some interesting merits:

• It's good for privacy, Since all code is running on your own pod, you have way more control over it. You could do similar things with external serivices, but that kind of defeats the purpose of having a Pod.
• It's performant, probably way more than an HTTP API. This is especially relevant
• It's powerful. Devs can build pretty much anything they want using this!
• It's language-agnostic, or at least, all languages that compile to WASM can work with this.

I think it might make sense to standardize an interface just like this, although it might need to be a separate spec from this one. Wondering what you think of this idea.

No repository files, tests, or entry points are named in the issue. Start by reviewing the proposed WASM/WASI plugin model and RDF ontology, then determine whether the project wants a separate standardized interface; done means an agreed scope and specification, rather than an implementation inferred from the proposal.