All right, how many of you welcome Shane, everyone?
Welcome, I'm Shane Perman, and I'm a developer contributor to the reticulum RS port of
the reticulum, which is originally a Python, and I think it was presented here in at
Boston maybe two or three years ago, but I think many people are familiar with it,
already. The reticulum RS port was initially started by Maxime Austepinko, and
Jokin Moller is another of the major contributors there. I think most people are
familiar with mesh networking, but I'll just briefly touch on it as opposed to
like an internet protocol where the networks are arranged more hierarchically. The
mesh networks can be any general topology, and in this case, in the case of
reticulum, any of the nodes are going to be relaying packets, whereas with
traditional networks, you'll have usually a backbone or a routers, and then
other devices are just going to be clients not necessarily during the relaying.
The excuse me. I have some of the uses for mesh networking that are seen
commonly are ad hoc networks that you need to set up, for example, in disaster
scenarios. A couple of years or a last year, I think it was in Spain. There was a
power outage nationwide, so you had no cell service, and that lasted about
pay to 10 hours. So this would be a way to keep connected with your devices, as
far as needing to keep connected with emergency services and response, and it's
also sees applications with IoT deployments where you have a large number of
nodes. So reticulum was created by Mark this, and he has actually a pretty good
talk on YouTube, where he goes into detail about its design and the design
philosophy. The best way to find information is the reticulum.network website, and
then the community is based around the reticulum matrix.org chat, so that's the
best place to get more information, and the reference implementation in Python is
on GitHub. So reticulum, I guess what makes it different, or makes it stand out
from other mesh networking solutions, would be that it was designed from the start,
assuming that any peer or link or node in the network could be potentially
compromised or hostile, but by default, everything is going to be in to end
encrypted, and forward secrecy is available by default. The identities on the
network are based around public keypairs. You have a X25519 key for key exchanges, and
then you have a add25519 key for signatures, and each identity is going to be
based around those keys. You don't have to appeal to any certificate authorities for
authentication or validating. The API is message oriented already, so it's very easy
to deploy to develop applications. Some of the more some additional points in
reticulum, all packets do not have a source address. It improves privacy and
censorship. It's more censorship resistant than that way. The addresses, whereas with
the traditional IP and the net IP, addresses are going to be bound to your location,
or depending on, for example, with reticulum, you're able to generate as many addresses
as you want from that key pair, that is your identity, and another one of the benefits
of reticulum is that it's designed to work very well in high latency environments and
with a very low bandwidth. I think the bit rate that mark usually sites is you need about
five bits per second to maintain a connection to appear. That's a trade-off based on how
long you want the time out to be for the link, but they settled on about that, which
is five bits per second. So the port to Rust was started based on performance issues with
the Python implementation. There is a messaging app for reticulum already that supports
mobile, but it's very slow on Android, running Python on Android is not very optimal. And
in addition, CPU overhead prevents it from being used in very small devices. Microsoft
processors, for example, with IOT devices. So, with regards to maybe keeping the Python implementation
and trying to optimize it, that's, so that would be very challenging. I don't know if
jit compilation would be very useful here. I know I've tried I've used number for some
optimization in Python, but for a mature code based like reticulum, it could be very difficult
or not maybe not too effective. Particularly the Python implementation uses, it links to sea
libraries. There is the option to use Python native cryptography primitives, but mostly it's
going to be linking to like open SSL. So that should already be very optimized, but the code
around that, which is in Python, which would be like the routing logic, is going to be harder
to optimize. And there's the issue of the interpreter lock with Python and also garbage collection.
So this image here just is pointing to part of the object graph. When you're running
reticulum, there are a lot of references, back references, and circular references. It can be
difficult to really pin down like where data is getting used. So we've evaluated a few languages
and looking at C++. C++ has cryptography libraries, but being C++, there are a lot of
differences with the adult system. API can differ quite a bit and packaging and including dependencies
in your C++ projects. Zig is a newer language, so it's still not quite a bit here. Another language
that might fit here would be like go, go link. So I wasn't actually at the stage of this project,
I wasn't on the project. I don't know if go was considered, but we settled on Rust for
being a memory safe language and having a available cryptographic libraries and also cross
compilation for Android, as well as being able to run on embedded targets. So that was the part of
the impetus. There, just an overview of going from Python to Rust, getting rid of the circular
dependencies, making it easier to test and scale. So the initial implementation there is on GitHub.
This is just an outline of the public modules for the library. The so far for the interfaces,
there's TCP and UDP and Keonic is a frequency hopping radio. That's being developed.
This while I'm on this in reticulum, the connections between pairs are links that would be
the upper right there and destinations are basically your addresses.
One reticulum node is going to have to handle a lot of connections and IO from multiple sources
depending on how many interfaces you're running. So for example, here is the, I believe this is
from the UDP interface. So receiving data on the socket as well as sending data out at the bottom
there. Each of these are going to be running in separate tasks. So the Python implementation does
not use async whereas with Rust, we settle on using the async runtime. So that fits pretty well
for helping the scale to async and having both input and output at the same time allows you to
interleave that very well and makes it very efficient. But also I have to do packet routing at the same
time, checking whether the packet needs to be forwarded or if it needs to be hand locally.
Yeah, managing peer sessions so keeping track of the state of your links which are the connections
to peers. So in Rust syntax, I think I don't really program JavaScript, but I think it's similar.
We have the awake keyword are the async methods and link management is another example of
something that needs to be done concurrently. So here, yeah, actually there's not too much to show here,
but yeah. As far as the difference in the architecture goes between Python and the Rust
implementation, the Python implementation, the like the public facing API is going to be using
callbacks mostly for when data comes in and you want to read the message and reply as one example.
That makes that means you have to go through setting up so for the destination when the
connection gets established. You need to set a callback first for when it gets established.
When it gets established, can you just set another callback for when the data comes in and then
that's at the top there and even more like if you wanted to do something when the link drops,
you'd have to set another callback there. Whereas with the Rust implementation, we're just going
to have channels here. So you just subscribe to broadcast channel and this is also an async channel.
It works well with async runtime and you're able to just wait for events and then
depending on what it then happened and you can proceed from there. So yeah, I think Rust is also
pretty well known at this point. It's been around for a while and it's fairly popular. Going from
Python, which is not necessarily typed, there's a gradual types or type hinting available,
but at least in the Python or a particular library, it's not really used. Moving to Rust,
the type system helps quite a bit with making sure things are correct. These are just some of the
design patterns that Rust allows with its types of systems. From the from the
reticulum RS implementation at the top here, you have a few different, it's like a state machine.
Depending on what state you're in, you're going to have a separate type. So it prevents errors
whereas, for example, if you're just dealing with raw, does cipher text or something like that.
And this is also an example of the new type pattern. So it's just a very light
struck, wrapping some data. It's a little bit confusing because of the lifetimes,
but the main thing to note is just the, it's a struck wrapping and array of bytes.
The builder interface pattern actually, I don't think it's used in reticulum RS right now.
You'd probably run into it like when you're initializing the logger and if you have some
types, for example, in the Rust RS implementation, you have destinations and the parameterized by
different types. And this allows you to, for example, have a type of method overloadings.
Rust doesn't have method overloading, but it has a trade systems, you're able to
depending on which type you plug in to these different type parameters. You can overload what the
trade implementation does. So the benchmarks are not too surprising. The base number
usage, going from Python to Rust was from 30 megabytes to four megabytes. I think that's pretty
typical. And on the CPU task block from 51 milliseconds to four. And this is just like a basic
curve test on Linux. The current state of the implementation, we have identity links,
transport and channels are working progress. And the roadmap is getting this able to run in embedded
environment. That's going to be a large one, configuring interfaces. So right now the Python
implementation has a configuration format, like it has a, it's not tumble. It's similar to
tumble. So there's some work being done right now on converting that to tumble. So it'll be standardized.
And then maybe make that readable by the reticulum RS implementation. Another feature of the
Python implementation that is missing in Rust right now is resources, which is a method for
sending large files and key ratcheting. So that's the forward secrecy part.
Yeah, I think embedded right, getting this on embedded is going to be one of the main challenges.
So we have been running it on micro processor, small and micro processors, but to get it into
the very smallest micro controllers will require some some rewriting. And there are available
pacing runtimes. There are two that I'm aware of, which is the embassy and RTSC.
Run times. It's sounding, yeah, embassy is more complete, but I'm not sure yet. So I think there's
still remains challenges with concurrency in Rust. Even though it has memory safety and you avoid
a lot of the pitfalls of CNC+. You can still run it to issues like deadlocks. So doing that
correctly is going to be a challenge. As far as, because this is so motivated by performance,
I'm not sure yet how profiling will be on Asik. So I've used, I've done profiling for rest,
but not with the Asik runtime. Yeah, that'll be seen. And maintaining compatibility with the Python
implementation. So we're testing against the Python reference implementation, but as that develops,
it's, I think it's in 1.0 now, within last year. So hopefully it's relatively stable, but we'll
want to maintain compatibility going forward. Some of the applications that we've been testing with.
So this is a VPN application using virtual ton interface on Linux. And that allows you to basically
route just at your standard TCP IP applications over a particular.
Another application that we've been working on is using your particular with drones. So
Mavlink is a standard for communication with drones. And this is what we've been testing on the
SDM32 microprocessor with the Octolinics. We also have some development on a messenger for Android.
And I think I'll leave it there for, yeah, GitHub repo link is there. If you want to reach out,
there's email there. And that's it. Yeah. All right, we have time for a few questions.
Here we go. I see a hand up here. And then I think there was a question here. Okay.
Hi. Thank you for your talk. It's very interesting to see a rest implementation of
the node and reticulum. I wanted to actually two questions. One is, do you plan to support
our node on the URL as well? And the second one is that we did this be a different kind of
compatible implementation with reticulum or since Markivist has altered public development,
you're going to try to take over or continue his lineage. So you said the first part was about
Laura, right, correct. So Laura, there is not currently as you saw. There was not currently
at interface. As far as I know, it's not on me. It's not on a roadmap for me, but it's open source.
So hopefully somebody can contribute. It's not very hard to implement the interfaces. And then,
sorry, what was the second part of the question they did? I'm sorry. Yeah. Actually,
partially answered this second question as well. This second question was, does it mean to be
protocol compatible with the Python version or will be, since the Markivist has altered
public development of the Python one, if you're going to take over his lineage. So you're referring
to like, where recently he's stopped. It's like a mirror now. Yeah, it was expected somehow because
already announced that I believe one year ago or something, they was completely tired. Was your question
are we going to be taking that over? Yeah, something like, would you really implement the
full stacking in Rust or just something like two separate implementations that are compatible
each other? Right. Basically, two separate implementations that are compatible with each other.
Right now, the Rust implementation is about 5,000 lines, whereas the Python has about 30,000 lines.
So there's still quite a bit to do. We've just basically implemented what's necessary to get it working.
So yeah. Thank you very much for your work. What were the biggest things you learned about
reticulum, which were not documented anywhere, while you plotted it to Rust? So I'm not sure
exactly specifically, but I remember mentioning 55,000 nodes or something with fit and like a
megabyte or something like that. And then I tried doing the math on that, because I saw that
comment in the code, and I looked at the like the path table. The sizes didn't really match up,
so I don't know if that's still true. So that was just something that came out when I was looking
at the code. So yeah. I've actually worked more on the application side, so I've contributed
like an interface and I do like code review for the reticulum RS code, but I work closely on the
application. Another question, reticulum 1.1-3, now depends on LXMF to do stamp verification
for announced interfaces. Do you think it's a good idea that there's a circular dependency
now between R and S and LXMF? So XMF is like the messaging? Yes, and LXM, LX stamp is what does the
proof of work, and now in the newest release R and S depends on LXMF.
Okay, yeah, it's a good point. I'm not too familiar with it, so I couldn't real say.
Yep. All right, and if you're other questions, feel free to talk to him after, but we are
going to keep things moving along now. Let's give another round of applause, everyone.
Thank you very much. All right, we're going to get set up for the next talk now. Give us
just like one minute, and we'll get going again. Okay, we'll be in there.