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!

  • Binette@lemmy.mlOP
    link
    fedilink
    arrow-up
    2
    ·
    3 days ago

    It’s mostly that I realised that there weren’t any object capability libraries in rust that weren’t just low level stuff. From what I understand, OCapN would allow one to create a Rust app that communicates with an app using Goblins, but the object capability stuff would have to be handled by the developpers. I currently implemented stuff like creating actors with a constructor and the bcom capability, which would allow one to make object capability apps easily.

    I have already started an OCapN implementation in Rust as it was still an integral part of Goblins, but another developper was also working on it, so I’m mostly trying to talk and seeing if I could help out as well. But I know I’m not the brightest person, and if a Goblins implementation in Rust would effectively be useless, then it’s okay. I’ll focus on developping OCapN.

    • PuercoPop@piefed.social
      link
      fedilink
      English
      arrow-up
      3
      ·
      3 days ago

      I know I’m not the brightest person

      Never put yourself down!

      If a Goblins implementation in Rust would effectively be useless

      Not saying it would be useless, I’m saying I don’t understand what you mean. Certainly a high-level API on top of OCapN would be useful. Goblins, afaiu, is a guile library. Given that there can’t be a 1-1 correspondence between the API, it is unclear what would a Goblins in Rust would look like. Have you written some [non-working] example code to give a more concrete idea of what you are looking to implement?

      • Binette@lemmy.mlOP
        link
        fedilink
        English
        arrow-up
        3
        ·
        2 days ago

        I do have a peculiar way of saying things sometimes. I didn’t mean to put myself down, but more so that I know I can make mistakes and am open to suggestions. Still, thank you!

        My goal is to expand the object capability environment and make it easily usable in Rust. Here’s an implementation of the greeter actor using the API that I made:

        // Vat Connector currently doesn't work, since vats are not implemented yet
        let vat_connector = Some(VatConnector::new());
        // New actormap inside vat
        let am = make_actormap(vat_connector);
        
        // Create a new constructor, greeter, that takes in the greeter's name to build an actor
        constructor!(greeter, |_bcom: Rc<dyn Bcom>, my_name: String| {
            // Creates a behavior for the actor that takes in a String to say hello to
            behavior!(|your_name: String| -> String {
                // Value is returned to handle different responses, but I will clean this up to only return the String itself
                // Also, Value is for JSON. The API should use Syrup for OCapN
                Value::String(format!(
                    "Hello {}, my name is {}",
                    your_name, my_name
                ))
            })
        });
        
        // New actor greeter alice
        let alice = actormap_direct_run!(&am, { spawn!(greeter, "Alice") });
        
        // Alice greets Bob
        assert_eq!(
            "Hello Bob, my name is Alice",
            actormap_direct_run!(&am, { call!(alice, "Bob") })?
        );
        

        This code works using the library. There are still many things I would like to clean up and change, as indicated by the comments. I just want to make it easier to create applications that interpret object capabilities. There are a lot of things that the library does different than Goblins (type restrictions, uses enums for return values, traits instead of meta types, etc.), but it mostly follows a similar philosophy of having a library that allows you to create an app that relies on object capability.