Reticulum support?

[samuk]

IMPORTANT: Check the wiki
Before submitting new issue, please check the Wiki and the API documentation. You might find a solution to your issue there.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

https://unsigned.io/projects/reticulum/ is a networking stack

Someone ports it to C markqvist/Reticulum#2 and this is added to RadioLib

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Downstream your project is used by https://www.project-owl.com/ and Meshtastic I think Reticulum would be interesting for their use case.

[jgromes]

I'm not familiar with Reticulum, I only quickly read through homepage of the documentation. However, as I understand it, I'm not sure it's a good fit to be added directly into RadioLib. It seems like a protocol that's quite high in the ISO/OSI model (I might be wrong though, like I said I only just learned about it from this post). So perhaps it should be implemented separately and could only take advantage of RadioLib for transport.

Addition of various protocols is a question of architecture that pops up from time to time, where should be the line between RadioLib (which only started as collection of drivers for wireless modules) and high-level protocols. I tend to lean in the direction of keeping RadioLib as "light" as possible, i.e. without high-level protocols. Furthermore, Reticulum doesn't seem to be very widespread, at least at the moment.

Overall, I would need to see some good arguments as to why Reticulum should be added. I'm not opposed to it, but not convinced either.

[markqvist]

@jgromes You are right, Reticulum is contains very high-level functionality (along with the most basic stuff such as wire format and adressing). If viewed through the OSI lens, Reticulum implements layers 3 through 6.

My original design intent was for Reticulum to run on more powerful chips with cryptographic acceleration, and for it to talk to things like a device running RadioLib. Things have changed a bit though, since I've managed to optimise it enough that it probably could run on an m1284p or similar. That said, it'd probably need a substantial percentage of the available memory and CPU cycles, depending on application complexity. I am planning a C implementation, but I have no idea when that will be in a stable and usable state.

When the time comes, it's probably more suitable to make it easy to use Reticulum and RadioLib together, than it is to include Reticulum directly in RadioLib.

[jgromes]

@markqvist I agree, it's probably not a good idea to create a separate RadioLib implementation of Reticulum stack. Especially since it should be quite easy to use RadioLib only as transport interface.

I'll take a look at the docs, Reticulum looks quite interesting :)