core VS inox2d

Secure notetaking, Identity and cryptography (README is way out of date, sorry), and seizing the means of production (kind of on hold until Stamp is out of PoC).

Organizationally, yes, the non-market portions of what you're talking about could be modeled by Basis. Right now, Basis is really just a protocol without any implementations. So the interactions you bring up can be described by that protocol, but there's no actual storage of transactions or costs or transferring of funds etc etc happening anywhere right now. I started on an implementation a while back but I realized I hadn't figured out the protocol itself well enough to sink time into building code. I'm now feeling good about where the project is and could probably start coding the implementation again. I'm working on a sister project to Basis currently (https://stamp-protocol.github.io/) which will ultimately be used to define network membership and is also giving me a playground to test out transactional p2p systems, which is ultiumately what Basis will be.

Right now there's no code (well, there is but it's pretty stale) as the protocol itself is getting more solid, but it's approaching the point where the reference implementation will start getting updates again, and ultimately start driving applications that will use it.

Thanks! And yes, the project is mostly theoretical right now. There's an incomplete rust implementation of an older version of the protocol. It's been collecting dust for a while, but once more of the newer iteration of the protocol is solid it'd be great to start working on it again.

A number of things. As mentioned, it's just a protocol right now (although there is a decent amount of code that goes into the economics) so it's more of a question of "what does it enable other things to do."

I'm writing Inox2D, which is kind of a rewrite of Inochi2D in Rust. The aim is to reach more use-cases such as web with WASM and even potentially embedded development, but at the very least an implementation in a low-level non-garbage-collected language.

Inox2D, an experimental native Rust implementation of Inochi2D.

inox2d - official experimental reimplementation of Inochi2D, an open-source alternative of Live2D for animating 2D puppets in various contexts such as games or vtubing. inox2d isn't really meant to be a replacement over the current implementation, but more of a complementary one that extends it's use-cases, for example embedded devices and web integration with WASM.

Hey, I'm working on inox2d which uses glow.

For example, I wouldn't want to separate this into multiple files, would make it harder to see where all the deserialization logic is.

For example, I'm working on Inox2D, a reimplementation of Inochi2D in Rust.

I absolutely get that. It was actually very clear in a project of mine. I work on inox2d which is a native implementation of Inochi2D in Rust (Inochi2D being a FOSS puppet animation system, like Live2D which is used by vtubers and light novel engines notably).

For example, on my Inox2D project, I was using serde to deserialize some JSON payload. But that came with some hacks I had to do, like have a temporary struct that gets converted to the final one because it wasn't possible to serialize it by itself, and add extra-dependencies to make the system extensible while also supporting external structures I used like Arena from the indextree crate.

You can find it at https://github.com/Inochi2D/inox2d. If you know stuff about OpenGL and low-level rendering in general I'd really appreciate some help as I myself am very new to this stuff.