ilias 🏴☠️💙💛be advised, a new change incoming to FreeRTOS codebase soon 
#Embedded #FreeRTOS #AgeVerification #Software #FOSS #OpenSource #Firmware #Tech #Technology
@kkrolczyk
- 1 Followers
- 0 Following
- 21 Posts
@steveklabnik.com 🤔 what's wrong with `pub(crate)`? I agree, i'm not a huge fan (but a small ventilator ;)) of all the name scoping rules, but... "all of them" but the pub?
Ariel OSWith today's release of 0.4.0 of Ariel OS, an operating system for portable embedded Rust, our BLE API now also supports the ESP32 platform. We've enhanced the integration of Clippy by using Rust 1.94's configuration includes, and enhanced lifetimes on our I2C abstraction.
Full change log: https://github.com/ariel-os/ariel-os/blob/main/CHANGELOG.md
@Harpocrates While I keep my fingers crossed for you (and will watch closely), I have some doubts. Without fully open hardware, and full chain of trust, I think it's hard to build "unblockable", anonymous and private network; aside from all possible "negative" implications, misuse of such net. 2/2
@Harpocrates but you'd be still constrained by the infrastructure in general, plain ol' wires (well, or fiberglass). I guess one could apply various techniques, "steganography"-like, to masquerade your traffic to resemble something else, at the cost of overhead. 1/2
Lady Laura 
@Harpocrates
I think there was (once?) an attempt to build truly distributed and anonymous network, but the protocol was rather niche, with somewhat unfortunate name choice "tox" (colliding with much more well-known Python tool). I guess lora-mesh approaches could be also considered, but due to the low bandwidth and even lower density - not really successful (for now).
All TCP/IP based communication can be simply filtered out, on many (even country) levels, even if fully encrypted.
I think there was (once?) an attempt to build truly distributed and anonymous network, but the protocol was rather niche, with somewhat unfortunate name choice "tox" (colliding with much more well-known Python tool). I guess lora-mesh approaches could be also considered, but due to the low bandwidth and even lower density - not really successful (for now).
All TCP/IP based communication can be simply filtered out, on many (even country) levels, even if fully encrypted.
Caria Giovanni - HarpocratesI’ve been analyzing the current state of "secure" messaging, and my recent tests with Signal have highlighted some persistent vulnerabilities inherent to any stack relying on standard TCP/IP. Even with strong encryption, metadata leakage at the ISP/CDN level and the reliance on kernel-level interfaces like TUN/TAP remain significant privacy bottlenecks.
I’m curious to discuss the feasibility of a user-space only stack built in Rust that completely decouples identity, addressing, and transport to mitigate these leaks. My current architectural hypothesis involves an identity layer using hardware-backed Zero-Knowledge Proofs—via TEE or zkVM—to handle authentication without persistent identifiers or central registries. For addressing and routing, I'm thinking of a minimal RINA overlay where Distributed IPC Facilities (DIF) allow us to route between processes rather than nodes, effectively moving away from traditional IP-based addressing. This would all be wrapped in a "blind" transport, such as Ockam or shadowsocks-rust, to make the traffic indistinguishable from generic noise to any external observer.
I’m still weighing the practical hurdles, especially how to best bridge RINA's recursive logic with a user-space transport like Ockam without requiring root privileges. I'm open to suggestions on alternative technologies or implementations that might achieve this same level of isolation. If anyone has thoughts on the practical hurdles or existing foundations that could be leveraged here, I’d really value your perspective. Definitely feels like there's a lot to dig into.
#Rust #Rustlang #Infosec #Cryptography #Networking #Privacy #DistributedSystems #RINA #ZKP
Rust Bytes"real time sync between browser and iOS in pure Rust"
Well no, it is possible, I vaguely remember doing this (but sadly long time ago, so I no longer remember the details). Basically boiled down to having a couple features for different platforms, separate optional feature(s), and specifying dependencies accordingly. While I think "it can be done" I remember it indeed could lead to "features" bloat. Having had an internal crate for a different purpose, I remember it was much more maintainable. Your mileage may wary though :)