From e699bb23f1306ed451568d647b497791a44be95a Mon Sep 17 00:00:00 2001 From: Mark Qvist Date: Sat, 19 Sep 2026 11:16:58 +0200 Subject: [PATCH] Structural cleanup --- docs/manual/_sources/brandolinis.rst.txt | 516 +++++++++++------------ docs/manual/brandolinis.html | 420 +++++++++--------- docs/manual/index.html | 26 +- docs/manual/objects.inv | Bin 4672 -> 4679 bytes docs/manual/searchindex.js | 2 +- docs/markdown/brandolinis.md | 446 ++++++++++---------- docs/markdown/index.md | 22 +- docs/source/brandolinis.rst | 516 +++++++++++------------ 8 files changed, 974 insertions(+), 974 deletions(-) diff --git a/docs/manual/_sources/brandolinis.rst.txt b/docs/manual/_sources/brandolinis.rst.txt index 16b0ce58..37fffa75 100644 --- a/docs/manual/_sources/brandolinis.rst.txt +++ b/docs/manual/_sources/brandolinis.rst.txt @@ -732,263 +732,6 @@ I'll close this guide by stating what these standards are *not*\ : They are neit The reference implementation has met this standard for years, and its users know what that looks like. -.. _brandolinis-prns: - -The Prns Case -------------- - -.. _brandolinis-purpose-and-scope: - -Purpose & Scope -^^^^^^^^^^^^^^^ - -This section provides a concrete example, which future evaluations can use as a template. Its purpose is not to be the last word on this particular subject, but to be an example of how the ideas in this chapter can be applied, and to make the next such examination easier. - -The subject of this case study is **Prns**\ , a project published at the repository ``github.com/KenAKAFrosty/Prns``\ , presented as a "ground-up implementation of Reticulum, written in Rust", marketed as faster, safer, and more strictly tested than the reference, and widely promoted with the claim of "up to 89× the throughput" of the reference implementation. The record described below is the project's own, and sourced from its GitHub repository, analyzed locally. - -.. _brandolinis-project-in-brief: - -The Project In Brief -^^^^^^^^^^^^^^^^^^^^ - -* **Time span.** 3,374 commits between 2026-05-26 and 2026-09-12: approximately 110 days, - at a mean rate of ~31 commits per day. Monthly: 132 / 1,137 / 1,097 / 805 / 203. -* **Authorship.** 3,252 of 3,374 commits (96.4%) are authored by a single account. A - second identity, "Prns Tests tests@example.test" - a fictitious identity on a reserved - domain - contributed 35 commits, every one of them website and marketing content. -* **Size.** 3,519 tracked files; 1,983 Rust files; 636,226 lines of Rust; approximately - 22.7 MB of Rust source; 69.5 MB of total repository content. -* **Scope claimed.** A daemon ("drop-in replacement" for the reference daemon), embedded - firmware for three microcontroller families (including six ESP32-S3 board variants and - nRF52840), SDKs and bindings for nine languages, a browser-based node and web flasher, a - twelve-language website, a benchmark apparatus with its own publication and "proof" - pipeline, and a validation hub with oracles, fuzzing, mutation testing, and formal-proof - claims. -* **Marketing claims.** "Ground-up implementation of Reticulum"; "up to 89× the - throughput"; "48× smaller peak-memory footprint"; "33× the energy efficiency"; - "Measured, not just claimed"; "Enforced, then audited"; "byte-for-byte wire parity with - the reference implementation"; "works with Sideband, NomadNet, MeshChat, etc."; - "no_std (no alloc required either)". -* **Status at the time of writing.** Version 0.3.7; published version history begins at - 0.3.0. The repository continues to receive commits. - -.. _brandolinis-prns-question-1: - -Question 1: Is this a clean implementation, or was it directly generated from the reference? -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The first of the two deciding questions from :ref:`Evaluating A Reticulum Implementation` is settled by the project's own record. An actual :ref:`clean-room` implementation, reasoned out and written by humans, would owe nothing to any license. The data available shows clearly that Prns is not that. - -* **The founding state.** The first commit, "Scaffold Personal Reticulum suite", contains - the scaffolding of not one but two ports - ``personal-rns`` and ``personal-lxmf``\ , the latter - being the reference's companion messaging protocol - together with a daemon scaffold and - a 233-line founding document, ``docs/build-ethos.md``. That document declares the project's - goal as a "performance-focused drop-in-replacement for rnsd" and its governing principle - as: "Port the contract, not the implementation." It further states directly to the - machine-loop, that **"You owe the reference fidelity at exactly two boundaries: - The wire... The behavior. ... Between those two boundaries, the model is yours"**. - At this point, the very first commit, effectively the whole of the implementation design - and any relevant decisions are handed over to the LLM. -* **Continuous ingestion from the reference.** 506 commits reference RNS or Reticulum - source behaviour; the word "parity" appears in 49 commit messages. Commits cite the reference - implementation's own source locations (for example ``Transport.py:1367``) when correcting - their own divergences and mistakes. -* **Byte-level fidelity as an explicit goal.** Within 48 hours of the first commit, the - record shows a "crypto adapter - vetted primitives, byte-exact vs RNS 1.3.1", and a wire - implementation matching the reference's packet header layout. The project's own - validation apparatus decodes wire vectors using the reference implementation's own - packet parser, and the interop suite consists of real, stock-RNS peer nodes - that is, - the reference source itself, used as the ground truth against which this LLM output is - checked, and committed as accepted and verified after 48 hours of the project's recorded start. -* **The marketing mismatch.** The same record that documents all of the above describes the - project, publicly, as "a ground-up implementation of Reticulum" - while declining, on its - website, to link to the reference implementation at all: the entire tree mentions the - reference's author in six files, and the website in none. - -Conclusion: the project's own history and commit record establishes that it was generated directly from the reference implementation's source code, not reasoned out from the public-domain protocol. It is a derivative of licensed work within the meaning of :ref:`the Reticulum License` and :ref:`general copyright law`. The "ground-up" claim, which carries its entire legal and marketing posture, is disproven by the project's own history. - -.. _brandolinis-prns-question-2: - -Question 2: Who, or what, is the agent of the work? -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The second deciding question is answered by the application of :ref:`Assistance Versus Machine Substitution` criteria to the project. - -**Scope that no human could have authored** - -636,226 lines of Rust in 110 days is approximately 5,800 lines per day, every day, including weekends - with 149 commits recorded between midnight and 06:00, and Saturday the single busiest weekday. No human review or decision capacity is commensurable with this volume; the review capacity and the output volume are structurally incommensurable, which is the definition of unauthored scope. - -**Uniform generation** - -The record shows no sign of human development, growth, or learning: No contested decisions, no style drift. Instead: endless renaming (in the first 48 hours: ``State → EngineState → TickInput → TickOutput``\ ), uniform fluent register in every commit, and the exact same, synthetic voice in code, documentation, and website copy. - -**Discovery by regeneration** - -Corrections arrived by the machine's own subsequent runs, recorded as planned milestones. In early July 2026, a series of "core review" commits documented, in the project's own words: - -* announce-ID history "was unbounded per-slot growth" (\ ``54cc8d601``\ ); -* interface announce limiting could "leak a sustained flood" (\ ``9d27af75c``\ ); -* a "phantom-airtime leak" where frames "used to vanish silently" (\ ``4ed75ffdd``\ ); -* Group-packet deduplication "which RNS does not do" - a behaviour the reference never had, - implemented and later removed (\ ``edd8e72be``\ ); -* "both ``unwrap_or(&[])`` arms were unreachable dead defaults" (\ ``74bea355e``\ ); -* a benchmark crate "hasn't compiled since" a prior rename, undetected for weeks because it - was outside the CI's workspace (\ ``86240b027``\ ). - -Earlier still: the record shows a ">1 MiB RNS-to-Prns interop stall" closed three weeks in -(\ ``cc4d524a3``\ ), and a known send-path hang shipped with the note "typed fast-fail a -candidate for later" (\ ``a010e6613``\ ). - -**Laundered provenance** - -The repository contains a committed commit-message hook (\ ``.githooks/commit-msg``\ ) that *blocks* any commit containing attribution for machine generation ("generated with claude/codex/copilot/cursor/gemini", "co-authored-by"), with the explanation "The committer owns the commit". The contributing guide is explicit: "AI tools ... are welcome ... what you submit is *yours*", and describes the contributing population as "both human and automated contributors". The fictitious "Prns Tests" identity completes the picture: A manufactured, unknowable contributor, used for marketing content. - -**Authorship by assignment** - -The human whose name is on the work cannot answer for it, because the choices were never made by a human, and only the general shape and constraints of the outward presentation was. Nothing in the project's history shows an individual explaining a design decision, accepting a mistake in the first person, or going deeper under technical questioning; the record shows process language and marketing instead. Per the earlier mentioned test: any other person could have pressed the same button, and nothing would be different. The project is effectively unowned, and void of value. - -By the criteria of :ref:`Assistance Versus Machine Substitution`, this is substitution. The machine was the agent of the work; the "author" was a facade. - -.. _brandolinis-prns-performance: - -The performance claims -^^^^^^^^^^^^^^^^^^^^^^ - -The project's central marketing claim - "up to 89× the throughput" of the reference - is also its most completely documented failure, because the project published the evidence of its own measurement. The apparatus, the results, and the problems are all on the record. - -**The claim** - -The README states "up to 89× the throughput"; 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"; the website's front page carries the tagline "Measured, not just claimed". - -**The apparatus** - -The reference is loaded through ``benchmarks/reference/compiled_reference.py``\ , which installs ``pyximport`` and then asserts two things: that ``RNS.compiled == True``\ , and that at least *one* RNS module was loaded from a native extension. The project's own published "proof" records show exactly what those checks captured, on every platform: - -.. code-block:: - - aarch64-apple-darwin: .../RNS.cpython-313-darwin.so, Cython 3.2.8, Python 3.13.13 - x86_64-unknown-linux-gnu: .../RNS.cpython-313-x86_64-linux-gnu.so, gcc 11.4.0 - x86_64-pc-windows-msvc: ~/.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.so``\ , nothing below it. Nothing named ``RNS.Transport``\ , ``RNS.Destination``\ , ``RNS.Packet``\ , ``RNS.Link``\ , or ``RNS.Resource`` ever appears, because *nothing below the top level was ever compiled*. Nobody bothered to check or verify *anything* here. - -The machine output was simply taken for truth, and a full marketing strategy was spun and produced on it. "RNS 1.4.2 (compiled)" - the label used in every table, chart, and marketing page - *is not a mode of RNS that exists*, but the hallucinations of a machine, which the humans created a marketing strategy on. In reality, it is the old ``CRNS`` development shim, whose top-level-only, debug-oriented "compilation" is slower than plain interpreted RNS, and which was *defunct for over a year* before these benchmarks were published. - -**Interface choices** - -The harness writes the reference's configuration itself (\ ``benchmarks/reference/participant_node.py``\ ): ``TCPClientInterface`` for the initiator, ``TCPServerInterface`` for the responder and both relay sides, with ``UDPInterface`` as the abstract wire. The reference was never given its modern ``BackboneInterface`` on any platform, forcing the slowest possible interrfaces. The interface selection is never mentioned in any methodology text. - -**The policy** - -The published default-policy tables record the asymmetry directly: Prns at 500 Mbps / 128 KiB TCP policy against the reference at 10 Mbps / 8 KiB - slyly footnoted as "preserves each implementation's normal TCP policy" (in the case of RNS, a conservative default policy that was selected to prioritize coexistence on slower, shared links, requiring the user to dial it up to full speed if they knew what they were doing). Raw transport "throughput" ratios of 20.65× (Linux) and 38.84× (Windows) are therefore mostly policy, not engine. - -**The cross-host evidence** - -The published results show the same scenario producing wildly different ratios by host, and the variance is entirely in the reference artifact: - -.. list-table:: - :header-rows: 1 - - * - Host - - Prns, single-packet - - "Reference", single-packet - - Ratio - * - macOS (Apple M4) - - 37.4k/s - - 420/s - - 89.09× - * - Linux (i7-1260P) - - 25.3k/s - - 3.5k/s - - 7.19× - * - Windows (Ryzen 5 5600X) - - 30.8k/s - - 3.9k/s - - 8.00× - -Prns is consistent (25–37k/s). The reference artifact collapses to different depths on different hosts, and the single worst collapse - 420 packets per second on macOS - is the cell selected as the global headline. The "89×" is not a measure of Prns; it is a measure of how badly the broken baseline happened to fail on one host. - -For reality calibration: Stock, interpreted RNS 1.5.4 on an ordinary mid-range laptop, single core, sustains roughly 30,000 single-packet deliveries per second (including ephemeral-key decryption), ~175,000–280,000 packets per second in transit relay, and on the order of 10 Gbps at 16 KiB payloads. The project's "compiled" artifact measured 420–3,900 packets per second for its single-packet scenario: An order of magnitude or more *below* stock interpreted RNS. The comparison being marketed was not "Rust vs Python"; **it was "an implementation running under optimal conditions versus a mislabeled, broken shim on a slow legacy interface at a severe policy disadvantage"**. - -**The equalized rows** - -The project's own "1 Gbps policy" rows, in which both sides are explicitly configured identically, publish ratios of roughly 2.4–8.4× across all hosts and scenarios - still against the broken baseline, but nowhere near 89×, and consistent with the ordinary, uncontroversial observation that a native implementation tends to outperform an interpreted one in raw throughput. That point needed no fudging to make, and is banal. - -Interestingly, though, it seems that Prns is really only *marginally* faster than a Python implementation, running in interpreted mode, on a single CPU core. - -**Assessment** - -The front page says "Measured, not just claimed." The record shows the opposite ordering: claimed, and arranged to look measured. No methodology section anywhere states what "compiled" means, that it is a deprecated development shim, that it builds debug targets, or which interface the reference was given; the one statement of the policy asymmetry appears in a footnote of the results tables themselves. If they did not need to fudge it, they would have published the method clearly. - -.. _brandolinis-prns-overall: - -Overall Evaluation -^^^^^^^^^^^^^^^^^^ - -Evaluated against the conditions of :ref:`Evaluating A Reticulum Implementation`: - -* **Provenance and attribution.** Fails: The fake "ground-up" origin story; zero reference links - on the website; a single well-hidden link in the README; a license file reading - ``Copyright (c) 2026 The Prns Authors`` over work directly generated from the licensed reference; - no original copyright or permission notice anywhere. -* **Agency and answerability.** Fails on every criterion of :ref:`Assistance Versus Machine Substitution`: - Unauthored scope, uniform generation, discovery by regeneration, laundered provenance, - authorship by assignment. -* **Engineering.** Fails: The benchmark apparatus above; interop demonstrated only - against a pinned, outdated reference version over loopback while the marketing claims current - parity, interop failures with stock RNS; vendored prebuilt binaries and a republished fork - of an upstream crate (``nrf-softdevice 0.1.0-prns.1``) with no verifiable provenance; - committed WASM bundles. -* **Network behaviour.** Fails: Invented spectrum behaviour and compatibility claims - about third-party applications of the reference ecosystem (Sideband, NomadNet, MeshChat) - that are not established by any evidence. -* **Monetary and influence signals.** The marketing apparatus - website before protocol, - day-three twelve-language marketing, false benchmark headlines, "audited" and "formal proof" - claims - the conformal surface described in :ref:`Evaluating A Reticulum Implementation`: - is where this project invested. - -.. _brandolinis-prns-licensing: - -Licensing Analysis -^^^^^^^^^^^^^^^^^^ - -Applying the two legal layers established in :ref:`Copyright & The Two Legal Layers`: - -**Layer A - copyright infringement (license-independent)** - -The record shows a direct copy roundtrip: the licensed reference implementation fed into a machine, transformed, at a scale and cadence no human could review, with a license file asserting a fresh copyright in the operator's name and no acknowledgment of the work the project was generated from. No substantial, new human creative input is demonstrated anywhere in the record - the founding document explicitly frames the design as an instructed port of the reference's contract. A primarily machine-generated copy of a copyrighted work, not accompanied by demonstrable substantial human creative input, is a derivative work over which the copier holds no copyright, and a reproduction of which without the original author's permission infringes the original author's copyright. This holds under any license, MIT included. The operator's copyright claim over the result is, on this evidence, not merely unsubstantiated; it is the absence of one, directly asserted in the project's own writing. - -**Layer B - license conditions (Reticulum License specific)** - -Modern Reticulum - the current wire format, the AES-256-based link encryption, ratchets, the cryptographic machinery as it exists today - has been published under the Reticulum License since April 15, 2025, effective from release 0.9.4 and every release since. As a derivative of that work, the license's conditions attach: The copyright and permission notice must be included in all copies and substantial portions; the AI-training condition must be honoured; the harm condition must be honoured. The record shows none of the notice requirements met, and a production process that consists of the licensed work being ingested into a machine and regurgitated, at industrial scale and cadence. - -**The cascading consequence** - -Prns is distributed claiming dual MIT/Apache-2.0 licensing. It is, however, a direct derivative of Reticulum-licensed work, and the claimed grant is therefore void. Every downstream project that builds on Prns believing it is MIT/Apache-licensed is building on a grant that does not exist. The users of Prns, and all software developers using it, have in effect, been placed under conditions they were never told about. The "ground-up" claim is not merely false; it is the sole load-bearing element of an entire licensing posture, and it fails spectacularly. - -.. _brandolinis-prns-consequences: - -Consequences -^^^^^^^^^^^^ - -The consequences of this pattern are examined in the following sections - the harm to users and to the network in :ref:`A Movement Of A Dozen`, and the human dimension in :ref:`Network Health & Coexistence`. This section's contribution is narrower and intended as an instructive example: This is what a substitution project looks like, in full, on its own record. It is a reference example for :ref:`Evaluating A Reticulum Implementation`, and it demonstrates, in one case, most of the elements this chapter describes. - -.. _brandolinis-prns-verdict: - -Verdict -^^^^^^^ - -Applying the three verdicts of :ref:`Evaluating A Reticulum Implementation`, this project does not meet the standard. It is not "experimental but honest" - it is not labeled as experimental anywhere; the first thing users saw was a polished marketing presence promising a finished, tested, drop-in replacement. It is a project whose central claims are fabricated (the performance apparatus), whose provenance is laundered (the authorship machinery), whose foundation is misrepresented (the "ground-up" story), whose core semantics were learned late and by regeneration, and whose operator cannot possibly answer for any of it. It is also a blatant copyright violation of the reference implementation. - -The proposed conclusion, for users and for the network: Treat the Prns project as hostile regardless of its polished surface, and as a hazard insofar as it invites users onto shared networks. Nothing in this section is a judgment about the people involved; it is a reading of the results produced, their history and how they came to be, which in the regrettable lack of any human authorship is the only thing that can be expected to be held to account. - -.. _brandolinis-prns-dating: - -Dating -^^^^^^ - -This examination reflects the publicly available material as of September 2026; the repository in question continued to receive commits at the time of writing, so readers should treat citations to commits and files as point-in-time evidence. A `forensics snapshot `_ is publicly available on GitHub. - .. _brandolinis-movement-of-a-dozen: The Movement Of A Dozen @@ -1322,4 +1065,261 @@ A lot of us rely on these networks every day. They carry our messages, our coord They are valuable, free, and very hard to shut down. The response is not to become aggressive. It is to be *more* of what the network already is: Real, open, owned, and shared. -*Mark* \ No newline at end of file +*Mark* + +.. _brandolinis-prns: + +Addendum A: The Prns Case +------------------------- + +.. _brandolinis-purpose-and-scope: + +Purpose & Scope +^^^^^^^^^^^^^^^ + +This section provides a concrete example, which future evaluations can use as a template. Its purpose is not to be the last word on this particular subject, but to be an example of how the ideas in this chapter can be applied, and to make the next such examination easier. + +The subject of this case study is **Prns**\ , a project published at the repository ``github.com/KenAKAFrosty/Prns``\ , presented as a "ground-up implementation of Reticulum, written in Rust", marketed as faster, safer, and more strictly tested than the reference, and widely promoted with the claim of "up to 89× the throughput" of the reference implementation. The record described below is the project's own, and sourced from its GitHub repository, analyzed locally. + +.. _brandolinis-project-in-brief: + +The Project In Brief +^^^^^^^^^^^^^^^^^^^^ + +* **Time span.** 3,374 commits between 2026-05-26 and 2026-09-12: approximately 110 days, + at a mean rate of ~31 commits per day. Monthly: 132 / 1,137 / 1,097 / 805 / 203. +* **Authorship.** 3,252 of 3,374 commits (96.4%) are authored by a single account. A + second identity, "Prns Tests tests@example.test" - a fictitious identity on a reserved + domain - contributed 35 commits, every one of them website and marketing content. +* **Size.** 3,519 tracked files; 1,983 Rust files; 636,226 lines of Rust; approximately + 22.7 MB of Rust source; 69.5 MB of total repository content. +* **Scope claimed.** A daemon ("drop-in replacement" for the reference daemon), embedded + firmware for three microcontroller families (including six ESP32-S3 board variants and + nRF52840), SDKs and bindings for nine languages, a browser-based node and web flasher, a + twelve-language website, a benchmark apparatus with its own publication and "proof" + pipeline, and a validation hub with oracles, fuzzing, mutation testing, and formal-proof + claims. +* **Marketing claims.** "Ground-up implementation of Reticulum"; "up to 89× the + throughput"; "48× smaller peak-memory footprint"; "33× the energy efficiency"; + "Measured, not just claimed"; "Enforced, then audited"; "byte-for-byte wire parity with + the reference implementation"; "works with Sideband, NomadNet, MeshChat, etc."; + "no_std (no alloc required either)". +* **Status at the time of writing.** Version 0.3.7; published version history begins at + 0.3.0. The repository continues to receive commits. + +.. _brandolinis-prns-question-1: + +Question 1: Is this a clean implementation, or was it directly generated from the reference? +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The first of the two deciding questions from :ref:`Evaluating A Reticulum Implementation` is settled by the project's own record. An actual :ref:`clean-room` implementation, reasoned out and written by humans, would owe nothing to any license. The data available shows clearly that Prns is not that. + +* **The founding state.** The first commit, "Scaffold Personal Reticulum suite", contains + the scaffolding of not one but two ports - ``personal-rns`` and ``personal-lxmf``\ , the latter + being the reference's companion messaging protocol - together with a daemon scaffold and + a 233-line founding document, ``docs/build-ethos.md``. That document declares the project's + goal as a "performance-focused drop-in-replacement for rnsd" and its governing principle + as: "Port the contract, not the implementation." It further states directly to the + machine-loop, that **"You owe the reference fidelity at exactly two boundaries: + The wire... The behavior. ... Between those two boundaries, the model is yours"**. + At this point, the very first commit, effectively the whole of the implementation design + and any relevant decisions are handed over to the LLM. +* **Continuous ingestion from the reference.** 506 commits reference RNS or Reticulum + source behaviour; the word "parity" appears in 49 commit messages. Commits cite the reference + implementation's own source locations (for example ``Transport.py:1367``) when correcting + their own divergences and mistakes. +* **Byte-level fidelity as an explicit goal.** Within 48 hours of the first commit, the + record shows a "crypto adapter - vetted primitives, byte-exact vs RNS 1.3.1", and a wire + implementation matching the reference's packet header layout. The project's own + validation apparatus decodes wire vectors using the reference implementation's own + packet parser, and the interop suite consists of real, stock-RNS peer nodes - that is, + the reference source itself, used as the ground truth against which this LLM output is + checked, and committed as accepted and verified after 48 hours of the project's recorded start. +* **The marketing mismatch.** The same record that documents all of the above describes the + project, publicly, as "a ground-up implementation of Reticulum" - while declining, on its + website, to link to the reference implementation at all: the entire tree mentions the + reference's author in six files, and the website in none. + +Conclusion: the project's own history and commit record establishes that it was generated directly from the reference implementation's source code, not reasoned out from the public-domain protocol. It is a derivative of licensed work within the meaning of :ref:`the Reticulum License` and :ref:`general copyright law`. The "ground-up" claim, which carries its entire legal and marketing posture, is disproven by the project's own history. + +.. _brandolinis-prns-question-2: + +Question 2: Who, or what, is the agent of the work? +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The second deciding question is answered by the application of :ref:`Assistance Versus Machine Substitution` criteria to the project. + +**Scope that no human could have authored** + +636,226 lines of Rust in 110 days is approximately 5,800 lines per day, every day, including weekends - with 149 commits recorded between midnight and 06:00, and Saturday the single busiest weekday. No human review or decision capacity is commensurable with this volume; the review capacity and the output volume are structurally incommensurable, which is the definition of unauthored scope. + +**Uniform generation** + +The record shows no sign of human development, growth, or learning: No contested decisions, no style drift. Instead: endless renaming (in the first 48 hours: ``State → EngineState → TickInput → TickOutput``\ ), uniform fluent register in every commit, and the exact same, synthetic voice in code, documentation, and website copy. + +**Discovery by regeneration** + +Corrections arrived by the machine's own subsequent runs, recorded as planned milestones. In early July 2026, a series of "core review" commits documented, in the project's own words: + +* announce-ID history "was unbounded per-slot growth" (\ ``54cc8d601``\ ); +* interface announce limiting could "leak a sustained flood" (\ ``9d27af75c``\ ); +* a "phantom-airtime leak" where frames "used to vanish silently" (\ ``4ed75ffdd``\ ); +* Group-packet deduplication "which RNS does not do" - a behaviour the reference never had, + implemented and later removed (\ ``edd8e72be``\ ); +* "both ``unwrap_or(&[])`` arms were unreachable dead defaults" (\ ``74bea355e``\ ); +* a benchmark crate "hasn't compiled since" a prior rename, undetected for weeks because it + was outside the CI's workspace (\ ``86240b027``\ ). + +Earlier still: the record shows a ">1 MiB RNS-to-Prns interop stall" closed three weeks in +(\ ``cc4d524a3``\ ), and a known send-path hang shipped with the note "typed fast-fail a +candidate for later" (\ ``a010e6613``\ ). + +**Laundered provenance** + +The repository contains a committed commit-message hook (\ ``.githooks/commit-msg``\ ) that *blocks* any commit containing attribution for machine generation ("generated with claude/codex/copilot/cursor/gemini", "co-authored-by"), with the explanation "The committer owns the commit". The contributing guide is explicit: "AI tools ... are welcome ... what you submit is *yours*", and describes the contributing population as "both human and automated contributors". The fictitious "Prns Tests" identity completes the picture: A manufactured, unknowable contributor, used for marketing content. + +**Authorship by assignment** + +The human whose name is on the work cannot answer for it, because the choices were never made by a human, and only the general shape and constraints of the outward presentation was. Nothing in the project's history shows an individual explaining a design decision, accepting a mistake in the first person, or going deeper under technical questioning; the record shows process language and marketing instead. Per the earlier mentioned test: any other person could have pressed the same button, and nothing would be different. The project is effectively unowned, and void of value. + +By the criteria of :ref:`Assistance Versus Machine Substitution`, this is substitution. The machine was the agent of the work; the "author" was a facade. + +.. _brandolinis-prns-performance: + +The performance claims +^^^^^^^^^^^^^^^^^^^^^^ + +The project's central marketing claim - "up to 89× the throughput" of the reference - is also its most completely documented failure, because the project published the evidence of its own measurement. The apparatus, the results, and the problems are all on the record. + +**The claim** + +The README states "up to 89× the throughput"; 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"; the website's front page carries the tagline "Measured, not just claimed". + +**The apparatus** + +The reference is loaded through ``benchmarks/reference/compiled_reference.py``\ , which installs ``pyximport`` and then asserts two things: that ``RNS.compiled == True``\ , and that at least *one* RNS module was loaded from a native extension. The project's own published "proof" records show exactly what those checks captured, on every platform: + +.. code-block:: + + aarch64-apple-darwin: .../RNS.cpython-313-darwin.so, Cython 3.2.8, Python 3.13.13 + x86_64-unknown-linux-gnu: .../RNS.cpython-313-x86_64-linux-gnu.so, gcc 11.4.0 + x86_64-pc-windows-msvc: ~/.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.so``\ , nothing below it. Nothing named ``RNS.Transport``\ , ``RNS.Destination``\ , ``RNS.Packet``\ , ``RNS.Link``\ , or ``RNS.Resource`` ever appears, because *nothing below the top level was ever compiled*. Nobody bothered to check or verify *anything* here. + +The machine output was simply taken for truth, and a full marketing strategy was spun and produced on it. "RNS 1.4.2 (compiled)" - the label used in every table, chart, and marketing page - *is not a mode of RNS that exists*, but the hallucinations of a machine, which the humans created a marketing strategy on. In reality, it is the old ``CRNS`` development shim, whose top-level-only, debug-oriented "compilation" is slower than plain interpreted RNS, and which was *defunct for over a year* before these benchmarks were published. + +**Interface choices** + +The harness writes the reference's configuration itself (\ ``benchmarks/reference/participant_node.py``\ ): ``TCPClientInterface`` for the initiator, ``TCPServerInterface`` for the responder and both relay sides, with ``UDPInterface`` as the abstract wire. The reference was never given its modern ``BackboneInterface`` on any platform, forcing the slowest possible interrfaces. The interface selection is never mentioned in any methodology text. + +**The policy** + +The published default-policy tables record the asymmetry directly: Prns at 500 Mbps / 128 KiB TCP policy against the reference at 10 Mbps / 8 KiB - slyly footnoted as "preserves each implementation's normal TCP policy" (in the case of RNS, a conservative default policy that was selected to prioritize coexistence on slower, shared links, requiring the user to dial it up to full speed if they knew what they were doing). Raw transport "throughput" ratios of 20.65× (Linux) and 38.84× (Windows) are therefore mostly policy, not engine. + +**The cross-host evidence** + +The published results show the same scenario producing wildly different ratios by host, and the variance is entirely in the reference artifact: + +.. list-table:: + :header-rows: 1 + + * - Host + - Prns, single-packet + - "Reference", single-packet + - Ratio + * - macOS (Apple M4) + - 37.4k/s + - 420/s + - 89.09× + * - Linux (i7-1260P) + - 25.3k/s + - 3.5k/s + - 7.19× + * - Windows (Ryzen 5 5600X) + - 30.8k/s + - 3.9k/s + - 8.00× + +Prns is consistent (25–37k/s). The reference artifact collapses to different depths on different hosts, and the single worst collapse - 420 packets per second on macOS - is the cell selected as the global headline. The "89×" is not a measure of Prns; it is a measure of how badly the broken baseline happened to fail on one host. + +For reality calibration: Stock, interpreted RNS 1.5.4 on an ordinary mid-range laptop, single core, sustains roughly 30,000 single-packet deliveries per second (including ephemeral-key decryption), ~175,000–280,000 packets per second in transit relay, and on the order of 10 Gbps at 16 KiB payloads. The project's "compiled" artifact measured 420–3,900 packets per second for its single-packet scenario: An order of magnitude or more *below* stock interpreted RNS. The comparison being marketed was not "Rust vs Python"; **it was "an implementation running under optimal conditions versus a mislabeled, broken shim on a slow legacy interface at a severe policy disadvantage"**. + +**The equalized rows** + +The project's own "1 Gbps policy" rows, in which both sides are explicitly configured identically, publish ratios of roughly 2.4–8.4× across all hosts and scenarios - still against the broken baseline, but nowhere near 89×, and consistent with the ordinary, uncontroversial observation that a native implementation tends to outperform an interpreted one in raw throughput. That point needed no fudging to make, and is banal. + +Interestingly, though, it seems that Prns is really only *marginally* faster than a Python implementation, running in interpreted mode, on a single CPU core. + +**Assessment** + +The front page says "Measured, not just claimed." The record shows the opposite ordering: claimed, and arranged to look measured. No methodology section anywhere states what "compiled" means, that it is a deprecated development shim, that it builds debug targets, or which interface the reference was given; the one statement of the policy asymmetry appears in a footnote of the results tables themselves. If they did not need to fudge it, they would have published the method clearly. + +.. _brandolinis-prns-overall: + +Overall Evaluation +^^^^^^^^^^^^^^^^^^ + +Evaluated against the conditions of :ref:`Evaluating A Reticulum Implementation`: + +* **Provenance and attribution.** Fails: The fake "ground-up" origin story; zero reference links + on the website; a single well-hidden link in the README; a license file reading + ``Copyright (c) 2026 The Prns Authors`` over work directly generated from the licensed reference; + no original copyright or permission notice anywhere. +* **Agency and answerability.** Fails on every criterion of :ref:`Assistance Versus Machine Substitution`: + Unauthored scope, uniform generation, discovery by regeneration, laundered provenance, + authorship by assignment. +* **Engineering.** Fails: The benchmark apparatus above; interop demonstrated only + against a pinned, outdated reference version over loopback while the marketing claims current + parity, interop failures with stock RNS; vendored prebuilt binaries and a republished fork + of an upstream crate (``nrf-softdevice 0.1.0-prns.1``) with no verifiable provenance; + committed WASM bundles. +* **Network behaviour.** Fails: Invented spectrum behaviour and compatibility claims + about third-party applications of the reference ecosystem (Sideband, NomadNet, MeshChat) + that are not established by any evidence. +* **Monetary and influence signals.** The marketing apparatus - website before protocol, + day-three twelve-language marketing, false benchmark headlines, "audited" and "formal proof" + claims - the conformal surface described in :ref:`Evaluating A Reticulum Implementation`: + is where this project invested. + +.. _brandolinis-prns-licensing: + +Licensing Analysis +^^^^^^^^^^^^^^^^^^ + +Applying the two legal layers established in :ref:`Copyright & The Two Legal Layers`: + +**Layer A - copyright infringement (license-independent)** + +The record shows a direct copy roundtrip: the licensed reference implementation fed into a machine, transformed, at a scale and cadence no human could review, with a license file asserting a fresh copyright in the operator's name and no acknowledgment of the work the project was generated from. No substantial, new human creative input is demonstrated anywhere in the record - the founding document explicitly frames the design as an instructed port of the reference's contract. A primarily machine-generated copy of a copyrighted work, not accompanied by demonstrable substantial human creative input, is a derivative work over which the copier holds no copyright, and a reproduction of which without the original author's permission infringes the original author's copyright. This holds under any license, MIT included. The operator's copyright claim over the result is, on this evidence, not merely unsubstantiated; it is the absence of one, directly asserted in the project's own writing. + +**Layer B - license conditions (Reticulum License specific)** + +Modern Reticulum - the current wire format, the AES-256-based link encryption, ratchets, the cryptographic machinery as it exists today - has been published under the Reticulum License since April 15, 2025, effective from release 0.9.4 and every release since. As a derivative of that work, the license's conditions attach: The copyright and permission notice must be included in all copies and substantial portions; the AI-training condition must be honoured; the harm condition must be honoured. The record shows none of the notice requirements met, and a production process that consists of the licensed work being ingested into a machine and regurgitated, at industrial scale and cadence. + +**The cascading consequence** + +Prns is distributed claiming dual MIT/Apache-2.0 licensing. It is, however, a direct derivative of Reticulum-licensed work, and the claimed grant is therefore void. Every downstream project that builds on Prns believing it is MIT/Apache-licensed is building on a grant that does not exist. The users of Prns, and all software developers using it, have in effect, been placed under conditions they were never told about. The "ground-up" claim is not merely false; it is the sole load-bearing element of an entire licensing posture, and it fails spectacularly. + +.. _brandolinis-prns-consequences: + +Consequences +^^^^^^^^^^^^ + +The consequences of this pattern are examined in the following sections: The harm to users and to the network in :ref:`A Movement Of A Dozen`, and the human dimension in :ref:`Network Health & Coexistence`. The contribution of this addendum is narrower and intended as an instructive example: This is what a substitution project looks like, in full, on its own record. It is a reference example for :ref:`Evaluating A Reticulum Implementation`, and it demonstrates, in one case, most of the elements this chapter describes. + +.. _brandolinis-prns-verdict: + +Verdict +^^^^^^^ + +Applying the three verdicts of :ref:`Evaluating A Reticulum Implementation`, this project does not meet the standard. It is not "experimental but honest" - it is not labeled as experimental anywhere; the first thing users saw was a polished marketing presence promising a finished, tested, drop-in replacement. It is a project whose central claims are fabricated (the performance apparatus), whose provenance is laundered (the authorship machinery), whose foundation is misrepresented (the "ground-up" story), whose core semantics were learned late and by regeneration, and whose operator cannot possibly answer for any of it. It is also a blatant copyright violation of the reference implementation. + +The proposed conclusion, for users and for the network: Treat the Prns project as hostile regardless of its polished surface, and as a hazard insofar as it invites users onto shared networks. Nothing in this section is a judgment about the people involved; it is a reading of the results produced, their history and how they came to be, which in the regrettable lack of any human authorship is the only thing that can be expected to be held to account. + +.. _brandolinis-prns-dating: + +Dating +^^^^^^ + +This examination reflects the publicly available material as of September 2026; the repository in question continued to receive commits at the time of writing, so readers should treat citations to commits and files as point-in-time evidence. A `forensics snapshot `_ is publicly available on GitHub. diff --git a/docs/manual/brandolinis.html b/docs/manual/brandolinis.html index e64386d6..02c1bc33 100644 --- a/docs/manual/brandolinis.html +++ b/docs/manual/brandolinis.html @@ -791,203 +791,6 @@ time is better spent elsewhere.

The reference implementation has met this standard for years, and its users know what that looks like.

-
-

The Prns Case

-
-

Purpose & Scope

-

This section provides a concrete example, which future evaluations can use as a template. Its purpose is not to be the last word on this particular subject, but to be an example of how the ideas in this chapter can be applied, and to make the next such examination easier.

-

The subject of this case study is Prns, a project published at the repository github.com/KenAKAFrosty/Prns, presented as a “ground-up implementation of Reticulum, written in Rust”, marketed as faster, safer, and more strictly tested than the reference, and widely promoted with the claim of “up to 89× the throughput” of the reference implementation. The record described below is the project’s own, and sourced from its GitHub repository, analyzed locally.

-
-
-

The Project In Brief

-
    -

  • Time span. 3,374 commits between 2026-05-26 and 2026-09-12: approximately 110 days, -at a mean rate of ~31 commits per day. Monthly: 132 / 1,137 / 1,097 / 805 / 203.

    • -

  • Authorship. 3,252 of 3,374 commits (96.4%) are authored by a single account. A -second identity, “Prns Tests tests@example.test” - a fictitious identity on a reserved -domain - contributed 35 commits, every one of them website and marketing content.

    • -

  • Size. 3,519 tracked files; 1,983 Rust files; 636,226 lines of Rust; approximately -22.7 MB of Rust source; 69.5 MB of total repository content.

    • -

  • Scope claimed. A daemon (“drop-in replacement” for the reference daemon), embedded -firmware for three microcontroller families (including six ESP32-S3 board variants and -nRF52840), SDKs and bindings for nine languages, a browser-based node and web flasher, a -twelve-language website, a benchmark apparatus with its own publication and “proof” -pipeline, and a validation hub with oracles, fuzzing, mutation testing, and formal-proof -claims.

    • -

  • Marketing claims. “Ground-up implementation of Reticulum”; “up to 89× the -throughput”; “48× smaller peak-memory footprint”; “33× the energy efficiency”; -“Measured, not just claimed”; “Enforced, then audited”; “byte-for-byte wire parity with -the reference implementation”; “works with Sideband, NomadNet, MeshChat, etc.”; -“no_std (no alloc required either)”.

    • -

  • Status at the time of writing. Version 0.3.7; published version history begins at -0.3.0. The repository continues to receive commits.

    • -
-
-
-

Question 1: Is this a clean implementation, or was it directly generated from the reference?

-

The first of the two deciding questions from Evaluating A Reticulum Implementation is settled by the project’s own record. An actual clean-room implementation, reasoned out and written by humans, would owe nothing to any license. The data available shows clearly that Prns is not that.

-
    -

  • The founding state. The first commit, “Scaffold Personal Reticulum suite”, contains -the scaffolding of not one but two ports - personal-rns and personal-lxmf, the latter -being the reference’s companion messaging protocol - together with a daemon scaffold and -a 233-line founding document, docs/build-ethos.md. That document declares the project’s -goal as a “performance-focused drop-in-replacement for rnsd” and its governing principle -as: “Port the contract, not the implementation.” It further states directly to the -machine-loop, that “You owe the reference fidelity at exactly two boundaries: -The wire… The behavior. … Between those two boundaries, the model is yours”. -At this point, the very first commit, effectively the whole of the implementation design -and any relevant decisions are handed over to the LLM.

    • -

  • Continuous ingestion from the reference. 506 commits reference RNS or Reticulum -source behaviour; the word “parity” appears in 49 commit messages. Commits cite the reference -implementation’s own source locations (for example Transport.py:1367) when correcting -their own divergences and mistakes.

    • -

  • Byte-level fidelity as an explicit goal. Within 48 hours of the first commit, the -record shows a “crypto adapter - vetted primitives, byte-exact vs RNS 1.3.1”, and a wire -implementation matching the reference’s packet header layout. The project’s own -validation apparatus decodes wire vectors using the reference implementation’s own -packet parser, and the interop suite consists of real, stock-RNS peer nodes - that is, -the reference source itself, used as the ground truth against which this LLM output is -checked, and committed as accepted and verified after 48 hours of the project’s recorded start.

    • -

  • The marketing mismatch. The same record that documents all of the above describes the -project, publicly, as “a ground-up implementation of Reticulum” - while declining, on its -website, to link to the reference implementation at all: the entire tree mentions the -reference’s author in six files, and the website in none.

    • -
-

Conclusion: the project’s own history and commit record establishes that it was generated directly from the reference implementation’s source code, not reasoned out from the public-domain protocol. It is a derivative of licensed work within the meaning of the Reticulum License and general copyright law. The “ground-up” claim, which carries its entire legal and marketing posture, is disproven by the project’s own history.

-
-
-

Question 2: Who, or what, is the agent of the work?

-

The second deciding question is answered by the application of Assistance Versus Machine Substitution criteria to the project.

-

Scope that no human could have authored

-

636,226 lines of Rust in 110 days is approximately 5,800 lines per day, every day, including weekends - with 149 commits recorded between midnight and 06:00, and Saturday the single busiest weekday. No human review or decision capacity is commensurable with this volume; the review capacity and the output volume are structurally incommensurable, which is the definition of unauthored scope.

-

Uniform generation

-

The record shows no sign of human development, growth, or learning: No contested decisions, no style drift. Instead: endless renaming (in the first 48 hours: State → EngineState → TickInput → TickOutput), uniform fluent register in every commit, and the exact same, synthetic voice in code, documentation, and website copy.

-

Discovery by regeneration

-

Corrections arrived by the machine’s own subsequent runs, recorded as planned milestones. In early July 2026, a series of “core review” commits documented, in the project’s own words:

-
    -

  • announce-ID history “was unbounded per-slot growth” (54cc8d601);

    • -

  • interface announce limiting could “leak a sustained flood” (9d27af75c);

    • -

  • a “phantom-airtime leak” where frames “used to vanish silently” (4ed75ffdd);

    • -

  • Group-packet deduplication “which RNS does not do” - a behaviour the reference never had, -implemented and later removed (edd8e72be);

    • -

  • “both unwrap_or(&[]) arms were unreachable dead defaults” (74bea355e);

    • -

  • a benchmark crate “hasn’t compiled since” a prior rename, undetected for weeks because it -was outside the CI’s workspace (86240b027).

    • -
-

Earlier still: the record shows a “>1 MiB RNS-to-Prns interop stall” closed three weeks in -(cc4d524a3), and a known send-path hang shipped with the note “typed fast-fail a -candidate for later” (a010e6613).

-

Laundered provenance

-

The repository contains a committed commit-message hook (.githooks/commit-msg) that blocks any commit containing attribution for machine generation (“generated with claude/codex/copilot/cursor/gemini”, “co-authored-by”), with the explanation “The committer owns the commit”. The contributing guide is explicit: “AI tools … are welcome … what you submit is yours”, and describes the contributing population as “both human and automated contributors”. The fictitious “Prns Tests” identity completes the picture: A manufactured, unknowable contributor, used for marketing content.

-

Authorship by assignment

-

The human whose name is on the work cannot answer for it, because the choices were never made by a human, and only the general shape and constraints of the outward presentation was. Nothing in the project’s history shows an individual explaining a design decision, accepting a mistake in the first person, or going deeper under technical questioning; the record shows process language and marketing instead. Per the earlier mentioned test: any other person could have pressed the same button, and nothing would be different. The project is effectively unowned, and void of value.

-

By the criteria of Assistance Versus Machine Substitution, this is substitution. The machine was the agent of the work; the “author” was a facade.

-
-
-

The performance claims

-

The project’s central marketing claim - “up to 89× the throughput” of the reference - is also its most completely documented failure, because the project published the evidence of its own measurement. The apparatus, the results, and the problems are all on the record.

-

The claim

-

The README states “up to 89× the throughput”; 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”; the website’s front page carries the tagline “Measured, not just claimed”.

-

The apparatus

-

The reference is loaded through benchmarks/reference/compiled_reference.py, which installs pyximport and then asserts two things: that RNS.compiled == True, and that at least one RNS module was loaded from a native extension. The project’s own published “proof” records show exactly what those checks captured, on every platform:

-
aarch64-apple-darwin: .../RNS.cpython-313-darwin.so,  Cython 3.2.8, Python 3.13.13
-x86_64-unknown-linux-gnu: .../RNS.cpython-313-x86_64-linux-gnu.so,  gcc 11.4.0
-x86_64-pc-windows-msvc: ~/.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.so, nothing below it. Nothing named RNS.Transport, RNS.Destination, RNS.Packet, RNS.Link, or RNS.Resource ever appears, because nothing below the top level was ever compiled. Nobody bothered to check or verify anything here.

-

The machine output was simply taken for truth, and a full marketing strategy was spun and produced on it. “RNS 1.4.2 (compiled)” - the label used in every table, chart, and marketing page - is not a mode of RNS that exists, but the hallucinations of a machine, which the humans created a marketing strategy on. In reality, it is the old CRNS development shim, whose top-level-only, debug-oriented “compilation” is slower than plain interpreted RNS, and which was defunct for over a year before these benchmarks were published.

-

Interface choices

-

The harness writes the reference’s configuration itself (benchmarks/reference/participant_node.py): TCPClientInterface for the initiator, TCPServerInterface for the responder and both relay sides, with UDPInterface as the abstract wire. The reference was never given its modern BackboneInterface on any platform, forcing the slowest possible interrfaces. The interface selection is never mentioned in any methodology text.

-

The policy

-

The published default-policy tables record the asymmetry directly: Prns at 500 Mbps / 128 KiB TCP policy against the reference at 10 Mbps / 8 KiB - slyly footnoted as “preserves each implementation’s normal TCP policy” (in the case of RNS, a conservative default policy that was selected to prioritize coexistence on slower, shared links, requiring the user to dial it up to full speed if they knew what they were doing). Raw transport “throughput” ratios of 20.65× (Linux) and 38.84× (Windows) are therefore mostly policy, not engine.

-

The cross-host evidence

-

The published results show the same scenario producing wildly different ratios by host, and the variance is entirely in the reference artifact:

-
- - - - - - - - - - - - - - - - - - - - - - - - - -

Host

Prns, single-packet

“Reference”, single-packet

Ratio

macOS (Apple M4)

37.4k/s

420/s

89.09×

Linux (i7-1260P)

25.3k/s

3.5k/s

7.19×

Windows (Ryzen 5 5600X)

30.8k/s

3.9k/s

8.00×

-
-

Prns is consistent (25–37k/s). The reference artifact collapses to different depths on different hosts, and the single worst collapse - 420 packets per second on macOS - is the cell selected as the global headline. The “89×” is not a measure of Prns; it is a measure of how badly the broken baseline happened to fail on one host.

-

For reality calibration: Stock, interpreted RNS 1.5.4 on an ordinary mid-range laptop, single core, sustains roughly 30,000 single-packet deliveries per second (including ephemeral-key decryption), ~175,000–280,000 packets per second in transit relay, and on the order of 10 Gbps at 16 KiB payloads. The project’s “compiled” artifact measured 420–3,900 packets per second for its single-packet scenario: An order of magnitude or more below stock interpreted RNS. The comparison being marketed was not “Rust vs Python”; it was “an implementation running under optimal conditions versus a mislabeled, broken shim on a slow legacy interface at a severe policy disadvantage”.

-

The equalized rows

-

The project’s own “1 Gbps policy” rows, in which both sides are explicitly configured identically, publish ratios of roughly 2.4–8.4× across all hosts and scenarios - still against the broken baseline, but nowhere near 89×, and consistent with the ordinary, uncontroversial observation that a native implementation tends to outperform an interpreted one in raw throughput. That point needed no fudging to make, and is banal.

-

Interestingly, though, it seems that Prns is really only marginally faster than a Python implementation, running in interpreted mode, on a single CPU core.

-

Assessment

-

The front page says “Measured, not just claimed.” The record shows the opposite ordering: claimed, and arranged to look measured. No methodology section anywhere states what “compiled” means, that it is a deprecated development shim, that it builds debug targets, or which interface the reference was given; the one statement of the policy asymmetry appears in a footnote of the results tables themselves. If they did not need to fudge it, they would have published the method clearly.

-
-
-

Overall Evaluation

-

Evaluated against the conditions of Evaluating A Reticulum Implementation:

-
    -

  • Provenance and attribution. Fails: The fake “ground-up” origin story; zero reference links -on the website; a single well-hidden link in the README; a license file reading -Copyright (c) 2026 The Prns Authors over work directly generated from the licensed reference; -no original copyright or permission notice anywhere.

    • -

  • Agency and answerability. Fails on every criterion of Assistance Versus Machine Substitution: -Unauthored scope, uniform generation, discovery by regeneration, laundered provenance, -authorship by assignment.

    • -

  • Engineering. Fails: The benchmark apparatus above; interop demonstrated only -against a pinned, outdated reference version over loopback while the marketing claims current -parity, interop failures with stock RNS; vendored prebuilt binaries and a republished fork -of an upstream crate (nrf-softdevice 0.1.0-prns.1) with no verifiable provenance; -committed WASM bundles.

    • -

  • Network behaviour. Fails: Invented spectrum behaviour and compatibility claims -about third-party applications of the reference ecosystem (Sideband, NomadNet, MeshChat) -that are not established by any evidence.

    • -

  • Monetary and influence signals. The marketing apparatus - website before protocol, -day-three twelve-language marketing, false benchmark headlines, “audited” and “formal proof” -claims - the conformal surface described in Evaluating A Reticulum Implementation: -is where this project invested.

    • -
-
-
-

Licensing Analysis

-

Applying the two legal layers established in Copyright & The Two Legal Layers:

-

Layer A - copyright infringement (license-independent)

-

The record shows a direct copy roundtrip: the licensed reference implementation fed into a machine, transformed, at a scale and cadence no human could review, with a license file asserting a fresh copyright in the operator’s name and no acknowledgment of the work the project was generated from. No substantial, new human creative input is demonstrated anywhere in the record - the founding document explicitly frames the design as an instructed port of the reference’s contract. A primarily machine-generated copy of a copyrighted work, not accompanied by demonstrable substantial human creative input, is a derivative work over which the copier holds no copyright, and a reproduction of which without the original author’s permission infringes the original author’s copyright. This holds under any license, MIT included. The operator’s copyright claim over the result is, on this evidence, not merely unsubstantiated; it is the absence of one, directly asserted in the project’s own writing.

-

Layer B - license conditions (Reticulum License specific)

-

Modern Reticulum - the current wire format, the AES-256-based link encryption, ratchets, the cryptographic machinery as it exists today - has been published under the Reticulum License since April 15, 2025, effective from release 0.9.4 and every release since. As a derivative of that work, the license’s conditions attach: The copyright and permission notice must be included in all copies and substantial portions; the AI-training condition must be honoured; the harm condition must be honoured. The record shows none of the notice requirements met, and a production process that consists of the licensed work being ingested into a machine and regurgitated, at industrial scale and cadence.

-

The cascading consequence

-

Prns is distributed claiming dual MIT/Apache-2.0 licensing. It is, however, a direct derivative of Reticulum-licensed work, and the claimed grant is therefore void. Every downstream project that builds on Prns believing it is MIT/Apache-licensed is building on a grant that does not exist. The users of Prns, and all software developers using it, have in effect, been placed under conditions they were never told about. The “ground-up” claim is not merely false; it is the sole load-bearing element of an entire licensing posture, and it fails spectacularly.

-
-
-

Consequences

-

The consequences of this pattern are examined in the following sections - the harm to users and to the network in A Movement Of A Dozen, and the human dimension in Network Health & Coexistence. This section’s contribution is narrower and intended as an instructive example: This is what a substitution project looks like, in full, on its own record. It is a reference example for Evaluating A Reticulum Implementation, and it demonstrates, in one case, most of the elements this chapter describes.

-
-
-

Verdict

-

Applying the three verdicts of Evaluating A Reticulum Implementation, this project does not meet the standard. It is not “experimental but honest” - it is not labeled as experimental anywhere; the first thing users saw was a polished marketing presence promising a finished, tested, drop-in replacement. It is a project whose central claims are fabricated (the performance apparatus), whose provenance is laundered (the authorship machinery), whose foundation is misrepresented (the “ground-up” story), whose core semantics were learned late and by regeneration, and whose operator cannot possibly answer for any of it. It is also a blatant copyright violation of the reference implementation.

-

The proposed conclusion, for users and for the network: Treat the Prns project as hostile regardless of its polished surface, and as a hazard insofar as it invites users onto shared networks. Nothing in this section is a judgment about the people involved; it is a reading of the results produced, their history and how they came to be, which in the regrettable lack of any human authorship is the only thing that can be expected to be held to account.

-
-
-

Dating

-

This examination reflects the publicly available material as of September 2026; the repository in question continued to receive commits at the time of writing, so readers should treat citations to commits and files as point-in-time evidence. A forensics snapshot is publicly available on GitHub.

-
-

The Movement Of A Dozen

@@ -1239,6 +1042,203 @@ defended.

Mark

+
+

Addendum A: The Prns Case

+
+

Purpose & Scope

+

This section provides a concrete example, which future evaluations can use as a template. Its purpose is not to be the last word on this particular subject, but to be an example of how the ideas in this chapter can be applied, and to make the next such examination easier.

+

The subject of this case study is Prns, a project published at the repository github.com/KenAKAFrosty/Prns, presented as a “ground-up implementation of Reticulum, written in Rust”, marketed as faster, safer, and more strictly tested than the reference, and widely promoted with the claim of “up to 89× the throughput” of the reference implementation. The record described below is the project’s own, and sourced from its GitHub repository, analyzed locally.

+
+
+

The Project In Brief

+
    +

  • Time span. 3,374 commits between 2026-05-26 and 2026-09-12: approximately 110 days, +at a mean rate of ~31 commits per day. Monthly: 132 / 1,137 / 1,097 / 805 / 203.

    • +

  • Authorship. 3,252 of 3,374 commits (96.4%) are authored by a single account. A +second identity, “Prns Tests tests@example.test” - a fictitious identity on a reserved +domain - contributed 35 commits, every one of them website and marketing content.

    • +

  • Size. 3,519 tracked files; 1,983 Rust files; 636,226 lines of Rust; approximately +22.7 MB of Rust source; 69.5 MB of total repository content.

    • +

  • Scope claimed. A daemon (“drop-in replacement” for the reference daemon), embedded +firmware for three microcontroller families (including six ESP32-S3 board variants and +nRF52840), SDKs and bindings for nine languages, a browser-based node and web flasher, a +twelve-language website, a benchmark apparatus with its own publication and “proof” +pipeline, and a validation hub with oracles, fuzzing, mutation testing, and formal-proof +claims.

    • +

  • Marketing claims. “Ground-up implementation of Reticulum”; “up to 89× the +throughput”; “48× smaller peak-memory footprint”; “33× the energy efficiency”; +“Measured, not just claimed”; “Enforced, then audited”; “byte-for-byte wire parity with +the reference implementation”; “works with Sideband, NomadNet, MeshChat, etc.”; +“no_std (no alloc required either)”.

    • +

  • Status at the time of writing. Version 0.3.7; published version history begins at +0.3.0. The repository continues to receive commits.

    • +
+
+
+

Question 1: Is this a clean implementation, or was it directly generated from the reference?

+

The first of the two deciding questions from Evaluating A Reticulum Implementation is settled by the project’s own record. An actual clean-room implementation, reasoned out and written by humans, would owe nothing to any license. The data available shows clearly that Prns is not that.

+
    +

  • The founding state. The first commit, “Scaffold Personal Reticulum suite”, contains +the scaffolding of not one but two ports - personal-rns and personal-lxmf, the latter +being the reference’s companion messaging protocol - together with a daemon scaffold and +a 233-line founding document, docs/build-ethos.md. That document declares the project’s +goal as a “performance-focused drop-in-replacement for rnsd” and its governing principle +as: “Port the contract, not the implementation.” It further states directly to the +machine-loop, that “You owe the reference fidelity at exactly two boundaries: +The wire… The behavior. … Between those two boundaries, the model is yours”. +At this point, the very first commit, effectively the whole of the implementation design +and any relevant decisions are handed over to the LLM.

    • +

  • Continuous ingestion from the reference. 506 commits reference RNS or Reticulum +source behaviour; the word “parity” appears in 49 commit messages. Commits cite the reference +implementation’s own source locations (for example Transport.py:1367) when correcting +their own divergences and mistakes.

    • +

  • Byte-level fidelity as an explicit goal. Within 48 hours of the first commit, the +record shows a “crypto adapter - vetted primitives, byte-exact vs RNS 1.3.1”, and a wire +implementation matching the reference’s packet header layout. The project’s own +validation apparatus decodes wire vectors using the reference implementation’s own +packet parser, and the interop suite consists of real, stock-RNS peer nodes - that is, +the reference source itself, used as the ground truth against which this LLM output is +checked, and committed as accepted and verified after 48 hours of the project’s recorded start.

    • +

  • The marketing mismatch. The same record that documents all of the above describes the +project, publicly, as “a ground-up implementation of Reticulum” - while declining, on its +website, to link to the reference implementation at all: the entire tree mentions the +reference’s author in six files, and the website in none.

    • +
+

Conclusion: the project’s own history and commit record establishes that it was generated directly from the reference implementation’s source code, not reasoned out from the public-domain protocol. It is a derivative of licensed work within the meaning of the Reticulum License and general copyright law. The “ground-up” claim, which carries its entire legal and marketing posture, is disproven by the project’s own history.

+
+
+

Question 2: Who, or what, is the agent of the work?

+

The second deciding question is answered by the application of Assistance Versus Machine Substitution criteria to the project.

+

Scope that no human could have authored

+

636,226 lines of Rust in 110 days is approximately 5,800 lines per day, every day, including weekends - with 149 commits recorded between midnight and 06:00, and Saturday the single busiest weekday. No human review or decision capacity is commensurable with this volume; the review capacity and the output volume are structurally incommensurable, which is the definition of unauthored scope.

+

Uniform generation

+

The record shows no sign of human development, growth, or learning: No contested decisions, no style drift. Instead: endless renaming (in the first 48 hours: State → EngineState → TickInput → TickOutput), uniform fluent register in every commit, and the exact same, synthetic voice in code, documentation, and website copy.

+

Discovery by regeneration

+

Corrections arrived by the machine’s own subsequent runs, recorded as planned milestones. In early July 2026, a series of “core review” commits documented, in the project’s own words:

+
    +

  • announce-ID history “was unbounded per-slot growth” (54cc8d601);

    • +

  • interface announce limiting could “leak a sustained flood” (9d27af75c);

    • +

  • a “phantom-airtime leak” where frames “used to vanish silently” (4ed75ffdd);

    • +

  • Group-packet deduplication “which RNS does not do” - a behaviour the reference never had, +implemented and later removed (edd8e72be);

    • +

  • “both unwrap_or(&[]) arms were unreachable dead defaults” (74bea355e);

    • +

  • a benchmark crate “hasn’t compiled since” a prior rename, undetected for weeks because it +was outside the CI’s workspace (86240b027).

    • +
+

Earlier still: the record shows a “>1 MiB RNS-to-Prns interop stall” closed three weeks in +(cc4d524a3), and a known send-path hang shipped with the note “typed fast-fail a +candidate for later” (a010e6613).

+

Laundered provenance

+

The repository contains a committed commit-message hook (.githooks/commit-msg) that blocks any commit containing attribution for machine generation (“generated with claude/codex/copilot/cursor/gemini”, “co-authored-by”), with the explanation “The committer owns the commit”. The contributing guide is explicit: “AI tools … are welcome … what you submit is yours”, and describes the contributing population as “both human and automated contributors”. The fictitious “Prns Tests” identity completes the picture: A manufactured, unknowable contributor, used for marketing content.

+

Authorship by assignment

+

The human whose name is on the work cannot answer for it, because the choices were never made by a human, and only the general shape and constraints of the outward presentation was. Nothing in the project’s history shows an individual explaining a design decision, accepting a mistake in the first person, or going deeper under technical questioning; the record shows process language and marketing instead. Per the earlier mentioned test: any other person could have pressed the same button, and nothing would be different. The project is effectively unowned, and void of value.

+

By the criteria of Assistance Versus Machine Substitution, this is substitution. The machine was the agent of the work; the “author” was a facade.

+
+
+

The performance claims

+

The project’s central marketing claim - “up to 89× the throughput” of the reference - is also its most completely documented failure, because the project published the evidence of its own measurement. The apparatus, the results, and the problems are all on the record.

+

The claim

+

The README states “up to 89× the throughput”; 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”; the website’s front page carries the tagline “Measured, not just claimed”.

+

The apparatus

+

The reference is loaded through benchmarks/reference/compiled_reference.py, which installs pyximport and then asserts two things: that RNS.compiled == True, and that at least one RNS module was loaded from a native extension. The project’s own published “proof” records show exactly what those checks captured, on every platform:

+
aarch64-apple-darwin: .../RNS.cpython-313-darwin.so,  Cython 3.2.8, Python 3.13.13
+x86_64-unknown-linux-gnu: .../RNS.cpython-313-x86_64-linux-gnu.so,  gcc 11.4.0
+x86_64-pc-windows-msvc: ~/.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.so, nothing below it. Nothing named RNS.Transport, RNS.Destination, RNS.Packet, RNS.Link, or RNS.Resource ever appears, because nothing below the top level was ever compiled. Nobody bothered to check or verify anything here.

+

The machine output was simply taken for truth, and a full marketing strategy was spun and produced on it. “RNS 1.4.2 (compiled)” - the label used in every table, chart, and marketing page - is not a mode of RNS that exists, but the hallucinations of a machine, which the humans created a marketing strategy on. In reality, it is the old CRNS development shim, whose top-level-only, debug-oriented “compilation” is slower than plain interpreted RNS, and which was defunct for over a year before these benchmarks were published.

+

Interface choices

+

The harness writes the reference’s configuration itself (benchmarks/reference/participant_node.py): TCPClientInterface for the initiator, TCPServerInterface for the responder and both relay sides, with UDPInterface as the abstract wire. The reference was never given its modern BackboneInterface on any platform, forcing the slowest possible interrfaces. The interface selection is never mentioned in any methodology text.

+

The policy

+

The published default-policy tables record the asymmetry directly: Prns at 500 Mbps / 128 KiB TCP policy against the reference at 10 Mbps / 8 KiB - slyly footnoted as “preserves each implementation’s normal TCP policy” (in the case of RNS, a conservative default policy that was selected to prioritize coexistence on slower, shared links, requiring the user to dial it up to full speed if they knew what they were doing). Raw transport “throughput” ratios of 20.65× (Linux) and 38.84× (Windows) are therefore mostly policy, not engine.

+

The cross-host evidence

+

The published results show the same scenario producing wildly different ratios by host, and the variance is entirely in the reference artifact:

+
+ + + + + + + + + + + + + + + + + + + + + + + + + +

Host

Prns, single-packet

“Reference”, single-packet

Ratio

macOS (Apple M4)

37.4k/s

420/s

89.09×

Linux (i7-1260P)

25.3k/s

3.5k/s

7.19×

Windows (Ryzen 5 5600X)

30.8k/s

3.9k/s

8.00×

+
+

Prns is consistent (25–37k/s). The reference artifact collapses to different depths on different hosts, and the single worst collapse - 420 packets per second on macOS - is the cell selected as the global headline. The “89×” is not a measure of Prns; it is a measure of how badly the broken baseline happened to fail on one host.

+

For reality calibration: Stock, interpreted RNS 1.5.4 on an ordinary mid-range laptop, single core, sustains roughly 30,000 single-packet deliveries per second (including ephemeral-key decryption), ~175,000–280,000 packets per second in transit relay, and on the order of 10 Gbps at 16 KiB payloads. The project’s “compiled” artifact measured 420–3,900 packets per second for its single-packet scenario: An order of magnitude or more below stock interpreted RNS. The comparison being marketed was not “Rust vs Python”; it was “an implementation running under optimal conditions versus a mislabeled, broken shim on a slow legacy interface at a severe policy disadvantage”.

+

The equalized rows

+

The project’s own “1 Gbps policy” rows, in which both sides are explicitly configured identically, publish ratios of roughly 2.4–8.4× across all hosts and scenarios - still against the broken baseline, but nowhere near 89×, and consistent with the ordinary, uncontroversial observation that a native implementation tends to outperform an interpreted one in raw throughput. That point needed no fudging to make, and is banal.

+

Interestingly, though, it seems that Prns is really only marginally faster than a Python implementation, running in interpreted mode, on a single CPU core.

+

Assessment

+

The front page says “Measured, not just claimed.” The record shows the opposite ordering: claimed, and arranged to look measured. No methodology section anywhere states what “compiled” means, that it is a deprecated development shim, that it builds debug targets, or which interface the reference was given; the one statement of the policy asymmetry appears in a footnote of the results tables themselves. If they did not need to fudge it, they would have published the method clearly.

+
+
+

Overall Evaluation

+

Evaluated against the conditions of Evaluating A Reticulum Implementation:

+
    +

  • Provenance and attribution. Fails: The fake “ground-up” origin story; zero reference links +on the website; a single well-hidden link in the README; a license file reading +Copyright (c) 2026 The Prns Authors over work directly generated from the licensed reference; +no original copyright or permission notice anywhere.

    • +

  • Agency and answerability. Fails on every criterion of Assistance Versus Machine Substitution: +Unauthored scope, uniform generation, discovery by regeneration, laundered provenance, +authorship by assignment.

    • +

  • Engineering. Fails: The benchmark apparatus above; interop demonstrated only +against a pinned, outdated reference version over loopback while the marketing claims current +parity, interop failures with stock RNS; vendored prebuilt binaries and a republished fork +of an upstream crate (nrf-softdevice 0.1.0-prns.1) with no verifiable provenance; +committed WASM bundles.

    • +

  • Network behaviour. Fails: Invented spectrum behaviour and compatibility claims +about third-party applications of the reference ecosystem (Sideband, NomadNet, MeshChat) +that are not established by any evidence.

    • +

  • Monetary and influence signals. The marketing apparatus - website before protocol, +day-three twelve-language marketing, false benchmark headlines, “audited” and “formal proof” +claims - the conformal surface described in Evaluating A Reticulum Implementation: +is where this project invested.

    • +
+
+
+

Licensing Analysis

+

Applying the two legal layers established in Copyright & The Two Legal Layers:

+

Layer A - copyright infringement (license-independent)

+

The record shows a direct copy roundtrip: the licensed reference implementation fed into a machine, transformed, at a scale and cadence no human could review, with a license file asserting a fresh copyright in the operator’s name and no acknowledgment of the work the project was generated from. No substantial, new human creative input is demonstrated anywhere in the record - the founding document explicitly frames the design as an instructed port of the reference’s contract. A primarily machine-generated copy of a copyrighted work, not accompanied by demonstrable substantial human creative input, is a derivative work over which the copier holds no copyright, and a reproduction of which without the original author’s permission infringes the original author’s copyright. This holds under any license, MIT included. The operator’s copyright claim over the result is, on this evidence, not merely unsubstantiated; it is the absence of one, directly asserted in the project’s own writing.

+

Layer B - license conditions (Reticulum License specific)

+

Modern Reticulum - the current wire format, the AES-256-based link encryption, ratchets, the cryptographic machinery as it exists today - has been published under the Reticulum License since April 15, 2025, effective from release 0.9.4 and every release since. As a derivative of that work, the license’s conditions attach: The copyright and permission notice must be included in all copies and substantial portions; the AI-training condition must be honoured; the harm condition must be honoured. The record shows none of the notice requirements met, and a production process that consists of the licensed work being ingested into a machine and regurgitated, at industrial scale and cadence.

+

The cascading consequence

+

Prns is distributed claiming dual MIT/Apache-2.0 licensing. It is, however, a direct derivative of Reticulum-licensed work, and the claimed grant is therefore void. Every downstream project that builds on Prns believing it is MIT/Apache-licensed is building on a grant that does not exist. The users of Prns, and all software developers using it, have in effect, been placed under conditions they were never told about. The “ground-up” claim is not merely false; it is the sole load-bearing element of an entire licensing posture, and it fails spectacularly.

+
+
+

Consequences

+

The consequences of this pattern are examined in the following sections: The harm to users and to the network in A Movement Of A Dozen, and the human dimension in Network Health & Coexistence. The contribution of this addendum is narrower and intended as an instructive example: This is what a substitution project looks like, in full, on its own record. It is a reference example for Evaluating A Reticulum Implementation, and it demonstrates, in one case, most of the elements this chapter describes.

+
+
+

Verdict

+

Applying the three verdicts of Evaluating A Reticulum Implementation, this project does not meet the standard. It is not “experimental but honest” - it is not labeled as experimental anywhere; the first thing users saw was a polished marketing presence promising a finished, tested, drop-in replacement. It is a project whose central claims are fabricated (the performance apparatus), whose provenance is laundered (the authorship machinery), whose foundation is misrepresented (the “ground-up” story), whose core semantics were learned late and by regeneration, and whose operator cannot possibly answer for any of it. It is also a blatant copyright violation of the reference implementation.

+

The proposed conclusion, for users and for the network: Treat the Prns project as hostile regardless of its polished surface, and as a hazard insofar as it invites users onto shared networks. Nothing in this section is a judgment about the people involved; it is a reading of the results produced, their history and how they came to be, which in the regrettable lack of any human authorship is the only thing that can be expected to be held to account.

+
+
+

Dating

+

This examination reflects the publicly available material as of September 2026; the repository in question continued to receive commits at the time of writing, so readers should treat citations to commits and files as point-in-time evidence. A forensics snapshot is publicly available on GitHub.

+
+
@@ -1342,19 +1342,6 @@ defended.

  • These Standards Are Reasonable
    • -
  • The Prns Case -
  • The Movement Of A Dozen
    • +
  • Addendum A: The Prns Case +
    • diff --git a/docs/manual/index.html b/docs/manual/index.html index d3f98f04..40e1189e 100644 --- a/docs/manual/index.html +++ b/docs/manual/index.html @@ -672,19 +672,6 @@ to participate in the development of Reticulum itself.

  • These Standards Are Reasonable
    • -
  • The Prns Case -
  • The Movement Of A Dozen
    • +
  • Addendum A: The Prns Case +
    • diff --git a/docs/manual/objects.inv b/docs/manual/objects.inv index fea5f35a5ba763f660a965a2ea98b66b909e095d..06a4c18a23f378b6e55db2167a7f36154b6a6a92 100644 GIT binary patch delta 4564 zcmV;_5i9P%B*!F>oqsNM>5yf)tSDR7NOITITo@1uNm!Evn*i<7occ93V)o_wNj4Jz z!C#qx+=mW#k@^TWN_fsEnINUFaMv)4gflQ<4jDg-&u5FW+JMGapwp+1e18$0Hl3OYy z%LrPlg9S9Chkud7%{E2*MC<8xc0b>Sv#00f7O9Ao1>2R9x^<+&FP7W+`nT!B1r#KT zXf8#VuA+@khG}}2d|!3sgG16>Lc&6!htnktW{HI? zgK2*y$$v#0R1%iKP%d4sf*mp!%%ZU@MmE$+^m_KZ{%!8Kb6HToq2c}4%60JH=07%z ze|a}+Hrx+D!}&i~i}ep*^mhHcoK3g$+wgw6xqp~1zi#h+Iij+F*A0t`eWuiBtFsu7 z?Zsl0qure(75=b2OQ;{JOp?%bPq3&9_MkSl1b=rKT?8$_-@`z?yL`#U(*a-BX@FsR z<2^HwNP^$J0OGZuS*)*zyS`*hvVdrr;GW_=f8hBU49cm!2iTMyJTQuRd0z#XZ?@B$ zhsEapalYJ!+r{Jj>3JKj=IikOY2`!oZ9ZR39~OSCTaaz}ZaUjOt$jG!>KWcQluQG& z)_>8!nnsjqfA(&*q%Gax0p&f+!>{Y<%xl;hhC}v2p}&Bf*VSZ{d{oy&oG~{3OU?G; z*CZqZkOk`K#1Cm|AMWxz_H01{-uzA0gHPUrqGg-BIa+IJD`Bhh57M>J$B2o21}SO($|lhuiGCh z*A1bG%pFzO#FUvUYNgEAVK7?odcK^kf2=UIdAxmg9F2jl9;S=s1+Y#Jhc|H}HGhC~ zi~`!iEgt8+q9O0<@f#3FpKlPbP#o*;2H+>&)0&&S9=nv@4QUO)IxK}hR@cW8*wTuV zm)q&nNS0FAd_DyB>caVxLTAWz2-_@^VR%V<>U2z>Ykj2K)w$9~n7W6X&JaHZoJkHG z0oQh$^l!|RBKQFouecCim0VeTF@J%`c_!!w;mX)A@G*1K%Stc zU3ks(b<9KryHx>MiaM#;6K@K%(mgBiP><(6VMCjOW#9}Q59Qm)gukhMpz43PW74%I z(`HI(%*qsegFId~kh%|*Vt-GU&5O#$Q(4wLet1>&7RRtQ4}Ie9=LoJ%UY?Q+5-L?D zyO8GhlA(>&T6rZ&={ZB<$jc-SOW1N*nkOt`=AhD#MtRhn7hYr8Rv-u8Xl1Wg)9wA; zVtEVR?a|RW)Zl?8hn+($*rgzE1a$=F>@~)QQ}HSC)%eCek?O9E&wq)3O$1x}1>FZf zBtpskKpFk1JlJKZ+WYw7{~|qAv9Q0c%FKVVNzNwbnxv5NmxSyf-kY2it!ncwvT@_$ znTx#bvWqY}RVTreu(9T+t3|M`9%>K-T3C15VNJ}X66DebBVRpJZITq0?BNKcYt4e#sq-@nB>6}bN58Z zisPoq5X>43S37m!4F<=AVvBi%T#d(yB)G8;{`}*AMZ=;Rk`pkhEb8>C%Y-JW#o#&o zC*Ej5b}Z?1W&+y?(}C6m_F++qi70ol=49Dlb3<)dc<`Ho2Y-(wIaw$NvSl2Hhs-c%?5T2@FHKUl;CKg$gzr)#Vgu z(=bRe$+(>GoMx`P78yM4t8py344#l0?#H1Ie~gd8=Y04 z;BTt2?Hdms=zjqQ_Miw_EyQ44IPZK9jio8{b(H^BL#naNG_1`EA)PukYM9nIZv|=^ z)KdYyE;9@s;@~UIz<_(k1g+^13SLY|aVRk;b()*o1~Ql$WQ&_-2QXw>;9?$QoHt~_ z!S{1@%TpE_picZ0=AV zlxpPLTm?C>gn}<-Bp!Du!3r!Dqo7QF3T`0fy3_bzi})7vL0LsI$wBcE0|hxvy|$$! zSXHPN=MnbD2x6~sGrF%NyZA&N)vAp+{iz1xumqM=zVYG(NdXS)cUFVj{P2($CtS8~ zMbiS>yN z%m`Duu%H26T>GGnLkZEJlL0I$n092aCx1n3iyHDt3XMV&*kuWEy%Y6=hCvgWc&4!} z>V7ymK;{$)q_82v`r^fe%Ofo&tmP!er%oAy>VM}WG6i?M2%eCs<8IosiRT&k3YAVK zG5@#YcKB#;sP$=Zi?|kVrkB735_tyi#F6FB%cg;8ae`^=3rb_2j#52k;Axa-mjP>0 zCX^8_G}^{$%qKL5JHm<#a)LHFgaJdb?+|YtF__tEJZY0ETfnP;;FQOC)qHP^^cDgJ z&VOIf5?Y+OTGgNm6#}^$77bP!7c4{oVNaV95=|9-Wc1C+epU!T<5>dWJp;`-L=n40 zg|x7R$#EsD3<9HAg=q6Z1i~We8mg|W_@`hB(YI2@J){M&@5EhVQ4L{26P_LLTIG0e z8?aBoyux*;9c*4dz+|95c1=!!4yMrl@De(}X`Lqj`cB6_yLasK7k^j` zT(=I3;#0tcY6mk~8SuUO2m14Y_RLxyZOp9T4gvok7$k1yyMocZ<1$tt^xZcI>N2Vi zRndPzry&&M4$-Fx?qG7JNUuM2HObU>Wazf>N;4;GTGgT|-UhGXyD$Zt3JSR`bl<|;{8*!LvagMmG)gdWSG&KcSUsK-7T$6v)qmb;0AzP0 z@3AE=v#;asjP}r`Xzdi6YEf`Ok0kDeX)spn@5W~st1kbr(p%j9@f1FJ#SmCXwZXRe zRU+3Y#U&7e;YRmD-6E|ST;PmqapJ%w$`W`V-Jjk;!Ilfmw6 z^NDhCSb>UM0zTLqu*d5fadU!)EIL+g{Mu>Z)at&fB)AOWq_e@Q<8y_(vQ;+IRa3og zJl56g+lJgN1vBBfs;V^vCvp9}-JdR-E(;Fw(VqmvnTh>yzeQx;)_*~+k+QH|!ATqu zA>YT{RALr5cyiT+nG1L|s1%Z?^?Bg?U?r>y6#DLkrJ)hnz`NKvNLX?FsH?gw^gisa zA!*_E(}{PX3v)j|((!Nw?w_l5fq2c_ii2)gN=CH$sD&)3`lR7qkhx(e8bO9tXzLuN z1%&J+M$^}ito%UPrhhkkEg*#U$1<&)t!c?V)J;t@ti>k89C5<-Q+p5m!s8xggBywm zPFD~lL)b!pcF&{qQ%$(Q|Gny;Q8oK;<^(JFs-I)*fG>hOwEY8XV_78(&oL*eJB*^L z0u6sKn&~;_3ad1QVyfzZz88^w^)}?sv{q0^Zot3kpT0QX8h^f4BZKx}U~3H%Ee^hu z@AcqGy+#s9Fw{3GHO&zMtv6E8rlP86l}V*(nVE$mf_wAQA_qp_A}}f&q~Lf&ewe^g zEKWIWWnD*q{=o8HLm|k=Z(@Ua&2Uv4ni)^S#%dF-s&8O1(F;UQ83x7b=2nvEdaQF_ zRtb@q3{N&WjepRms0tcp+)FMgcF0~wYxSynTIo64vqP!QVH!@f7PET>X1blub;uf9 zN3cfo!dfom5G}S+@=+3$v7Kq5e}4Y^DEgn*AoOjq*$i{wZSo!OM#+7in@VnwMQ>7L z9R1y?K~df1>L)3EqT8nIFdh4xkFhL1uZBkhvyazYRe#|gCTxrc%ZbfjI8u}Sz`#MF zZ))(qFfnQ}=Vz+F#0NAyYQOmL=V&J^6cUcOjpzA55;N2hJQHjXJ!xE%DrfoVOs`O8 zP#s0a<5Bo}i9!#2P2M4yq-7$R8`Yx{9pn<=*U6}{Y_!xMgN*WM48NVNf?2{;4swP= zxNtx}aDP7>|W||lkesxh`yaN$TewtJ-baP;| zrE&}y%a~K4mfNqMnM*SzOVnYuElO1H2i9B*ihi*NZggj)pR1ER!XjyP*OpA1{cT@2 z>RcAnHXKzk%KJe;C8exc7_8ZG2d>F=@r#C}0e_E29;z)PEy^5kQ+0FJE@WfHZn&yK zVX+HRI2PGXmv}kueU@h>^2X$`5%&p73dnm~K>bWBccb600D2|(UUmbs>Y15B{DOm| z0@_k)t(!4o1Nvz(=;G@c4y}b&>-v%Ds(If-3^m#S)(UPw)lC^yF|4e}G}(Hg8-8xd zo`2yulV11fObN{fOOF&2WhPSaJ22@GHz#M9v5HO(19m&uh;3lifUQf+wc7MMB3QHs zQT-d9y(@f!>RvLFxGm`d}?qDO$Fk`7e=ShVhUsnkx)ZUkc zI^Z4Ws?xtZjp)+xUU7Sv1?4(eb1Roo7k`3<74ERS&{JhM`rD~-E|b`NqbF-T3ff`r zueL!pw^fsJi9b)|X3~#VxWi($snA1pg9J_8SJ~QG4WnPipHFpBt%|0$DBK~@cazn* zrgY%>&cHq2Dd`@OJi7E`P1TjtgE~BHEQl^$p(6TMr_s&u_rB1p=SQ%gm4)^=xqsvl zPlU-?oov!zf-2GNlG}QRoG`gE4V5} zcT*DeX4Kv_16VjepcBDH4PQei^;Ze?$48yMh5yf)tY}NtN^;lKTo@1uNthxDHUZkDIrVEy#O%xUlWZmc z{(z)RK<-0_yU6@L0Et8*GXZL|+TPxkhXXBw{QPs25Fvt}f`Y;Wnnm>XB-7--{yUi5 zY-+)t{Gfm{NaGS=dBJm9$g?}JphqS^WA#AfIj7h3pr9##rGJG!e08wYP2Lef#|*eFs!8st zkSrr;tqvB@l7AjX4maBt?GtULyV>J>7tWqvRy(93QWk7qO6t~;3cpzG=9}N9PghWo zD5AL(VZyTS!bSHMILmkm65hBx55Y=8B64sSB0Lm44KtE@6GaInMHtfqDH9nYZA>Kb zX3-AhJ3V`AAf{1q&ZR%BUVR1qy@WSD%cjjlGqO*>X@3$Kov0N4@T>YyvjZ=p4>bED z$N9fz%8yirdBI-IjQPS(M4Ya{G&ZU%m&G)bOnNt;a1wu{`+t?$2+-n3mkn~D+X&$q z7$FlU8ix@{l0AvOUqhCXAN9Bd`xm{2BZs!(&quleTPZ(O9r@spG?$RDQ0Vb|4TD)? zAoZ5SWP1(T%qnMZXRe*-U3%!`3hyvJVRV1?0T0CZpt|rY7QyspG%Y zY%hLILNWkZppH)bkf!$GF3)4n2BcpDzk5kz;RL*~PcG45g@mSj(gi?Ak6A zRPYiL{12je7A0l;;a-4$Ddb#KS>-2DV6Mr{S z14zdxz!tW6ocD^BysO7=K^%R)LBK+BtiKz8pLkDeZt{BUQhGO}H2~|d6#iIUA4_0M zE6!eSr%xkUN@4T)5ZJ2=mrn|vA-5rHvrLBJHSMX>F@3J}k#1M#N*`hB9&S2A{1k8@ zIdBBr*4w0iW2O|rkFa>fmGG+M%75ak2}I5_K|csr#(pJ-`#Rs4aKLGrwCDilQr>6e zI(QO;ACb&eLk1NQc$auVP!%esb}gS^w7>k^eLDw8sGvN0ojJ6)}wUskhuIGeiGQ5x|5{9*d?RM%mu>VJqg&(mV{ zYq;FKg!hZ>?D@C3bEUeWST0tJ<;ya>TkJN|-P|9)d-28$X#CO&tpvLi`vi8E6Hg#d zP}45FX8JZ}B7)tjfGkCw)EtO61zPEW6?mw}bDyxmreGO3L&rmT8=3GowGUMN5BE&E z)?{p^l*X(~!8gd$bpvVoP=6`*eBHdLY&?}^!{dinRc~<$8}ra7?tYHo*5u_W$snOp zWwI-2elHo?SfiC!l9Zk^Bu>0c;;@7*m!)~aB4!RM{b-a&&3WN9mR$vM@Qt#EHBC!6GKVy;OF8ULJ+J;ZyHi=tI+-bFTU zT|9G^OmBHp4r>uRUXezyM70Xo|T9 zB4ovJ*JcQ2Ery%DI`9UAV?wdTJVLJ4V?`3&)ervs{7*!T^devn@lhk7H z9R3q;v>ON0;`1>j0@+TAE2=`g}#pR-)l%UmYIgxtPs+vQ=^t?jq_HZ zwn04?(Cae8;2{pa&@ z@}N{BZ*vvo$Px;^n2~tgr37oRRE&Z$`6;-Alr)!;G_ObW;07 z2WEsRUDTifUR?X2jbjPXpOXPBDwuX;uqS^(tVIp^B!xzy3GA|jxZa8SNyDHCO+3?B zi@G094v;xT0x4{Wu)cUP;qpX_3A3EU_|z#wP=EbgB2)0di{KfVI_}1vO+3%QSEzI{ ziTS@Ax5K5uq1LCtJ>o3hOfP{6B=QX2i4)76mrV;}ae`?a3QA+1j#52m;Axa-mjP>0 zCX^8_G}^`*%qKL52f~UBasrzi!hoUJcZj!%7|d+7p4gfjJ`S9&l&+}JSzaaXP`NUC}N+e zkQTNuIj)4YL0}ZC5H=q~AS{xuq3XI8{}fCi`c}$#gtP$mow!RZsv%5h!m}e@s~qob z3-&3PSGW$fgRSb`g5V62)E?Z5d>vxXMt`_Z6}tsL_e!h}*WTEL;i;CKfyNH_!NM1eVpJNEf!SO8qN4h!K^z<-2l z2eVii@PqmX`tX7F%=#T|%&giD0skiq5;yRD!RWzpF(?rF>pKK>8P&(B=(C{H5Poro zh|>ggFga7C*PpkV1nMg?blZ5PnUgiG8&Q?x%Q~O28Os9vAyvVbfUMGiSR)|r+M>M0 z26n@b8PoX|FxH3WW2Bn~2*eu$>wj{e!E)ot8{|?hgi1R23eul~2U?)1cfCge3a;jh zLCW*W;*umzwy?q3H50X{p%%OA9=qfa+mJ#RV<5~oQLEwXG$M5=^XR_ZJnb$8*MFTkfRV2MvIXj^sVI#D8V>b*!Dy z9@-SDo#Ig~3NC0#;$CP5W3Bz2!%q6fYnKO66z=$V@}9h6*ej&kU~PVtytT@234~p^ z(S4_G(N(LwqM!jn`z>IEsq+Lk+CTsJ55|>Pl+sZqghmW6MJMMzdAnBVJpilF_}&n3 zTC3U)2B0x_2?Xj8v?}f>7k>;nD(vWI$UeHBqHe0r{DgZOO`WDr0K2ozC(6ZP)hTib z@?dYk9&Z}N-5DOT=v1}wOQ(gi)qPbxa2di`XMk15=L&aISJq5dO~tzPSXZp?TXOdl z%!KEvlGYNO#LaWNKV3Fm3LNC4KM001llo(Qi^#lf${j|khV2VZ;(v$;`9AKh603oO zr&V2;xpdcnN+EgLoB_TMR>G<%q3>JNG&BMmco#bdiCP>#g!rAcXd(GJma{t!b%#sGFK*Sbt53Io5>jr|};6RmUUB26q$>nQkCRhOmYH z=$=98rI{D{n&~;_ z3ad1QVye=Bz88^w^|s_Mv{q0^Zot3kpS!r+8opK|gZ5xx8-EQG76;$U_j>TGULy%4 z80tHehUNr;)*C5kTT#`s%B0e?%*;X&!J~OuBL_xr5g3&XQgA#LKTcpN7UvwcvaX}Q zd`S7Ip%CQbcd)^{VYq1w&5WmIV~vSc6*sV$=sQGC83x7bwpNnp8mx0))(MfA3{SQ> zjnJp4su^b7D}OF2cBsCBX7#FiTIo4Euw$vtURqAH5v%tM%yc`Q>yWj!j$ni4h4ov= zAuP61@=+3$sXJq#e|-L*QS{$$LFm`Tc00_0H^}$A8zuL7?kc%K7QIQ0arAem7DaV` ztDmIwiSFC7!*uL(KE|^6ydEA6%syUiRmFOkurVGiA%C`i)ksbD69Wf@zNy9gorzJC zxja+-B|f0xQTxRYK1VxILm}aaZ9LBhl9-{6;5lH6=vm|1R5{B>XL^k?gX$k(9MC-mdY_;EMrcB zEVo}hGZ$q_mZ$^lx+qb-A6Ro16#Zfk-0IFqKi6k@f<Rb@hHXKzk z%KJe;C8exc7_8ZG2d>6-@r#zE0gp!>sx2ce%6}YhP<3UNB(7*h%3mg~H>pq<+ zp?}rE(vo7L%tQ))2PPfj=Hvo1R?*3Ez-|W{sT)|gV4D(iEt`H%1d9$Js(-h$cWrNw zeSxt;Tt=oUeTN*uLz|@2O6xvqM$+EW9c-i>W~>zGGO6(6>ng#7+J~}Ghq~ijRr>d! z5nVdoD{c?7pj-!QZsIcPLa?ZXJ1pPnxqq@7{k_yUmq~1XrRUms6tu(KUu}bIZmTBc z5`U7&&7_yLaEHZgQ=y0I1_|1_ud=m^8b-g2Kbh*HS`|(0P`E>)?<1>oP3ge%m4SPH zP|`gjd2;E=hN^3(M|F7ES`b~jLPhkiPNSRQZ+xLw&re`K>l)hQl9#CbU(=@6a>^1TO$+v_?u8ApE*1rMmeIsgwF59V{Y(V#J;tz rpXiBHCm>8T?f-I9T?aGL@J}uJ4{8@XZ+iE}DpBZ2Px$`1 MiB RNS-to-Prns interop stall” closed three weeks in -(`cc4d524a3`), and a known send-path hang shipped with the note “typed fast-fail a -candidate for later” (`a010e6613`). - -**Laundered provenance** - -The repository contains a committed commit-message hook (`.githooks/commit-msg`) that *blocks* any commit containing attribution for machine generation (“generated with claude/codex/copilot/cursor/gemini”, “co-authored-by”), with the explanation “The committer owns the commit”. The contributing guide is explicit: “AI tools … are welcome … what you submit is *yours*”, and describes the contributing population as “both human and automated contributors”. The fictitious “Prns Tests” identity completes the picture: A manufactured, unknowable contributor, used for marketing content. - -**Authorship by assignment** - -The human whose name is on the work cannot answer for it, because the choices were never made by a human, and only the general shape and constraints of the outward presentation was. Nothing in the project’s history shows an individual explaining a design decision, accepting a mistake in the first person, or going deeper under technical questioning; the record shows process language and marketing instead. Per the earlier mentioned test: any other person could have pressed the same button, and nothing would be different. The project is effectively unowned, and void of value. - -By the criteria of [Assistance Versus Machine Substitution](#brandolinis-assistance-versus-substitution), this is substitution. The machine was the agent of the work; the “author” was a facade. - -### The performance claims - -The project’s central marketing claim - “up to 89× the throughput” of the reference - is also its most completely documented failure, because the project published the evidence of its own measurement. The apparatus, the results, and the problems are all on the record. - -**The claim** - -The README states “up to 89× the throughput”; 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”; the website’s front page carries the tagline “Measured, not just claimed”. - -**The apparatus** - -The reference is loaded through `benchmarks/reference/compiled_reference.py`, which installs `pyximport` and then asserts two things: that `RNS.compiled == True`, and that at least *one* RNS module was loaded from a native extension. The project’s own published “proof” records show exactly what those checks captured, on every platform: - -```default -aarch64-apple-darwin: .../RNS.cpython-313-darwin.so, Cython 3.2.8, Python 3.13.13 -x86_64-unknown-linux-gnu: .../RNS.cpython-313-x86_64-linux-gnu.so, gcc 11.4.0 -x86_64-pc-windows-msvc: ~/.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.so`, nothing below it. Nothing named `RNS.Transport`, `RNS.Destination`, `RNS.Packet`, `RNS.Link`, or `RNS.Resource` ever appears, because *nothing below the top level was ever compiled*. Nobody bothered to check or verify *anything* here. - -The machine output was simply taken for truth, and a full marketing strategy was spun and produced on it. “RNS 1.4.2 (compiled)” - the label used in every table, chart, and marketing page - *is not a mode of RNS that exists*, but the hallucinations of a machine, which the humans created a marketing strategy on. In reality, it is the old `CRNS` development shim, whose top-level-only, debug-oriented “compilation” is slower than plain interpreted RNS, and which was *defunct for over a year* before these benchmarks were published. - -**Interface choices** - -The harness writes the reference’s configuration itself (`benchmarks/reference/participant_node.py`): `TCPClientInterface` for the initiator, `TCPServerInterface` for the responder and both relay sides, with `UDPInterface` as the abstract wire. The reference was never given its modern `BackboneInterface` on any platform, forcing the slowest possible interrfaces. The interface selection is never mentioned in any methodology text. - -**The policy** - -The published default-policy tables record the asymmetry directly: Prns at 500 Mbps / 128 KiB TCP policy against the reference at 10 Mbps / 8 KiB - slyly footnoted as “preserves each implementation’s normal TCP policy” (in the case of RNS, a conservative default policy that was selected to prioritize coexistence on slower, shared links, requiring the user to dial it up to full speed if they knew what they were doing). Raw transport “throughput” ratios of 20.65× (Linux) and 38.84× (Windows) are therefore mostly policy, not engine. - -**The cross-host evidence** - -The published results show the same scenario producing wildly different ratios by host, and the variance is entirely in the reference artifact: - -| Host | Prns, single-packet | “Reference”, single-packet | Ratio | -|-------------------------|-----------------------|------------------------------|---------| -| macOS (Apple M4) | 37.4k/s | 420/s | 89.09× | -| Linux (i7-1260P) | 25.3k/s | 3.5k/s | 7.19× | -| Windows (Ryzen 5 5600X) | 30.8k/s | 3.9k/s | 8.00× | - -Prns is consistent (25–37k/s). The reference artifact collapses to different depths on different hosts, and the single worst collapse - 420 packets per second on macOS - is the cell selected as the global headline. The “89×” is not a measure of Prns; it is a measure of how badly the broken baseline happened to fail on one host. - -For reality calibration: Stock, interpreted RNS 1.5.4 on an ordinary mid-range laptop, single core, sustains roughly 30,000 single-packet deliveries per second (including ephemeral-key decryption), ~175,000–280,000 packets per second in transit relay, and on the order of 10 Gbps at 16 KiB payloads. The project’s “compiled” artifact measured 420–3,900 packets per second for its single-packet scenario: An order of magnitude or more *below* stock interpreted RNS. The comparison being marketed was not “Rust vs Python”; **it was “an implementation running under optimal conditions versus a mislabeled, broken shim on a slow legacy interface at a severe policy disadvantage”**. - -**The equalized rows** - -The project’s own “1 Gbps policy” rows, in which both sides are explicitly configured identically, publish ratios of roughly 2.4–8.4× across all hosts and scenarios - still against the broken baseline, but nowhere near 89×, and consistent with the ordinary, uncontroversial observation that a native implementation tends to outperform an interpreted one in raw throughput. That point needed no fudging to make, and is banal. - -Interestingly, though, it seems that Prns is really only *marginally* faster than a Python implementation, running in interpreted mode, on a single CPU core. - -**Assessment** - -The front page says “Measured, not just claimed.” The record shows the opposite ordering: claimed, and arranged to look measured. No methodology section anywhere states what “compiled” means, that it is a deprecated development shim, that it builds debug targets, or which interface the reference was given; the one statement of the policy asymmetry appears in a footnote of the results tables themselves. If they did not need to fudge it, they would have published the method clearly. - -### Overall Evaluation - -Evaluated against the conditions of [Evaluating A Reticulum Implementation](#brandolinis-evaluating): - -* **Provenance and attribution.** Fails: The fake “ground-up” origin story; zero reference links - on the website; a single well-hidden link in the README; a license file reading - `Copyright (c) 2026 The Prns Authors` over work directly generated from the licensed reference; - no original copyright or permission notice anywhere. - -* **Agency and answerability.** Fails on every criterion of [Assistance Versus Machine Substitution](#brandolinis-assistance-versus-substitution): - Unauthored scope, uniform generation, discovery by regeneration, laundered provenance, - authorship by assignment. - -* **Engineering.** Fails: The benchmark apparatus above; interop demonstrated only - against a pinned, outdated reference version over loopback while the marketing claims current - parity, interop failures with stock RNS; vendored prebuilt binaries and a republished fork - of an upstream crate (`nrf-softdevice 0.1.0-prns.1`) with no verifiable provenance; - committed WASM bundles. - -* **Network behaviour.** Fails: Invented spectrum behaviour and compatibility claims - about third-party applications of the reference ecosystem (Sideband, NomadNet, MeshChat) - that are not established by any evidence. - -* **Monetary and influence signals.** The marketing apparatus - website before protocol, - day-three twelve-language marketing, false benchmark headlines, “audited” and “formal proof” - claims - the conformal surface described in [Evaluating A Reticulum Implementation](#brandolinis-evaluating): - is where this project invested. - -### Licensing Analysis - -Applying the two legal layers established in [Copyright & The Two Legal Layers](#brandolinis-copyright-and-layers): - -**Layer A - copyright infringement (license-independent)** - -The record shows a direct copy roundtrip: the licensed reference implementation fed into a machine, transformed, at a scale and cadence no human could review, with a license file asserting a fresh copyright in the operator’s name and no acknowledgment of the work the project was generated from. No substantial, new human creative input is demonstrated anywhere in the record - the founding document explicitly frames the design as an instructed port of the reference’s contract. A primarily machine-generated copy of a copyrighted work, not accompanied by demonstrable substantial human creative input, is a derivative work over which the copier holds no copyright, and a reproduction of which without the original author’s permission infringes the original author’s copyright. This holds under any license, MIT included. The operator’s copyright claim over the result is, on this evidence, not merely unsubstantiated; it is the absence of one, directly asserted in the project’s own writing. - -**Layer B - license conditions (Reticulum License specific)** - -Modern Reticulum - the current wire format, the AES-256-based link encryption, ratchets, the cryptographic machinery as it exists today - has been published under the Reticulum License since April 15, 2025, effective from release 0.9.4 and every release since. As a derivative of that work, the license’s conditions attach: The copyright and permission notice must be included in all copies and substantial portions; the AI-training condition must be honoured; the harm condition must be honoured. The record shows none of the notice requirements met, and a production process that consists of the licensed work being ingested into a machine and regurgitated, at industrial scale and cadence. - -**The cascading consequence** - -Prns is distributed claiming dual MIT/Apache-2.0 licensing. It is, however, a direct derivative of Reticulum-licensed work, and the claimed grant is therefore void. Every downstream project that builds on Prns believing it is MIT/Apache-licensed is building on a grant that does not exist. The users of Prns, and all software developers using it, have in effect, been placed under conditions they were never told about. The “ground-up” claim is not merely false; it is the sole load-bearing element of an entire licensing posture, and it fails spectacularly. - -### Consequences - -The consequences of this pattern are examined in the following sections - the harm to users and to the network in [A Movement Of A Dozen](#brandolinis-movement-of-a-dozen), and the human dimension in [Network Health & Coexistence](#brandolinis-health-and-coexistence). This section’s contribution is narrower and intended as an instructive example: This is what a substitution project looks like, in full, on its own record. It is a reference example for [Evaluating A Reticulum Implementation](#brandolinis-evaluating), and it demonstrates, in one case, most of the elements this chapter describes. - -### Verdict - -Applying the three verdicts of [Evaluating A Reticulum Implementation](#brandolinis-evaluating), this project does not meet the standard. It is not “experimental but honest” - it is not labeled as experimental anywhere; the first thing users saw was a polished marketing presence promising a finished, tested, drop-in replacement. It is a project whose central claims are fabricated (the performance apparatus), whose provenance is laundered (the authorship machinery), whose foundation is misrepresented (the “ground-up” story), whose core semantics were learned late and by regeneration, and whose operator cannot possibly answer for any of it. It is also a blatant copyright violation of the reference implementation. - -The proposed conclusion, for users and for the network: Treat the Prns project as hostile regardless of its polished surface, and as a hazard insofar as it invites users onto shared networks. Nothing in this section is a judgment about the people involved; it is a reading of the results produced, their history and how they came to be, which in the regrettable lack of any human authorship is the only thing that can be expected to be held to account. - -### Dating - -This examination reflects the publicly available material as of September 2026; the repository in question continued to receive commits at the time of writing, so readers should treat citations to commits and files as point-in-time evidence. A [forensics snapshot](https://github.com/markqvist/forensics_prns) is publicly available on GitHub. - ## The Movement Of A Dozen ### Presentation, Elongated @@ -1131,4 +909,226 @@ A lot of us rely on these networks every day. They carry our messages, our coord They are valuable, free, and very hard to shut down. The response is not to become aggressive. It is to be *more* of what the network already is: Real, open, owned, and shared. -*Mark* \ No newline at end of file +*Mark* + +## Addendum A: The Prns Case + +### Purpose & Scope + +This section provides a concrete example, which future evaluations can use as a template. Its purpose is not to be the last word on this particular subject, but to be an example of how the ideas in this chapter can be applied, and to make the next such examination easier. + +The subject of this case study is **Prns**, a project published at the repository `github.com/KenAKAFrosty/Prns`, presented as a “ground-up implementation of Reticulum, written in Rust”, marketed as faster, safer, and more strictly tested than the reference, and widely promoted with the claim of “up to 89× the throughput” of the reference implementation. The record described below is the project’s own, and sourced from its GitHub repository, analyzed locally. + +### The Project In Brief + +* **Time span.** 3,374 commits between 2026-05-26 and 2026-09-12: approximately 110 days, + at a mean rate of ~31 commits per day. Monthly: 132 / 1,137 / 1,097 / 805 / 203. + +* **Authorship.** 3,252 of 3,374 commits (96.4%) are authored by a single account. A + second identity, “Prns Tests [tests@example.test](mailto:tests@example.test)” - a fictitious identity on a reserved + domain - contributed 35 commits, every one of them website and marketing content. + +* **Size.** 3,519 tracked files; 1,983 Rust files; 636,226 lines of Rust; approximately + 22.7 MB of Rust source; 69.5 MB of total repository content. + +* **Scope claimed.** A daemon (“drop-in replacement” for the reference daemon), embedded + firmware for three microcontroller families (including six ESP32-S3 board variants and + nRF52840), SDKs and bindings for nine languages, a browser-based node and web flasher, a + twelve-language website, a benchmark apparatus with its own publication and “proof” + pipeline, and a validation hub with oracles, fuzzing, mutation testing, and formal-proof + claims. + +* **Marketing claims.** “Ground-up implementation of Reticulum”; “up to 89× the + throughput”; “48× smaller peak-memory footprint”; “33× the energy efficiency”; + “Measured, not just claimed”; “Enforced, then audited”; “byte-for-byte wire parity with + the reference implementation”; “works with Sideband, NomadNet, MeshChat, etc.”; + “no_std (no alloc required either)”. + +* **Status at the time of writing.** Version 0.3.7; published version history begins at + 0.3.0. The repository continues to receive commits. + +### Question 1: Is this a clean implementation, or was it directly generated from the reference? + +The first of the two deciding questions from [Evaluating A Reticulum Implementation](#brandolinis-evaluating) is settled by the project’s own record. An actual [clean-room](#brandolinis-cleanroom-delusion) implementation, reasoned out and written by humans, would owe nothing to any license. The data available shows clearly that Prns is not that. + +* **The founding state.** The first commit, “Scaffold Personal Reticulum suite”, contains + the scaffolding of not one but two ports - `personal-rns` and `personal-lxmf`, the latter + being the reference’s companion messaging protocol - together with a daemon scaffold and + a 233-line founding document, `docs/build-ethos.md`. That document declares the project’s + goal as a “performance-focused drop-in-replacement for rnsd” and its governing principle + as: “Port the contract, not the implementation.” It further states directly to the + machine-loop, that **“You owe the reference fidelity at exactly two boundaries: + The wire… The behavior. … Between those two boundaries, the model is yours”**. + At this point, the very first commit, effectively the whole of the implementation design + and any relevant decisions are handed over to the LLM. + +* **Continuous ingestion from the reference.** 506 commits reference RNS or Reticulum + source behaviour; the word “parity” appears in 49 commit messages. Commits cite the reference + implementation’s own source locations (for example `Transport.py:1367`) when correcting + their own divergences and mistakes. + +* **Byte-level fidelity as an explicit goal.** Within 48 hours of the first commit, the + record shows a “crypto adapter - vetted primitives, byte-exact vs RNS 1.3.1”, and a wire + implementation matching the reference’s packet header layout. The project’s own + validation apparatus decodes wire vectors using the reference implementation’s own + packet parser, and the interop suite consists of real, stock-RNS peer nodes - that is, + the reference source itself, used as the ground truth against which this LLM output is + checked, and committed as accepted and verified after 48 hours of the project’s recorded start. + +* **The marketing mismatch.** The same record that documents all of the above describes the + project, publicly, as “a ground-up implementation of Reticulum” - while declining, on its + website, to link to the reference implementation at all: the entire tree mentions the + reference’s author in six files, and the website in none. + +Conclusion: the project’s own history and commit record establishes that it was generated directly from the reference implementation’s source code, not reasoned out from the public-domain protocol. It is a derivative of licensed work within the meaning of [the Reticulum License](#brandolinis-what-the-license-is) and [general copyright law](#brandolinis-copyright-and-layers). The “ground-up” claim, which carries its entire legal and marketing posture, is disproven by the project’s own history. + +### Question 2: Who, or what, is the agent of the work? + +The second deciding question is answered by the application of [Assistance Versus Machine Substitution](#brandolinis-assistance-versus-substitution) criteria to the project. + +**Scope that no human could have authored** + +636,226 lines of Rust in 110 days is approximately 5,800 lines per day, every day, including weekends - with 149 commits recorded between midnight and 06:00, and Saturday the single busiest weekday. No human review or decision capacity is commensurable with this volume; the review capacity and the output volume are structurally incommensurable, which is the definition of unauthored scope. + +**Uniform generation** + +The record shows no sign of human development, growth, or learning: No contested decisions, no style drift. Instead: endless renaming (in the first 48 hours: `State → EngineState → TickInput → TickOutput`), uniform fluent register in every commit, and the exact same, synthetic voice in code, documentation, and website copy. + +**Discovery by regeneration** + +Corrections arrived by the machine’s own subsequent runs, recorded as planned milestones. In early July 2026, a series of “core review” commits documented, in the project’s own words: + +* announce-ID history “was unbounded per-slot growth” (`54cc8d601`); +* interface announce limiting could “leak a sustained flood” (`9d27af75c`); +* a “phantom-airtime leak” where frames “used to vanish silently” (`4ed75ffdd`); +* Group-packet deduplication “which RNS does not do” - a behaviour the reference never had, + implemented and later removed (`edd8e72be`); +* “both `unwrap_or(&[])` arms were unreachable dead defaults” (`74bea355e`); +* a benchmark crate “hasn’t compiled since” a prior rename, undetected for weeks because it + was outside the CI’s workspace (`86240b027`). + +Earlier still: the record shows a “>1 MiB RNS-to-Prns interop stall” closed three weeks in +(`cc4d524a3`), and a known send-path hang shipped with the note “typed fast-fail a +candidate for later” (`a010e6613`). + +**Laundered provenance** + +The repository contains a committed commit-message hook (`.githooks/commit-msg`) that *blocks* any commit containing attribution for machine generation (“generated with claude/codex/copilot/cursor/gemini”, “co-authored-by”), with the explanation “The committer owns the commit”. The contributing guide is explicit: “AI tools … are welcome … what you submit is *yours*”, and describes the contributing population as “both human and automated contributors”. The fictitious “Prns Tests” identity completes the picture: A manufactured, unknowable contributor, used for marketing content. + +**Authorship by assignment** + +The human whose name is on the work cannot answer for it, because the choices were never made by a human, and only the general shape and constraints of the outward presentation was. Nothing in the project’s history shows an individual explaining a design decision, accepting a mistake in the first person, or going deeper under technical questioning; the record shows process language and marketing instead. Per the earlier mentioned test: any other person could have pressed the same button, and nothing would be different. The project is effectively unowned, and void of value. + +By the criteria of [Assistance Versus Machine Substitution](#brandolinis-assistance-versus-substitution), this is substitution. The machine was the agent of the work; the “author” was a facade. + +### The performance claims + +The project’s central marketing claim - “up to 89× the throughput” of the reference - is also its most completely documented failure, because the project published the evidence of its own measurement. The apparatus, the results, and the problems are all on the record. + +**The claim** + +The README states “up to 89× the throughput”; 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”; the website’s front page carries the tagline “Measured, not just claimed”. + +**The apparatus** + +The reference is loaded through `benchmarks/reference/compiled_reference.py`, which installs `pyximport` and then asserts two things: that `RNS.compiled == True`, and that at least *one* RNS module was loaded from a native extension. The project’s own published “proof” records show exactly what those checks captured, on every platform: + +```default +aarch64-apple-darwin: .../RNS.cpython-313-darwin.so, Cython 3.2.8, Python 3.13.13 +x86_64-unknown-linux-gnu: .../RNS.cpython-313-x86_64-linux-gnu.so, gcc 11.4.0 +x86_64-pc-windows-msvc: ~/.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.so`, nothing below it. Nothing named `RNS.Transport`, `RNS.Destination`, `RNS.Packet`, `RNS.Link`, or `RNS.Resource` ever appears, because *nothing below the top level was ever compiled*. Nobody bothered to check or verify *anything* here. + +The machine output was simply taken for truth, and a full marketing strategy was spun and produced on it. “RNS 1.4.2 (compiled)” - the label used in every table, chart, and marketing page - *is not a mode of RNS that exists*, but the hallucinations of a machine, which the humans created a marketing strategy on. In reality, it is the old `CRNS` development shim, whose top-level-only, debug-oriented “compilation” is slower than plain interpreted RNS, and which was *defunct for over a year* before these benchmarks were published. + +**Interface choices** + +The harness writes the reference’s configuration itself (`benchmarks/reference/participant_node.py`): `TCPClientInterface` for the initiator, `TCPServerInterface` for the responder and both relay sides, with `UDPInterface` as the abstract wire. The reference was never given its modern `BackboneInterface` on any platform, forcing the slowest possible interrfaces. The interface selection is never mentioned in any methodology text. + +**The policy** + +The published default-policy tables record the asymmetry directly: Prns at 500 Mbps / 128 KiB TCP policy against the reference at 10 Mbps / 8 KiB - slyly footnoted as “preserves each implementation’s normal TCP policy” (in the case of RNS, a conservative default policy that was selected to prioritize coexistence on slower, shared links, requiring the user to dial it up to full speed if they knew what they were doing). Raw transport “throughput” ratios of 20.65× (Linux) and 38.84× (Windows) are therefore mostly policy, not engine. + +**The cross-host evidence** + +The published results show the same scenario producing wildly different ratios by host, and the variance is entirely in the reference artifact: + +| Host | Prns, single-packet | “Reference”, single-packet | Ratio | +|-------------------------|-----------------------|------------------------------|---------| +| macOS (Apple M4) | 37.4k/s | 420/s | 89.09× | +| Linux (i7-1260P) | 25.3k/s | 3.5k/s | 7.19× | +| Windows (Ryzen 5 5600X) | 30.8k/s | 3.9k/s | 8.00× | + +Prns is consistent (25–37k/s). The reference artifact collapses to different depths on different hosts, and the single worst collapse - 420 packets per second on macOS - is the cell selected as the global headline. The “89×” is not a measure of Prns; it is a measure of how badly the broken baseline happened to fail on one host. + +For reality calibration: Stock, interpreted RNS 1.5.4 on an ordinary mid-range laptop, single core, sustains roughly 30,000 single-packet deliveries per second (including ephemeral-key decryption), ~175,000–280,000 packets per second in transit relay, and on the order of 10 Gbps at 16 KiB payloads. The project’s “compiled” artifact measured 420–3,900 packets per second for its single-packet scenario: An order of magnitude or more *below* stock interpreted RNS. The comparison being marketed was not “Rust vs Python”; **it was “an implementation running under optimal conditions versus a mislabeled, broken shim on a slow legacy interface at a severe policy disadvantage”**. + +**The equalized rows** + +The project’s own “1 Gbps policy” rows, in which both sides are explicitly configured identically, publish ratios of roughly 2.4–8.4× across all hosts and scenarios - still against the broken baseline, but nowhere near 89×, and consistent with the ordinary, uncontroversial observation that a native implementation tends to outperform an interpreted one in raw throughput. That point needed no fudging to make, and is banal. + +Interestingly, though, it seems that Prns is really only *marginally* faster than a Python implementation, running in interpreted mode, on a single CPU core. + +**Assessment** + +The front page says “Measured, not just claimed.” The record shows the opposite ordering: claimed, and arranged to look measured. No methodology section anywhere states what “compiled” means, that it is a deprecated development shim, that it builds debug targets, or which interface the reference was given; the one statement of the policy asymmetry appears in a footnote of the results tables themselves. If they did not need to fudge it, they would have published the method clearly. + +### Overall Evaluation + +Evaluated against the conditions of [Evaluating A Reticulum Implementation](#brandolinis-evaluating): + +* **Provenance and attribution.** Fails: The fake “ground-up” origin story; zero reference links + on the website; a single well-hidden link in the README; a license file reading + `Copyright (c) 2026 The Prns Authors` over work directly generated from the licensed reference; + no original copyright or permission notice anywhere. + +* **Agency and answerability.** Fails on every criterion of [Assistance Versus Machine Substitution](#brandolinis-assistance-versus-substitution): + Unauthored scope, uniform generation, discovery by regeneration, laundered provenance, + authorship by assignment. + +* **Engineering.** Fails: The benchmark apparatus above; interop demonstrated only + against a pinned, outdated reference version over loopback while the marketing claims current + parity, interop failures with stock RNS; vendored prebuilt binaries and a republished fork + of an upstream crate (`nrf-softdevice 0.1.0-prns.1`) with no verifiable provenance; + committed WASM bundles. + +* **Network behaviour.** Fails: Invented spectrum behaviour and compatibility claims + about third-party applications of the reference ecosystem (Sideband, NomadNet, MeshChat) + that are not established by any evidence. + +* **Monetary and influence signals.** The marketing apparatus - website before protocol, + day-three twelve-language marketing, false benchmark headlines, “audited” and “formal proof” + claims - the conformal surface described in [Evaluating A Reticulum Implementation](#brandolinis-evaluating): + is where this project invested. + +### Licensing Analysis + +Applying the two legal layers established in [Copyright & The Two Legal Layers](#brandolinis-copyright-and-layers): + +**Layer A - copyright infringement (license-independent)** + +The record shows a direct copy roundtrip: the licensed reference implementation fed into a machine, transformed, at a scale and cadence no human could review, with a license file asserting a fresh copyright in the operator’s name and no acknowledgment of the work the project was generated from. No substantial, new human creative input is demonstrated anywhere in the record - the founding document explicitly frames the design as an instructed port of the reference’s contract. A primarily machine-generated copy of a copyrighted work, not accompanied by demonstrable substantial human creative input, is a derivative work over which the copier holds no copyright, and a reproduction of which without the original author’s permission infringes the original author’s copyright. This holds under any license, MIT included. The operator’s copyright claim over the result is, on this evidence, not merely unsubstantiated; it is the absence of one, directly asserted in the project’s own writing. + +**Layer B - license conditions (Reticulum License specific)** + +Modern Reticulum - the current wire format, the AES-256-based link encryption, ratchets, the cryptographic machinery as it exists today - has been published under the Reticulum License since April 15, 2025, effective from release 0.9.4 and every release since. As a derivative of that work, the license’s conditions attach: The copyright and permission notice must be included in all copies and substantial portions; the AI-training condition must be honoured; the harm condition must be honoured. The record shows none of the notice requirements met, and a production process that consists of the licensed work being ingested into a machine and regurgitated, at industrial scale and cadence. + +**The cascading consequence** + +Prns is distributed claiming dual MIT/Apache-2.0 licensing. It is, however, a direct derivative of Reticulum-licensed work, and the claimed grant is therefore void. Every downstream project that builds on Prns believing it is MIT/Apache-licensed is building on a grant that does not exist. The users of Prns, and all software developers using it, have in effect, been placed under conditions they were never told about. The “ground-up” claim is not merely false; it is the sole load-bearing element of an entire licensing posture, and it fails spectacularly. + +### Consequences + +The consequences of this pattern are examined in the following sections: The harm to users and to the network in [A Movement Of A Dozen](#brandolinis-movement-of-a-dozen), and the human dimension in [Network Health & Coexistence](#brandolinis-health-and-coexistence). The contribution of this addendum is narrower and intended as an instructive example: This is what a substitution project looks like, in full, on its own record. It is a reference example for [Evaluating A Reticulum Implementation](#brandolinis-evaluating), and it demonstrates, in one case, most of the elements this chapter describes. + +### Verdict + +Applying the three verdicts of [Evaluating A Reticulum Implementation](#brandolinis-evaluating), this project does not meet the standard. It is not “experimental but honest” - it is not labeled as experimental anywhere; the first thing users saw was a polished marketing presence promising a finished, tested, drop-in replacement. It is a project whose central claims are fabricated (the performance apparatus), whose provenance is laundered (the authorship machinery), whose foundation is misrepresented (the “ground-up” story), whose core semantics were learned late and by regeneration, and whose operator cannot possibly answer for any of it. It is also a blatant copyright violation of the reference implementation. + +The proposed conclusion, for users and for the network: Treat the Prns project as hostile regardless of its polished surface, and as a hazard insofar as it invites users onto shared networks. Nothing in this section is a judgment about the people involved; it is a reading of the results produced, their history and how they came to be, which in the regrettable lack of any human authorship is the only thing that can be expected to be held to account. + +### Dating + +This examination reflects the publicly available material as of September 2026; the repository in question continued to receive commits at the time of writing, so readers should treat citations to commits and files as point-in-time evidence. A [forensics snapshot](https://github.com/markqvist/forensics_prns) is publicly available on GitHub. \ No newline at end of file diff --git a/docs/markdown/index.md b/docs/markdown/index.md index 4f49af57..10caa78c 100644 --- a/docs/markdown/index.md +++ b/docs/markdown/index.md @@ -302,17 +302,6 @@ to participate in the development of Reticulum itself. * [The Conformal Surface](brandolinis.md#the-conformal-surface) * [Possible Verdicts](brandolinis.md#possible-verdicts) * [These Standards Are Reasonable](brandolinis.md#these-standards-are-reasonable) - * [The Prns Case](brandolinis.md#the-prns-case) - * [Purpose & Scope](brandolinis.md#purpose-scope) - * [The Project In Brief](brandolinis.md#the-project-in-brief) - * [Question 1: Is this a clean implementation, or was it directly generated from the reference?](brandolinis.md#question-1-is-this-a-clean-implementation-or-was-it-directly-generated-from-the-reference) - * [Question 2: Who, or what, is the agent of the work?](brandolinis.md#question-2-who-or-what-is-the-agent-of-the-work) - * [The performance claims](brandolinis.md#the-performance-claims) - * [Overall Evaluation](brandolinis.md#overall-evaluation) - * [Licensing Analysis](brandolinis.md#licensing-analysis) - * [Consequences](brandolinis.md#consequences) - * [Verdict](brandolinis.md#verdict) - * [Dating](brandolinis.md#dating) * [The Movement Of A Dozen](brandolinis.md#the-movement-of-a-dozen) * [Presentation, Elongated](brandolinis.md#presentation-elongated) * [Headcount](brandolinis.md#headcount) @@ -330,6 +319,17 @@ to participate in the development of Reticulum itself. * [The Place Of New Implementations](brandolinis.md#the-place-of-new-implementations) * [Expanding The Commons](brandolinis.md#expanding-the-commons) * [Defence Of The Commons](brandolinis.md#defence-of-the-commons) + * [Addendum A: The Prns Case](brandolinis.md#addendum-a-the-prns-case) + * [Purpose & Scope](brandolinis.md#purpose-scope) + * [The Project In Brief](brandolinis.md#the-project-in-brief) + * [Question 1: Is this a clean implementation, or was it directly generated from the reference?](brandolinis.md#question-1-is-this-a-clean-implementation-or-was-it-directly-generated-from-the-reference) + * [Question 2: Who, or what, is the agent of the work?](brandolinis.md#question-2-who-or-what-is-the-agent-of-the-work) + * [The performance claims](brandolinis.md#the-performance-claims) + * [Overall Evaluation](brandolinis.md#overall-evaluation) + * [Licensing Analysis](brandolinis.md#licensing-analysis) + * [Consequences](brandolinis.md#consequences) + * [Verdict](brandolinis.md#verdict) + * [Dating](brandolinis.md#dating) * [API Reference](reference.md) * [`Reticulum`](reference.md#RNS.Reticulum) diff --git a/docs/source/brandolinis.rst b/docs/source/brandolinis.rst index 16b0ce58..37fffa75 100644 --- a/docs/source/brandolinis.rst +++ b/docs/source/brandolinis.rst @@ -732,263 +732,6 @@ I'll close this guide by stating what these standards are *not*\ : They are neit The reference implementation has met this standard for years, and its users know what that looks like. -.. _brandolinis-prns: - -The Prns Case -------------- - -.. _brandolinis-purpose-and-scope: - -Purpose & Scope -^^^^^^^^^^^^^^^ - -This section provides a concrete example, which future evaluations can use as a template. Its purpose is not to be the last word on this particular subject, but to be an example of how the ideas in this chapter can be applied, and to make the next such examination easier. - -The subject of this case study is **Prns**\ , a project published at the repository ``github.com/KenAKAFrosty/Prns``\ , presented as a "ground-up implementation of Reticulum, written in Rust", marketed as faster, safer, and more strictly tested than the reference, and widely promoted with the claim of "up to 89× the throughput" of the reference implementation. The record described below is the project's own, and sourced from its GitHub repository, analyzed locally. - -.. _brandolinis-project-in-brief: - -The Project In Brief -^^^^^^^^^^^^^^^^^^^^ - -* **Time span.** 3,374 commits between 2026-05-26 and 2026-09-12: approximately 110 days, - at a mean rate of ~31 commits per day. Monthly: 132 / 1,137 / 1,097 / 805 / 203. -* **Authorship.** 3,252 of 3,374 commits (96.4%) are authored by a single account. A - second identity, "Prns Tests tests@example.test" - a fictitious identity on a reserved - domain - contributed 35 commits, every one of them website and marketing content. -* **Size.** 3,519 tracked files; 1,983 Rust files; 636,226 lines of Rust; approximately - 22.7 MB of Rust source; 69.5 MB of total repository content. -* **Scope claimed.** A daemon ("drop-in replacement" for the reference daemon), embedded - firmware for three microcontroller families (including six ESP32-S3 board variants and - nRF52840), SDKs and bindings for nine languages, a browser-based node and web flasher, a - twelve-language website, a benchmark apparatus with its own publication and "proof" - pipeline, and a validation hub with oracles, fuzzing, mutation testing, and formal-proof - claims. -* **Marketing claims.** "Ground-up implementation of Reticulum"; "up to 89× the - throughput"; "48× smaller peak-memory footprint"; "33× the energy efficiency"; - "Measured, not just claimed"; "Enforced, then audited"; "byte-for-byte wire parity with - the reference implementation"; "works with Sideband, NomadNet, MeshChat, etc."; - "no_std (no alloc required either)". -* **Status at the time of writing.** Version 0.3.7; published version history begins at - 0.3.0. The repository continues to receive commits. - -.. _brandolinis-prns-question-1: - -Question 1: Is this a clean implementation, or was it directly generated from the reference? -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The first of the two deciding questions from :ref:`Evaluating A Reticulum Implementation` is settled by the project's own record. An actual :ref:`clean-room` implementation, reasoned out and written by humans, would owe nothing to any license. The data available shows clearly that Prns is not that. - -* **The founding state.** The first commit, "Scaffold Personal Reticulum suite", contains - the scaffolding of not one but two ports - ``personal-rns`` and ``personal-lxmf``\ , the latter - being the reference's companion messaging protocol - together with a daemon scaffold and - a 233-line founding document, ``docs/build-ethos.md``. That document declares the project's - goal as a "performance-focused drop-in-replacement for rnsd" and its governing principle - as: "Port the contract, not the implementation." It further states directly to the - machine-loop, that **"You owe the reference fidelity at exactly two boundaries: - The wire... The behavior. ... Between those two boundaries, the model is yours"**. - At this point, the very first commit, effectively the whole of the implementation design - and any relevant decisions are handed over to the LLM. -* **Continuous ingestion from the reference.** 506 commits reference RNS or Reticulum - source behaviour; the word "parity" appears in 49 commit messages. Commits cite the reference - implementation's own source locations (for example ``Transport.py:1367``) when correcting - their own divergences and mistakes. -* **Byte-level fidelity as an explicit goal.** Within 48 hours of the first commit, the - record shows a "crypto adapter - vetted primitives, byte-exact vs RNS 1.3.1", and a wire - implementation matching the reference's packet header layout. The project's own - validation apparatus decodes wire vectors using the reference implementation's own - packet parser, and the interop suite consists of real, stock-RNS peer nodes - that is, - the reference source itself, used as the ground truth against which this LLM output is - checked, and committed as accepted and verified after 48 hours of the project's recorded start. -* **The marketing mismatch.** The same record that documents all of the above describes the - project, publicly, as "a ground-up implementation of Reticulum" - while declining, on its - website, to link to the reference implementation at all: the entire tree mentions the - reference's author in six files, and the website in none. - -Conclusion: the project's own history and commit record establishes that it was generated directly from the reference implementation's source code, not reasoned out from the public-domain protocol. It is a derivative of licensed work within the meaning of :ref:`the Reticulum License` and :ref:`general copyright law`. The "ground-up" claim, which carries its entire legal and marketing posture, is disproven by the project's own history. - -.. _brandolinis-prns-question-2: - -Question 2: Who, or what, is the agent of the work? -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The second deciding question is answered by the application of :ref:`Assistance Versus Machine Substitution` criteria to the project. - -**Scope that no human could have authored** - -636,226 lines of Rust in 110 days is approximately 5,800 lines per day, every day, including weekends - with 149 commits recorded between midnight and 06:00, and Saturday the single busiest weekday. No human review or decision capacity is commensurable with this volume; the review capacity and the output volume are structurally incommensurable, which is the definition of unauthored scope. - -**Uniform generation** - -The record shows no sign of human development, growth, or learning: No contested decisions, no style drift. Instead: endless renaming (in the first 48 hours: ``State → EngineState → TickInput → TickOutput``\ ), uniform fluent register in every commit, and the exact same, synthetic voice in code, documentation, and website copy. - -**Discovery by regeneration** - -Corrections arrived by the machine's own subsequent runs, recorded as planned milestones. In early July 2026, a series of "core review" commits documented, in the project's own words: - -* announce-ID history "was unbounded per-slot growth" (\ ``54cc8d601``\ ); -* interface announce limiting could "leak a sustained flood" (\ ``9d27af75c``\ ); -* a "phantom-airtime leak" where frames "used to vanish silently" (\ ``4ed75ffdd``\ ); -* Group-packet deduplication "which RNS does not do" - a behaviour the reference never had, - implemented and later removed (\ ``edd8e72be``\ ); -* "both ``unwrap_or(&[])`` arms were unreachable dead defaults" (\ ``74bea355e``\ ); -* a benchmark crate "hasn't compiled since" a prior rename, undetected for weeks because it - was outside the CI's workspace (\ ``86240b027``\ ). - -Earlier still: the record shows a ">1 MiB RNS-to-Prns interop stall" closed three weeks in -(\ ``cc4d524a3``\ ), and a known send-path hang shipped with the note "typed fast-fail a -candidate for later" (\ ``a010e6613``\ ). - -**Laundered provenance** - -The repository contains a committed commit-message hook (\ ``.githooks/commit-msg``\ ) that *blocks* any commit containing attribution for machine generation ("generated with claude/codex/copilot/cursor/gemini", "co-authored-by"), with the explanation "The committer owns the commit". The contributing guide is explicit: "AI tools ... are welcome ... what you submit is *yours*", and describes the contributing population as "both human and automated contributors". The fictitious "Prns Tests" identity completes the picture: A manufactured, unknowable contributor, used for marketing content. - -**Authorship by assignment** - -The human whose name is on the work cannot answer for it, because the choices were never made by a human, and only the general shape and constraints of the outward presentation was. Nothing in the project's history shows an individual explaining a design decision, accepting a mistake in the first person, or going deeper under technical questioning; the record shows process language and marketing instead. Per the earlier mentioned test: any other person could have pressed the same button, and nothing would be different. The project is effectively unowned, and void of value. - -By the criteria of :ref:`Assistance Versus Machine Substitution`, this is substitution. The machine was the agent of the work; the "author" was a facade. - -.. _brandolinis-prns-performance: - -The performance claims -^^^^^^^^^^^^^^^^^^^^^^ - -The project's central marketing claim - "up to 89× the throughput" of the reference - is also its most completely documented failure, because the project published the evidence of its own measurement. The apparatus, the results, and the problems are all on the record. - -**The claim** - -The README states "up to 89× the throughput"; 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"; the website's front page carries the tagline "Measured, not just claimed". - -**The apparatus** - -The reference is loaded through ``benchmarks/reference/compiled_reference.py``\ , which installs ``pyximport`` and then asserts two things: that ``RNS.compiled == True``\ , and that at least *one* RNS module was loaded from a native extension. The project's own published "proof" records show exactly what those checks captured, on every platform: - -.. code-block:: - - aarch64-apple-darwin: .../RNS.cpython-313-darwin.so, Cython 3.2.8, Python 3.13.13 - x86_64-unknown-linux-gnu: .../RNS.cpython-313-x86_64-linux-gnu.so, gcc 11.4.0 - x86_64-pc-windows-msvc: ~/.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.so``\ , nothing below it. Nothing named ``RNS.Transport``\ , ``RNS.Destination``\ , ``RNS.Packet``\ , ``RNS.Link``\ , or ``RNS.Resource`` ever appears, because *nothing below the top level was ever compiled*. Nobody bothered to check or verify *anything* here. - -The machine output was simply taken for truth, and a full marketing strategy was spun and produced on it. "RNS 1.4.2 (compiled)" - the label used in every table, chart, and marketing page - *is not a mode of RNS that exists*, but the hallucinations of a machine, which the humans created a marketing strategy on. In reality, it is the old ``CRNS`` development shim, whose top-level-only, debug-oriented "compilation" is slower than plain interpreted RNS, and which was *defunct for over a year* before these benchmarks were published. - -**Interface choices** - -The harness writes the reference's configuration itself (\ ``benchmarks/reference/participant_node.py``\ ): ``TCPClientInterface`` for the initiator, ``TCPServerInterface`` for the responder and both relay sides, with ``UDPInterface`` as the abstract wire. The reference was never given its modern ``BackboneInterface`` on any platform, forcing the slowest possible interrfaces. The interface selection is never mentioned in any methodology text. - -**The policy** - -The published default-policy tables record the asymmetry directly: Prns at 500 Mbps / 128 KiB TCP policy against the reference at 10 Mbps / 8 KiB - slyly footnoted as "preserves each implementation's normal TCP policy" (in the case of RNS, a conservative default policy that was selected to prioritize coexistence on slower, shared links, requiring the user to dial it up to full speed if they knew what they were doing). Raw transport "throughput" ratios of 20.65× (Linux) and 38.84× (Windows) are therefore mostly policy, not engine. - -**The cross-host evidence** - -The published results show the same scenario producing wildly different ratios by host, and the variance is entirely in the reference artifact: - -.. list-table:: - :header-rows: 1 - - * - Host - - Prns, single-packet - - "Reference", single-packet - - Ratio - * - macOS (Apple M4) - - 37.4k/s - - 420/s - - 89.09× - * - Linux (i7-1260P) - - 25.3k/s - - 3.5k/s - - 7.19× - * - Windows (Ryzen 5 5600X) - - 30.8k/s - - 3.9k/s - - 8.00× - -Prns is consistent (25–37k/s). The reference artifact collapses to different depths on different hosts, and the single worst collapse - 420 packets per second on macOS - is the cell selected as the global headline. The "89×" is not a measure of Prns; it is a measure of how badly the broken baseline happened to fail on one host. - -For reality calibration: Stock, interpreted RNS 1.5.4 on an ordinary mid-range laptop, single core, sustains roughly 30,000 single-packet deliveries per second (including ephemeral-key decryption), ~175,000–280,000 packets per second in transit relay, and on the order of 10 Gbps at 16 KiB payloads. The project's "compiled" artifact measured 420–3,900 packets per second for its single-packet scenario: An order of magnitude or more *below* stock interpreted RNS. The comparison being marketed was not "Rust vs Python"; **it was "an implementation running under optimal conditions versus a mislabeled, broken shim on a slow legacy interface at a severe policy disadvantage"**. - -**The equalized rows** - -The project's own "1 Gbps policy" rows, in which both sides are explicitly configured identically, publish ratios of roughly 2.4–8.4× across all hosts and scenarios - still against the broken baseline, but nowhere near 89×, and consistent with the ordinary, uncontroversial observation that a native implementation tends to outperform an interpreted one in raw throughput. That point needed no fudging to make, and is banal. - -Interestingly, though, it seems that Prns is really only *marginally* faster than a Python implementation, running in interpreted mode, on a single CPU core. - -**Assessment** - -The front page says "Measured, not just claimed." The record shows the opposite ordering: claimed, and arranged to look measured. No methodology section anywhere states what "compiled" means, that it is a deprecated development shim, that it builds debug targets, or which interface the reference was given; the one statement of the policy asymmetry appears in a footnote of the results tables themselves. If they did not need to fudge it, they would have published the method clearly. - -.. _brandolinis-prns-overall: - -Overall Evaluation -^^^^^^^^^^^^^^^^^^ - -Evaluated against the conditions of :ref:`Evaluating A Reticulum Implementation`: - -* **Provenance and attribution.** Fails: The fake "ground-up" origin story; zero reference links - on the website; a single well-hidden link in the README; a license file reading - ``Copyright (c) 2026 The Prns Authors`` over work directly generated from the licensed reference; - no original copyright or permission notice anywhere. -* **Agency and answerability.** Fails on every criterion of :ref:`Assistance Versus Machine Substitution`: - Unauthored scope, uniform generation, discovery by regeneration, laundered provenance, - authorship by assignment. -* **Engineering.** Fails: The benchmark apparatus above; interop demonstrated only - against a pinned, outdated reference version over loopback while the marketing claims current - parity, interop failures with stock RNS; vendored prebuilt binaries and a republished fork - of an upstream crate (``nrf-softdevice 0.1.0-prns.1``) with no verifiable provenance; - committed WASM bundles. -* **Network behaviour.** Fails: Invented spectrum behaviour and compatibility claims - about third-party applications of the reference ecosystem (Sideband, NomadNet, MeshChat) - that are not established by any evidence. -* **Monetary and influence signals.** The marketing apparatus - website before protocol, - day-three twelve-language marketing, false benchmark headlines, "audited" and "formal proof" - claims - the conformal surface described in :ref:`Evaluating A Reticulum Implementation`: - is where this project invested. - -.. _brandolinis-prns-licensing: - -Licensing Analysis -^^^^^^^^^^^^^^^^^^ - -Applying the two legal layers established in :ref:`Copyright & The Two Legal Layers`: - -**Layer A - copyright infringement (license-independent)** - -The record shows a direct copy roundtrip: the licensed reference implementation fed into a machine, transformed, at a scale and cadence no human could review, with a license file asserting a fresh copyright in the operator's name and no acknowledgment of the work the project was generated from. No substantial, new human creative input is demonstrated anywhere in the record - the founding document explicitly frames the design as an instructed port of the reference's contract. A primarily machine-generated copy of a copyrighted work, not accompanied by demonstrable substantial human creative input, is a derivative work over which the copier holds no copyright, and a reproduction of which without the original author's permission infringes the original author's copyright. This holds under any license, MIT included. The operator's copyright claim over the result is, on this evidence, not merely unsubstantiated; it is the absence of one, directly asserted in the project's own writing. - -**Layer B - license conditions (Reticulum License specific)** - -Modern Reticulum - the current wire format, the AES-256-based link encryption, ratchets, the cryptographic machinery as it exists today - has been published under the Reticulum License since April 15, 2025, effective from release 0.9.4 and every release since. As a derivative of that work, the license's conditions attach: The copyright and permission notice must be included in all copies and substantial portions; the AI-training condition must be honoured; the harm condition must be honoured. The record shows none of the notice requirements met, and a production process that consists of the licensed work being ingested into a machine and regurgitated, at industrial scale and cadence. - -**The cascading consequence** - -Prns is distributed claiming dual MIT/Apache-2.0 licensing. It is, however, a direct derivative of Reticulum-licensed work, and the claimed grant is therefore void. Every downstream project that builds on Prns believing it is MIT/Apache-licensed is building on a grant that does not exist. The users of Prns, and all software developers using it, have in effect, been placed under conditions they were never told about. The "ground-up" claim is not merely false; it is the sole load-bearing element of an entire licensing posture, and it fails spectacularly. - -.. _brandolinis-prns-consequences: - -Consequences -^^^^^^^^^^^^ - -The consequences of this pattern are examined in the following sections - the harm to users and to the network in :ref:`A Movement Of A Dozen`, and the human dimension in :ref:`Network Health & Coexistence`. This section's contribution is narrower and intended as an instructive example: This is what a substitution project looks like, in full, on its own record. It is a reference example for :ref:`Evaluating A Reticulum Implementation`, and it demonstrates, in one case, most of the elements this chapter describes. - -.. _brandolinis-prns-verdict: - -Verdict -^^^^^^^ - -Applying the three verdicts of :ref:`Evaluating A Reticulum Implementation`, this project does not meet the standard. It is not "experimental but honest" - it is not labeled as experimental anywhere; the first thing users saw was a polished marketing presence promising a finished, tested, drop-in replacement. It is a project whose central claims are fabricated (the performance apparatus), whose provenance is laundered (the authorship machinery), whose foundation is misrepresented (the "ground-up" story), whose core semantics were learned late and by regeneration, and whose operator cannot possibly answer for any of it. It is also a blatant copyright violation of the reference implementation. - -The proposed conclusion, for users and for the network: Treat the Prns project as hostile regardless of its polished surface, and as a hazard insofar as it invites users onto shared networks. Nothing in this section is a judgment about the people involved; it is a reading of the results produced, their history and how they came to be, which in the regrettable lack of any human authorship is the only thing that can be expected to be held to account. - -.. _brandolinis-prns-dating: - -Dating -^^^^^^ - -This examination reflects the publicly available material as of September 2026; the repository in question continued to receive commits at the time of writing, so readers should treat citations to commits and files as point-in-time evidence. A `forensics snapshot `_ is publicly available on GitHub. - .. _brandolinis-movement-of-a-dozen: The Movement Of A Dozen @@ -1322,4 +1065,261 @@ A lot of us rely on these networks every day. They carry our messages, our coord They are valuable, free, and very hard to shut down. The response is not to become aggressive. It is to be *more* of what the network already is: Real, open, owned, and shared. -*Mark* \ No newline at end of file +*Mark* + +.. _brandolinis-prns: + +Addendum A: The Prns Case +------------------------- + +.. _brandolinis-purpose-and-scope: + +Purpose & Scope +^^^^^^^^^^^^^^^ + +This section provides a concrete example, which future evaluations can use as a template. Its purpose is not to be the last word on this particular subject, but to be an example of how the ideas in this chapter can be applied, and to make the next such examination easier. + +The subject of this case study is **Prns**\ , a project published at the repository ``github.com/KenAKAFrosty/Prns``\ , presented as a "ground-up implementation of Reticulum, written in Rust", marketed as faster, safer, and more strictly tested than the reference, and widely promoted with the claim of "up to 89× the throughput" of the reference implementation. The record described below is the project's own, and sourced from its GitHub repository, analyzed locally. + +.. _brandolinis-project-in-brief: + +The Project In Brief +^^^^^^^^^^^^^^^^^^^^ + +* **Time span.** 3,374 commits between 2026-05-26 and 2026-09-12: approximately 110 days, + at a mean rate of ~31 commits per day. Monthly: 132 / 1,137 / 1,097 / 805 / 203. +* **Authorship.** 3,252 of 3,374 commits (96.4%) are authored by a single account. A + second identity, "Prns Tests tests@example.test" - a fictitious identity on a reserved + domain - contributed 35 commits, every one of them website and marketing content. +* **Size.** 3,519 tracked files; 1,983 Rust files; 636,226 lines of Rust; approximately + 22.7 MB of Rust source; 69.5 MB of total repository content. +* **Scope claimed.** A daemon ("drop-in replacement" for the reference daemon), embedded + firmware for three microcontroller families (including six ESP32-S3 board variants and + nRF52840), SDKs and bindings for nine languages, a browser-based node and web flasher, a + twelve-language website, a benchmark apparatus with its own publication and "proof" + pipeline, and a validation hub with oracles, fuzzing, mutation testing, and formal-proof + claims. +* **Marketing claims.** "Ground-up implementation of Reticulum"; "up to 89× the + throughput"; "48× smaller peak-memory footprint"; "33× the energy efficiency"; + "Measured, not just claimed"; "Enforced, then audited"; "byte-for-byte wire parity with + the reference implementation"; "works with Sideband, NomadNet, MeshChat, etc."; + "no_std (no alloc required either)". +* **Status at the time of writing.** Version 0.3.7; published version history begins at + 0.3.0. The repository continues to receive commits. + +.. _brandolinis-prns-question-1: + +Question 1: Is this a clean implementation, or was it directly generated from the reference? +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The first of the two deciding questions from :ref:`Evaluating A Reticulum Implementation` is settled by the project's own record. An actual :ref:`clean-room` implementation, reasoned out and written by humans, would owe nothing to any license. The data available shows clearly that Prns is not that. + +* **The founding state.** The first commit, "Scaffold Personal Reticulum suite", contains + the scaffolding of not one but two ports - ``personal-rns`` and ``personal-lxmf``\ , the latter + being the reference's companion messaging protocol - together with a daemon scaffold and + a 233-line founding document, ``docs/build-ethos.md``. That document declares the project's + goal as a "performance-focused drop-in-replacement for rnsd" and its governing principle + as: "Port the contract, not the implementation." It further states directly to the + machine-loop, that **"You owe the reference fidelity at exactly two boundaries: + The wire... The behavior. ... Between those two boundaries, the model is yours"**. + At this point, the very first commit, effectively the whole of the implementation design + and any relevant decisions are handed over to the LLM. +* **Continuous ingestion from the reference.** 506 commits reference RNS or Reticulum + source behaviour; the word "parity" appears in 49 commit messages. Commits cite the reference + implementation's own source locations (for example ``Transport.py:1367``) when correcting + their own divergences and mistakes. +* **Byte-level fidelity as an explicit goal.** Within 48 hours of the first commit, the + record shows a "crypto adapter - vetted primitives, byte-exact vs RNS 1.3.1", and a wire + implementation matching the reference's packet header layout. The project's own + validation apparatus decodes wire vectors using the reference implementation's own + packet parser, and the interop suite consists of real, stock-RNS peer nodes - that is, + the reference source itself, used as the ground truth against which this LLM output is + checked, and committed as accepted and verified after 48 hours of the project's recorded start. +* **The marketing mismatch.** The same record that documents all of the above describes the + project, publicly, as "a ground-up implementation of Reticulum" - while declining, on its + website, to link to the reference implementation at all: the entire tree mentions the + reference's author in six files, and the website in none. + +Conclusion: the project's own history and commit record establishes that it was generated directly from the reference implementation's source code, not reasoned out from the public-domain protocol. It is a derivative of licensed work within the meaning of :ref:`the Reticulum License` and :ref:`general copyright law`. The "ground-up" claim, which carries its entire legal and marketing posture, is disproven by the project's own history. + +.. _brandolinis-prns-question-2: + +Question 2: Who, or what, is the agent of the work? +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The second deciding question is answered by the application of :ref:`Assistance Versus Machine Substitution` criteria to the project. + +**Scope that no human could have authored** + +636,226 lines of Rust in 110 days is approximately 5,800 lines per day, every day, including weekends - with 149 commits recorded between midnight and 06:00, and Saturday the single busiest weekday. No human review or decision capacity is commensurable with this volume; the review capacity and the output volume are structurally incommensurable, which is the definition of unauthored scope. + +**Uniform generation** + +The record shows no sign of human development, growth, or learning: No contested decisions, no style drift. Instead: endless renaming (in the first 48 hours: ``State → EngineState → TickInput → TickOutput``\ ), uniform fluent register in every commit, and the exact same, synthetic voice in code, documentation, and website copy. + +**Discovery by regeneration** + +Corrections arrived by the machine's own subsequent runs, recorded as planned milestones. In early July 2026, a series of "core review" commits documented, in the project's own words: + +* announce-ID history "was unbounded per-slot growth" (\ ``54cc8d601``\ ); +* interface announce limiting could "leak a sustained flood" (\ ``9d27af75c``\ ); +* a "phantom-airtime leak" where frames "used to vanish silently" (\ ``4ed75ffdd``\ ); +* Group-packet deduplication "which RNS does not do" - a behaviour the reference never had, + implemented and later removed (\ ``edd8e72be``\ ); +* "both ``unwrap_or(&[])`` arms were unreachable dead defaults" (\ ``74bea355e``\ ); +* a benchmark crate "hasn't compiled since" a prior rename, undetected for weeks because it + was outside the CI's workspace (\ ``86240b027``\ ). + +Earlier still: the record shows a ">1 MiB RNS-to-Prns interop stall" closed three weeks in +(\ ``cc4d524a3``\ ), and a known send-path hang shipped with the note "typed fast-fail a +candidate for later" (\ ``a010e6613``\ ). + +**Laundered provenance** + +The repository contains a committed commit-message hook (\ ``.githooks/commit-msg``\ ) that *blocks* any commit containing attribution for machine generation ("generated with claude/codex/copilot/cursor/gemini", "co-authored-by"), with the explanation "The committer owns the commit". The contributing guide is explicit: "AI tools ... are welcome ... what you submit is *yours*", and describes the contributing population as "both human and automated contributors". The fictitious "Prns Tests" identity completes the picture: A manufactured, unknowable contributor, used for marketing content. + +**Authorship by assignment** + +The human whose name is on the work cannot answer for it, because the choices were never made by a human, and only the general shape and constraints of the outward presentation was. Nothing in the project's history shows an individual explaining a design decision, accepting a mistake in the first person, or going deeper under technical questioning; the record shows process language and marketing instead. Per the earlier mentioned test: any other person could have pressed the same button, and nothing would be different. The project is effectively unowned, and void of value. + +By the criteria of :ref:`Assistance Versus Machine Substitution`, this is substitution. The machine was the agent of the work; the "author" was a facade. + +.. _brandolinis-prns-performance: + +The performance claims +^^^^^^^^^^^^^^^^^^^^^^ + +The project's central marketing claim - "up to 89× the throughput" of the reference - is also its most completely documented failure, because the project published the evidence of its own measurement. The apparatus, the results, and the problems are all on the record. + +**The claim** + +The README states "up to 89× the throughput"; 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"; the website's front page carries the tagline "Measured, not just claimed". + +**The apparatus** + +The reference is loaded through ``benchmarks/reference/compiled_reference.py``\ , which installs ``pyximport`` and then asserts two things: that ``RNS.compiled == True``\ , and that at least *one* RNS module was loaded from a native extension. The project's own published "proof" records show exactly what those checks captured, on every platform: + +.. code-block:: + + aarch64-apple-darwin: .../RNS.cpython-313-darwin.so, Cython 3.2.8, Python 3.13.13 + x86_64-unknown-linux-gnu: .../RNS.cpython-313-x86_64-linux-gnu.so, gcc 11.4.0 + x86_64-pc-windows-msvc: ~/.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.so``\ , nothing below it. Nothing named ``RNS.Transport``\ , ``RNS.Destination``\ , ``RNS.Packet``\ , ``RNS.Link``\ , or ``RNS.Resource`` ever appears, because *nothing below the top level was ever compiled*. Nobody bothered to check or verify *anything* here. + +The machine output was simply taken for truth, and a full marketing strategy was spun and produced on it. "RNS 1.4.2 (compiled)" - the label used in every table, chart, and marketing page - *is not a mode of RNS that exists*, but the hallucinations of a machine, which the humans created a marketing strategy on. In reality, it is the old ``CRNS`` development shim, whose top-level-only, debug-oriented "compilation" is slower than plain interpreted RNS, and which was *defunct for over a year* before these benchmarks were published. + +**Interface choices** + +The harness writes the reference's configuration itself (\ ``benchmarks/reference/participant_node.py``\ ): ``TCPClientInterface`` for the initiator, ``TCPServerInterface`` for the responder and both relay sides, with ``UDPInterface`` as the abstract wire. The reference was never given its modern ``BackboneInterface`` on any platform, forcing the slowest possible interrfaces. The interface selection is never mentioned in any methodology text. + +**The policy** + +The published default-policy tables record the asymmetry directly: Prns at 500 Mbps / 128 KiB TCP policy against the reference at 10 Mbps / 8 KiB - slyly footnoted as "preserves each implementation's normal TCP policy" (in the case of RNS, a conservative default policy that was selected to prioritize coexistence on slower, shared links, requiring the user to dial it up to full speed if they knew what they were doing). Raw transport "throughput" ratios of 20.65× (Linux) and 38.84× (Windows) are therefore mostly policy, not engine. + +**The cross-host evidence** + +The published results show the same scenario producing wildly different ratios by host, and the variance is entirely in the reference artifact: + +.. list-table:: + :header-rows: 1 + + * - Host + - Prns, single-packet + - "Reference", single-packet + - Ratio + * - macOS (Apple M4) + - 37.4k/s + - 420/s + - 89.09× + * - Linux (i7-1260P) + - 25.3k/s + - 3.5k/s + - 7.19× + * - Windows (Ryzen 5 5600X) + - 30.8k/s + - 3.9k/s + - 8.00× + +Prns is consistent (25–37k/s). The reference artifact collapses to different depths on different hosts, and the single worst collapse - 420 packets per second on macOS - is the cell selected as the global headline. The "89×" is not a measure of Prns; it is a measure of how badly the broken baseline happened to fail on one host. + +For reality calibration: Stock, interpreted RNS 1.5.4 on an ordinary mid-range laptop, single core, sustains roughly 30,000 single-packet deliveries per second (including ephemeral-key decryption), ~175,000–280,000 packets per second in transit relay, and on the order of 10 Gbps at 16 KiB payloads. The project's "compiled" artifact measured 420–3,900 packets per second for its single-packet scenario: An order of magnitude or more *below* stock interpreted RNS. The comparison being marketed was not "Rust vs Python"; **it was "an implementation running under optimal conditions versus a mislabeled, broken shim on a slow legacy interface at a severe policy disadvantage"**. + +**The equalized rows** + +The project's own "1 Gbps policy" rows, in which both sides are explicitly configured identically, publish ratios of roughly 2.4–8.4× across all hosts and scenarios - still against the broken baseline, but nowhere near 89×, and consistent with the ordinary, uncontroversial observation that a native implementation tends to outperform an interpreted one in raw throughput. That point needed no fudging to make, and is banal. + +Interestingly, though, it seems that Prns is really only *marginally* faster than a Python implementation, running in interpreted mode, on a single CPU core. + +**Assessment** + +The front page says "Measured, not just claimed." The record shows the opposite ordering: claimed, and arranged to look measured. No methodology section anywhere states what "compiled" means, that it is a deprecated development shim, that it builds debug targets, or which interface the reference was given; the one statement of the policy asymmetry appears in a footnote of the results tables themselves. If they did not need to fudge it, they would have published the method clearly. + +.. _brandolinis-prns-overall: + +Overall Evaluation +^^^^^^^^^^^^^^^^^^ + +Evaluated against the conditions of :ref:`Evaluating A Reticulum Implementation`: + +* **Provenance and attribution.** Fails: The fake "ground-up" origin story; zero reference links + on the website; a single well-hidden link in the README; a license file reading + ``Copyright (c) 2026 The Prns Authors`` over work directly generated from the licensed reference; + no original copyright or permission notice anywhere. +* **Agency and answerability.** Fails on every criterion of :ref:`Assistance Versus Machine Substitution`: + Unauthored scope, uniform generation, discovery by regeneration, laundered provenance, + authorship by assignment. +* **Engineering.** Fails: The benchmark apparatus above; interop demonstrated only + against a pinned, outdated reference version over loopback while the marketing claims current + parity, interop failures with stock RNS; vendored prebuilt binaries and a republished fork + of an upstream crate (``nrf-softdevice 0.1.0-prns.1``) with no verifiable provenance; + committed WASM bundles. +* **Network behaviour.** Fails: Invented spectrum behaviour and compatibility claims + about third-party applications of the reference ecosystem (Sideband, NomadNet, MeshChat) + that are not established by any evidence. +* **Monetary and influence signals.** The marketing apparatus - website before protocol, + day-three twelve-language marketing, false benchmark headlines, "audited" and "formal proof" + claims - the conformal surface described in :ref:`Evaluating A Reticulum Implementation`: + is where this project invested. + +.. _brandolinis-prns-licensing: + +Licensing Analysis +^^^^^^^^^^^^^^^^^^ + +Applying the two legal layers established in :ref:`Copyright & The Two Legal Layers`: + +**Layer A - copyright infringement (license-independent)** + +The record shows a direct copy roundtrip: the licensed reference implementation fed into a machine, transformed, at a scale and cadence no human could review, with a license file asserting a fresh copyright in the operator's name and no acknowledgment of the work the project was generated from. No substantial, new human creative input is demonstrated anywhere in the record - the founding document explicitly frames the design as an instructed port of the reference's contract. A primarily machine-generated copy of a copyrighted work, not accompanied by demonstrable substantial human creative input, is a derivative work over which the copier holds no copyright, and a reproduction of which without the original author's permission infringes the original author's copyright. This holds under any license, MIT included. The operator's copyright claim over the result is, on this evidence, not merely unsubstantiated; it is the absence of one, directly asserted in the project's own writing. + +**Layer B - license conditions (Reticulum License specific)** + +Modern Reticulum - the current wire format, the AES-256-based link encryption, ratchets, the cryptographic machinery as it exists today - has been published under the Reticulum License since April 15, 2025, effective from release 0.9.4 and every release since. As a derivative of that work, the license's conditions attach: The copyright and permission notice must be included in all copies and substantial portions; the AI-training condition must be honoured; the harm condition must be honoured. The record shows none of the notice requirements met, and a production process that consists of the licensed work being ingested into a machine and regurgitated, at industrial scale and cadence. + +**The cascading consequence** + +Prns is distributed claiming dual MIT/Apache-2.0 licensing. It is, however, a direct derivative of Reticulum-licensed work, and the claimed grant is therefore void. Every downstream project that builds on Prns believing it is MIT/Apache-licensed is building on a grant that does not exist. The users of Prns, and all software developers using it, have in effect, been placed under conditions they were never told about. The "ground-up" claim is not merely false; it is the sole load-bearing element of an entire licensing posture, and it fails spectacularly. + +.. _brandolinis-prns-consequences: + +Consequences +^^^^^^^^^^^^ + +The consequences of this pattern are examined in the following sections: The harm to users and to the network in :ref:`A Movement Of A Dozen`, and the human dimension in :ref:`Network Health & Coexistence`. The contribution of this addendum is narrower and intended as an instructive example: This is what a substitution project looks like, in full, on its own record. It is a reference example for :ref:`Evaluating A Reticulum Implementation`, and it demonstrates, in one case, most of the elements this chapter describes. + +.. _brandolinis-prns-verdict: + +Verdict +^^^^^^^ + +Applying the three verdicts of :ref:`Evaluating A Reticulum Implementation`, this project does not meet the standard. It is not "experimental but honest" - it is not labeled as experimental anywhere; the first thing users saw was a polished marketing presence promising a finished, tested, drop-in replacement. It is a project whose central claims are fabricated (the performance apparatus), whose provenance is laundered (the authorship machinery), whose foundation is misrepresented (the "ground-up" story), whose core semantics were learned late and by regeneration, and whose operator cannot possibly answer for any of it. It is also a blatant copyright violation of the reference implementation. + +The proposed conclusion, for users and for the network: Treat the Prns project as hostile regardless of its polished surface, and as a hazard insofar as it invites users onto shared networks. Nothing in this section is a judgment about the people involved; it is a reading of the results produced, their history and how they came to be, which in the regrettable lack of any human authorship is the only thing that can be expected to be held to account. + +.. _brandolinis-prns-dating: + +Dating +^^^^^^ + +This examination reflects the publicly available material as of September 2026; the repository in question continued to receive commits at the time of writing, so readers should treat citations to commits and files as point-in-time evidence. A `forensics snapshot `_ is publicly available on GitHub.