[l5yth]

Ref #888

Findings from a live RNode + rnsd test, where the shipped behaviour from #889/#890/#893 did not survive contact with a real stack.

One node record per identity (RE7, superseding RE1). A peer announcing lxmf.delivery, lxmf.propagation and nomadnetwork.node is one node with three destinations, not three nodes. RE1 had split them to stop a merged row being named from one aspect and roled from another; the destinations table (RE2) already carries the per-aspect name and role, so the split bought nothing and cost the node count its meaning. Verified against RNS: Destination.hash reproduces all three field destination hashes from identity 27716218... alone.

Destinations become a table, and are served. destinations (id, node_id, identity_hash, name, aspect, role, interface, first_heard, last_heard, protocol) replaces the nodes.dest_hash JSON column -- a column and a table modelling one relationship would drift -- and is served by GET /api/destinations. The write is its own forward-only statement outside the upsert's freshness guard, so a stale record's new destination is not dropped, and it still cannot regress last_heard or write through a synthetic placeholder.

A 0-hop announce is always ingested. Transport.inbound adds a hop to every inbound packet and takes it back for a local-client or shared-instance interface, so zero hops can only mean "announced by an app on this machine". Filtering purely on interface name hid the operator's own nodes, because every local destination legitimately reads LocalInterface[rns/default]. RETICULUM_INTERFACES now applies from one hop out; empty (the default) still ingests everything.

Share the operator's RNS stack. RETICULUM_CONFIG_DIR defaults to ~/.reticulum again; the config seeding and the allowlist's fail-open, both of which existed to work around an app-owned directory, are removed.

Derive the host node id the Reticulum way. canonical_node_id keeps the low 32 bits of a hex value -- right for a Meshtastic node num, wrong for a 16-byte identity hash, which it truncates from the opposite end: the ingestor registered !86c39940 while its own peer row read !27716218. Raw identity hashes now map through _reticulum_node_id. With INGESTOR_NODE_ID unset the id is derived from the transport identity rather than warned about.

Log the transmit gate only when it blocks something. The announcement policy check moves after the due check, so the suppression line names the gate when it actually blocks a due announcement instead of once per 60 s loop; the startup "Transmit policy resolved" line already carries that.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

[eknuth]

Pulled e0b7913 onto my Pi 5 (RNode + rnsd, shared instance, enable_transport = False) and ran it against a live stack. The host-id discovery works, and I like it better than what I did in #896: deriving from the primary announced identity means the ingestor's row is one an operator can actually recognise, instead of a synthetic key. Three things to report.

1. The README documents the approach you rejected

README.md tells operators the id comes from the transport identity, and hands them a command to predict it:

The ingestor derives its own node id from the config dir's transport identity

python -c "import RNS; RNS.Reticulum(configdir='$HOME/.reticulum'); \
  print('!' + RNS.Transport.internal_identity().hash.hex()[:8])"

The code does not do that. _derived_host_node_id() returns _reticulum_node_id(_primary_local_identity()), and your own module docstring is explicit that "the transport identity is deliberately not the node id".

Both on my box, same config dir:

README snippet says:     !1254d60f     (transport identity 1254d60f17f92697...)
code actually derives:   !e492a9cd     (primary local identity e492a9cd6fe8f0e0...)

So the README is describing the !fbf8e338 vs 27716218… bug this PR fixes, and its copy-paste command prints the wrong id. Line 340 (the env table) and line 446 both need it. Happy to push that fix to your branch if it is easier.

2. The PR title and body describe a different design than the head commit

The title says "key Reticulum nodes on destinations" and the body opens with "Key rows on the destination hash again (reverses RN1)". The head commit e0b7913 says "key Reticulum nodes on identity; discover host aspects", and the docstring still describes identity keying with aspects collapsing onto one row. Looks like the body did not get updated after the approach changed. Worth a pass before merge, since RN1 and the SPEC entries key off which way this went.

3. Changing the id rule strands the previous ingestor row

Not a defect, but it has now bitten twice on the same host. /api/ingestors on my instance:

!edabc002  reticulum    <- what I had pinned via INGESTOR_NODE_ID
!887391ba  reticulum    <- #896's generated identity
!e492a9cd  reticulum    <- this PR's primary local identity

Each id-scheme change leaves the old row behind, unheartbeated, until it ages out. I had drafted an upgrade caveat for #896 but did not push it, since you had this in flight and its premise changed. If you want, I will send a short note for the README and CHANGELOG against whatever lands: leaving INGESTOR_NODE_ID set is inert, removing or changing it moves the ingestor's node id, and the old row ages out.

Otherwise clean

• The RN10 line still earns its keep. My reticulum unit shares the meshtastic .env via EnvironmentFile, so it correctly reports the inherited TBeam CONNECTION as inapplicable.
• Config dir back to ~/.reticulum behaves as described, and it attaches to my running rnsd as a shared instance.
• No warnings or errors in the run, including against a web tier several commits behind, so the ingestor half degrades quietly.
• 1426 passed locally, black clean.

One small thing: at connect the startup line reads node_id=None, because the path table has nothing local yet. It resolves on a later daemon loop and registered fine, but an operator reading the startup log sees None and no indication that a retry is coming. A word in that log line, or logging the id once it resolves, would save someone a false alarm.

[l5yth]

Good findings, I fixed all three.