{"id":850,"date":"2026-06-07T20:08:32","date_gmt":"2026-06-08T04:08:32","guid":{"rendered":"https:\/\/salemdata.net\/johnpress\/?p=850"},"modified":"2026-06-07T20:08:32","modified_gmt":"2026-06-08T04:08:32","slug":"reticulum-on-rust-comparison-of-two-projects","status":"publish","type":"post","link":"https:\/\/salemdata.net\/johnpress\/?p=850","title":{"rendered":"Reticulum on Rust: Comparison Of Two Projects"},"content":{"rendered":"<p><strong><span style=\"color: #ff0000;\">highly technical<\/span><\/strong><\/p>\n<p>There are two projects that came to my attention where the Reticulum implementation<span id='easy-footnote-1-850' class='easy-footnote-margin-adjust'><\/span><span class='easy-footnote'><a href='https:\/\/salemdata.net\/johnpress\/?p=850#easy-footnote-bottom-1-850' title='As of June 7, 2026, there is no generally accepted Specification for Reticulum, the protocol is a reference protocol which means, in practical terms: look at the code.'><sup>1<\/sup><\/a><\/span> is built using the Rust programming language. I know very little Rust, but I have been impressed with everything so far. Scott Lamb of the <a href=\"https:\/\/github.com\/scottlamb\/moonfire-nvr\">Moonfire NVR<\/a> project has been suggesting I learn Rust since 2018, and a top-notch Perl maven, <a href=\"https:\/\/szabgab.com\/\">Gabor Szabo<\/a>, has been branching out into Rust. I built in Rust a UDP extension in Thomas Habets <a href=\"https:\/\/github.com\/ThomasHabets\/rustradio\">rustradio<\/a> project (similar to the <a href=\"https:\/\/www.gnuradio.org\/\">GNU Radio<\/a> project) and it took a lot of time and consideration, Habets leverages a variety of Rust&#8217;s powerful features in designing his crate. My conclusion was that Rust offers a huge panoply of ways to extend and integrate components, so much so that trying to extend an existing project can be a very daunting task.<\/p>\n<p>My practical question is whether either Rust project could eventually become useful for constrained Reticulum work on ESP32-class hardware, particularly the LilyGO T-Beam Supreme.\u00a0 So, as a preliminary step, I thought I&#8217;d set the stage for Open AI&#8217;s Codex to evaluate and contrast both projects and then relate what they may offer vis-a-vis my work with the LilyGO T-Beam Supreme.<\/p>\n<p>I downloaded and staged these two projects on my workstation:<\/p>\n<blockquote><p>Beechcraft Network Systems Ltd.&#8217;s <strong>Reticulum-rs<\/strong> (https:\/\/github.com\/BeechatNetworkSystemsLtd\/Reticulum-rs)<\/p>\n<p>Lew Palm&#8217;s <strong>leviculum<\/strong> (<a href=\"https:\/\/codeberg.org\/Lew_Palm\/leviculum\">https:\/\/codeberg.org\/Lew_Palm\/leviculum<\/a>)<\/p><\/blockquote>\n<p>With OpenAI&#8217;s Codex, I gave it the task to compare and contrast.\u00a0 Here&#8217;s the prompt I used:<\/p>\n<blockquote><p>I have staged two Rust Reticulum projects under \/usr\/local\/src\/reticulum\/rust Would you please compare and contrast both projects and provide me a list pros &amp; cons for each? I would like to know how they may differ.<\/p><\/blockquote>\n<p>Here&#8217;s Codex&#8217;s conclusion.\u00a0 My take-away is that Reticulum-rs appears easier to understand and reuse, but is not close to an embedded transport. Leviculum is much more ambitious and architecturally closer to embedded use, but its size, AGPL license, and current nRF52840 focus make it a porting project rather than a drop-in T-Beam solution.<\/p>\n<div class=\"imported-codex-report\">\n<h1>Rust Reticulum Project Comparison<\/h1>\n<h2>Scope and basis<\/h2>\n<p><code>\/usr\/local\/src\/reticulum\/rust<\/code> was empty on June 7, 2026. This comparison<br \/>\ntherefore covers the two Rust projects staged beside it<span id='easy-footnote-2-850' class='easy-footnote-margin-adjust'><\/span><span class='easy-footnote'><a href='https:\/\/salemdata.net\/johnpress\/?p=850#easy-footnote-bottom-2-850' title='I staged the projects in a higher directory when I pulled them thinking I was in the \/usr\/local\/src\/reticulum\/rust subdirectory. Any references in the report should have the &amp;#8220;rust&amp;#8221; subdirectory added.'><sup>2<\/sup><\/a><\/span>:<\/p>\n<ul>\n<li><code>\/usr\/local\/src\/reticulum\/Reticulum-rs<\/code>, commit<br \/>\n<code>d68c4f5a22f12915004fb38dcc8e15c596d89edf<\/code><\/li>\n<li><code>\/usr\/local\/src\/reticulum\/leviculum<\/code>, commit<br \/>\n<code>6f366ca04f64075acf4dc3d90e1dda88b23d325d<\/code><\/li>\n<\/ul>\n<p>The findings below are based on the checked-out source, manifests, tests, and<br \/>\nrepository history. Project README claims are not treated as proof unless the<br \/>\ncorresponding implementation or test infrastructure is present.<\/p>\n<h2>Executive summary<\/h2>\n<p>These projects target different levels of the stack.<\/p>\n<ul>\n<li><strong>Reticulum-rs<\/strong> is a compact, permissively licensed Rust library for core<br \/>\nReticulum packet, identity, destination, link, routing, and TCP\/UDP\/Kaonic<br \/>\nbehavior. It is much easier to understand and embed into a conventional<br \/>\nTokio application, but it does not currently provide a complete Reticulum<br \/>\noperational environment.<\/li>\n<li><strong>Leviculum<\/strong> is a much larger independent implementation intended to replace<br \/>\nPython Reticulum operationally. It includes a <code>no_std<\/code> protocol core, daemon,<br \/>\nshared-instance compatibility, CLI tools, persistence, resource transfer,<br \/>\nratchets, RNode\/LoRa support, embedded firmware, Debian packaging, and a large<br \/>\ninteroperability test system. Its costs are complexity, a larger maintenance<br \/>\nsurface, unfinished edges, and AGPL licensing.<\/li>\n<\/ul>\n<p>For a full Rust Reticulum node or daemon, <strong>Leviculum is substantially closer<br \/>\nto the goal<\/strong>. For a smaller library, prototype, or permissively licensed<br \/>\ncommercial integration, <strong>Reticulum-rs is the easier starting point<\/strong>, provided<br \/>\nits missing protocol and operational features are acceptable.<\/p>\n<h2>Comparison matrix<\/h2>\n<table>\n<thead>\n<tr>\n<th>Area<\/th>\n<th>Reticulum-rs<\/th>\n<th>Leviculum<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Repository shape<\/td>\n<td>One crate<\/td>\n<td>Multi-crate workspace plus embedded firmware<\/td>\n<\/tr>\n<tr>\n<td>Version<\/td>\n<td><code>0.1.0<\/code><\/td>\n<td>Workspace <code>0.6.3<\/code><\/td>\n<\/tr>\n<tr>\n<td>License<\/td>\n<td>MIT<\/td>\n<td>AGPL-3.0-or-later<\/td>\n<\/tr>\n<tr>\n<td>Rust source size<\/td>\n<td>About 7,548 lines<\/td>\n<td>About 130,925 lines<\/td>\n<\/tr>\n<tr>\n<td>Checked-out Git commits<\/td>\n<td>181<\/td>\n<td>652<\/td>\n<\/tr>\n<tr>\n<td>Main authorship<\/td>\n<td>Several contributors<\/td>\n<td>Almost entirely one contributor<\/td>\n<\/tr>\n<tr>\n<td>Protocol architecture<\/td>\n<td>Tokio-coupled <code>Transport<\/code> and interfaces<\/td>\n<td>Sans-I\/O <code>no_std + alloc<\/code> core plus platform drivers<\/td>\n<\/tr>\n<tr>\n<td>Genuine <code>no_std<\/code> core<\/td>\n<td>No<\/td>\n<td>Yes, <code>reticulum-core<\/code><\/td>\n<\/tr>\n<tr>\n<td>Included interfaces<\/td>\n<td>TCP client\/server, UDP, Kaonic gRPC; HDLC framing<\/td>\n<td>TCP, UDP, serial, RNode, AutoInterface, local\/shared instance; HDLC, KISS, BLE framing<\/td>\n<\/tr>\n<tr>\n<td>Routing and links<\/td>\n<td>Implemented, with remaining TODOs<\/td>\n<td>Broad implementation with extensive interop scenarios<\/td>\n<\/tr>\n<tr>\n<td>Channels<\/td>\n<td>Packet context exists; no channel subsystem found<\/td>\n<td>Implemented<\/td>\n<\/tr>\n<tr>\n<td>Resource transfer<\/td>\n<td>Packet context exists; no resource subsystem found<\/td>\n<td>Implemented, including segmented transfer and compression<\/td>\n<\/tr>\n<tr>\n<td>Ratchets<\/td>\n<td>Not found<\/td>\n<td>Implemented with storage support<\/td>\n<\/tr>\n<tr>\n<td>Persistence abstraction<\/td>\n<td>Not found<\/td>\n<td><code>Storage<\/code> trait with memory, embedded, and file-backed implementations<\/td>\n<\/tr>\n<tr>\n<td>Daemon and native CLI<\/td>\n<td>None<\/td>\n<td><code>lnsd<\/code>, <code>lns<\/code>, and <code>lncp<\/code><\/td>\n<\/tr>\n<tr>\n<td>Python shared-instance compatibility<\/td>\n<td>Not found<\/td>\n<td>Implemented and tested<\/td>\n<\/tr>\n<tr>\n<td>Embedded deliverable<\/td>\n<td>No firmware; Tokio\/tonic dependencies<\/td>\n<td>nRF52840 firmware for T114 and RAK4631<\/td>\n<\/tr>\n<tr>\n<td>FFI<\/td>\n<td>None<\/td>\n<td>Present, but explicitly incomplete<\/td>\n<\/tr>\n<tr>\n<td>Packaging<\/td>\n<td>None<\/td>\n<td>Nightly static Debian packages and systemd service<\/td>\n<\/tr>\n<tr>\n<td>Test surface in source<\/td>\n<td>11 plain tests and 8 Tokio tests found<\/td>\n<td>1,735 plain tests and 322 Tokio tests found<\/td>\n<\/tr>\n<tr>\n<td>Project maturity statement<\/td>\n<td>No explicit production warning<\/td>\n<td>Explicitly says not production-ready<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2>Reticulum-rs<\/h2>\n<h3>Pros<\/h3>\n<ul>\n<li><strong>Small and understandable.<\/strong> The single-crate design and roughly 7.5K lines<br \/>\nof Rust make code review, experimentation, and focused modification practical.<\/li>\n<li><strong>Permissive MIT license.<\/strong> This is materially easier for proprietary,<br \/>\nembedded-product, and commercial use than Leviculum\u2019s AGPL license.<\/li>\n<li><strong>Conventional Tokio integration.<\/strong> Applications already using Tokio can<br \/>\ninstantiate <code>Transport<\/code>, spawn interfaces, and consume broadcast channels<br \/>\nwithout building a separate driver layer.<\/li>\n<li><strong>Useful core coverage.<\/strong> Source implements identities, destinations,<br \/>\nannounces, packets, links, path requests, routing tables, announce rate<br \/>\nlimiting, TCP, UDP, and Kaonic gRPC support.<\/li>\n<li><strong>Multiple contributors.<\/strong> The checked-out history shows meaningful work from<br \/>\nat least three primary contributors, reducing total dependence on one author.<\/li>\n<li><strong>Clean low-level safety profile.<\/strong> No <code>unsafe<\/code> blocks were found in its Rust<br \/>\nsource.<\/li>\n<li><strong>CI includes Python interoperability.<\/strong> GitHub Actions clones Python<br \/>\nReticulum and runs the feature-gated Python test along with Clippy and tests.<\/li>\n<\/ul>\n<h3>Cons<\/h3>\n<ul>\n<li><strong>Not a full Reticulum replacement.<\/strong> There is no daemon, shared-instance<br \/>\nserver, Reticulum-compatible configuration loader, native CLI, persistence<br \/>\nlayer, packaging, or RNode implementation.<\/li>\n<li><strong>Embedded claim is not currently supported by the crate design.<\/strong> The crate<br \/>\nhas an empty <code>alloc<\/code> feature but no <code>#![no_std]<\/code>; it unconditionally depends<br \/>\non Tokio <code>full<\/code>, tonic, prost, and OS randomness. Using it on a bare-metal<br \/>\ntarget would require substantial restructuring.<\/li>\n<li><strong>Important protocol subsystems appear absent.<\/strong> Resource and channel packet<br \/>\ncontexts are defined, but no resource-transfer or channel implementation was<br \/>\nfound. Ratchets were not found.<\/li>\n<li><strong>Interface coverage is narrow.<\/strong> The README mentions serial, but the source<br \/>\ncontains HDLC framing without a serial interface implementation.<\/li>\n<li><strong>Some claims exceed implementation.<\/strong> Crate docs say resources can send<br \/>\narbitrary amounts of data, but no resource API or module exists.<\/li>\n<li><strong>Limited test depth compared with Leviculum.<\/strong> The repository has a small<br \/>\nunit\/integration suite and only one Python interoperability test file.<\/li>\n<li><strong>Remaining implementation TODOs affect behavior.<\/strong> Examples include announce<br \/>\nqueue\/cap handling, proof strategy checks, active-link timeout cleanup, and<br \/>\ngeneric packet handling.<\/li>\n<li><strong>Verification concern.<\/strong> In this environment, 12 unit tests and three hop<br \/>\ntests passed, but <code>message_proof_over_remote_link<\/code> ran for more than three<br \/>\nminutes without completing and had to be terminated. The full test run<br \/>\ntherefore did not pass.<\/li>\n<li><strong>Build-time dependency on <code>protoc<\/code>.<\/strong> Kaonic gRPC generation is unconditional<br \/>\nin <code>build.rs<\/code>, increasing setup burden even for users not using Kaonic.<\/li>\n<\/ul>\n<h2>Leviculum<\/h2>\n<h3>Pros<\/h3>\n<ul>\n<li><strong>Much broader implementation coverage.<\/strong> Source includes routing, path<br \/>\ndiscovery, links, encrypted channels, requests, receipts, segmented resource<br \/>\ntransfer, BZ2 compression, ratchets, IFAC, RNode handling, and persistence.<\/li>\n<li><strong>Strong architecture for portability.<\/strong> <code>reticulum-core<\/code> is explicitly<br \/>\n<code>#![no_std]<\/code>, uses a sans-I\/O design, and injects clocks, storage, randomness,<br \/>\nand interfaces through traits. The protocol core is not tied to Tokio.<\/li>\n<li><strong>Operationally useful deliverables.<\/strong> It provides <code>lnsd<\/code>, <code>lns<\/code>, and <code>lncp<\/code>,<br \/>\nReticulum-style configuration, shared-instance support, Python CLI RPC<br \/>\ncompatibility, systemd packaging, and static Linux builds.<\/li>\n<li><strong>Concrete embedded implementation.<\/strong> The repository includes nRF52840<br \/>\nfirmware, LoRa\/SX1262 support, BLE framing, board support, and hardware test<br \/>\nscenarios rather than only claiming embedded suitability.<\/li>\n<li><strong>Extensive verification infrastructure.<\/strong> It has unit tests, property tests,<br \/>\ngenerated Python-derived vectors, Python <code>rnsd<\/code> interoperability tests,<br \/>\nDocker topology tests, fault injection, cross-implementation LoRa tests, and<br \/>\nhardware test tiers.<\/li>\n<li><strong>Storage is a first-class design concern.<\/strong> Protocol state is abstracted<br \/>\nbehind a typed <code>Storage<\/code> trait with no-op, memory, embedded, and file-backed<br \/>\nimplementations.<\/li>\n<li><strong>Deployment work is unusually complete for a pre-production project.<\/strong><br \/>\nStatic musl builds, Debian packaging, systemd units, nightly releases, and<br \/>\ndiagnostic tooling are present.<\/li>\n<li><strong>Documentation is significantly deeper.<\/strong> Architecture, configuration,<br \/>\ntesting tiers, CLI manuals, structured event logs, and hardware protocol notes<br \/>\nare included.<\/li>\n<\/ul>\n<h3>Cons<\/h3>\n<ul>\n<li><strong>AGPL-3.0-or-later licensing.<\/strong> Network use and distribution can impose<br \/>\nsource-sharing obligations. This may rule it out for some commercial or<br \/>\nclosed-source deployments; obtain legal advice for the intended use.<\/li>\n<li><strong>Much larger complexity and audit surface.<\/strong> At roughly 131K Rust lines plus<br \/>\nscripts, packaging, docs, and hardware support, it is far harder to fully<br \/>\nunderstand, audit, or maintain than Reticulum-rs.<\/li>\n<li><strong>High single-maintainer concentration.<\/strong> Nearly all checked-out commits are<br \/>\nattributed to one author. That creates bus-factor and continuity risk despite<br \/>\nthe project\u2019s high activity.<\/li>\n<li><strong>Explicitly not production-ready.<\/strong> The project says this directly. Its<br \/>\nchangelog also shows frequent fixes to routing, links, resources, shared<br \/>\ninstance behavior, and LoRa reliability.<\/li>\n<li><strong>Some public-facing pieces remain incomplete.<\/strong> The FFI crate describes<br \/>\nitself as a stub\/orphaned crate and only exposes identity operations. Several<br \/>\nfallback <code>lns<\/code> command paths print \u201cnot implemented yet,\u201d and two integration<br \/>\nexecutor step types use <code>unimplemented!<\/code>.<\/li>\n<li><strong>Default build setup adds friction.<\/strong> <code>.cargo\/config.toml<\/code> defaults host<br \/>\nbuilds to <code>x86_64-unknown-linux-musl<\/code>. The first core test attempt failed here<br \/>\nbecause that target was not installed; a GNU-target override was required.<\/li>\n<li><strong>Workspace boundaries are less simple than advertised.<\/strong> <code>reticulum-nrf<\/code> is<br \/>\nexcluded from the workspace and must be built separately. Full verification<br \/>\nalso depends on Docker, vendored Python Reticulum, system services, and<br \/>\nphysical LoRa hardware.<\/li>\n<li><strong>One-author velocity can increase regression risk.<\/strong> The large test suite<br \/>\nmitigates this, but the rapid sequence of protocol bug fixes indicates that<br \/>\nbroad feature coverage should not be confused with stable production maturity.<\/li>\n<\/ul>\n<h2>Key architectural difference<\/h2>\n<p>Reticulum-rs puts networking and protocol state into a Tokio-oriented<br \/>\n<code>Transport<\/code> object. This is straightforward for a normal async Rust program,<br \/>\nbut makes bare-metal reuse and deterministic protocol testing difficult.<\/p>\n<p>Leviculum separates protocol decisions from I\/O. Its core consumes packets and<br \/>\ntimeouts, then returns actions and events. Tokio, embedded firmware, or another<br \/>\nruntime performs the actual I\/O. This adds abstraction and code volume, but it<br \/>\nis the stronger architecture for running the same protocol implementation<br \/>\nacross Linux daemons and microcontrollers.<\/p>\n<h2>Recommendation by use case<\/h2>\n<ul>\n<li><strong>Full replacement for Python <code>rnsd<\/code>, interoperability testing, LoRa\/RNode,<br \/>\nfile transfer, or embedded firmware:<\/strong> choose Leviculum as the evaluation<br \/>\nbaseline.<\/li>\n<li><strong>Small Rust application needing only core packet\/link\/routing behavior:<\/strong><br \/>\nReticulum-rs may be sufficient and is much easier to integrate.<\/li>\n<li><strong>Closed-source or commercially sensitive use:<\/strong> Reticulum-rs has the simpler<br \/>\nlicense. Leviculum\u2019s AGPL implications need legal review.<\/li>\n<li><strong>Protocol research or implementation-derived specification work:<\/strong> Leviculum<br \/>\ncurrently provides much more observable behavior and many more reproducible<br \/>\ninterop scenarios, but claims still need comparison against upstream Python<br \/>\nsource and traces.<\/li>\n<li><strong>Production deployment today:<\/strong> neither project should be accepted solely on<br \/>\nrepository claims. Leviculum is closer functionally but explicitly<br \/>\npre-production; Reticulum-rs has a narrower scope and an observed hanging<br \/>\nintegration test.<\/li>\n<\/ul>\n<h2>Verification notes<\/h2>\n<ul>\n<li>Reticulum-rs: <code>cargo test --all-targets<\/code>\n<ul>\n<li>12 unit tests passed.<\/li>\n<li>Three hop tests passed.<\/li>\n<li><code>message_proof_over_remote_link<\/code> did not complete after more than three<br \/>\nminutes and was terminated.<\/li>\n<li>The Python interop feature was not enabled in this run.<\/li>\n<\/ul>\n<\/li>\n<li>Leviculum: <code>cargo test -p reticulum-core --lib<\/code>\n<ul>\n<li>The default attempt failed because the configured<br \/>\n<code>x86_64-unknown-linux-musl<\/code> target was not installed.<\/li>\n<li>Verification was rerun against <code>x86_64-unknown-linux-gnu<\/code>.<\/li>\n<li>All 1,109 <code>reticulum-core<\/code> library tests passed in 1.81 seconds.<\/li>\n<\/ul>\n<\/li>\n<li>Docker, Python interop, embedded cross-builds, and hardware tests were not run.<\/li>\n<\/ul>\n<\/div>\n<p>I then asked:<\/p>\n<div class=\"bg-token-foreground\/5 max-w-[77%] min-w-0 overflow-hidden break-words rounded-2xl px-3 py-2 [&amp;_.contain-inline-size]:[contain:initial]\">\n<div class=\"flex flex-col items-end gap-1\">\n<div class=\"text-size-chat relative w-full min-w-0\">\n<blockquote>\n<div class=\"text-size-chat whitespace-pre-wrap\">I&#8217;ve been using microreticulum for work on the T-Beam SUPREMES. Would either of these be easily configured to work on the ESP32-S of the T-Beam? Can you also assess some memory metrics as I wonder if leviculum would need some paring down and removing features not needed for a T-Beam (in transport mode).<\/div>\n<\/blockquote>\n<div>Here&#8217;s Codex&#8217;s response.<\/div>\n<div class=\"imported-codex-report\">\n<p><strong>Recommendation<\/strong><\/p>\n<ul>\n<li>Continue using <strong>microReticulum<\/strong> for the shortest path to a working T-Beam Supreme transport.<\/li>\n<li>Use <strong>Leviculum<\/strong> if you want to develop a Rust-based transport implementation.<\/li>\n<li>Do not use <strong>Reticulum-rs<\/strong> for the T-Beam unless you are prepared for a substantial redesign.<\/li>\n<\/ul>\n<p><strong>ESP32-S3 Suitability<\/strong><\/p>\n<table>\n<thead>\n<tr>\n<th>Project<\/th>\n<th style=\"text-align: right;\">ESP32-S3 effort<\/th>\n<th>Assessment<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>microReticulum<\/td>\n<td style=\"text-align: right;\">Already operational<\/td>\n<td>Best current option<\/td>\n<\/tr>\n<tr>\n<td>Leviculum<\/td>\n<td style=\"text-align: right;\">Moderate porting project<\/td>\n<td>Suitable Rust foundation<\/td>\n<\/tr>\n<tr>\n<td>Reticulum-rs<\/td>\n<td style=\"text-align: right;\">Major architectural rewrite<\/td>\n<td>Poor embedded starting point<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Leviculum\u2019s <code>reticulum-core<\/code> is genuinely <code>no_std<\/code>, uses a sans-I\/O design, and abstracts its clock, RNG, storage, and interfaces. However, it currently only has an embedded runtime for nRF52840 boards. An ESP32-S3 runtime, T-Beam board definition, and SX1262 interface would need to be implemented.<\/p>\n<p>Reticulum-rs currently depends directly on Tokio, tonic, host networking, and the standard library. Its empty <code>alloc<\/code> feature does not make it an embedded-ready crate.<\/p>\n<p><strong>Memory Findings<\/strong><\/p>\n<p>Leviculum\u2019s existing T114 firmware provides the best available embedded measurement:<\/p>\n<ul>\n<li>Approximately <strong>189 KB flash<\/strong><\/li>\n<li>Approximately <strong>232 KB application RAM<\/strong><\/li>\n<li>Approximately <strong>48\u201350 KB steady\/peak heap usage<\/strong><\/li>\n<li>Current configured heap: <strong>64 KB<\/strong><\/li>\n<\/ul>\n<p>This full firmware includes LoRa, BLE, USB, logging, and other functionality. A transport-only ESP32-S3 build should be feasible within the T-Beam Supreme\u2019s nominal <strong>320 KB internal RAM<\/strong>, without requiring aggressive removal of protocol features.<\/p>\n<p>The current T-Beam PlatformIO profiles report <strong>no PSRAM enabled<\/strong>, even though the Supreme hardware may include PSRAM. Existing heavier microReticulum test logs still showed roughly <strong>197\u2013243 KB free heap<\/strong>, suggesting memory is not presently the primary constraint.<\/p>\n<p><strong>Recommended Leviculum Transport Configuration<\/strong><\/p>\n<p>Start with Leviculum\u2019s existing T114 transport configuration as the model:<\/p>\n<pre><code class=\"language-rust\">NodeCoreBuilder::new()\r\n    .enable_transport(true)\r\n    .max_incoming_resource_size(8 * 1024)\r\n    .max_queued_announces(32)\r\n    .max_random_blobs(8)\r\n<\/code><\/pre>\n<p>For an initial T-Beam transport-only build, I would reduce it further:<\/p>\n<ul>\n<li>One SX1262 LoRa interface<\/li>\n<li><code>max_queued_announces<\/code>: 8\u201316<\/li>\n<li><code>max_random_blobs<\/code>: 4\u20138<\/li>\n<li>Disable probe responses initially<\/li>\n<li>Keep compression disabled<\/li>\n<li>Exclude BLE, Wi-Fi, GPS, display, SD, USB shared-instance support, and application destinations<\/li>\n<li>Use internal RAM for protocol state; reserve PSRAM for large buffers or logs<\/li>\n<\/ul>\n<p>Leviculum\u2019s <code>EmbeddedStorage<\/code> consumes approximately <strong>20\u201330 KB inline<\/strong>, but its table capacities are currently hard-coded. Making those capacities configurable would be the most useful memory-reduction change. Removing channels, resources, links, and ratchets at compile time would require more invasive feature-gating and probably is not necessary merely to fit the ESP32-S3.<\/p>\n<p>The main Leviculum work is therefore an ESP32-S3 board\/runtime port and capacity tuning, not wholesale protocol removal. Exact memory margin remains undetermined until that ESP32 firmware is built and measured on the T-Beam.<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>highly technical There are two projects that came to my attention where the Reticulum implementation is built using the Rust programming language. I know very little Rust, but I have been impressed with everything so far. Scott Lamb of the Moonfire NVR project has been suggesting I learn Rust since 2018, and a top-notch Perl [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[37,126,130,121,1],"tags":[39],"class_list":["post-850","post","type-post","status-publish","format-standard","hentry","category-ai","category-codex","category-reticulum","category-t-beam","category-uncategorized","tag-rust"],"_links":{"self":[{"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=\/wp\/v2\/posts\/850","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=850"}],"version-history":[{"count":10,"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=\/wp\/v2\/posts\/850\/revisions"}],"predecessor-version":[{"id":860,"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=\/wp\/v2\/posts\/850\/revisions\/860"}],"wp:attachment":[{"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=850"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=850"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/salemdata.net\/johnpress\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=850"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}