rns.recipes

Hi there, maybe this is a stupid question, but... reticulum advertises its uncentralizability and so on. But as far as my first experiences with reticulum go, most of the nodes/tcpservers/backbones seem to run on some IP Address on Port 4242. So... if any ISP simply blocks traffic on 4242, then what? I guess as long as plain TCP/IP and some ports in it get used, traffic could still be blocked? (and with deep packet inspection even when running on other ports?). What would be the case when using I2P or yggdrasil?

Anonymous wrote:

Hi there, maybe this is a stupid question, but... reticulum advertises its uncentralizability and so on. But as far as my first experiences with reticulum go, most of the nodes/tcpservers/backbones seem to run on some IP Address on Port 4242. So... if any ISP simply blocks traffic on 4242, then what? I guess as long as plain TCP/IP and some ports in it get used, traffic could still be blocked? (and with deep packet inspection even when running on other ports?). What would be the case when using I2P or yggdrasil?

The idea behind it is that Reticulum is connection-agnostic, it can run over almost any connection, LoRa, TCP, UDP, fiber, I2P, whatever. Connections are managed by Interface programs which transfer data between nodes to make a connection for RNS to run over.

So if TCP gets completely blocked you can easily add another Interface that bypasses the blocking. For example you can run RNS over DNS (slowly and inefficiently but it does work) and HTTP (a website can look normal but a certain path can have a Reticulum connection). It all depends on what the Interface does.

The manual at https://reticulum.network/manual/software.html#interface-modules-connectivity-resources has a couple of good interfaces that aren't bundled with RNS by default but work well.

The networking mechanisms of RNS are very robust, but this has nothing to do with channel resilience. Of course TCP will fall, when non-standard ports get blocked, or some AI creepy-crawly just munches at encrypted payload packets. LoRa can get wiped easily by targeted RF jamming, as will HaLow. All RF comms are also subject to highly automated analysis, triangulation via mechanisms, such as TOA, RF hardware fingerprinting via specific signal shaping and distortion and much more. This implies high-level adversary.
Topics like link resilience and robust comm channels are not a subject here in general, they require a very different level of understanding, gear, comms discipline, etc. The capacity to run successfully clandestine comms is about much more, than just a network stack.
P.S. IPv6 is also very easy to cut off. After all it passes trough the same HW on the way.

Anonymous wrote:

The idea behind it is that Reticulum is connection-agnostic, it can run over almost any connection, LoRa, TCP, UDP, fiber, I2P, whatever. Connections are managed by Interface programs which transfer data between nodes to make a connection for RNS to run over.

So if TCP gets completely blocked you can easily add another Interface that bypasses the blocking. For example you can run RNS over DNS (slowly and inefficiently but it does work) and HTTP (a website can look normal but a certain path can have a Reticulum connection). It all depends on what the Interface does.

The manual at https://reticulum.network/manual/software.html#interface-modules-connectivity-resources has a couple of good interfaces that aren't bundled with RNS by default but work well.

Be mindful of such advice.
Adding another interface to bypass blocking is not a valid construct.
Interfaces have to be agreed upon and widely used, otherwise who will "meet you" on the other end, where will your interface point to? This is not a door to walk trough, when you have nothing on the other side. Also, do available and widely used apps support those types of interfaces?
So every interface you add, should have it's counterpart on some defined other side, be it point-to-point or point-to-multipoint, like radio. It all bоils down to existing entrypoints and infrastructure.
Also, it depends on what you want to encompass in your network. If you want it local only or connected to the world trough backbones.
So the question, while sounding valid, is too general and I have to say - it depends! If one puts it in a more specific way, according to his actual situation and/or goals, a lot of people here will be able to help with actually setting the network in the most adequate way.

However, strategies can be proposed to make this network more resilient. One approach involves various communication methods that are gradually rolled out and announced—such as connecting via DNS or using censorship-resistant protocols.

There are also solutions regarding accessibility; in fact, I had an idea last night that I wanted to share today!
For the past few days, internet conditions in Iran have deteriorated significantly. Certain operators are experiencing issues where Tor connects but fails to transmit data, or the connection drops intermittently; even when connected, speeds are extremely low—often just a few kilobytes per second.

Unfortunately, this situation misleads users and hinders VPN connectivity. For instance, I found numerous V2Ray servers; some offered very low latency (under 400ms), yet the actual connection quality was poor. It is strange—they show a ping response, but nothing actually works, or it works only sporadically. Sometimes, one has to attempt to connect to a server repeatedly before a successful connection is established.
I am unsure how much of this is due to general international internet disruptions versus deliberate filtering and traffic manipulation.

What is clear, however, is that this situation makes connecting difficult, necessitating a smarter approach to server connections. Currently, a simple latency test isn't enough for me to connect; I have to run a ping test and sift through the responsive servers to find one that actually works—not just one that returns a ping.

I doubt Reticulum currently has a system to detect these specific issues!

I would appreciate it if you could consider these points and look for a way to implement a connection health check mechanism across the entire network. Or an option to thoroughly test the connections...

I think I made my point clear: they’ve messed up the internet handling to such an extent that there’s a high probability a good connection gets skipped, while a bad one is mistaken for the best—leading us to connect to it and run into trouble...

Boltic wrote:

However, strategies can be proposed to make this network more resilient. One approach involves various communication methods that are gradually rolled out and announced—such as connecting via DNS or using censorship-resistant protocols.

There are also solutions regarding accessibility; in fact, I had an idea last night that I wanted to share today!
For the past few days, internet conditions in Iran have deteriorated significantly. Certain operators are experiencing issues where Tor connects but fails to transmit data, or the connection drops intermittently; even when connected, speeds are extremely low—often just a few kilobytes per second.

Unfortunately, this situation misleads users and hinders VPN connectivity. For instance, I found numerous V2Ray servers; some offered very low latency (under 400ms), yet the actual connection quality was poor. It is strange—they show a ping response, but nothing actually works, or it works only sporadically. Sometimes, one has to attempt to connect to a server repeatedly before a successful connection is established.
I am unsure how much of this is due to general international internet disruptions versus deliberate filtering and traffic manipulation.

What is clear, however, is that this situation makes connecting difficult, necessitating a smarter approach to server connections. Currently, a simple latency test isn't enough for me to connect; I have to run a ping test and sift through the responsive servers to find one that actually works—not just one that returns a ping.

I doubt Reticulum currently has a system to detect these specific issues!

I would appreciate it if you could consider these points and look for a way to implement a connection health check mechanism across the entire network. Or an option to thoroughly test the connections...

I think I made my point clear: they’ve messed up the internet handling to such an extent that there’s a high probability a good connection gets skipped, while a bad one is mistaken for the best—leading us to connect to it and run into trouble...

btw, rnsoverdns exists
on the topic of rkn-resillient protocols, yggdrasil and i2p should work in russia

burger wrote:

если что, по днс есть транспорт,
насчет защищённых от цензуры протоколов, i2p и ygg в россии должны работать

This is an English speaking forum.

#7
oh shit im sorry

burger wrote:

#7
oh shit im sorry

Then edit the fucking message.

Nickie wrote:

burger wrote:

#7
oh shit im sorry

Then edit the fucking message.

There's no need to be so hostile.

Don't worry no big deal lol, yes English is preferred but you are welcome to make a thread for your country/region in the Regional subforum

burger wrote:

btw, rnsoverdns exists
on the topic of rkn-resillient protocols, yggdrasil and i2p should work in russia

There is a different kind of disruption affecting one specific ISP; while some things still work, that provider suffers from significant interference—specifically, I2P and Yggdrasil fail to connect to many foreign servers. I tried a few times—I2P showed plenty of nodes, but it kept throwing errors when building tunnels or simply wouldn't function correctly. Even an acquaintance of mine—who used to be happy with Yggdrasil and praised its speed—reported that it has been completely cut off.

Yet, Reticulum still works! (Well, Nomadnet runs on top of it; I’m not sure if there are underlying disruptions that could be avoided or not.) I suppose it largely comes down to luck, the specific location of the servers, or perhaps simply the fact that Reticulum hasn't yet caught the attention of those imposing the blocks.

I wrote this hoping that developers might consider a solution to make the system resilient against this kind of interference. After all, it’s understandable that someone in the US, Europe, or even countries where the internet is censored—but not manipulated to this extreme degree—wouldn't find this situation normal. They might not have encountered such a problem or seen a need for a fix; to them, a simple latency test determines a good connection—if it connects, it's good; if not, it's bad. I shared this in the hope that it might prompt someone to find and implement a solution.

The DNS method is good—thanks for writing about it—but the situation isn't that critical yet; that approach is really for scenarios like a total internet blackout, a workaround, or when connecting becomes absolutely impossible. Also, it would be great if DNS support were added to MeshChatX or Reticulum itself—though I suppose there might be some limitations involved?

Let me put it this way: our internet is a joke. I was checking the site rmap.world; a few days later, I found it wouldn't load. I discovered it would load with one ISP but would hang and fail to load with another. I honestly don't know what the hell they’re doing, but they don't seem to care much if the internet is a wreck—as long as a few key services (like Google or popular online games) aren't disrupted, they’re content to let the rest of the internet suffer severe issues and still call it "internet."

Sometimes sites load only partially; even if you aren't worried about privacy, things get so messed up that you just think, "Forget it, I might as well use a VPN." Of course, whether things get better or worse depends on the ISP and the specific situation—like if the country is in turmoil, for instance.
But overall, compared to a few years ago, they’ve kept narrowing this window of access and tightening control; it used to be difficult and bad back then, too, but not this bad.