While I do not have the time for (or, even if I had a spare decade on hand, the intentions of) reviewing 637,000 lines of machine-generated "network protocol code" (which is really trying to be a game engine, or something), this is - thankfully - not required, as I too do have access to the same big, fat, red button, for which the repeated hammering on has attained such popularity recently, in the context of "producing" whatever thing related to Reticulum one might dream of (usually, the real goal seem to be, as always, attention).

Given that the project under the looking glass here is itself fully and entirely generated by this very process, and evidently places ultimate and unquestionable trust therein, I shall be delighted to share - without further human oversight - this cursory overview, of what approximately 35 minutes of DeepSeek v4 Flash (running locally, Q8_K_XL quant) has presented me with, in regards to the "Prns" "high-performance, enforced-then-audited, measured-not-claimed ground-up implementation" of Reticulum.

In an effort to take on the same kind of spirit as the Prns "build ethos", I therefore simply trust the machine's output to be all-goody, and publish it at is. I dabbled in a bit of bold here, some cursive there, but that's about it.

Oh, and a flashy website, with some really neat effects is incoming too, but to be completely "honest" and "truthful" to the "Prns workflow" I'm trying to emulate, I should have created the website first, then ran the actual analysis. Oh well, I guess I still have a lot to learn on how to be a true agentic developer.

The short, and very polite, version: Don't use Prns, it's the 100% vibe-coded fullfilment function for the attention needs of one man, not a protocol implementation.

The long version follows.

Prns performance claims: an accounting of fudged measurements

1. The claim

The front page of the Prns website states, as a headline, that performance is "Measured, not just claimed", and that every number "comes from the published results in the repo, measured on real hardware by a harness you can run yourself" (docs/website/i18n/en-US.ftl). The README states "up to 89× the throughput" (README.md), and the on-network marketing page repeats "up to 89× the throughput, 48× smaller peak-memory footprint, and 33× the energy efficiency of stock RNS 1.4.2" (assets/nnpages/why_prns.mu). A comprehensive and multi-proged marketing rollout, which we will focus on in more detail later.

The "89×" is, in their own published tables, a single cell: single-packet throughput on macOS, measured at 37,400/s for Prns against 420/s for the reference (benchmarks/RESULTS-aarch64-apple-darwin.md). The same scenario measures 7.19× on Linux and 8.00× on Windows. The factor of twenty between hosts is not Prns — it is an invalid test reference harness collapsing to a different degree on each platform.

This is not an accident of hardware. The reason the test reference collapses so uniformly is that the reference is not RNS. It is a mislabeled, broken development shim, further hobbled by the interface and policy choices the harness itself imposes. Three stacked handicaps, each verifiable in the repository, account for essentially the entire claimed advantage of Prns. Either this was intentional, or more likely; nobody bothered to check anything.

It shall additionally be noted here, that Prns publishes no actual measurements of real-world performance or reliability metrics on heavily utilised nodes with hundreds of interfaces, or any benchmarks covering correctness of traffic handling, announce/PR flood rejection, et cetera; only extremely synthetic throughput benchmarks.

2. Handicap one: the "compiled RNS" reference is a defunct development shim

The benchmark harness loads the reference through benchmarks/reference/compiled_reference.py, which installs pyximport and asserts two things:

1. RNS.compiled == True, and
2. that at least one RNS module was loaded from a native extension (*.so / *.pyd).

Both checks are trivially satisfied, and their own published proof records show exactly what they captured. From the currently published suites:

benchmarks/results/aarch64-apple-darwin/suites/a52f5446-.../suite.json:
  "cython": "3.2.8", "python": "3.13.13",
  "native_module": "<repo>/.../pyximport/lib.macosx-26.0-arm64-cpython-313/RNS.cpython-313-darwin.so"

benchmarks/results/x86_64-unknown-linux-gnu/suites/c0595056-.../suite.json:
  "native_module": "<repo>/.../pyximport/lib.linux-x86_64-cpython-313/RNS.cpython-313-x86_64-linux-gnu.so"

benchmarks/results/x86_64-pc-windows-msvc/suites/729ba968-.../suite.json:
  "native_module": "~/.prns-oc/lib.win-amd64-cpython-313/RNS.cp313-win_amd64.pyd"

In every case the recorded native module is the top-level package only: RNS.cpython-313-<platform>.so. Nothing under RNS.Transport, RNS.Destination, RNS.Identity, RNS.Packet, RNS.Link or RNS.Resource ever appears — because nothing under those was ever compiled. This is the old CRNS development shim, whose pyximport-based "compilation" has been known for over a year to compile only the top-level __init__ module on modern Cython, leaving the entire actual protocol machinery in interpreted mode. It is a development utility that produces debug-oriented builds that are slower than plain interpreted RNS.

It was, in fact, deprecated and non-functional for more than a year before these benchmarks were published, and has only recently been repaired in the reference implementation itself — after the fact.

In short: "RNS 1.4.2 (compiled)" — the label used in every table, every chart, and every marketing page — is not a mode of RNS that exists, and is not faster than interpreted RNS. It is the opposite: a stale tool that makes RNS look far slower than it actually is.

The harness's own documentation (benchmarks/implementations/rns-1.4.2-compiled.json) says runs are "rejected unless RNS.compiled is true and native extension modules are loaded" — as if that constituted a meaningful verification. It verifies a flag and the presence of a .so. It never verifies what was compiled. It also never states, anywhere, what "compiled" means, that it is a development shim, or that it builds debug targets.

Interpreted RNS 1.5.4 on an ordinary mid-range laptop, single core, sustains roughly 30,000 deliveries/s for small single packets (including ephemeral-key decryption), about 175,000–280,000 packets/s in transit relay at 135–475 B payloads, and 10+ Gbps throughput at 16 KiB payloads. The "compiled" artifact in these benchmarks sustained 420–3,900 packets/s for its single-packet scenario, depending on host. That is the artifact being broken — not Python being slow. Any benchmark that claims to measure "Rust vs Python" while its Python side performs 10–100× worse than stock interpreted Python is measuring its own rigging, not engineering.

3. Handicap two: the reference was forced onto the slowest possible interface types

The harness does not use RNS's modern BackboneInterface on any platform, on either the endpoint or the relay side. The harness itself writes the reference's configuration (benchmarks/reference/participant_node.py):

type = TCPServerInterface      (responder, and both sides of the relay)
type = TCPClientInterface      (initiator)
type = UDPInterface            (the abstract wire between the two hops)

TCPInterface is the legacy interface in RNS, maintained for stability and compatibility with older systems. BackboneInterface is the modern high-performance interface — and on macOS it is, moreover, not even usable in this configuration on RNS 1.4.2 without development branches (which Prns did not have access to, because they never asked or consulted RNS developers on anything before publishing their "benchmarks"). A fair modern-interface comparison was therefore structurally impossible in their setup, and none was even attempted.

The results tables never mention the interface module selection at all; the reader is left to assume the reference was configured with reasonable modern settings. It was not: It was configured to be as slow as possible.

4. Handicap three: the "default" rows compare different interface policies outright

The published tables state the policies openly, in a footnote, as if this was a virtue:

"This practical profile preserves each implementation's normal TCP policy: 500 Mbps for Prns and 10 Mbps for compiled RNS 1.4.2."

Their own tables (benchmarks/RESULTS-x86_64-unknown-linux-gnu.md):

Raw transport throughput at a 10 Mbps MTU policy compared against a 500 Mbps MTU policy is not "20–39× faster". It is 20–39× more policy. When the harness equalizes the policy — the rows it labels "1 Gbps policy", in which both sides are explicitly configured identically — the published ratios collapse to roughly 2.4–8.4× across all hosts and scenarios. Keep in mind, the gains here are still measured against the broken baseline of section 2, but even so: nowhere near 89×, and consistent with the simple, uncontroversial observation that a native implementation tends to outperform an interpreted one in raw throughput — a point that needed no fudging to make.

Interestingly, a "high-performance" Rust implementation is apparently not really that much faster than the Python reference implementation - running in interpreted mode on a single CPU core.

5. What this means

• The "89×" headline is the worst-case cell of a broken measurement. It is one scenario, on one host, where a stale debug-oriented Cython shim and deliberate slow interface choices collapsed to 420 packets/s. The honest reading of their own cross-host data is that the multiplier is dominated by the reference artifact test harness' instability, not by Prns's speed.
• Every published ratio against "RNS 1.4.2 (compiled)" is void, because that artifact is not a valid measure of RNS on any axis: it is a deprecated dev shim, debug-targeted, top-level-only, on a Python version where it is known-broken, running a legacy interface at a fraction of the allowed policy.
• No methodology section anywhere addresses any of this. The writeups describe machines, durations, and accounting rules in detail — and omit most of the important methodology; the interface module used for the reference, the meaning of "compiled", the fact that it is a dev-only debug shim, and the policy asymmetry they themselves document in passing. That is not an oversight; that is selection of the one presentation that yields the marketing number.
• The front page says "Measured, not just claimed." On this evidence, the correct summary is: claimed, and arranged to look measured.

For anyone who wants an honest comparison: run stock interpreted RNS, current version, on BackboneInterface where available, at identical interface policy, with methodology published in advance. The results will be less flattering — and worth a lot more.

On "owning the commits" — authorship laundering and the accountability problem

1. The policy, in the project's own words

The Prns repository contains a committed commit-message hook, .githooks/commit-msg, that scans every commit message and blocks it if it contains an AI-attribution trailer:

if grep -qiE '^[[:space:]]*co-authored-by[[:space:]]*:|generated with.*(claude|codex|copilot|cursor|gemini)' "$1"; then
    echo "✗ commit blocked: attribution trailers are not used in this repository."
    echo "  The committer owns the commit; remove the trailer and commit again."
    exit 1
fi

The contributing guide is explicit about the philosophy (CONTRIBUTING.md):

"This is the repo-wide contribution guide for both human and automated contributors."
"AI tools (and other assistance like pair programming, web snippets, etc.) are welcome, but slop is slop regardless of how it was produced. How you wield your tools is still under your control, and what you submit is yours."

So: AI tools are welcome, credit for the work is not, and the human "owns" the output. There is a pre-push gate to match — .githooks/pre-push runs validation/hygiene/no-personal-paths.py, which scans pushed commits for any personal path tokens and blocks the push, going so far as to obfuscate one personal token in the script itself (TOKENS_SPLIT_SO_SCRUBS_NEVER_MATCH_THIS_FILE = ((b"kc", b"tra"),)) so that a naive grep of the file will never find it.

There is also a second author identity in the history that deserves a mention: Prns Tests <tests@example.test> — a fake identity (example.test is a reserved domain) credited with 35 commits, every single one of them website and marketing content: "Ship every implemented SDK language and complete the marquee", "Add Benchmarks to the top nav", "Post the status card at every young SDK gate", "Misc docs polish". A fictitious "tests" persona does not write marketing copy; a person or LLM-operator hiding behind a fictitious persona does.

2. What the history actually shows

The hook exists to keep machine-generated commits from looking machine-generated. The history shows why that is necessary:

• 3,374 commits in ~110 days (2026-05-26 → 2026-09-12), i.e. about 31 commits per day, with 96.4% of all commits authored by a single account — the repository's maintainer.
• Commit activity is spread across all hours, including 149 commits between midnight and 06:00, with Saturdays and Sundays among the highest-volume days (Saturday is the single busiest weekday). No human circadian or weekly pattern is visible. An automated loop has no weekends, and this history has none.
• The commit style is uniform, nonsensically fluent, and self-referential in a way that is characteristic of large language models: "Harden egress isolation and stalled-writer recovery", "Make embedded resource evidence truthful", "Close embedded assurance evidence audit", "Sync directives & ethos for next wave of work".
• The project's own contributing guide addresses "automated contributors" directly — an unusual acknowledgment that makes the machine's role explicit, while the commit hook simultaneously ensures no record of it ever reaches the history.

On the one hand: "The committer owns the commit." On the other hand: the material reality is that roughly 637,000 lines of Rust were produced in 110 days by one human LLM-operator who also "built" firmware for three embedded families, five SDK languages, a web flasher, a 12-locale website, a benchmark suite, and a validation hub. Nobody writes 5,800 lines of Rust per day, every day, including weekends, without a weekend. The only coherent explanation is continuous machine generation with minimal human oversight — exactly what the hook exists to obscure.

3. The hypocrisy, measured against the project's own claims

The irony would be merely aesthetic if the claimed standards were not part of the marketing. The website's front page states, in permanent copy:

"Enforced, then audited. In the engine, panics, unwraps, and unjustified unsafe never compile."

The same project that asks you to believe its code is strictly enforced and audited ships a commit history in which the audit trail itself is laundered. And its own log shows that large parts of the "engine" — the protocol semantics — were simply wrong for months:

• 2026-07-06 (74bea355e): "both unwrap_or(&[]) arms were unreachable dead defaults" — code paths the author thought existed never did; announced ratchet rotation "matching RNS" only discovered four days earlier.
• 2026-07-06 (54cc8d601): announce-ID history "was unbounded per-slot growth" — an unbounded memory growth bug in core routing, fixed months in.
• 2026-07-06 (edd8e72be): Group packet deduplication "which RNS does not do" — implemented behavior the reference explicitly does not have, then removed.
• 2026-07-05 (9d27af75c): interface announce limiting could "leak a sustained flood" — a flood-control bug in the announce path.
• 2026-07-05 (4ed75ffdd): a "phantom-airtime leak" where oversized frames "used to vanish silently while permanently shrinking the queue budget".
• 2026-07-07 (86240b027): a benchmark crate "hasn't compiled since" a rename — unnoticed for weeks, because it was outside the workspace and CI never built it.
• 2026-06-17 (cc4d524a3): "This closes the >1 MiB RNS-to-Prns interop stall" — the headline interoperability feature (resources over a megabyte) did not work at all until three weeks in.
• 2026-07-13 (5944992a4): a large single-segment response "could previously race its own timeout mid-transfer", and a known send-path hang toward a detached-interface route was deemed "typed fast-fail a candidate for later" — a known hang, shipped.

Month after month of "core review" commits are, in plain language, the discovery that core protocol behavior diverged from the reference — deduplication, announce-ID history, group handling, duty-cycle accounting, acceptance semantics, receipt laws — all of it after the marketing described the engine as "byte-for-byte wire parity" and "diff-tested against RNS" and "Enforced, then audited".

4. Why this matters: accountability

For any software, but absolutely for a cryptographic networking stack, the question of who is answerable for the code is not bureaucratic. It is existential. If a flaw in the engine leaks key material, or fragments the network, or drops emergency traffic, someone must be able to stand behind the code and explain it. "The committer owns the commit" is precisely backwards as a policy when the committer cannot have read, understood, or verified the thing being committed — it converts accountability into credit:

This mechanism is designed to harvest the credit for more than a decade of actual, human work — while the liability is quietly transferred to every user who runs the software, and the responsibility to the original creator of the protocol and reference implementation.

To be absolutely clear about what this document is and is not: we are not accusing anyone of running an intentional scam by these mechanisms alone. What we are stating, on the evidence of the repository itself, is that the authorship record of this project is an engineered fiction — a history made to look like the careful work of a single diligent engineer, when the engineering record shows otherwise — and that this has direct consequences:

1. Nobody can be held to account for this code. The credited author of 3,252 commits cannot plausibly have reviewed them, and the actual generator is, by policy, never recorded anywhere.
2. Every claim of testing, audit, and proof inherits this problem. Self-certification by an unreviewable pipeline is not certification, it is theatrics.
3. The project has also chosen to omit the reference implementation from its own record. It markets itself as "a ground-up implementation of Reticulum" while its own commit log references RNS behavior in 506 separate commits; distributes LICENSE-MIT as "Copyright (c) 2026 The Prns Authors" with no RNS or LXMF copyright line, despite machine-porting both; and its website contains no link to the reference implementation at all — the entire tree mentions the author of RNS in six files, and the website in none. None of these where they should be, to comply with the (very generous) licensing.

A reasonable person may disagree about whether any of this is intentional. What is not open to reasonable disagreement is that a project which spends its resources on laundering its own history, obfuscating its authors' paths, and erasing its provenance, while simultaneously claiming to be more strictly tested and more safety-enforced than the reference it declines to credit, has made a choice about what kind of project it is. That choice is visible to anyone who looks.

It is the choice of a project that wants to be seen as responsible more than it wants to be responsible.

5. The general principle

Claim credit only for what you can personally vouch for. If you cannot explain a line of code, you do not own it; you are merely its courier. A commit history is a record of responsibility — or, when it is fabricated, as in this case, a record of its absence.

Communities that care about the traffic their networks carry should treat engineered authorship records the same way they treat engineered benchmarks: as uncomfortable evidence of what the project is, not as decoration to be celebrated (or believed in).

The bizarre commit history

1. Some raw numbers

There is no human on earth who writes and commits 31 meaningful commits per day for 110 days straight. There is no human whose busiest workday is Saturday. There is no human who commits 149 times between midnight and 6 a.m. while also producing a 12-locale marketing site, three embedded firmware families, five language SDKs, and a web flasher — in the same period. The history is not a human's diary; it is the transcript of a completely automated loop, period.

2. Cadence

Commits by hour of day (author timezone):
00h:61 01h:32 02h:23 03h:11 04h:8 05h:14 06h:21 07h:47 08h:113 ... 19h:244 20h:187 21h:217 22h:183 23h:114

Commits by weekday: Sat 578 · Fri 574 · Thu 557 · Tue 478 · Wed 442 · Mon 343 · Sun 402.

The pattern has no weekends, no nights, no breaks, no vacation, no sickness. Machine output has no circadian rhythm — and this history has none either.

3. The vocabulary

Word frequencies in non-merge commit messages are themselves a signature:

A repository whose marketing calls itself "a ground-up implementation of Reticulum" references RNS behavior in 506 commits and says "parity" 49 times. The commit log is, in effect, a record of continuous alignment to the very code the marketing refuses to credit.

This is, by any sensible measure, a direct machine-generated simulacra of the RNS reference implementation, trying very hard not to appear as one. A mangled xerox, spattered in off-hue technicolor dressing.

Meanwhile the self-referential vocabulary — "truthful", "evidence", "assurance", "directives", "ethos" — is the language of a process that is extremely concerned with appearing rigorous. That concern is not, as far as the history shows, matched by an actual review process.

4. Fix parades wearing formal clothes

The single most instructive period is the "core review" series of early July 2026. Under titles of bureaucratic elegance, the log records the discovery that core protocol behaviors were simply wrong — months after the marketing described the engine as having "byte-for-byte wire parity" and being "diff-tested against RNS":

Other entries of the same kind, scattered across the log:

• 2026-06-17 (cc4d524a3): "This closes the >1 MiB RNS-to-Prns interop stall" — resources larger than a megabyte did not work at all until three weeks into the project's life. That the flagship interoperability feature was non-functional this long after the "drop-in replacement" claim is not a footnote.
• 2026-07-13 (a010e6613): "found en route: send_single_packet toward a detached-interface route hangs out the receipt ladder rather than erroring (capstone time-boxes attempts, typed fast-fail a candidate for later)" — a known hang in a routing/send path, shipped with a note to fix it later.
• 2026-07-13 (5944992a4): "a big single-segment response could previously race its own timeout mid-transfer" — a receipt-timing bug in resource transfers.
• 2026-07-06 (74bea355e): "entropy goes lazy (write fns take the host fill_entropy closure, rotate_if_due draws only once a rotation is actually due instead of draw-then-zeroize per announce)" — entropy handling for ratchet rotation in a cryptographic context, revised months in.
• 2026-07-13 (a5af4333b): persistence "the reference stalls forever" — a documented deviation from RNS receive semantics, presented as if the reference were at fault.

None of this is unusual for a young port. What is unusual is the register: every one of these is dressed in the language of deliberate engineering — "review", "parity", "evidence" — when what actually happened was that an automated process generated incorrect code, and the divergence was discovered later, sometimes months later, often by cross-checking against RNS source line numbers that are cited in the very same commits. The history is not a record of a person building; it is a record of a generator being corrected, commit after commit, with the corrections phrased as if they were planned.

A cryptographic networking stack is a category of software where this pattern is intolerable. In routing, deduplication, duty-cycle accounting, announce-ID history, and ratchet rotation, the difference between "matches the reference" and "mostly matches, except the parts we got wrong, and we have no clue how much is still wrong" is the difference between a working network and a network that silently leaks, floods, grows without bound, or fails to interoperate. The July "core review" series demonstrates, in the project's own words, that all of those failure classes were present at some point in this code.

5. Process theater

The repository carries the full costume of a rigorously governed project: 26 CI workflows with names like deep-validation.yml, mutation-audit.yml, flasher-promote.yml, host-sdk-stage.yml, prnsd-staging-qualification.yml; a 26,794-line audits/unsafe-snapshot.json; a 511 KB generated third-party notices file; a "validation hub" with oracles, fuzz corpora, mutation testing, Kani proofs in (some) hot paths; and a benchmark publication pipeline with cryptographic proof records and immutable suites. As infrastructure, much of it is real code that "exists". But the relationship between this apparatus and the product it claims to certify is broken in the ways documented throughout these sections:

• The benchmark "proof records" prove only that a stale development shim loaded a single top-level module.
• The CI that was supposed to catch a crate that "hasn't compiled since" a rename did not catch it for weeks, because the crate was outside the workspace — and the commit notes this without apparent embarrassment.
• The "enforced, then audited" front-page claim coexists with commit-history admissions of unbounded growth, silent flood leaks, misimplemented reference semantics, and known shipped hangs.

This is process as marketing, not process as engineering. That distinction is the entire story of this project in one sentence.

6. What the history is

A commit history is, among other things, a record of attention: what the author cared about, in what order, and for how long. This history reports that the author cared about, in the first three days: a scaffolding of two protocol ports, a no-alloc engine, an ESP32-C6 host, an Android archive, a multi-node simulator, a first protocol object, and — on day three — a marketing website with twelve languages. The protocol objects that the engine would need to actually talk to RNS took months to converge on the reference's semantics, and some are, per the project's own admissions, still deviating by design ("flagged deviation", "the reference stalls forever").

The history shows a project that was, at every stage, running way ahead of its own understanding, while being dressed — in its own commit messages, its own website, and its own hook-enforced authorship fiction — in the appearance of the opposite. That is the strangest thing about it, and it is worth stating plainly: the record of this project is not the record of a person doing careful work fast. It is the record of a process that was optimised to look like that, and the two are not the same thing.

That, by any definition of the word, is a sham.

The "build ethos", the initial commit, and the question of who built this

1. The founding document

The fourth file created in the history of this repository was a 233-line text called docs/build-ethos.md, committed at b0e1b2d73, "Scaffold Personal Reticulum suite", on 2026-05-26. It opened with:

"Port the contract, not the implementation. Build one pure engine, and let each platform bring a thin host."

and declared the full scope of the project in one line:

"a performance-focused drop-in-replacement for rnsd, with full embedded support, plus ecosystem libraries including iOS/SPM, android/maven central, and npm; with formal proofs and extensive testing"

It also contained this assessment of the reference implementation:

"The single most clarifying fact about the target: rnsd itself is about thirty lines of real code. Strip the example-config string and the Python daemon is Reticulum(configdir=…) followed by while True: sleep(1)."

This is worth pausing on, because it is the project's own founding description of its relationship to Reticulum. The framing — that the daemon is thirty lines, therefore the real work is "be Reticulum + Transport + the interfaces", and everything else is "reference material, not code we carry" — is a deliberate narrowing of what Reticulum is.

It reads as the confident summary of someone (or something) that has read the surface of the codebase and concluded the reference is simple. The subsequent history — dozens of "core review" commits discovering that Transport, routing, dedup, announce-ID history, duty cycling, acceptance semantics, and receipt law all had to be re-learned from the reference, month after month — suggests the founding confidence was, to put it mildly, optimistic at best.

The founding document also says, in the most memorable sentence of the whole repository:

"You owe the reference fidelity at exactly two boundaries: The wire. ... The behavior. ... Between those two boundaries, the model is yours."

Two boundaries, the wire and the behavior. Every subsequent advisory in this series is, in essence, a report card on how those two vows were kept. The wire was eventually made largely compatible (with interop gaps that took weeks to close, and that remain verified only against pinned, outdated reference versions). The behavior, as the July "core review" series demonstrates, was not known, let alone honored, for months — in routing, dedup, group handling, flood control, ratchet rotation, receipt law, and resource semantics.

2. The founding state

The initial commit — 14 files, 640 lines — already contained: personal-rns, personal-lxmf, personal-rnsd, a Cargo.lock, and the "build-ethos" document. Two protocol ports, a daemon, and a philosophy, all on day one. Within 48 hours the log shows:

• day 2: a "crypto adapter — vetted primitives, byte-exact vs RNS 1.3.1", a "Reticulum Visual Toolkit — multi-node sim", announcement handling, SoA routing tables, an ESP32-C6 host adapter, and an Android archive build;
• day 3: "Bootstrap reticulum.rs docs site (Dioxus 0.7 + Tailwind + dioxus-i18n)", "Sync all i18n locales", "Deeper-pass refinement on all 11 non-English locales", "Hero cleanup + mission tightening across all 12 locales".

A marketing website in twelve languages predates, by this record, almost everything that would make the project real: the daemon had no working resource transfer for three weeks, interop with RNS resources above a megabyte for nearly a month, and the core routing semantics were still being corrected in July.

The order of operations — marketing first, protocol semantics whenever — is itself a finding.

3. The scope problem

What the history claims to have been produced, by one person, in 110 days:

• A protocol engine (1,983 Rust files, 636,226 lines, 22.7 MB) implementing the RNS wire contract, transport, links, resources, channels, remote control, persistence, identities, and configuration parsing;
• Firmware for ESP32-C6, ESP32-S3 (six board variants), and nRF52840, with on-device screens and controls;
• Native SDKs and bindings for Rust, TypeScript/JavaScript, Python, .NET/C#, Go, Swift, Kotlin/Java, Julia, and C/C++;
• A web flasher and a browser-based in-browser node;
• A 12-language marketing website;
• A benchmark harness with its own publication-and-proof pipeline;
• A "validation hub" with oracles, fuzzing, mutation testing, hardening gates, and Kani proofs;
• 3,374 commits, an average of ~31 per day.

Putting aside for one moment the quality questions documented elsewhere: this is 636,226 lines of Rust — about 5,800 lines per day, every day, including weekends, with no breaks — plus everything else. The median professional Rust engineer, working flat out on a greenfield protocol implementation with no distractions, produces a small fraction of this. The record is not merely unlikely; it is impossible for a single human, and the claim that it was reviewed by one is impossible in a stronger sense: 637,000 lines generated at this rate cannot have been read by the author at any level of scrutiny, let alone "strictly tested, audited, and proven" as the marketing asserts. The project states an MSRV, an audit snapshot, a mutation-testing program, formal proofs, and a publication pipeline — but no human can have verified the material those claims refer to. The claims are structurally incapable of being true.

All of that, quite literally, is either a fabrication, or psychosis.

4. The agent-loop evidence

The repository is unusually rich in evidence about how it was made, if one is willing to read the history as data rather than as narrative:

• Cadence. 31 commits/day, 110 days, no weekends, no nights — 149 commits between midnight and 6 a.m.; Saturday is the busiest day. Humans do not do this.
• The commit-message hook. .githooks/commit-msg blocks any AI-attribution trailer ("generated with claude/codex/copilot/cursor/gemini", "co-authored-by"). A repository that is not machine-generated does not need a hook whose sole purpose is to erase machine-generation from the record. Its own contributing guide addresses "automated contributors" and declares that what an AI tool produces becomes "yours".
• The register. "Sync directives & ethos for next wave of work", "Close embedded assurance evidence audit", "Make embedded resource evidence truthful" — this is the language of a loop being commanded, not a person reporting.
• Renaming churn. Daily architectural renames in the early period (State → EngineState, Input → TickInput, Effects → TickOutput, drive_once → step all inside 48 hours) — the behavior of an agent editing a plan while executing it.
• The discovery curve. The "core review" series of July — dedup, caps, group handling, flood control, ratchet timing, receipt law — is precisely the correction curve of a system that generates plausible code from a partial (but incorrect) model of a complex reference, then discovers the divergence when tested against the real thing. The commit messages cite the reference's own source line numbers (Transport.py:1367) as if the discovery were part of a plan. It was not; it was the loop meeting reality.
• The scale of the claims vs. the scale of the output. Twelve-language website on day three; formal proofs and byte-exact crypto on day two; months of divergences from the reference that followed. This is the ordering of an agent that produces presentation and coverage as its primary objectives, because those are the objectives it was given.

None of this is, by itself, a crime. What it is, is a finding: the most probable reading of this repository is that it was produced by a continuous autonomous loop, with a human's name attached, at a rate and scale that no human could replicate, review, or — critically — be answerable for.

5. Why this is irresponsible

There is a class of software where the difference between "plausible" and "correct" is life-safety: aircraft firmware, medical devices, cryptographic protocols. Networking stacks that carry end-to-end encrypted traffic belong on that list. The properties that must hold are not the ones that a model can be prompted into holding; they are the ones that require a human who understands the protocol deeply enough to answer, without an LLM, the question "what does this byte do to state, and what can an adversary do with that?", and has been asking themselves those questions for a significantly longer period than 110 days.

The record shows the answer this project would give: its own history shows its generated code misread the reference's semantics in deduplication, group handling, announce-ID history, duty-cycle accounting, flood limiting, ratchet rotation, acceptance semantics, and receipt law — and in at least one case shipped a known hang ("typed fast-fail a candidate for later"). It shows a benchmark apparatus that mislabeled a broken development shim as a fair test reference. It shows a "compiled" mode that does not exist being used as the baseline for the project's central marketing claim. It shows an authorship policy engineered to ensure that no automated tool is ever credited, and therefore that no human can ever be meaningfully held to account.

The people who will bear the consequences of this are not the author and not the loop. They are the users who attach a mesh radio or a backbone server to software whose correctness they cannot verify, whose provenance is laundered, whose benchmarks are fiction, and whose operator — by the project's own design — never has to answer for any of it. A person can build a hobby project this way. A person cannot responsibly build the substrate of other people's communications this way, and then market it to the world as safer than the reference it will not name.

6. Summary

The founding document of this project promised a disciplined port: the wire, the behavior, nothing else. The founding state was a marketing-first, scope-maximal, one-person-in-name suite. The intervening 110 days produced 637,000 lines of Rust, three firmware families, five SDKs, a 26-workflow CI apparatus, and a 12-language website — a scope and a velocity that are coherent only as the output of a continuous automated loop, with very little oversight per executed decision.

And the chosen field for this experiment was a cryptographic networking stack whose every semantic misread, whose every "parity fix" months late, whose every known shipped hang, is a safety property that real users will discover in the field instead of in review.

This is not a critique of using tools. It is a critique of a specific, evidenced pattern: delegating the unforgiving core of a communications protocol to an uncredited loop, for the appropriation of credit, marketing the output as more rigorous than the reference, and arranging the record so that responsibility evaporates.

The RNS community should treat this project the way it would treat any binary blob of unknown provenance: with full skepticism, until the provenance, the semantics, and the people are all actually verifiable. At this point, it seems very difficult to imagine how it would actually be able to recover such trust in this project.

Conclusion — trust, accountability, and the health of the network

1. What the preceding documents establish

Across four separate examinations of the public record — the benchmark apparatus, the authorship machinery, the commit history, and the founding documents — the following facts are established by the repository's own material:

1. The central performance claim is built on a broken measurement. The "89×" headline compares Prns to a stale development shim (top-level-only, debug-targeted, Cython 3.x-broken) that is slower than stock interpreted RNS; forces the reference onto the slowest interfaces possibl; and, in its "default" rows, compares a 500 Mbps MTU policy against a 10 MTU Mbps policy. The project's own equalized-policy rows collapse the ratios to ~2.4–8.4×, still against the broken-by-harness baseline. The front page of the project says "Measured, not just claimed." The record shows the opposite ordering.
2. The authorship record is engineered. A commit hook exists for the sole purpose of blocking AI-attribution trailers; the contributing guide declares AI output "yours"; a fake "tests" identity contributed 35 marketing commits; a pre-push gate scrubs personal paths from the history with an obfuscated token. 96.4% of 3,374 commits come from one account, at ~31/day, with no nights and no weekends.
3. The history shows a generator being corrected, months late, in the core of a cryptographic protocol stack. Deduplication RNS doesn't do; unbounded announce-ID growth; a flood limiter that leaks; a phantom airtime leak; receipt races; a known send-path hang shipped with a "candidate for later" note; a ">1 MiB interop stall" closed three weeks in. All phrased as deliberate "core review" and "parity" work. All after the marketing claimed byte-for-byte parity and diff-testing.
4. The scope is preposterous for a human and coherent only for an automated loop. 637,000 lines of Rust in 110 days, plus three firmware families, five SDKs, a web flasher, a validation hub, a 26-workflow CI apparatus, and a 12-language website that existed on day three — before most of the protocol did.
5. The reference is systematically uncredited. The website contains no link to it at all; a single (well-hidden) link exists in the README; the license files carry no RNS or LXMF copyright line; 506 commits reference RNS behavior while the marketing calls the result "a ground-up implementation".

2. Trustworthiness

For a communications stack carrying end-to-end encrypted traffic, trust is not a property of good intentions. It is a property of verifiable facts: who wrote the code, who reviewed it, how it was tested, what it was measured against, and who answers when it fails. On every one of those axes, this project fails:

• Who wrote it: a person on record whose history shows he cannot have reviewed what he committed, and a machine that is, by policy, never recorded. The operator of the machine has no other published relevant code to compare against.
• Who reviewed it: only the same source. The elaborate validation apparatus is self-certified by the same unanswerable pipeline; its "proof records" prove only that a broken shim loaded one module.
• How it was tested: interop is verified only against a pinned, outdated reference version (RNS 1.4.2; some published suites against 1.4.0) over loopback and TCP. The published results themselves document races, cliffs, and polling-loop pathologies with stock RNS. No real-hardware evidence exists.
• What it was measured against: a mislabeled development shim, on the slowest possible legacy interfaces, at a 32× MTU policy disadvantage.
• Who answers when it fails: the authorship policy is designed so that nobody does.

A project with this profile cannot be trusted to carry the real traffic of real users. Not because every line is known to be wrong — but because nothing about it can be known to be right, and because the parts that are known (the benchmarks, the authorship, the semantics discovery curve) are not reassuring, to put it very mildly. For a mesh radio carrying a community's communications, "probably fine, trust me" is not a security argument; the record here is worse than "probably fine" — it is "measured to be misrepresented".

3. Accountability and maintainability

The question of maintenance is the quiet part of this story. A 637,000-line protocol stack whose semantics had to be re-learned from the reference over months, whose core is generated code no human has read, cannot be maintained by its own author — there is no evidence, and no plausible mechanism, for a human to keep this much machine-generated protocol code correct as the protocol evolves, as RNS moves on, as new reference versions ship, as vulnerabilities are found in the primitives or the state machines. When the loop moves on to its next project — and the pattern of this kind of output is that it does, sooner rather than later — this code will not be maintained; it will be abandoned mid-claim, the way the 8+ other LLM-generated Rust "Reticulum Implementations" have been before it, the way the benchmark crate "hasn't compiled since" a rename for weeks, the way a "typed fast-fail" for a known hang was "a candidate for later".

Maintainability is not a virtue that can be claimed for code that no human can hold in working memory. It is a function of authorship, review, and understanding — and all three are absent here by design.

4. Harm to the network

Projects like this are not neutral. They inflict identifiable harm on the ecosystem they claim to join:

• Confusion and wasted time. The marketing presents a finished, tested, drop-in replacement. Users — the people without the time to audit 637,000 lines — install it, believe the "89×" figure, and spend their evenings debugging interop races that the project's own benchmark tables document, against a reference version the project itself has already abandoned. The community has already eaten this cost. It will keep eating it.
• Protocol fragmentation. The project ships a self-invented "turbo" sub-GHz mode sharing the same spectrum as standard RNS LoRa operation. A "drop-in replacement" that invents its own channel behavior is not a drop-in replacement; it is a fork of the airwaves. This is the kind of unilateral protocol invention that harms real deployments, and it was shipped by a process that, by its own history, had not yet correctly understood the reference's duty-cycle accounting when it started inventing on top of it.
• Reputational damage to RNS. The marketing explicitly (and maliciously) positions Prns as "what RNS should have been" — faster, safer, "Enforced, then audited", "Runs on everything" — while systematically omitting that it is a low-quality carbon-copy "port" of RNS, and omitting the reference's copyright from its licenses. Every user who believes the "89×" framing concludes that RNS is slow and carelessly built. It is neither; it is simply not marketed by a machine, and was not developed by a narcissist.
• The normalization of fabricated rigor. When a project can claim "formally proven, fuzzed, mutated, audited, measured" on the evidence presented here, and attract attention on the strength of it, the ecosystem learns that rigor is a marketing genre rather than a property. That is the deep harm: not one project, but the inflation of the currency of trust that every honest project pays with.

5. On intent

Whether the author intended any of this is unknowable, and ultimately it is beside the point. The pattern — a person who outsources a cryptographic networking stack to an uncredited automated loop, markets it with fabricated measurements, erases provenance, and claims full ownership of the result — produces the same consequences whether it springs from malice, from naive self-deception, or from the particular blend of confidence and outsourced judgment that this decade has made so cheap. The network does not run on intent; it runs on packets, and the packets will not care why they were dropped or misrouted.

6. What trust would have required

For the record — for the community, and for anyone who wants to work on an actual implementation — here is the bar, and it is the same bar RNS holds itself to:

1. Human answerability. A named person who can and does explain the code line by line, accepts the maintenance burden, and stays with the project's users for the long term — the decade-plus scale that network infrastructure actually lives on.
2. Clearly label in-progress and experimental work. A big fat "This is an in-progress, experimental Reticulum implementation, do not use this yet" disclaimer should have been the very first thing users saw. In this case, they got a polished marketing website with gradient effects and insane levels of misinformation instead.
3. Disclosed provenance. Record honestly how the code was produced. An authorship policy whose purpose is to hide the generator is incompatible with a security-sensitive project, full stop.
4. Attribution. Credit the reference implementation properly in the code, the licenses, the website, and the marketing, and follow the actual license terms as any just half-sane developer would do.
5. Honest benchmarks or none. Run against stock, current, interpreted RNS on the modern interface at equal policies, methodology published in advance, not smudged up in un-interpretable LLM lingo.
6. Compatibility with reality. Interop evidence against current RNS on real hardware, including the radio and serial interfaces this protocol family lives on; remove or clearly quarantine nonstandard spectrum behavior.

None of this is punitive. It is a boringly ordinary entry fee for a project that wants other people to route their communications through it. RNS has paid it for more than a decade, and its users know what that looks like.

7. Closing reflection

The pattern on display here is not rare anymore, and it will become increasingly more commonplace: Polished surfaces, fabricated measurements, laundry-cycle authorship, and scope that only a machine could produce, presented as the well-tested, well-intentioned work of a diligent individual. The cost of that pattern is paid by everyone, both those who believes the fantasy, and those who do not. Mostly by those who do not, though: We're the ones cleaning up the mess after the prior.

The networks are healthy when their components are accountable — when a claim is well-substantiated, a benchmark is an honest measurement, a commit is a human being taking responsibility, and a port gives credit to the thing it was ported from. By every one of those standards, this project is not what it presents itself as.

And before any of the usual suspects start shouting "AI HATEEEEER BOWOO", sit down, relax and find great peace in the following facts:

• I absolutely love AI. Best sci-fi trope there is. Basis for all my favorite fairy-tales. Chef's kiss.
• As you can see, most of this was genrated by the deterministic software process you believe is, and refer to as "Artificial Intelligence". I even wrote the "agent" framework it ran under. See? It's all love and hugs here ;)

To quote the Prns project itself:

"slop is slop regardless of how it was produced"

Prns is particularly bad, but this is just one example of an LLM sloppulus "port". There are about a dozen at this point, and its fair to say the same analysis above applies to all of them. Especially the one by the absolute cornball with an NFT profile picture trying to run a crypto scam with his vibecoded Rust port who I'm not going to even name here.

One thing not mentioned in this analysis is the code churn rate, which is inherit to most vibecoded projetcs.

I'm away from my desktop but the screenshot of the Github Contributors page paints the picture.
1,895,076++ 954,495--

That is a churn rate of 50%. For every one line of code generated, another one is deleted in a project that is only 3 months old. I don't have the numbers to tell you what % of that is actually touching the main codebase (refactoring things to a new file would count as a diff or deleting LLM markdown vomit) but my guess is it is at or around that 50% figure.

The invented vocabulary of LLM generated projects is what pisses me personally off the most. I have never heard anyone refer to commit messages as "trailers" in everyday use. I have never even heard the word "Oracles" or "attestations" in any sort of development context.

If I can't even understand the natural language description of what an LLM is regurgitating how can I understand the code?

The guerilla marketing of LLMs by companies like Anthropic and OpenAI as general purpose artificial intelligence has given people a total misunderstanding of these tools, what they are, what they can do, and their capabilities.

It's a mass psychosis event.

I can't put it into writing what's happening. It is so much of an incomprehensible clusterfuck and we are barreling towards a future that is fundamentally post-truth, and anti-human. If we weren't there already.

Let's talk about the word "agency" too. It's the new buzzword, but when I say agency I mean the pre-LLM mass formation psychosis definition of the word.

Human agency is being stripped away by things that are non-human. This process was happening long before LLMs but they certainly have accelerated it.

Is the future we want really a future where the process of thinking is outsourced entirely to a third party black box in which you have zero control over?

What even happens at that point? Billions of years of evolution that led to the development of human qualia will atrophy into non-existence. The first species to domesticate itself via glowing screen.

Without agency you have nothing. Do not trade your agency for this.

Oh, this is a beautiful read, thank you!!!

Not to use this forum as my personal soapbox but one thing I hope to see born from Reticulum is human-centric networks.

A reinforcement learning algorithm or LLM can't install an RNode on a mast. Or string up a HF dipole antenna. Or install a Ubiquiti access point on a pole. All of this requires intentional action and coordination by real people to create an organic network.

You can't prompt an LLM to do that. If I want to put together LoRa coverage for my area I can't just open up Claude and ask it to do that. Just like in ye days of old, you have to talk to real people for this.

We're just at the start of the LLM psychosis. If you think it's bad now, it's gonna get a lot worse. The Internet won't even be usable in a handful of years.

Exactly! We need more human connections in our lives! And the fitting technology for it! Its not just about DIY, or decentralized, its about meeting and connecting your neighborhood and make human relations the center of our lives again.

Why are you using this forum to spray llm generated text just as a show of force? @mark
I get your point on llm generated stuff without oversight or organic audit is not trustworthy (this statement should be very banal and aggreeable at this point for everybody in the field).

Why is it ok to bomb your personal attacks at people? Calling out peoples actions as attentionseeking is a needless aggression without basis in fact (unless his highness now has the abilities of mind reading as well)

Why are you @mark and zenith so stobbernly insisiting to be bullies on everything and everybody you dont like?
I think you are unprofessional in your communication and its hurting the communities.

Supernihil wrote:

Why are you using this forum to spray llm generated text just as a show of force? @mark
I get your point on llm generated stuff without oversight or organic audit is not trustworthy (this statement should be very banal and aggreeable at this point for everybody in the field).

Why is it ok to bomb your personal attacks at people? Calling out peoples actions as attentionseeking is a needless aggression without basis in fact (unless his highness now has the abilities of mind reading as well)

Why are you @mark and zenith so stobbernly insisiting to be bullies on everything and everybody you dont like?
I think you are unprofessional in your communication and its hurting the communities.

Truth hurts, heh? When someone stands you up to face what you are and calls things their proper names, ya'll start playing devil's advocates and whine and blame, you children...
You all do not even realize, that YOU ARE THE BULLIES, this absolute shit, that gets thrown around , posing as Reticulum is actually bullying the real efforts, the real work that is done, the network itself is poisoned by the endless mindless datastreams of your decrepit creations and instead of building networks and getting people together, we all have to NON-STOP deal with all you needy selfish kids, crapping all over something so beautiful and great, BECAUSE YOU CAN. You are no good for anything else, but to complain, blast passive-aggressiveness and blame. All of you punks don't even USE reticulum I haven't seen ONE IDENTITY OVER YOUR POSTS. GO AWAY AND STOP PEEING IN THE WELL YOU NIHILISTS!

i gently open the door
Five, hundred, protocol violations. ken gotta stop that slop before its 2l8 I'll print this on my printer & i will read it to my grandvibe children when they'll start vibecoding, thanks Mark! On another note, this is fucking insane, time for a license change part 2, eletric slopaloo? xoxo, burger

What an analysis... A perfect illustration of the Brandolini's law.

I wrote about AI last week in https://not-a-number.io/2026/on-the-use-of-ai/ and I think you answered my question ! Thank you :)

Lol @burger, Reticulum License - Electric Slopaloo Edition, here we come. Although, he's already breaking the license in several ways. Not because he's reading the reference implementation with an LLM (which is fine, use it for learning and helping you out, then do some actual work), but because of the fully automated copy roundtrip he's doing, without incorporating the proper attribution and license notices anywhere. He's claiming Prns as "Copyright, the prns contributors", which as it stands right now is a fantasy. To be clear, I want to have nothing to do with that theater, but what that license file should have read was "Copyright, Mark Qvist - Reticulum License". Which really makes me curl my toes.

There's provably zero actual creative input from a human there. In no actual copyright court case has any sort of direct machine copy of an original work been deemed to grant the copier copyright over the result, however re-mangled or shuffled the result was. If I was one of those snarky grab-some-damages-money IP trolls, I'd have a pretty clean case here.

Thanks for sharing the article @p1ld7a, I think it provides really valuable and thoughtful framing of some very relevant questions. And that is something sorely needed to start dissecting this whole topic in any meaningful way. Big respect for also actually writing an article that attempts to raise meaningful questions in a considered and well-defined way, and resisting the temptation to cut straight to all the conclusions. I certainly find it helpful for framing my own thinking on the subject more clearly.

Lol @aetherlab, I must say that I appreciate the clarity.

That is the same guy who went on a reddit rampage last week, calling for "removing Mark from the equation", all because his advertising post for his completely nonsensical LLM slop was moved to the another category on this forum (for breaking the, cleanly stated, forum rules).

After which he then returned here to start a new, completely incoherent, thread on "forum politics", which essentially amounted to saying "toxic" and "bully" as many times as possible. Waste of time, indeed. It would be comical if it wasn't so farcical at this point.

I mean, haven't run the numbers, but I think your observation about it always being anons and people without an RNS ident yelling up like this is pretty accurate. Not a decision for me to make, but maybe it's worth considering whether posting should require actually having used Reticulum, just... at least once.

Edit: And no, the post was not moderated by me; I don't have any moderator or admin rights on this forum. I'm a normal user like everyone else. But apparently my dictatorial powers now transcend even the boundaries set by elliptic curve math. Really should get to using that a bit more creatively than moderating forum posts, I guess.

@mark your analysis is wrong. I posted a project of mine, yes openly written by ai, no secret about that. Its a long going effort to collect information of 20 years of mesh network ideas. As much a research documentation effort as a try at building something new. Not a blatant copy in any way, also not a mindless journey, also not a short journey.

I am tired of your judgements on people and their motives.

I am critizing rightfully your antagonizing of communities and community members. I respect your ownership of your repo. I disagree with your license.

I think its wrong that you are being treating people how you do. I think its wrong to assume ai==one-singular-worst-case
I think its wrong to assume that everybody who tries to produce code using ai is lazy and attention seeking.
And your actions by using said same weapon (llm) to spur out stuff you would never read yourself purely because ot was openly written by ai is hideous and a weird attack on ken who has been polite while you and zenith has repetedly attacked him.

Its enough, you are showing bad leadership in a community sense.

And i am not alone in my thoughts.
https://gaggl.com/blogs/2026-09-05-enclosure-by-good-intentions/