[nexus_six]

Reticulum is incredibly versatile and has an entire ecosystem of tools under development. NomadNet is just one of the messengers. There is Sideband, a mobile app client (https://github.com/markqvist/Sideband), and Reticulum MeshChat, developed by Liam Cottle which is a browser based client https://github.com/liamcottle/reticulum-meshchat.

Reticulum can work over anything that has a throughput greater than 5 bits a second (yes, bits) and a MDU of 500 bytes. Not only can it work over hundreds of different carriers (LoRa, BLE, Packet Radio, overlay networks like Tor and I2P) but each of these carriers can be apart of the same network.

I threw together a quick proof of concept of it working over HF radio. I setup two nodes about 144 km (90 miles) separate. Both were ICOM-7300's with a Raspberry Pi 5 driving the software modem that would take packets from Reticulum and send them over the air. https://www.youtube.com/watch?v=blwNVumLujc

Node 1 was out in the field while Node 2 was back at my house. Node 2 had two interfaces setup, one for the HF modem and another connected to the TCP testnet. This means that Node 1 could access any peer that was over on the TCP testnet.

Here is a quick primer on Reticulum that explains some of the basic concepts: https://www.youtube.com/watch?v=q8ltLt5SK6A

[bigallen]

Are you in USA? I'm seeing words like "private" and "cryptographic" in the github. What's the interaction with ham radio rules about no encryption?

[jvanderbot]

Lora and wifi are not ham radio networks. I imagine that kind of multi-channel use is just fine.

[linsomniac]

I believe the question you are replying to is directly in response to:

>I threw together a quick proof of concept of it working over HF radio

Which I assume was amateur band rather than commercial (in the 3-30MHz range). I don't believe LoRa and WiFi operate in that band.

[jvanderbot]

Correct: I misread the thread. Thanks!

[exe34]

would you be able to transmit under the noisefloor and integrate on the other side? i imagine it would still break the law, but you wouldn't be likely to get caught?

[bigallen]

Physics aside, I think the FCC is very, very slowly considering removing the "no encryption" aspect of ham radio. The arguments against encryption seem to be weak, and revolve around "if we don't know what people are saying, we won't know if they're trying to use it for commercial purposes" which is just simply not true. Oh well, here's to hoping the FCC will move into this century!

[Dylan16807]

Under the noise floor at what distance? If you don't want to be a bright beacon at a mile, then you're not going to have a lot of signal at a hundred miles.

[exe34]

yeah occurred to me a while after posting :-D

[crest]

You can still use ham packet radio protocols over ISM bands not held back by those stupid historical limitations and stay within the law.

[anamexis]

Parent is responding to this:

> I threw together a quick proof of concept of it working over HF radio.

I'm not aware of any HF bands you can use in the US without a license. And it is prohibited to use any kind of secret encryption on amateur bands.

[genewitch]

11 meters is in a different part than ham and is usable unlicensed.

Doesn't mean you can send encrypted traffic and there are FCC rules about duty cycle, etc.

[AstroJetson]

In Part 95, Section D, encryption is not mentioned.

But the Emission Types are limited, digital emissions are not allowed. (AM and SSB) are specified.)

In theory, you could have a transmission header / trailer in Esperanto that would route the message, and then the message traffic. But that sounds like a hill that wouldn't be worth the climb.

[anamexis]

Indeed, only plain language voice communications are allowed.

§ 95.931 Permissible CBRS uses.

The operator of a CBRS station may use that station to transmit two-way plain language voice communications to other CBRS stations and to other stations that are authorized to transmit on CBRS frequencies.

[kragen]

is there maybe an explanation of how the network works that isn't a video? is chapter 4 of the manual the best explanation? i admit i'm spoiled by the great explanations provided by academic projects, and i don't know where to look for, say, how it defends against traffic analysis attacks to statistically deanonymize speakers, or whether that's outside of its threat model

if it were a mechanical device or a graphics rendering algorithm i would think a video would be better, but it's a peer-to-peer networking protocol, and the video just looks like distracting eye candy

[franek]

> chapter 4 of the manual

To me that chapter ("Understanding Reticulum") was a very pleasant read a few weeks ago, and inspiring too. I would love to get some HN expert opinions on it, especially about routing, so I posted it separately:

https://news.ycombinator.com/item?id=41257619

[nexus_six]

It's meant to just be a quick explanation of some of the very basic concepts. But if you want to understand the network stack in-depth the manual is the best resource: https://reticulum.network/manual/index.html

[generalizations]

Is there a more formal description of the algorithm? I'd be interested in understanding not the implementation, but how the algo has been constructed, to understand its strengths and weaknesses.

[franek]

Does Reticulum routing always prefer the path with the fewest hops, even if a path with more hops might have higher throughput or lower latency?

That's how I understand the manual (https://reticulum.network/manual/understanding.html):

> Once an announce has reached a node in the network, any other node in direct contact with that node will be able to reach the destination the announce originated from, simply by sending a packet addressed to that destination. Any node with knowledge of the announce will be able to direct the packet towards the destination by looking up the next node with the shortest amount of hops to the destination.

[LinuxinaBIt]

I like the way you’re thinking but it doesn’t necessarily work like that in practice. Why? Because of how announce queues work, each interface has its own queue, and announces are limited very specifically to 2% of a channel’s bandwidth.

This means that announces are much more likely to be transferred over the faster medium first, resulting in paths that are on average the most reasonable balance between speed and distance.

If that doesn’t make sense at first, I get it. I find trying to visualize how it works really helps. Reticulum is conceptually so different from anything else out there that it takes a while to understand.

See http://reticulum.network/manual/understanding.html#the-annou... for more details.

[franek]

That does make a lot of sense, at least in terms of latency: I imagine that when a one-hop announce comes back from outer space, the faster multi-hop path across town will have already been established.

For bandwidth, however, I don't see it yet. If all relevant nodes are idle at the time an announce comes in (so the 2% limit doesn't come into effect), a low-bandwith route might be established before one with a much higher bandwidth, no? (Prioritising latency over bandwidth can be the right thing to do, of course, depending on what the network is used for. But it might not.)

[LinuxinaBIt]

Sure, in some cases, when the network has fewer announces to deal with, the 2% limit has less effect, the best way Reticulum can deal with this is with a network made out of more specialized node types connecting the lower speed links (http://reticulum.network/manual/interfaces.html#interfaces-m...)

However when the network (and each node) is receiving enough announces to saturate that 2% chunk of most smaller links, those interfaces prioritize announces with less hops, and there is a queue, meaning it takes that interface longer to transport announces coming from further away. This makes it much more likely that nodes will form routes over a faster but longer path.

[franek]

> Sure, in some cases, when the network has fewer announces to deal with, the 2% limit has less effect, the best way Reticulum can deal with this is with a network made out of more specialized node types connecting the lower speed links (http://reticulum.network/manual/interfaces.html#interfaces-m...)

I see. So it seems that optimizing a complex network can be a little more hands-on, not completely automatic (which would be a bit too much to ask, thinking about it). I guess my hypothetical path via outer space would have a "boundary" mode node somewhere on the way, although I am still fuzzy on how exactly this would affect things.

And your point about the announce queue with saturated 2% bandwidth is clear.

Thanks so far! This makes me want to read the rest of the manual and possibly start tinkering with Reticulum myself at some point.

[LinuxinaBIt]

Yeah, exactly what each type of node does gets a bit into the weeds where even I don't really know. You can ask in the Github Forum (https://github.com/markqvist/Reticulum/discussions) or Matrix Room (https://matrix.to/#/#reticulum:matrix.org) if you need more detailed information :)

[cyberax]

How does Reticulum solve the fundamental issue of mesh networks: either you have to have a central controlling authority for addressing, or an adversary can just flood your network?

Does it have some kind of blockchain crap tie-in?

[__MatrixMan__]

I can't comment on Reticulum, but I think there are solutions to that problem re: content-addressing rather than node-addressing.

If you replicate a piece of data based on whether you or your (explicitly trusted) peers are interested in it, then the only way to flood the network is to convince all of the users to become interested in it, which is likely difficult enough to discourage misbehavior.

pub/sub, not request/response.

[cyberax]

Sigh. The problem is not the content. It's the addressing.

For the content-based addressing to work, you need to flood the network with the reachability information ("how can I get to this block?"), and it's trivially easy to just generate enough of it to overwhelm the routing nodes.

[__MatrixMan__]

But that's request/response, because you're requesting blocks.

I'm saying that when two nodes pass each other in the street or whatever they think "hey, a peer is in range" so they see if:

- The peer carries any topics they're interested in

- That topic's synchronization algorithm indicates that any actual synchronization is needed in this case

So some content may get shared between the devices, but nobody requested it. The event source was the arrival of the peer. You might also recheck periodically, supposing they stick around for a while.

If you subscribe to topics with dumb synchronization algorithms that just copy everything they see and don't check a web of trust, then yeah you could still get floods of data that saturate whatever resources you've allocated to that topic, but that would quickly become a useless topic, so just unsubscribe and pick smarter topics next time.

In summary, push the routing problem to the application layer.

Different data is going to have different needs. Map tiles need to stay near the parts of the planet that they describe. Information about how to mitigate a harm needs to be near the audience that might be harmed. Manuals need to be in the hands of people who are interested in the objects that they describe. Menu and open hours data needs to be near the restaurants with those menus and hours, or to nodes whose owners like that kind of food...

The goal is to converge on a particular distribution of data across nodes, not to get any one piece of data to any one particular node. No requests, and no handling data that you haven't opted into handling by subscribing to that topic.

I suppose you might conceive of the synchronization process as a series of requests, but they don't propagate anywhere. For each datum you either already have it, you decide to take it, or you decide to leave it.

[cyberax]

> But that's request/response, because you're requesting blocks.

It doesn't matter.

> - The peer carries any topics they're interested in

How do you implement it? Do you have a human manually looking over each message and marking the interesting ones? Heck, it's likely that everything is encrypted anyway!

> So some content may get shared between the devices, but nobody requested it. The event source was the arrival of the peer. You might also recheck periodically, supposing they stick around for a while.

So you get 10^12 anonymous peers arriving at your node. How do you filter them?

[__MatrixMan__]

The node operator subscribes their node to topics, so yeah that part is manual, and that's how the humans express their interest. You might have to update it every now and then if one topic is killing your battery or your hard drive or you just don't care anymore. The data which that topic governs is handled by the synchronization function which runs periodically without supervision.

Whether some or all of the data is encrypted is an application level detail. At the network layer you just call the function provided by the app/topic and it tells you whether to accept or ignore a datum, and which datum to delete if the storage quota for that topic is full. Lots of things don't need encryption (e.g. map tiles). Or if there's some kind of trust structure in place, the node may have keys necessary for doing the decryption--it's not like you're carrying data for apps besides those you're participating in.

As for the peer filtering thing, peer-discovery and synchronization would happen in time slots. So if it happens for 30 seconds each time and this app in particular gets 30% of that, then I guess you spend 10 seconds trying to see if any of those 10^12 peers are worth synchronizing with. Maybe you're checking to see if they're n hops away on your web of trust for that topic or something like that, it would depend on the case. But I don't see how this case has anything to do with mesh networking: all forms of communication are susceptible to DOS of some kind or another. The best we can do is limit the blast radius and maybe raise it to the user so they can handle the adversary out of band.

[AyyEye]

> either you have to have a central controlling authority for addressing, or an adversary can just flood your network

False dichotomy. IIRC reticulum does something like an inverse TTL, so packets have priority based on how local they are.

[cyberax]

Nope. It's fundamental.

The problem is in the _addressing_. How do you find the packet's next hop?

[AyyEye]

Not sure about reticulum but Yggdrasil uses a hybrid spanning tree and dht to guess based off dht and uses key weight to failover to the spanning tree.

[icepat]

No, Reticulum does not require a blockchain. My understanding is that Reticulum solves this by allowing network redundancy.

[cyberax]

So what happens if I create a node, then create 10 trillion addresses and send a message to every one of them?

[dicknuckle]

blockchain can be cheap (power, compute etc) and not crap. Doesn't mean every project that builds with it takes that into consideration.

[__MatrixMan__]

If you've picked mesh networking, then you care about partition tolerance. But blockchains prioritize consistency. So I think using blockchains on mesh networks puts you in a disadvantaged situation re: the CAP theorem. There's got to be a way which better aligns the application layer with the constraints of the physical layer.

[cyberax]

> blockchain can be cheap (power, compute etc) and not crap.

No. All blockchain is crap, no exceptions are fundamentally possible. The reality reflects that rather starkly.

By "blockchain" I mean a system with a distributed consesus via proof-of-work or proof-of-stake.

[__MatrixMan__]

So it stops being a blockchain if the criteria for adding a block is based on something else? Or do you intend to update your definition to incorporate other consensus mechanisms as they emerge?

Seems to me that a more useful definition would abstract out the consensus model such that a blockchain is essentially a merkle-linked-list together with some function for determining which of two candidate next-blocks will be the actual one, but without getting too specific for what that function is... just because there's so much potential for variation there.

[jazzyjackson]

> just because there's so much potential for variation there.

There really isn't. Either you expend some resource to make it expensive to attack or you stake some resource so you have something to lose to prove you're not a bad actor. I've never seen anything more creative than this.

[__MatrixMan__]

Or you participate in some activity which provides a service, like filecoin. Or you get somebody's approval of the block's contents, like in a permissioned blockchain.

I think we'll also see something where you do key-signing parties all at the same time as a way of providing sybil resistance. Or proof of having voted on whatever it is (the outcome of the vote would then go into the block).

Stake and work are just the easy ones to implement because they don't even try to be simultaneously useful.

Personally I'm not very excited about blockchains because I think global consistency is overkill for pretty much everything, and is in many cases harmful. But it's hard to take anyone seriously who classifies a technology as by-definition-useless. Its current forms are weak enough to defeat at face value, no need for propaganda.

As for the future ones... Maybe they be useful, we'll see.

[K0balt]

POW doesn’t have to be useless work. It can be useful work, so that mining actually creates a value tied to off chain economic systems. Then you have something that actually has value, and you can then use POS to give validators both a correct incentive alignment and a way to get paid for their work. Hybrid value backed POW for token creation with POS for validation creates a really good system for digital assets.

Sadly, extant systems for this are few because generating real value is actually challenging.

[EGreg]

There are lots of other approaches - IOTA DAG, HashGraph, Ripple Consensus Process etc.

I am not a fan of blockchains, though. They are overkill for most uses. But here is an example of a non-blockchain system that doesn’t even require global consensus:

http://intercoin.org/technology.pdf

Also check out the Autonomi network

[acaloiar]

I'm afraid you're redefining what a blockchain is. A blockchain is a distributed ledger. Distributed ledgers are an application of distributed conensus, which is a truly interesting field within computer science.

[EGreg]

You’re being downvoted because you’re making sweeping unsupported assertions, likely based on an ideological opposition to blockhain.

I am guessing it has to do with anger at FTX and other negligent participants in the wider “crypto” ecosystem that has very little to do with blockchains. But that is a “non sequitur” (Latin for “it does not follow).

If I am wrong in my assumptions and you have an actual argument supporting your assertions about “all blockchains” being crap, please do elaborate on the substance.

[cyberax]

The reality is: blockchain has failed in EVERY area it's been tried, except for illegal/unregulated payments.

Assets tracking? Failed. Interbank settlements? Failed. NFT and art? Spectacularly failed (wanna an NFT for that spectacle?).

[LinuxinaBIt]

Reticulum uses absolutely no blockchain. It uses a fairly novel routing strategy with something called announces.

Read this page to learn more about it: https://reticulum.network/manual/understanding.html

TL;DR it only flood routes packets that tell the network the location of a node; each node stores the “next hop” to get to every other node on the network. Everything else is routed along a single path determined by those “next hops.”

[cyberax]

What stops me from flooding the network with 10^12 of fake addresses?

[adinisom]

The intended solution seems to be a 2% bandwidth limit for announcements and a preference for lower hop-counts to keep your flooding local.

There's a FAQ item on this: https://github.com/markqvist/Reticulum/wiki/Frequently-Asked...

[Aerbil313]

Why is the lower limit on bps? If there is interference for 5 seconds and my hardware can't get signal, will it drop the packet? Ideally it wouldn't.

[392]

You'd better go read the spec. And this: https://chsasank.com/classic_papers/end-to-end-system-design...