From 0576f04c36b5bd164a679becd4509b26210ff563 Mon Sep 17 00:00:00 2001 From: Rob Date: Mon, 4 May 2026 22:16:40 -0400 Subject: [PATCH] todo: mark microReticulum random_hash issue filed (#48) Filed as attermann/microReticulum#48 on 2026-05-04. Co-Authored-By: Claude Opus 4.7 (1M context) --- todo.md | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/todo.md b/todo.md index ebcbac4..3bd0330 100644 --- a/todo.md +++ b/todo.md @@ -10,18 +10,14 @@ Outstanding work for the spec repo. official Reticulum manual. Frame it as a complement to (not a replacement for) the existing operator-focused docs. -- [ ] **File a `random_hash` interop issue on `attermann/microReticulum`.** - `src/Destination.cpp:270-272` emits 10 fully-random bytes - where upstream Python emits 5 random + 5 BE-uint40 unix_seconds - (§4.1, §9.10). Effect: Python RNS path-table replacement - `RNS/Transport.py:1721-1745` rejects fresh announces from - Python sources as "stale" once a microReticulum announce has - populated the random_blob set, because the random tail is - interpreted as a far-future timestamp. Workaround documented - in §9.10; the durable fix is implementing the TODO comment in - the upstream source — even seconds-since-boot is preferable - to random bytes since path-table comparisons care about - ordering, not absolute time. +- [x] **File a `random_hash` interop issue on `attermann/microReticulum`.** + Filed as [attermann/microReticulum#48](https://github.com/attermann/microReticulum/issues/48) + on 2026-05-04. Documents the missing 5-byte timestamp half of + `random_hash`, the path-table replacement effect on mixed-vendor + meshes, and a fix recipe (the existing TODO comment, with a + suggestion that `millis()/1000` is acceptable for clockless + devices since the path-table comparison cares about ordering + not absolute time). ## Test infrastructure