rns.recipes

Hello, I hope you're doing well. I finally signed up (had to be talked into it), lol. It's good, though. Why the limit of 200? Is there a way to increase it? I don't see an option for this in the MeshChatX graphics settings—what about in Reticulum? I’d really like to be able to copy interface files to another location to add them, and also configure when inactive or old interfaces get deleted. Why? Let me give you an example: when our internet was completely cut off, everyone said I2P wouldn't work. I told them it could work with some effort, and I sent them a .zip file containing active I2P servers. How? I used to run a script to back up the netdb and saved a massive database—over 100,000 nodes. When the "National Internet" (intranet) was implemented, I loaded that database, found about 100 nodes located within the country, and managed to connect. :) I’d like Reticulum to offer more flexibility in this regard—ideally something even better than the I2P approach, where I wouldn't need to manually tweak things or constantly run a script, or at least have that level of capability available! You might say, "Well, isn't it foolish to run a script that saves every single network node just so one of them might work?" But the truth is, it helped me connect more effectively when access was restricted. It also enabled me to use the network during the "National Internet" phase—when international access was cut off—even though I thought i2pd might run into issues. It worked out, despite not being the standard approach. And that’s about it! That’s why I feel the 200-node limit might eventually become a bottleneck for me. :) What do you think?

What are you talking about?

How did you set up a 200 node limit in Reticulum?

There is no hard interface limit. Starting up rnsd might just take some time if you have a lot though.

That said I wouldn't recommend having a crazy number of them, especially if they are all to Backbone interfaces.

The main issue you will run into is fast-flapping blocks. Backbone nodes will drop clients that connect repeatedly and if your IP makes more than 5 connections that each last under 20 seconds you get a 12 hour timeout

When your config has hundreds and hundreds of interfaces this is somewhat easy to trip. If you do plan to use a lot of them, setting up rnsd as a daemon that programs connected to as a shared instance is a must.

One thing that would be nice is some config cleanup tools or a bit more intuitive error logging for RNS config issues. Right now if there is an error it just throws the error away instead of logging it. (Perhaps a new RNS utility in the future?)

Sorry, my previous message was a bit jumbled and poorly written. No, the issue is that in both the Python and Android versions of meshchatx, it only finds 200 interfaces and won't go beyond that; this started happening after an update.

Some great features were added in version v4.10.1 of meshchatx (: Thanks.

I don't know exactly the reasoning behind the limit of 200 interfaces in MeshChatX, but I can imagine it was reasonably put there since startup would take a long time, if you have a huge amount interfaces that are unreachable.

For a home node, having a dozen or so internet-based interfaces connected will be more than plenty in almost all situations. Okay, a high-performance backbone node used by many hundreds of people may want to bump that up to more to ensure wide and redundant connectivity, but honestly, the return you get from many more active interfaces than six or so is very limited. Milgram's small world and all that...

Now, for the situation where you might not know which interfaces to connect to, because they could be down, blocked or filtered for some reason, the "brute force" approach of just having 300 interfaces in your config file is not very efficient.

The interface discovery and auto-connect system was designed exactly to work around situations like that. RNS will happily store thousands of discovered interfaces, and continously tries to connect to a number of those (how many can be specified in the config).

If one of the discovered interfaces is not functional or can't be connected, it is removed, and another one is tried. This process happens on startup, and will pretty quickly find N workable interfaces to get you connected, pooling from all the potential ones it has discovered previously.

It also continuously monitors the auto-connected interfaces, so if one goes down, another one will be tried in its place.

In practice, this system already works very well, and is quite robust. It could be improved by having the option to add manually specified interfaces to the discovery pool as well, for bootstrapping a node that has never heard any discovery announces yet, of course.

And also, just to make it clear that my joke above is indeed a joke, Reticulum can handle many hundreds of interfaces just fine. It's just that in most situations, you really don't need to.

If you have just 5 interfaces, each with a pretty bad uptime of only 90%, the aggregate uptime between them that actually provides you with connectivity will be 99.999%. Far better than most high-end and very expensive commercial service providers.

To be honest, since the last update I performed (maybe about a month ago), I noticed it wouldn't go above 200. You're right; fortunately, Ivan implemented it quite well in this new version. The default is 500, though it can be adjusted up or down. I'm also glad you mentioned how the network itself tries to find good connections—that’s definitely a crucial aspect. That said, I don't intend to disrupt the network—for instance, by setting the auto-connection limit to 500 or anything like that—but I do think the addition of import/export features was a good move. I’m not sure if having such a capability is actually harmful to the network or not, but I personally prefer having those interfaces accessible rather than not. However, the possibility of users having many interfaces and setting high auto-connection limits is certainly not good news; it would undoubtedly hurt both our own bandwidth and the network as a whole, especially if everyone did it. Oh boy, I wish my English was good I'm always worried about what the translator will say and then I'll see what the translation turns out to be, I'll tell myself, maybe it's a mess? And at the end of the day, I'll have a dry text..(:

It was just a temporary frontend only limit to keep that page load fast and memory low till I got around to doing proper pagination and optimization.