This reminds me of a nosleep story a youtuber I watch read.

Strangely enough, same in french.

Once again, the only thing leftist can be reprimanded for is being right too early.

I mean that the article mentions a group based in the DPRK using stolen credit cards to fund their stuff. The rust article shortcuts this by saying it’s the DPRK itself that are behind this style of attack.

The article say the attack style is “known to be used by the DPRK” (emphasis on the “the”) when the article cited mentions no government involvement whatsoever lol.

Anyone else feels like we’re supposed to sleep more often than is recommended?

I think the Lemmy logo being a blank-ish Lemming works well for it. Kinda like an invitation to add in your own characteristics (similar to how one would make their owninstance), even if that design choice wasn’t the intention of the creator.

If there’s a redesign needed, maybe the proportions could be changed, but idk.

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:

1. Implementing it in Rust would allow ocap applications to have access to the Rust environment. I have explored solutions that would allow to use the Guile/Racket library in order to create applications in Rust with it, but they often weren’t viable. I had also thought about applications having to run a Guile part, then would communicate to a Rust part via OCapN, but I thought it would be a complicated sollution. If it is implemented in Rust, it can have access to Bevy, Tauri, and any other libraries that are also available to Rust programmers.

2. Performance, memory safety and thread safety are all things Rust excels at. Currently there are concurrency issues that affect the Guile implementation (I am not sure about the Racket one, to be honest). I don’t want something that completely replaces the Guile implementation, as it has its use (dynamic typing, easier to use, easier to implement features). I do believe that implementing the library in Rust would allow for use cases not only in lower level environments (embeded, kernels, etc.), but also in environments where performance and resources are critical (certain video games, heavier applications like editors, etc.). Video games have already been created using Guile, like Cirkoban (source code: https://codeberg.org/spritely/cirkoban), which you can play right now: https://davexunit.itch.io/cirkoban. From what I’ve seen, Goblins on Guile tends to be a little slow, but I do believe that it is something that will get better as the implementation matures. Implementing it in Rust I believe will allow for a more performant application, but at the cost of dynamic types and harsher rules.

3. Implementing it in Rust implicitly expands the OCapN environment. I believe there are many use cases for applications to use a distributive ocap model. The more languages that not only support OCapN, but also make abstraction of it, the more it gives choices to people who want to jump in. While I do know the basics of Guile and would like to create an application that uses Goblins with it, I know some people who wouldn’t want to use something if it’s made with a programming language they aren’t familiar with. By having more choices, people will feel more inclined to explore the world of ocap.

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.

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.

That’s okay! I hope you enjoy your retirement!

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.

Fair lol. But it is a very interesting project and I recommend checking it out if you’re interested in ActivityPub!

I don’t think they were talking about taxes, unless I’m mistaken. It’s obviously about wage theft, right?

Edit: Nvm I forgot taxes work differently in the US

Okay yeah no the fact that you defend owning CSAM is crazy and disrespectful to its victims. Fuck off

I mean that it often does in action. Yes, theoretically, an AI could be successful at generating CSAM, but since in practice, it is nigh impossible to remove all instances of CSAM from scrapped data just by trying to filter it out, you cannot decouple the fact that it does use actual abuse material.

I was talking under the hypothetical that you proposed. That CP would be drawn. CP is a synonym for CSAM, although CSAM is more respectful. This is just semantics.

Groomers often use that as a tactic. It happens on the Internet as well. Porn can be shown, but unlike porn, CSAM is necessarily SA material. I’m saying that if it’s something ONLY used for that, then its harm is undeniable. Just having a legal blanket over the fact that showing a child porn is illegal is not the point. It’s what use case of the materials are actually valid. For example, consumming CSAM is invalid, since the children cannot consent. The second use case is grooming, which is also invalid. Since AI CSAM in practice has shown to be produced by agents that CAN’T filter out all CSAM from their data set (because it is impossible), then, for the respect of the victims, it should be illegal.

I’m not just bringing up things that are already illegal, but that if it’s used by predators to get off of material that is most likely made off of existing CSAM, and that it can harm children by the same means, then there isn’t any good that can come off of allowing its possession either. We’re talking about children who were exploited being reexploited again.

And what would stop a predator from saying that a footage or picture of CSAM was AI generated and get away with it? It purpousfully mudies the water.

CSAM, computer generated or drawn, can and has used references of other CSAM materials in order to be drawn. It’s existence can rely on the existence of previous materials, and it often does.

It makes it harder for kids to understand what’s wrong with the behaviour, and even grow up themselves to be offenders later on. Candy can’t do that.

The rate might be higher in Japan specificaly because it’s normalised. If the victims themselves don’t see any wrong with what happened to them and bystanders too, then it’s way less likely to be repported.

SA cases have been seen to be heavily underepported in Japan. Upskirts were normalized too, for reference, and they had to force the cameras to make shutter sounds when taking pictures to try to solve the issue. Still, people mod their phones to circumvent it, and the demand for such content is still high, hence encouraging the practice more.

It’s because CSAM can be used to groom kids and has to be produced. It’s existance also leads to harm to the victims, who couldn’t consent to the act.

It won’t because it normalises it. Groomers often use media like this to encourage pedophilia and convince their victims that it’s normal. Litteraly how the pedo side of the fediverse opperates.

Also, the CSAM has to be produced. I know people say AI can just approximate how a child would look doing sexual acts, but that’s half the truth. Oftentimes, predators will use victims’ names to generate it, and pictures/videos similar to the ones in their CSAM would appear. So now, according to this ruling, the produced media would be legal. That, and how sometimes loli/shota artist use CSAM for reference, the AI will most likely use existing CSAM as a reference as well simply because of the tags used in a prompt.