I have an idea rattling around in my head and I thought Lobste.rs would be a good audience to talk about it with. Also, I don’t have a blog.
I want to make federated protocols support sandboxed general purpose cloud computation. I see the current move towards federated protocols as following a sort of progression:
- Protocols v1 (imap/smtp, git, http): a closed capability carried out by users of a custom local application
- Protocols v2 (webmail, activitypub, diaspora): a closed capability carried out by users of a shared, cloud hosted application (an http server, as viewed through the browser)
The natural progression as a user of classic protocols is to gain the ability to script and tweak the interactions however I desire. I can write a bash script on my computer that runs curl, saves the result to git, and then pushes to github over https. This is possible largely because the application is local (I can choose my interface software, and I can write scripts that are also local).
However, the newer generation of protocols are based on a thin client model – I typically interact with them entirely in my browser. While advanced users continue to be able to run software on machines that they control, for many users these systems lose the natural progression of script-abiilty or plugin-ability that used to be possible with a local software paradigm.
Therefore, it seems clear to me that the next generation of federated “protocols” ought to directly support user extensibility via sandboxed execution. This is possible via seccomp/bpf, AWS Firecracker, Google gVisor, BSD jails, and other similar tools. What’s missing is tight integration with a common set of abstractions, so that these extensions are accessible by moderately-power-users, and not full software engineers.
I think this ends up looking like a thin API layer over a script execution environment. I’m envisioning a federation setup where:
- You create an account on a cluster of nodes known as a group
- You can use, modify, or create software that runs in the sandboxes on this cluster
- Your cluster can talk to other clusters run by other groups (like email, or activitypub)
- The group handles things like identity, backup, and common UI interfaces (i.e. sanitized HTML rendering, or possibly higher level abstractions like “document”, “messages”, “social media timeline”, “html5 canvas”)
To experiment with these ideas, I started writing a small rust service that runs user-submitted lua scripts to play around with some of these ideas. However, I wanted to see if Lobste.rs has any thoughts on this idea, or any pointers on prior art that might be related?
The big pain points I think will be figuring out quotas, and moderation.
You may want to consider having VMs that have some notion of “gas”, like with Ethereum or rarVM.
If you want to run code, then wasm should be your thing. By default wasm doesn’t define any APIs and if there are some, they are handed in from whatever is instantiating the module (this is also known as capability-based security, because it can only access things that you explicitly put into its namespace).
There are WebAssembly runtimes that are not in the browser, so that might solve your use case? Specifically, if you define your own APIs and hand them into the module.
I think the whitelist approach is a must here, but in your view what is the benefit of webassembly over an approach like gVisor or mbox where a supervisor process proxies all system calls?
That supervisor process can choose to expose as wide or as narrow an API as is desired in either case.