Network time on Reticulum

[faragher]

My thoughts are here: #717

Short version, it's application level, trivial to get network time out of band with greater security and precision, and doesn't belong in the stack.

Now, "Consensus."

No, no, a thousand times no. Let's follow consensus down the garden path. Bring an axe.

• We need trusted data from an untrusted group of peers. Let's use consenus!
• Someone just spun up a hundred VMs and has consensus saying we're at 3,500 BC. Let's set up proof of work.
• Okay, some Antminer farm in (region where electricity is cheap/free) now has more hashes than everyone else in the network combined! Let's move to proof of stake.
• We can't figure out the definitions of "stake" even though we introduced yet another blockchain and had it crash through the floor! Let's just have trusted sources.

And now we have trusted data . . . from trusted sources. But years down the line of massive technical and implementation challenges that end up tarnishing Reticulum forever.

And since Reticulum refuses to use arbitrary trust, blockchain, or any sort of proof of anything (please see Red Queen's Race and Oligarchy for reasons why the concept itself is fundamentally flawed) consensus simply doesn't work.

The most fundamental issue here is that network time isn't mutable data; UTC is universal time. It's available from multiple sources and while there is something to be said about trusting GNSS for time, it's trivial to get time without some complicated hoop-jumping to protect against malicious actors modifying publicly available information.

So, so sum up: NTP is application layer. Sub-second accuracy time is easy to collect out of band. There is no reason to put network time in the stack. There are myriad reasons against consensus. In-band networked time is a security vulnerability.

There is no reason to not have NTP serving applications, but putting it directly in the stack is the wrong move.

[markqvist]

Completely agree on this one.

That being said, an NTP-like application for Reticulum would be fun and useful, and something I was actually playing around with recently, but never at all finished. It seems very possible to use to original approach of NTP over Reticulum as well, though.

For context, what I was using it for in that particular purpose was to try and accurately measure signal-streaming latency over a Reticulum link (specifically for audio telephone calls), for the purpose of auto-adapting audio frame sizes and codec selection on the fly, to optimize call quality against available network bandwidth and latency.