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:
rust
// 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.
I know it's a lot! I myself didn't fully read the white paper, but skimmed over it and went through the API documentation, as well as looked at how apps that use Goblins work. I'll try to summarize it as best as I can.
Object Capability (ocap) is a model of sorts that makes an object (app, library, etc.) secure by only allowing it to have access to certain resources based on what it needs and not what environment it's in. For example, in a regular environment, an object's permissions are based on who's running it, what group they belong to, where it's being run, etc. . It's hard to keep track of and keep totally secure, since an object might not be isolated enough. In an ocap environment, that object doesn't have any permission unless it is given. It cannot even try to do something without permission since it doesn't have the reference to the object that would allow it to do something. If the object does something malicious, you can also easily trace which permission was allocated to it and easily fix the issue.
It's use cases are mostly related to things that require interoperability between different objects and safety when interacting with these objects, since they might not bee 100% trustworthy. This can help a lot for multiplayer games, cooperative environments, chat applications, and more. To see a use case, you can go to the section 3.3 of the white paper. It was mostly the part where everything clicked for me. Section 3.3.4 really shows the power of having an ocap environment, I believe.
Currently with Rust, if you want to create an app that uses ocap, you have to implement the model yourself. During my research, I had found libraries that allowed creation of applications that use ocap, but only for accessing file/system resources. It didn't allow the user to create other objects that use ocap.
I have to admit, I am more up to speed with the Guile implementation, since I believe it is the one that the Racket implementation now derives from.
But my justification for implementing it in Rust was that:
I'm always open to criticism though. As I said, I'm still a beginner in software engineering. I just really like and see the potential in what Spritely is developing, and would like to contribute to it as well.