RNS Over Meshtastic

[TheRouce]

Opening this discussion to cover the idea of supporting Meshtastic nodes in Columba, realistically, in the far-future.

This is a longshot but for some background: my local mesh is based on meshtastic https://mtnme.sh, it's quite large and very active with routers spread all the way from Central Georgia up into Tennessee. Reticulum is not at the stage where it really makes sense to organize people onto a new protocol though I would like to in the future (ideally when a no_std version of reticulum-rs is available publicly).

Which is why the RNS over Meshtastic interface seemed interesting, after chatting with a few other mountain mesh users there seems to be a lot of interest.

[serialrf433]

Yes about adding https://github.com/landandair/RNS_Over_Meshtastic

No about adding general Meshtastic support. I do not think Columba should be just a second choice for a Meshtastic app. A app you could use to chat with other people having Meshtastic and have no motivation to to move all over to correct RNode. Its known how extreme much overhead it creates to use RNS over Meshtastic.

This is the example that should work when implementing RNS over Meshtastic:
Starting situation: You(running Meshtastic LoRa node) <-> Meshtastic1 hop <-> Meshtastic 2 hop <-> Your friend(running Meshtastic LoRa node)
Wit this starting situation, you can chat with your friend, but also start a chat with Meshtastic1 and Meshtastic2 hop, chat with them and so on.
But now you and your friend make the decision to use Columba and RNS instead.

Changed situation: You(running Columba and LoRa) <-> Meshtastic1 hop <-> Meshtastic 2 hop <-> Your friend(running Columba and LoRa)
The changed situation should result into you not being able to communicate with Meshtastic1 and Meshtastic2 hop. Because both do not understand the RNS protocol. The Meshtastic1 and Meshtastic2 hops are now degraded from possible communication partners to infrastructure you are using to communicate with your friend.

[TheRouce]

I worded this improperly, I understand the added overhead and I'm not discussing meshtastic/reticulum interoperability. I meant that users could take their existing meshtastic nodes already flashed for mtnme.sh and without extra flashing or configurations give reticulum a try. Thus encouraging a more intentional reticulum deployment in the future.

Ultimately there is already a huge push for meshtastic in Atlanta and the infrastructure exists, I can reliably get messages up to nodes in Tennessee, so being able to utilize meshtastic as infrastructure for a new reticulum would be incredibly useful in a more user-friendly package (columba).

[serialrf433]

and without extra flashing

Columba have a extra own RNode flasher in version 0.9.x. And in 0.10.x it have support for two additional Reticulum firmware projects. You just connect the Node to your phone and choose what firmware you want on it and it installs it.
No, i do not think there would be ever any Meshtastic-flashed devices support.

Thus encouraging a more intentional reticulum deployment in the future.

No, it does not. Just install some Reticulum firmware. Use it. When you like it, keep it. When not, swap to whatever else you want. If for example Meshtastic app can not flash the firmware on its own, then blame the Meshtastic developers to wasting time of the people to having to connect the LoRa device to a computer.

Ultimately there is already a huge push for meshtastic in

Then get rid of this 'huge Meshtastic push' and use Reticulum instead.

Side note:
If you are part of the https://mtnme.sh/ , then tell the people there, that you are violating the OpenStreetMap License.
https://osmfoundation.org/wiki/Licence/Attribution_Guidelines#Static_images
Here the Github issue: MtnMesh/mtnmesh.github.io#90

[torlando-tech]

1. Reticulum can be tried over any transport, LoRa is only one of them. Columba can be used with or without LoRa. For just getting started and trying things out, it's easiest to connect to one of the public TCP entrypoints to the global network (Columba has one of these pre-configured).
2. Given that LoRa is already pretty slow, adding a lot of extra overhead to convert RNode packets into Meshtastic packets, and downgrading to Meshtastic's flood routing, is likely to leave a sour taste in people's mouths about Reticulum.

I also think that Reticulum and Meshtastic can happily co-exist, so long as Reticulum (being the newcomer) chooses a LoRa frequency that avoids interference with local Meshtastic networks.

[TheRouce]

and without extra flashing

Columba have a extra own RNode flasher in version 0.9.x. And in 0.10.x it have support for two additional Reticulum firmware projects. You just connect the Node to your phone and choose what firmware you want on it and it installs it. No, i do not think there would be ever any Meshtastic-flashed devices support.

Thus encouraging a more intentional reticulum deployment in the future.

No, it does not. Just install some Reticulum firmware. Use it. When you like it, keep it. When not, swap to whatever else you want. If for example Meshtastic app can not flash the firmware on its own, then blame the Meshtastic developers to wasting time of the people to having to connect the LoRa device to a computer.

Ultimately there is already a huge push for meshtastic in

Then get rid of this 'huge Meshtastic push' and use Reticulum instead.

Side note: If you are part of the https://mtnme.sh/ , then tell the people there, that you are violating the OpenStreetMap License. https://osmfoundation.org/wiki/Licence/Attribution_Guidelines#Static_images Here the Github issue: MtnMesh/mtnmesh.github.io#90

When I refer to a huge push for meshtastic I mean that I've been communicating with people on mtnme.sh and they seem largely uninterested in Reticulum (from the <10 people I've chatted with). Considering this conversation I think the plan is to just wait until there's a better ecosystem and in the process try to develop tools and guides for Reticulum. But, your response is too blunt imo, mtnme.sh is made up of hundreds of people, there's no just getting rid of the interested in meshtastic. Also, I'm probably not gonna bother them about the OSM license as it seems you've already done that lol.

[torlando-tech]

Yeah, I am in a similar situation; my local mesh is meshtastic and actively hostile to meshcore (closed source clients rub people the wrong way and I don't blame them).

I will not even bother bringing up reticulum to my local community until Columba is stable on google play and apple app store, and there is a standalone microReticulum firmware. Until then, no matter how nice the UI is, or how much better Reticulum may perform mesh over LoRa, it will not be in a strong enough position to get a majority of people to move over.

To elaborate on @serialrf433's explanation, remember that generally speaking, each hop in a reticulum network is managed by an interface 1:1 (this may be different for RNode, I have yet to fully understand how reticulum works over LoRa). Each interface creates a "dumb pipe" of data between your node and the next node over.

In the case of the BLE interface for example, the two phones discover each other and create a BLEPeerInterface for each other, much like the AutoInterface does, and then uses that interface to send data across.

If I'm understanding RNS over Meshtastic correctly, it uses the entire Meshtastic mesh as a "dumb pipe." So you can probably imagine that this is just about the worst possible (not to mention wasteful) way to transport reticulum data. What if some of the packets of your Resource get lost in the meshtastic mesh?

There is also the license issue; RNS over Meshtastic is GPLv3, which is great, but it is a Python interface (naturally, since Python is still the only fully complete and tested reticulum implementation), which means for me to use it in Columba, I must bundle it in a single APK with RNS, which uses the Reticulum license, which is not compatible with GPL (or I would have already made Columba AGPLv3). I would have to either use RetiNet, which afaik does not support the RNS 1.1 interface discovery feature, or I would have to completely rewrite RNS over Meshtastic as a pure kotlin library, which as you can imagine by now, would be a pretty big waste of time.

I often say we have to "meet the people where they are" but I think in this case, we just have to have a product that is superior in every way for people to want to switch over, instead of us trying to convince them that it has more potential to be better.

[landandair]

I agree with your points, this works best on a pc or sbc with a meshtastic node plugged in running rns rather than in a phone setting due to the python issue. I dont believe there is a kotlin version of the meshtastic library sepparate from the android meshtastic app though I may be mistaken.

[serialrf433]

Thanks @landandair (founder of https://github.com/landandair/RNS_Over_Meshtastic ) for joining the discussion 👍

[serialrf433]

I will not even bother bringing up reticulum to my local community until Columba is stable on google play and apple app store, and there is a standalone microReticulum firmware.

I fully understand. It 'could' be hopeless to start a discussion in person when those 3 things are not solved. You could burn down more ground now if you start convincing the people at the current state. Maybe you would find now this one person who really love the the RNS idea, but the other people would remember the current state and in few months when there are the app store releases and microreticulum firmware available, many of those people would only remember their decision against it from some weeks ago and do not look again at it.
Making a thing for the masses is a sad path you have to walk on your own for some time.

So you can probably imagine that this is just about the worst possible (not to mention wasteful) way to transport reticulum data. What if some of the packets of your Resource get lost in the meshtastic mesh?

Yep. But what else do you want to do when there is no other link to your friend over LoRa? If the link is unreliable, and so on, then its still the only link to your friend.
Having the ability to (ab)use every ressource out there to communicate with RNS over it is just showing up why RNS is just superior to Meshtastic, Meshcore, Bluetooth, Internet and so on.
Things like having a Columba phone connected to a powerbank bridging Meshtastic to Meshcore to make things would show how superior things could be:
Person with Columba LoRa <-> Meshtastic1 <-> Meshtastic2 <-> Columba-powerbank phone <-> Meshcore1 <-> Meshcore2 <-> Your friend running Columba LoRa

I must bundle it in a single APK with RNS, which uses the Reticulum license, which is not compatible with GPL

You are currently using the Reticulum license in MIT licensed Columba and Columba is happily not released under the Reticulum license. I know you asked Mark and Mark just do not answered anything. And because Mark also opened an issue in Columba to make it better and does not say something against Columba license, it seems like he just ignore this license 'problem' Columba runs into because of Mark's wrong license choice. It would be up to him to say something against it and he does not do so.
When you make Columba AGPLv3 and still put the Reticulum licensed RNS into it, i still do not think Mark would say something against it. It does not change things from Reticulum license now not followed by using MIT to later Reticulum license not followed by using AGPLv3.

I would have to either use RetiNet, which afaik does not support the RNS 1.1 interface discovery feature,

It would be nice to see more RetiNet usage in general. Lets see if it gets a compatible RNS 1.1 interface discovery feature implemented. When you for example write here that this is the single functionality that is currently holding you back from using RetiNet, then this would be for sure great motivation for the RetiNet developer (SkyGuy) to add it to https://codeberg.org/skyguy/retinet

or I would have to completely rewrite RNS over Meshtastic as a pure kotlin library, which as you can imagine by now, would be a pretty big waste of time

I think adding missing functionality to RetiNet while having Columba AGPLv3 licensed is the way to go. Then you also could add such a thing like RNS over Meshtastic that is GPLv3.

but I think in this case, we just have to have a product that is superior in every way for people to want to switch over, instead of us trying to convince them that it has more potential to be better.

Partly. If something bad happens, then the people are busy doing something else like getting food sources then trying to read into what other software they should install on their LoRa devices.
When you tell to the public they could install Columba and use RNodes, Meshtastic and Meshcore networks but also bluetooth, 1000km ham radio hardware (KISS/TNC) and much other things to communicate with their friends who also installed Columba on their devices, this would instantly convince them to switch over. Its just a much higher chance to have a successful communication working with someone else.
Its the most easy thing to convince people to use something that is making things possible that was not possible before.
When you then have technical issues(too much overhead, wrong LoRa Speading Factor configured and other things) with any Meshtastic LoRa node out there, you could use the RNode flasher that have been added in 0.8 on the go. Search for the owner of the Meshtastic LoRa node and ask if this person even care if his device gets flashed to the RNode firmware.

[torlando-tech]

You are currently using the Reticulum license in MIT licensed Columba and Columba is happily not released under the Reticulum license.

This is because neither the Reticulum license nor MIT have the "viral" nature that GPL does. In order for me to use a GPL licensed library, the entire work must be released as GPL, but the Reticulum license does not allow for this. That's fine; I am happy to create a (hopefully) more optimized-for-Android reticulum implementation in kotlin.

When you make Columba AGPLv3 and still put the Reticulum licensed RNS into it

I will not do this. I will remove RNS before moving to AGPLv3.

It would be nice to see more RetiNet usage in general [...] this is the single functionality that is currently holding you back from using RetiNet
While it may be the only feature keeping me from using RetiNet, I similarly view migrating to it in Columba as a waste of time. I would much rather migrate to reticulum-kt and gain all the benefits of native Android optimization. If RetiNet on the other hand provided some meaningful feature advantage that RNS does not have, then perhaps I would be tempted to migrate to it in Columba, but even then it would only be temporary; full native kotlin is what's best for Columba. I feel that Python's biggest advantage is its readability in this domain. While it has a great many data science/analytics uses, and is easy to write, neither of those are pertinent to Android at the moment. I would much rather see more complete implementations that are optimized for their target platforms than everyone try to make python forks.

Regarding RNS Over Meshtastic, if anything I think it makes more sense to bridge them at the software layer - have some application which connects to both an RNode (or any other reticulum interface), terminates the reticulum encryption, and sends them to a local meshtastic user, or vice-versa - terminate the incoming meshtastic encryption, and send to the specified reticulum destination. But even then, that doesn't make much sense either.

[serialrf433]

I am happy to create a (hopefully) more optimized-for-Android reticulum implementation in kotlin.

Like you said in a different issue, the people should follow up and look at how the Columba battery usage is getting over different versions. Such a Android optimized implementation could be helpful in many different directions 👍

[torlando-tech]

Just a sneak peek