The would protect against malicious code running on the Dev's computer (which AFAICT is the case here), but not against the code created using the infected library running on users' computers. And honestly, seeing the regularity of supply chain attacks in recent times, I think we need to find a better way to work with supply chains going forward. Although I admittedly don't have any solutions myself, tbh.

pretty specific baremetal requirements

I do, for some things, unfortunately.

I think Firejail or good old systemd sandboxing would be massive improvements though; I just need to invest the energy in setting them up.

An atomic distro + toolbox may be what you’re looking for, unless you have pretty specific baremetal requirements

These build scripts should really be restricted. For any language, not just Rust.

It appears I wasn’t hit, though I easily could have been, as I installed some Rust-based Python packages recently.

I keep telling myself I’m going to containerize more projects, but it’s getting ridiculous now… TBH, maybe more Linux distros need to operate on a more strict “containerize everything by default” principle, as this is going to keep happening.

It was a backhanded complement based on that fact, my friend.

I haven’t use AI at all

use cargo-scholium to extract and format annotations

At least use slop in the README so we can complain.

I'm so confused, is this an AI company or is it one dude and his Claude subscription larping as a company? Because its the same 1 guy on all the Repo's that aren't forked.

Slop. And yeah I hate it. Rust already has plenty of concurrency features.

As mentioned in the article, it enables scenarios that getters/setters can't because of the borrow checker.

Thanks. Ive started doing that. With the signal protocol. https://github.com/positive-intentions/signal-protocol

I have a demo of the JavaScript version. The UI there is reasonably mature. https://ui.positive-intentions.com/ . Tauri would be good to package it up into a native app with a web-view, the rust approach would allow for a better native build. I see that native build is only about a couple megabytes (in contrast to a whole functional web-view as the base).

I wonder if there could be architectural benefits to having it all in rust. In particular I'm interested in the idea of "end-to-end formal verification" (I just made that term up. Not sure how to describe it).

Thanks for tips! i really appriciate the thoughts and advice. id like to drill into the feedback further.

For learning purposes?

sure. as would be the persuit of creating anything worthwhile. i consider myself an expert in javascript. there are countless learnings i had in the approach when i was working with js. rust certainly carries a learning overhead to pull of properly.

use something that already exists like Matrix or Signal

agreed. my project isnt at all compable or as stable as those tried-and-tested implementation. my project is far from comparable, but its not for lack of trying. the key detail that sets this apart from all other apps is the browser based client-side philosophy. no need to install anything. your ID is crypto-random and so the app doesnt need to rely on any central registration system like phone numbers. your ID is unguessable and to connect to someone, you have to explicitly share it. webrtc has other nuances like being to route through a shared network for secure/faster transfer. my approach to "secure messaging" in this project is fundamentally different to signal and matrix and has tradeoffs and capabilities that make a direct comparison nuanced.

No encryption is secure if it isn’t peer reviewed and extensively tested

correct. i am also looking to create something people can use. youre not the first to advise things like peer-review, but its also important to have context?/perspective?. as a unfunded-side-project, things like third-party audit are prohibitively expensive. the best i can offer is to mention the caveats (as is the first thing mentioned in the post and throughout my documentation). its clear and understandable nobody is going to take their own time to review my code/docs. i have tried for various open source funding/grants... all rejections. Kerkhoff's principles are met, but its clearly too specialized and complicated to review for most... again, its not for lack of trying.

You can do formal verification in any language

i was previsouly investigating what could be done in JS. i couldnt find anything that i liked. perhaps you have any suggestions? i wanted to avoid creating AI-slop to address this and so i though rust would be more suitable with existing "reasonably mature" tooling. i was separately working on the signal-protocol, where i added things like formal-verification... it seems to work well, but there is a bit of a diconnect when bridging js to wasm... and thus this approach for a more pure rust approach. thanks for pointing me to Ferrocene. i'll take a look. note: im aiming to avoid costs where possible.

This can help defend against timing attacks.

the signal-protocol there aims to address this, like all of my projects, it lacks third-part reviews, but i hope its comprehensively documented (https://positive-intentions.com/docs/technical/p2p-signal-protocol/). there is an unfortunate AI-stink to it that is difficult to remove from my docs, but i hope it doesnt come across as low-effort. i remember the days before AI. without it, i wouldnt be creating docs. i would still encourage you to ask me for clarity on details instead of wasting your time on the docs.

Rust also has a great crypto ecosystem

yes. it was needed for the signal protocol because i needed certain primitives that were not provided by the browser.

thanks again for all the advice. i really appriciate it. id like to avoid having a backend as part of the "philosophy" of the app. it revolves around a webrtc connection and local-only storage.

Have you considered just rewriting the cryptography parts in Rust and calling those from JavaScript? In the projects I've seen so far, it was always possible to move the cryptography stuff into a standalone library.
And then with a WebAssembly wrapper, you could call that from JS: https://opensource.com/article/19/3/calling-rust-javascript

Don't get me wrong, I'm a big fan of Rust. I also think the WebAssembly GUI frameworks are cool. But at this point in time, I'd say they're cool for people who don't want to write JS.
If you're happy with JS, then the ecosystem of web component libraries will very likely make you more productive than you'll be with Dioxus or Leptos.

The GUI frameworks that OP mentions, Dioxus and Leptos, use WebAssembly under the hood.

Was interesting to skim through that article, though. I've been building WebAssembly GUIs for 3 years now and I'm only superficially aware of the described steps, because the frameworks abstract all that gubbins away for you. 😅

id like to investigate about rewriting my "decentralized p2p encrypted messaging app" in Rust. if you are familiar with any of the details, id like to hear your opnions on the approach.

For learning purposes? If you actually intend to create a service people are supposed to use, then use something that already exists like Matrix or Signal. No encryption is secure if it isn't peer reviewed and extensively tested.

If it's just for personal learning, then that doesn't matter.

the core reason behind investigating rust is that it has better tooling for things like formal-verification.

You can do formal verification in any language, but it's mostly used for languages with certified compilers (and you'd have to use one of those compilers). For that, you'd want to look at something like Ferrocene, but that costs money.

Instead, the core reason behind using Rust should be the ability to use constant-time algorithms. This can help defend against timing attacks.

Rust also has a great crypto ecosystem, so a lot of the tools you'll want are already built for you. Use them.

things like audits and formal-proofs/verification are fundamentally invalid because i used AI to create it.

Correct. An audit depends on someone's reputation, and formal verification requires review.

Anyway, learning Rust will take some time. For backend, the ecosystem goto is usually axum, and Rust has a built-in TCP client/server but you might want to see what tokio offers if you're using async.

I'm not an expert on Rust nor webdev but maybe wasm (I just picked a result that seemed worthwhile. IDK how much up-to-date this is) is the thing for you to explore?

Yes and no.

And you clearly missed the enums part.

So basically language support for sealed traits and reducing need for getter functions. Kinda neat but not that significant.

most types are not thread-safe.

Safe rust is thread-safe in the sense that you can't have runtime thread unsafely. If we are going to ignore the role of compile-time errors, then literally nothing is safe.

Also, what is "most"? Can you source that claim?

This is horrible in my view. All types that implement Deref and/or DerefMut can be called smart pointers, and everything is “thread-safe” in safe Rust.

If I had to call something “Rust’s thread-safe smart pointer”, it would be the actual references &T/&mut T where T: Send + Sync.

Not everything is thread-safe in safe rust; while safe rust prevents you from using thread-unsafe constructs in a threaded context, most types are not thread-safe. That's why you have both Rc and Arc, since it is not safe to use non-atomic reference counting in a threaded context, but you don't need the overhead of atomics in a non-threaded context.

Nor are references &T/&mut T where T: Send + Sync considered smart pointers in Rust. Those are just references to something that itself implements the traits required to make that type thread-safe.

See also https://doc.rust-lang.org/stable/book/ch15-00-smart-pointers.html and https://doc.rust-lang.org/std/sync/struct.Arc.html#thread-safety

This is a very pedantic complaint. Given that you haven't read past the first sentence, I'm not really sure what to discuss here.

"Smart pointer" is commonly used to refer to reference-counted pointers that free automatically.

great article!

Is it?

I didn't read past the first sentence:

The Arc type is Rust’s thread-safe smart pointer

This is horrible in my view. All types that implement Deref and/or DerefMut can be called smart pointers, and everything is "thread-safe" in safe Rust.

If I had to call something "Rust's thread-safe smart pointer", it would be the actual references &T/&mut T where T: Send + Sync.

Digression: All the traits involved like the 4 mentioned above point to the C++ centric concept of smart pointer not mapping cleanly to Rust semantics imho. But that's a long lost battle.

Let's see what the official Arc docs say:

A thread-safe reference-counting pointer.

Will you look at that! An actually accurate short description that is already available.

While not widespread, there is already a small myth out there that paints Rust as if it's Swift-like, a ref-counting centric language.

rkyv is not like serde. There is no process of deserialization. The function rkyv::access(...) takes a &[u8], performs a consistency check, then casts the pointer it was passed to the desired type and returns Result<&T, Err>. I will say this again: "deserialization" in rkyv is a reference-to-reference conversion.

As you can imagine, it's very fast, but the tradeoffs are massive. The serialized bytes must exactly match the memory layout of a struct (usually distinct from the type being serialized) called the "archived type" (which must be #[repr(C)] or #[repr(transparent)], and which is most commonly generated from the fields of the struct being serialized using a derive macro). More importantly, there is nowhere to stick deserialization code which could convert a Unix timestamp to a jiff::Timestamp.

You can't really implement custom serialization schemes for third party types with it, at least not unless you want to define that #[repr(C)] struct yourself, and/or you're okay with actually deserializing (in rkyv, the Deserialize trait accepts a reference to the archived type and returns an owned value of the serialized type, usually by effectively cloning it) and the performance cost that entails, and with how my codebase is currently architected, I'd have to redo it every time I used the value. rkyv support kind of has to be baked into a library from the get-go for it to be worthwhile.