For those who don’t know, Spritely is an organisation building various tools to create decentralized applications with object capability security. It is run by familiar names that have participated in the creation of ActivityPub: Jessica Talon and Christine Lemmer-Webber.
The library that they created (currently implemented in Guile and Racket Scheme) called Goblins, allows the creation of such applications easily. A Rust implementation would be really useful for its performance, memory safety and thread safety, things that I believe would help develop the Spritely environment.
There are 5 stages to start implementing Goblins (0 to 4) and I have currently implemented stage 0 and 1. The source code can fe found here: https://codeberg.org/spritely/goblins. Each stages are in the pre-goblins folder. As I approached implementing stage 2 and looked at the overall architecture, I realized how much bigger this project was going to be. I took a lot of time understanding how Goblin works, and even more developping the initial stages. I’m admittedly still a beginner in software development and in making full projects in Rust. Therefore, I encountered several issues that required changes to the architecture of my implementation several times.
I am planning to make my implementation open source after I document stage 1 and make sure I didn’t put any redundant enums and traits. I’m mostly making this post to wonder if anyone would be interested to jump in, or even contribute from time to time? Documenting would even help a lot, since I’m not the best at explaining things in a clear and concise way. So any sort of help, even bug finding or suggestions, would be very helpful!
It sounds like for this thing to be really useful, you have to replace the whole application ecosystem. Sounds like the basis of a new mobile OS or something. Capability based OS’s have been written before, though IDK if any have gotten any traction.
Guile is supposed to be embeddable in C so I’d hope it’s also embeddable in Rust, or at most needs some Rust bindings. That would be a good thing to write if it hasn’t already been done.
Yeah I don’t know the situation with Guile and threading, but is there really a serious performance bottleneck? What is going on that is slow? If it’s something like cryptographic signatures, it’s presumably using a fast library, so calling the same library from Rust wouldn’t give much of a speedup. If the Guile version is basically fast enough, running it in a single thread could be a decent workaround. Do applications really have to present capabilities millions of times? I’d think it’s something they’d do once at program startup, or maybe occasionally where the user would invoke some protected operation and the capability would temporarily be enabled. In fact maybe you don’t even need language bindings instead of a local socket to pass capabilities through. Then if you really needed parallelism in Guile, you could run multiple processes listening on the socket, instead of multiple threads.
I’ll look at that section of the whitepaper. I’m still a bit puzzled by this whole thing.