# Leviculum Assessment Against `SPEC.md`

Date: 2026-06-09

## Executive conclusion

Leviculum is the strongest of the two staged Rust Reticulum implementations
and is a credible implementation of most of the Reticulum network layer.
Its `no_std` sans-I/O core, broad protocol coverage, extensive unit tests, and
Python interoperability infrastructure put it substantially ahead of the
sibling `Reticulum-rs`.

It is not, however, a complete implementation of this repository's
`SPEC.md`, and its claims of providing the same functionality as Python
Reticulum and having a functionally complete protocol implementation are too
broad.

The most important findings are:

1. `GROUP` destinations are represented but not implemented with the required
   shared symmetric Token key. They instead use SINGLE-style identity ECDH.
2. There is no native LXMF implementation. Leviculum's LXMF integration tests
   run Python LXMF helpers against `lnsd`; they validate daemon compatibility,
   not native compliance with `SPEC.md` section 5.
3. Transport tunnels are explicitly not implemented.
4. Resource receive supports segment metadata, but sender-side multi-segment
   Resources are explicitly not implemented.
5. Busy-mesh controls added or refined in current RNS, including per-interface
   path-request limiting and held-announce ingress control, are absent.
6. Interface modes are explicitly not implemented; all interfaces behave as
   full-mode interfaces.
7. Blackhole operations are RPC stubs and the announce receive path does not
   enforce the specification's blackhole check.
8. Leviculum has useful Python-derived vectors, but it does not consume this
   specification project's thirteen-domain deterministic vector suite.

The practical verdict is:

- **Core leaf/node RNS behavior:** strong.
- **Ordinary transport relay behavior:** strong, with important operational
  omissions.
- **Full drop-in `rnsd` behavior:** incomplete.
- **Full `SPEC.md` clean-room implementation:** incomplete.
- **Native LXMF implementation:** absent.

## Assessment basis

This assessment used:

- specification repository target:
  `Reticulum@422dc055` (`RNS 1.3.5`) and
  `LXMF@fab12ad` (`LXMF 1.0.1`);
- Leviculum commit:
  `6f366ca04f64075acf4dc3d90e1dda88b23d325d`;
- sibling `Reticulum-rs` commit:
  `d68c4f5a22f12915004fb38dcc8e15c596d89edf`;
- the prior staged-project comparison in
  `/usr/local/src/reticulum/rust/Code_Response_1.md`;
- source inspection, repository tests, and comparison with the normative and
  behavioral requirements in `SPEC.md`.

Repository claims were treated as claims until supported by code or tests.
No source files in Leviculum or `Reticulum-rs` were modified.

## Major findings

### High: GROUP destinations use the wrong cryptographic construction

`SPEC.md` section 1.4 requires GROUP destinations to use a pre-shared
32- or 64-byte Token key and emit:

```
iv || ciphertext || hmac
```

without an ephemeral X25519 public key.

Leviculum's `Destination` stores an `Identity` for GROUP destinations,
requires an identity for outbound GROUP destinations, and routes both
`encrypt()` and `decrypt()` through identity/ratchet ECDH:

- `reticulum-core/src/destination.rs:297-306`
- `reticulum-core/src/destination.rs:640-682`
- `reticulum-core/src/identity.rs:485-495`
- `reticulum-core/src/identity.rs:521-531`

This is not merely missing API surface. A GROUP packet produced by this path
has the wrong cryptographic wire body and will not interoperate with an
upstream GROUP destination.

### High: Native LXMF is absent

No Rust LXMF message packer/parser, signature layer, stamp/ticket
implementation, propagation-node protocol, or LXMF field implementation was
found.

The integration framework's LXMF scenarios spawn
`scripts/lxmf_node.py` inside Docker and drive that Python helper:

- `reticulum-integ/src/topology.rs:314-359`
- `reticulum-integ/src/lxmf.rs:1-8`
- `reticulum-integ/src/lxmf.rs:67-75`

Those tests provide useful evidence that Python LXMF can operate through
Leviculum's Reticulum daemon. They do not show that Leviculum implements:

- opportunistic, direct, or propagated LXMF wire formats;
- LXMF signature and msgpack tolerance;
- stamps and tickets;
- propagation `/offer` and `/get`;
- LXMF 1.0.1 field and capability semantics.

This is an application-layer scope gap rather than a defect in the RNS
transport core, but it is a major gap against the combined `SPEC.md`.

### High: Transport tunnels are absent

Leviculum recognizes the well-known tunnel-synthesis control destination only
to prevent accidental forwarding. Its source states:

> Tunnels are not implemented in Rust

at `reticulum-core/src/transport.rs:3622-3627`.

Therefore `SPEC.md` section 12.6.2 tunnel synthesis, detached-path retention,
and path restoration are not implemented. Shared-instance HDLC and local
client behavior are implemented separately and should not be conflated with
tunnel support.

### Medium: Sender-side multi-segment Resources are absent

Leviculum implements Resource fragmentation, hashmap continuation, Resource
proofs, compression, and incoming segment metadata. Outgoing advertisements,
however, hard-code `segment_index = 1` and `total_segments = 1`:

- `reticulum-core/src/resource/outgoing.rs:267-279`
- `reticulum-core/src/node/link_management.rs:2168-2171`

The source explicitly says multi-segment sending is not yet implemented.
Payloads above the `SPEC.md` section 10.11 cutover therefore do not receive the
required chained Resource treatment.

### Medium: Current busy-mesh ingress controls are incomplete

Leviculum implements per-destination path-request minimum intervals,
announce-rate behavior, announce caps, and bounded state. It does not expose
the RNS 1.2.5+ per-interface path-request ingress/egress limiter state or the
RNS announce `held_announces` ingress-control queue.

Evidence includes:

- no path-request ingress/egress limiter methods or timestamp deques;
- RPC interface stats report `held_announces = 0`;
- the receive path validates and immediately processes announces rather than
  holding unknown destinations under interface burst load.

These omissions do not alter ordinary wire bytes. They do alter transport-node
behavior and denial-of-service resistance under heavy announce or path-request
load. See `SPEC.md` sections 4.5.8 and 7.2.3.

### Medium: Interface modes are absent

Leviculum documents that all interfaces behave as `MODE_FULL`:

- `docs/src/architecture-broadcast-python-parity.md:414-420`
- `reticulum-core/src/transport.rs:3807-3811`

This is adequate for many simple deployments, but it diverges from upstream
path discovery, rebroadcast selection, and path lifetime behavior on access
point, roaming, boundary, gateway, and point-to-point interfaces.

### Medium: Blackhole enforcement is absent

`SPEC.md` section 4.5 requires an announce receiver to reject blackholed
identities. Leviculum's blackhole RPC operations return successful stub
responses without maintaining or applying a blackhole set:

- `reticulum-std/src/rpc/handlers.rs:52-55`

The core announce path validates signature and destination hash, but no
blackhole enforcement was found. This is an operational and security-control
gap, not a byte-format mismatch.

### Medium: The completed specification vectors are not a Leviculum gate

Leviculum's Python-derived vector suite is valuable, but its
`reticulum-core/tests/test_vectors.rs` currently covers foundational identity,
crypto, packet, announce, IFAC, and Link-handshake domains.

It does not consume this repository's completed vectors for Resource,
link-LXMF, request/response, propagated LXMF, propagation peer sync,
transport-link, transport-data, transport-announce, or transport-tunnel.
Consequently the existing green test suite cannot be interpreted as a pass of
the completed specification suite.

## Strongly covered areas

Source and tests show substantial implementation depth in:

- identity serialization, signing, ECDH, Token crypto, and ratchets;
- packet headers, IFAC, KISS, HDLC, BLE, RNode, and AutoInterface framing;
- announce parsing, signature validation, replay handling, and path updates;
- path discovery and ordinary transport forwarding;
- Link request/proof/activation, MTU signaling, keepalive, close, identify,
  receipts, and Channel;
- Resource packet flow, compression, retransmission, and incoming assembly;
- Link REQUEST/RESPONSE and authorization modes;
- shared-instance local interfaces and Python CLI RPC compatibility;
- bounded embedded storage and a genuine `no_std + alloc` core.

The codebase also contains unusually broad interop, topology, fault-injection,
LoRa, and hardware-test infrastructure for a pre-production implementation.

## Comparison with `Reticulum-rs`

The previous comparison remains valid after applying the completed
specification as the measuring stick.

`Reticulum-rs` is smaller, MIT-licensed, and easier to understand, but lacks
major protocol subsystems including Resources, Channels, ratchets, shared
instance, persistence, RNode, and a genuine `no_std` core. Its remaining TODOs
also affect transport behavior.

Leviculum is therefore the clear Rust baseline for further specification
conformance work. The gaps identified here are bounded additions or
corrections within an architecture that already supports most of the required
stack. Closing equivalent gaps in `Reticulum-rs` would require a much larger
expansion and, for embedded use, architectural redesign.

## Verification performed

Commands used a GNU target override and a writable temporary target directory
because Leviculum defaults to musl and its staged checkout is read-only in this
environment.

Results:

- `cargo test -p reticulum-core --lib --target x86_64-unknown-linux-gnu`
  - **1109 passed; 0 failed**
- `cargo test -p reticulum-core --tests --target x86_64-unknown-linux-gnu`
  - **1109 unit tests, 18 property tests, and 31 Python-derived vector tests
    passed**
- `cargo test -p reticulum-std --lib --target x86_64-unknown-linux-gnu`
  - **191 passed; 32 failed; 2 ignored**
  - the 32 failures were dominated by sandbox-denied socket operations
    (`Operation not permitted`); one fixture-dependent
    `known_destinations` test also failed because no entries were present.
    These results do not establish product defects, but the full std suite was
    not green in this environment.

Docker interop, full topology tests, vendored-Python interop, embedded builds,
and physical hardware tests were not run.

## Recommended conformance path

Priority order:

1. Import this repository's thirteen deterministic vector domains into a
   Leviculum conformance test target and publish a pass/fail matrix.
2. Correct GROUP destinations or explicitly reject GROUP construction until
   the shared-key Token form is implemented.
3. Implement transport tunnels if `lnsd` is to be described as a drop-in
   `rnsd` replacement.
4. Implement sender-side multi-segment Resources and test the exact
   `MAX_EFFICIENT_SIZE` boundary.
5. Add RNS 1.3.x per-interface path-request limiting and announce ingress
   holding with signature prevalidation before held-state insertion.
6. Implement interface modes and blackhole enforcement, or narrow public
   compatibility claims to the supported deployment profile.
7. Treat native LXMF as a separate project milestone. Until then, describe
   Leviculum as an RNS implementation capable of carrying upstream Python
   LXMF, not as an implementation of the combined RNS/LXMF specification.

After these gates, rerun the specification vectors in both directions against
the pinned RNS 1.3.5 / LXMF 1.0.1 sources and then run Leviculum's Docker and
hardware interop tiers.