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

>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.

> 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.

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.

§ 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.

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

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.

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.

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.)

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.

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

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.

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.

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.

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

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.

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.

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.

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

It can be in theory, but in practice there are no tasks that fit the definition. All attempts to use something like protein folding ended up in failure.

Umm, I don’t think that’s true at all.

Digital content platform, for example, is a perfect task to generate outside value. Data storage is another example with many chains in that category thriving. Database is another, gpu compute/render, lots of useful tasks. You are basically saying that computational resources cannot be used to do valuable work, which is a premise that I think is questionable at best.

You don’t see a lot of hype around these projects because they aren’t intended to be speculative- teams in this space try to avoid wild speculation driven value cycles, because it is damaging to their economic models.

A malicious notary network can simply flood the ledger with conflicting views. So clients will have to somehow find a set of notaries that is the "best".

Proof-of-stake means that there's effectively a vote on the set of "reliable" agents, and proof-of-work works because the malicious notaries can't outrace everyone else.

Yep, and none of them managed to solve the issue of resiliency without some kind of a stake.

From your own link:

> Intercoin’s ledger technology requires the sender to endorse a transaction after a supermajority of validators have approved it.

> Validators periodically check one another with “proof of resource” techniques.

Basically, it just moves the problem of validating individual transactions to validating the set of trusted notaries via proof-of-stake.

Just another rehash of crapcoin bullshit.

Each coin has a few notaries — not the majority of the network. Did you even glance at all at the arxiv paper?

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.

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

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.”

edit: nvmd, looks like it is set at a global level not a link level

Sneakernet transport has a wide array of definitions, but my favorite part about NomadNet and Sideband is the fact you can print paper QR code messages and have a recipient or LXMF propagation node scan them and have your message delivered. I have a $13 thermal printer I was able to get messages printed with.

Functionally, this is something that should be in everyone's hands, wrapped in an app on all mobile and desktop platforms. I imagine it would be quite the challenge to make it so.

Puts the number used as identity (address) up front in a way that the user can understand what it means. So better than most. Combining that identity with trust in a dialog seems to be relatively understandable. Having a category other than trusted and untrusted (unknown) is a good idea but is not immediately understandable. The user of course would have to be instructed to know exactly what "trust" means in this context.

The user doesn't need to know that they are using Curve25519. Just that some sort of encryption has been achieved.

Hex for the identity number is the worst possible choice of base. Either decimal which is quite familiar for identifying things or base32 for shorter numbers. The identity number should be consistently displayed in some helpful grouping (4 groups of 5?).

> Coordination-less globally unique addressing and identification

> Fully self-configuring multi-hop routing

> Unforgeable packet delivery confirmations

> Initiator anonymity

So the noisiest protocol ever with zero flood protection? Anyone knows better than my superficial hot take? But I doubt they solved those problems for real, that would be real news and academic progress.

The blockchain approach basically bootstraps said authority, and comes with tons of additional baggage. It's the only one I'm aware of that has real countermeasures to Sybil attacks though (in a sense; 51% attacks can also look a lot like a Sybil attack with the right glasses on)

1. https://en.wikipedia.org/wiki/Sybil_attack

there are a lot of possible approaches to the problem, though

hashcash for announcing new destinations is one possible measure

reserving most of the bandwidth for established connections to which both parties are indicating their continuing enthusiastic consent is another, and one which the circuit-switched pstn does implicitly, which is why your phone calls wouldn't drop or skip when there was a commercial break in prime-time tv. reticulum seems to do this by reserving 97% of bandwidth for non-announcement traffic, though i might be misunderstanding

the agorics 'digital silk road' paper from 01995 (unrelated to the later darknet market) describes another approach: include a source route and postage on every packet, with each network provider deducting however much postage it feels like deducting, and keeping track of bilateral account balances with each peer network (postage sent minus postage received). if the postage runs out, your packet gets lost, and the sender can choose to try resending it over the same route with more postage or routing it over a less expensive network. periodic cash settlement between network service providers zeroes out any persistent imbalance in cash sent and received: http://www.cap-lore.com/Agorics/Library/dsr.html. i don't think this has ever been implemented, though current nsp peering agreements do resemble it to some degree. the original paper suggested using eft for the periodic settlements, but nowadays you could very reasonably do it with something like ether

you can supplement the established-connection-prioritizing mechanism with a granovetter-diagram introducer mechanism: if alice has an established connection to bob, and bob has an established connection to carol, bob can dedicate some of his bandwidth on those two connections to passing messages between alice and carol. he can do this either completely at the application layer, with no support from lower layers of the network, like an irc server or turn server, or potentially with support from the network layer to find a more efficient and reliable route. (reticulum seems to support this; bob can pass alice's destination to carol or vice versa, which the manual seems to say eliminates the need for the announce mechanism, though i don't yet understand how the protocol works.) this allows bob to prioritize such connection requests using information that isn't available at the network layer, such as whether alice and/or carol have passed a captcha and/or are paying him, who they were introduced to him by, who they've introduced him to in the past, and what valuable data they've sent him. if bob repeatedly introduces alice to people she doesn't like talking to, she might cut off contact with bob, or at least look on his future introductions with a jaundiced eye and not allocate them much bandwidth

one malicious peer can have as many sources as they want. don't even need a botnet of IPs.

The link you posted seem to guard against flood of sinks on the distributed routing, but there's no mention of source flooding.

fwiw, those seem to apply to only a single destination, and any node can sybil up as many destinations as it wants, right? `announce_cap` seems more relevant

is there a place where you've written down the threat model reticulum is intended to defend against? it's hard for me to evaluate its security measures without that context

The threat model would be highly dependent on the carrier used. For example, if you're using LoRa an adversary would be using far different methods of disruption when compared to a traditional overlay network.

i think physical-layer disruption like lora jamming is kind of a separate consideration, but physical-layer traffic analysis might not be

i had misunderstood you to be saying that the second reticulum node ever was at your house, so i had assumed you were the author

Scuttlebutt: Reticulum is a network stack for routing data in real time, not a decentralized social network.

Nostr: See Scuttlebutt

IPFS: Reticulum transfers data, it does not store it (though some protocols that work over Reticulum like LXMF optionally have functionality that allows for temporary message storage)

Yggdrasil is the closest analog to Reticulum you mentioned, but unfortunately from a cursory search I could not find any details about how it works. I can see that it currently works only over IPv6 (with IPv4 tunnels of some kind), unlike Reticulum which works over anything.

I suggest at least reading http://reticulum.network/manual/understanding.html to see how Reticulum works, if you are interested.

If you want actual privacy you need to run a keyboard/ terminal running bare-metal code for capturing and displaying text, encryption, and sending the encrypted packet over your reticulum client as an encrypted blob.

This could be a hardwired serial or Bluetooth, for example. Or you could run a separate MCU to handle networking and protocols. The important thing is to run verified code on bare metal with no binary blobs, and that the encrypted payload should be the only thing sent to the network node, preferably over a TTL serial link between the terminal controller and the network controller.

Even better than hand crank or solar would be miniature nuclear batteries that run for a decade or two.

Can't wait for those to become available commercially.