[HN Gopher] Reticulum, a secure and anonymous mesh networking stack
___________________________________________________________________
Reticulum, a secure and anonymous mesh networking stack
Author : brogu
Score : 335 points
Date : 2026-01-19 23:59 UTC (23 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| gnabgib wrote:
| Popular in 2022 (95 points, 15 comments)
| https://news.ycombinator.com/item?id=30870187
| elbci wrote:
| ... urgently needed now ;)
| 405nm wrote:
| it hit version 1.0.0 this summer and it works!
|
| to get started easily, check out meshchat:
|
| https://github.com/liamcottle/reticulum-meshchat
|
| or sideband on android:
|
| https://github.com/markqvist/Sideband
|
| you can _already_ send photos and voice chat over lora, and when
| lora runs out of bandwidth or if there's no link, the protocol
| can seamlessly go over any other link type.
| gaudystead wrote:
| I just happened to recently learn about Reticulum from another
| part of the internet and find it fascinating. Am I correct in
| thinking that it can basically run on anything that can run
| arbitrary code and the ability to talk to another device? (seems
| like it'd even work over serial if one had the determination to
| make it work)
| hoss1474489 wrote:
| The only fully-functional stack currently available requires
| Python >= 3.8, which is the main limitation to where it will
| run. But there's still a lot you can do with that!
| khimaros wrote:
| there is a pretty compatible rust implementation as well
| which claims to target microcontrollers
| https://github.com/BeechatNetworkSystemsLtd/Reticulum-rs
| snickerer wrote:
| Did you use it? I've never seen it used outside of
| Beechat's own devices.
| RiverCrochet wrote:
| - If it runs Python and pip/pipx, and you can pull in the
| required packages via pip/pipx, it'll run Reticulum.
|
| - On 32-bit x86 platforms it has to build the PyCA/cryptography
| module, but works fine after it does that.
|
| - Reticulum supports a number physical interfaces, serial is
| one of them. It of course has the "RNode" intefaces for LoRa
| radios. For Ethernet, there is "AutoInterface" which uses IPv6
| autoconfiguration for peer discovery and IPv6 UDP for transport
| but doesn't rely on DNS, DHCP, or anything else. If your PC,
| phone, or other involved devices on the same network have IPv6
| enabled and no filtering is happening on layer 2 then it's dead
| simple - any device there will see announces from others and be
| able to transact with you not doing much more than spinning up
| MeshChat.
|
| - Other interface types are TCP client, TCP server, IPv4 UDP,
| I2P, and a pipe interface. The pipe interface is interesting as
| it's basically stdin/stdout to an executable of your choice, so
| you can use that to make Reticulum available over really
| anything you could dream up, such as an SSH tunnel.
| phil37412 wrote:
| so you mean it would work from Iran?
| TheCraiggers wrote:
| Anybody have any experience running this on a tdeck? I'm kinda
| toying with the idea of ordering a couple just to play with.
| pwndByDeath wrote:
| It is not yet like meshtastic in that. Rnode is more of a lora
| modem than a lora server. There is a micro recticlum project
| but not out yet.
| TheCraiggers wrote:
| Ahh, yes. I see that now. I appreciate the correction.
| ashton314 wrote:
| Sounds like someone is a fan of _Anathem_!
| MPSimmons wrote:
| That's an amazing book, and I highly recommend it, for anyone
| who isn't familiar.
| NewJazz wrote:
| _The Software shall not be used, directly or indirectly, in the
| creation of an artificial intelligence, machine learning or
| language model training dataset, including but not limited to any
| use that contributes to the training or development of such a
| model or algorithm._
| dotty- wrote:
| I saw this too and immediately thought: well, they published
| this on GitHub which surely has a clause that grants it a
| license to use the code for training Copilot for Microsoft at a
| minimum, sooo should've published on another Git platform.
| promiseofbeans wrote:
| > This repository is a public mirror. All development is
| happening elsewhere.
|
| So if I have code on a personal (but publicly exposed) git
| server with a license that includes the above quoted terms,
| and someone decides they want to be helpful and publish a
| public read-only mirror of my code to GitHub, then they're
| allowed to accept that license on my behalf? I never did a
| thing and yet I'm now in a contract with Microsoft? How does
| this work legally?
| gpm wrote:
| Not a lawyer but I'm pretty sure:
|
| 1. Microsoft does not gain the license, but will be able to
| argue that they aren't _intentionally_ committing copyright
| infringement in the cases where that distinction matters.
|
| 2. If Microsoft does something resulting in damages because
| they thought they had a license, their indemnification
| clause kicks in and they can recoup those damages from the
| user who uploaded it (to the extent that that user doesn't
| go bankrupt anyways)
|
| 3. Likely none of this matters because your license can't
| prevent activities that weren't prohibited by copyright in
| the first place, and training doesn't appear to be a
| prohibited activity at least under US law.
| exitb wrote:
| When code is published on GitHub, GitHub itself is not
| bound by the public-facing license, but rather license
| grants the uploader aggress to as part of the terms of
| service. That points to the uploader as a responsible
| party.
|
| In practice though, none of that is even remotely
| enforceable.
| avodonosov wrote:
| Not sure GitHub has such a clause. Just looked at their terms
| and don't see it.
| gpm wrote:
| See term D.4., the relevant part of which is
|
| > You grant us and our legal successors the right to store,
| archive, parse, and display Your Content, and make
| incidental copies, as necessary to provide the Service,
| including improving the Service over time. This license
| includes the right to do things like [...] or otherwise
| analyze it on our servers; share it with other users
| AceJohnny2 wrote:
| That could be boilerplate legalese for " _obviously we
| need access to your code if we 're to display and share
| it (as is the purpose for a public git host)_"
| gpm wrote:
| It doesn't matter what the original purpose of the terms
| was it matters what they do.
| snickerer wrote:
| Mark's Reticulum implementation has a strong ideolgical
| background. Not just the oppositon to AI. If anybody is
| interested in what drives the developer, here's the manifesto:
| https://github.com/markqvist/Reticulum/blob/master/Zen%20of%...
| samantp wrote:
| Looks great. Does it need all users to install Reticulum, or
| app/service prividers (online shop etc) on Reticulum can make
| their services available for access via browsers?
| 405nm wrote:
| all users need to be running the reticulum network stack to be
| able to send, receive, and route packets.
|
| reticulum itself describes the network stack (like tcp/ip) and
| it has its own protocols like LXMF for messaging and LXST for
| streaming. applications can be built on top of these protocols.
|
| it's different than IP, instead of addresses, each node has an
| identity that's a cryptographic key pair that you send messages
| to, the routing happens in the background regardless of network
| topology or diversity of link types.
|
| you CAN send reticulum packets over a TCP/IP adapter and thus
| across the normal Internet (there are a lot of testnet and
| community nodes that are accessed this way), but the protocol
| also seamlessly bridges over any interface (lora, bluetooth,
| HAM radio, etc) that is attached to the node.
|
| so like, there could be a message sent over lora to a base
| station that relays it to another server through the internet,
| then that server sends it out over a ham radio link to another
| computer somewhere else, etc.
|
| all the message sender has to know is the pubkey of the node
| they want to talk to, and the network figures out how to
| establish a link.
|
| 128 hops maximum.
|
| the prerolled binaries of the aforementioned software include
| the network stack and easy enough presets to find content from
| other nodes and people to talk to.
| roxolotl wrote:
| How does this differ from meshtastic? Is meshtastic just more
| chat based and this is more generic?
| 405nm wrote:
| meshtastic is chat and lora only. its protocol is super
| inefficient and unreliable, and only can handle a maximum of 7
| hops across the mesh.
| snickerer wrote:
| Reticulum is a full network stack with full user anonymity. You
| can integrate it in every app that needs P2P network
| connections and that can live with a slow connection. Reticulum
| is an alternative to TCP/IP and UDP/IP, using a mesh.
|
| Meshtastic and Meshcore are mesh messengers, focusing on mesh
| text messages.
| arthurmorgxn wrote:
| This is cool, I've been playing around Offline Protocol's DORS
| SDK that they put out last month and it's been great for cross
| platform whereas Bitchat's Noise setup was a little more
| cumbersome to get started. Need to dig more into LoRa meshes.
| SuperMouse wrote:
| I've never seen a bigger network with Reticulum in the wild. And
| I'm deep into Mesh stuff with several local communities.
|
| One of the main reasons of the communities not jumping onto the
| ship was that it's mostly a one-man-project and most of its Git
| changes are "Update" "Better Version" "Update" "Cleanup" which
| makes it basically impossible to track changes.
| agent86 wrote:
| And, as of 3 weeks ago, the one man is "stepping back from all
| public-facing interaction with this project".[1]
|
| Further, "Occasional updates may appear at unpredictable
| intervals, but there will be no support, no responses to
| issues, no discussions, and no community management in this or
| any other public venue."
|
| Nothing salacious here - just another one man open source
| project with a burnt out maintainer :(.
|
| [1] - https://github.com/markqvist/Reticulum/discussions/1069
| 405nm wrote:
| it's a bummer, but according to folks in the matrix chat,
| he's still developing and in touch with some of the community
| devs.
| sunshine-o wrote:
| The reticulum dev have been trying to quit for years and have
| been quite open about his own personal struggles.
|
| More recently:
|
| - v1.0.0 was supposed to be the time his involvement is over
| [0]
|
| - 6 months later [1]
|
| > This is not a temporary break. It's not "see you after some
| rest", but a recognition that the current model is
| fundamentally incompatible with my life, my health, and my
| reality.
|
| - But he pushed 3 releases since his last message [2]
|
| It is like he is trying to quit somking.
|
| I am not sure what the problem is exactly but it seems
| someone need to take over and honor the fantastic work he has
| done over the years.
|
| - [0] https://unsigned.io/articles/2025_05_09_The_End_Is_Nigh
| _For_...
|
| - [1]
| https://unsigned.io/articles/2025_12_28_Carrier_Switch.html
|
| - [2] https://github.com/markqvist/Reticulum/releases
| latchkey wrote:
| To be fair, satoshi stepped back too.
| agravier wrote:
| So what mesh stuff do you recommend for the uninitiated?
| agent86 wrote:
| In the LoRA/radio device sense, Meshtastic[1] is probably the
| easiest to get started with. It's the biggest player in the
| space, has devices that come pre-installed and configured,
| the most likely chance of making contact with someone else,
| etc. MeshCore[2] is the other major player. It's newer and
| tends to have been adopted by communities that have run into
| issues with large Meshtastic networks.
|
| If you meant PC-based mesh networking, I'll leave someone
| more knowledgeable to speak about that :).
|
| [1] - https://meshtastic.org/
|
| [2] - https://meshcore.co.uk/
| blep-arsh wrote:
| I've had some experience with both Meshtastic and
| Reticulum, and Meshtastic software was mostly unusable for
| me even with 3-node networks. E.g. a node sends a message
| and gets a successful delivery notification from the
| receiver but the receiver fails to display the message to
| the user. Reticulum was mostly working fine. Haven't tried
| MeshCore yet.
| fragmede wrote:
| Meshtastic also doesn't really... work. Let me qualify
| that. You can get a couple of nodes for cheap, and you
| can (with a bit of work) get messages to go between them.
| The problem is coordination between nodes is required for
| the network as a whole to work. Specifically, user
| adjustable node -local settings can overwhelm the network
| for everyone else around you. Defcon "solves" this by
| providing firmware to flash with preconfigured settings
| tuned for the event. But hopefully this makes the problem
| obvious - in some other scenario that you might hope to
| use them - and TBC, my goals for a long range, non-
| cellular network mesh network are for connectivity during
| a hurricane/flood/firestorm/earthquake/tornado/etc.
|
| An open implementation is preferred, because it drives
| down the cost of hardware and lets users purchase the
| grade of hardware they want. But if it doesn't work, an
| imperfect proprietary solution(s) available now >
| hypothetical perfect future solution.
| mytailorisrich wrote:
| Lora, especially on regulated bands that are the most
| used ones, is designed for very small, very infrequent
| messages. It isn't suited for real-time chat (nevermind
| secure) and so I think you can't really make it work
| while respecting transmission regulations.
|
| There are lora modules that work on the 2.4GHz ISM band
| but then you probably need to consider whether Bluetooth
| is not a simpler choice if range is not the no. 1
| concern.
| BSDobelix wrote:
| >It isn't suited for real-time chat (nevermind secure)
|
| It is encrypted on private channels and direct messages.
|
| >and so I think you can't really make it work while
| respecting transmission regulations.
|
| I don't know from where your information's are from, but
| for sure not from reality. Voice encryption/scramble on
| Amateur-Band's is not allowed, everything else is ok.
| mytailorisrich wrote:
| I know what features it claims to have. The question is
| how well this can work on bands (US915, EU868) that very
| strictly limit the amount of time a device may transmit.
| IMHO you can't really have interactive chat on a mesh
| network over lora in those bands.
| BSDobelix wrote:
| >I know what features it claims to have.
|
| Yeah...no i don't think so.
|
| >IMHO you can't really have interactive chat on a mesh
| network over lora in those bands.
|
| Devices allow 10% Airtime on ISM here (EU) that's about
| 300 messages (with 255 characters) per hour, and yes
| interactive chat is possible with around 20 seconds of
| lag.
|
| EDIT: I stop here, so much half knowledge that sounds
| educated but is in fact just wrong and TBH not even sure
| if i talk to a selfhosted AI.
|
| Have a good Day.
| mytailorisrich wrote:
| Yes, in the EU one subband allows 10%, the rest is 1%. I
| believe that Meshtastic uses the whole 250kHz of that
| subband by default. This is by far the most relaxed
| constraints of what is available in the EU and US. That's
| about 180 max. size messages per hour (at longfast) per
| device but you need to take into account retransmissions,
| acks, mesh management and routing of third party
| messages. So it may work, barely, for this specific
| config and very small number of people or 1-to-1, but
| that's it.
|
| I am not picking on Meshtastic specifically, it's just
| that Lora and, especially the regs on those bands are
| such that some applications are never going to work well
| beyond extremely small meshes, if at all.
| BSDobelix wrote:
| >I believe that Meshtastic uses the whole 250kHz of that
| subband by default. This is by far the most relaxed
| constraints of what is available in the EU and US.
|
| Again wrong, just look at EU vs US:
|
| https://meshtastic.org/docs/configuration/radio/lora/#reg
| ion
|
| > beyond extremely small meshes, if at all.
|
| 180 online nodes (300 at max) is not extremely small (and
| that's our small mesh EU with medium_fast)
| mytailorisrich wrote:
| How many text messages does each user send per hour? Or
| how many are in active chat with each others at a given
| time?
|
| (Careful that the US have a 400ms dwell time depending on
| settings that can put a significant limit on
| things/range)
| beala wrote:
| > Voice encryption/scramble on Amateur-Band's is not
| allowed, everything else is ok.
|
| It seems like you're saying voice encryption is not
| permitted, but data encryption is? This is not true in
| the US. Any encoding used for the purpose of "obscuring
| meaning" is not permitted on amateur frequencies. Even
| using code phrases like "the eagle has landed" is
| arguably not allowed. There are some narrow exceptions
| for things like satellite control codes, but nothing that
| applies to hobby mesh nets.
|
| Here is the relevant Part 97 rule: https://www.ecfr.gov/c
| urrent/title-47/part-97#p-97.113(a)(4)
|
| > No amateur station shall transmit: [...] messages
| encoded for the purpose of obscuring their meaning,
| except as otherwise provided herein; obscene or indecent
| words or language; or false or deceptive messages,
| signals or identification.
| selimthegrim wrote:
| So numbers stations fall under as otherwise provided?
| beala wrote:
| No, numbers stations are not permitted on amateur
| frequencies in the US. There are some notable cases of
| foreign governments setting these up and interfering with
| amateur allocations [1], but there's not much the FCC can
| do about that.
|
| [1] https://www.arrl.org/news/russian-buzzer-disappears-
| chinese-...
| MarsIronPI wrote:
| My dream would be to have something like Yggdrasil[0] over
| some kind of mesh-based transport. Yggdrasil already does a
| good job with routing, it just needs a mesh-based transport
| IMO.
|
| [0]: https://yggdrasil-network.github.io
| jkingsman wrote:
| Big fan of MeshCore; been using it recently and it Just
| Works. Especially where I am in the USA Pacific Northwest,
| the mesh is always hopping with conversation. I have run
| into delivery issues a single digit number of times over
| hundreds of messages.
| pelagicAustral wrote:
| Unsurprisingly:
|
| > To the small group of people who has actually been here, and
| understood what this work was and what it cost - you already
| know where to find me if it actually matters.
|
| >To everyone else: This is where we part ways. No hard
| feelings. It's just time.
|
| https://github.com/markqvist/Reticulum/blob/master/MIRROR.md
| Evanito wrote:
| > I've never seen a bigger network with Reticulum in the wild.
|
| Bigger than.. what?
|
| > One of the main reasons of the communities not jumping onto
| the ship was that it's mostly a one-man-pr...
|
| Reticulum does not support group chats. Which is a far more
| realistic explanation than suggesting the average user cares
| what the commit messages are.
| tosti wrote:
| Such a nasty name for a good project ;-;
| ravenstine wrote:
| Sounds too close to "rectum".
| furyofantares wrote:
| The name comes from Neal Stephenson's book Anathem
| tosti wrote:
| Thanks. That's quite a dictionary there and I'm not familiar
| with that particular universe so the reference was lost on
| me.
|
| It's quite a tough read for me with such an alien vocabulary.
|
| Anyway, good to know it's not meant to resemble anything
| nasty.
| furyofantares wrote:
| The first ... few hundred pages were tough, between that
| and the massive amount of world building (which I enjoyed,
| but there is a lot.) I was lucky to make it over the hump
| as I find out well worth it.
| pona-a wrote:
| Surprised to see nobody mentioned Yggdrasil [0]. It's a routing
| protocol with cryptographic, non-topologic addresses, which could
| be used on top of TCP/IP or any alternative stack, like LoRA.
|
| I've been using it as a Tailscale replacement for a few weeks,
| including hosting game servers, with about equivalent latency,
| and it seemed pretty stable.
|
| How does Reticulum differ?
|
| [0] https://yggdrasil-network.github.io/
| Evanito wrote:
| For starters, Reticulum can communicate over a Yggdrasil
| network natively, but no one has yet implemented a Yggdrasil
| link over Reticulum as far as I am aware.
| snickerer wrote:
| A Yggdrasil link is an IP tunnel. Reticulum has its own
| network protocol instead of IP because IP would not work well
| over slow and low-bandwidth connections. I think tunneling IP
| through Reticulum would cause only headaches.
| Evanito wrote:
| A few years back, I ran Yggdrasil (poorly) over LoRa using
| a then-available experimental Meshtastic IP tunnel.
| Reticulum supports text-only websites (in the NomadNet
| software), and I have tested how these load over LoRa
| links. Loading time on a single hop (lab conditions) isn't
| half bad, honestly. My point in telling you this is that
| much of the mesh networking space is proof of concepts and
| poor executions, which _often_ must happen first before
| elegant solutions to _real_ problems can form.
|
| My 2C/ on why Meshtastic is so popular (despite its many
| flaws) is because the original developer decided to
| implement a solution for a real use case.
| igogq425 wrote:
| It is very stable. I have been using it for several years for
| exactly this purpose without any problems. It simply runs in
| the background and does its job so reliably that I simply
| forget about it for long periods of time.
| Western0 wrote:
| ygdrasill is very very big! reticulum use small band ygdrasil
| cant work on this small radio network
| azthecx wrote:
| I currently use Headscale, can you give some more details on
| how you use this to the same effect as Tailscale / Headscale?
| pona-a wrote:
| Yggdrasil is a more generic overlay. It can run over
| unconfigured Ethernet links, auto-discover other nodes on
| your local network, or punch through firewalls if you
| configure any public peers. You can setup a private network
| by only declaring your private peers. I think each device
| gets an entire subnet, so you might be able to expose
| multiple services on multiple IPs, though I'm not sure about
| that.
|
| My use-case was sharing things like game servers and websites
| with friends--which we previously did by sharing each other's
| machines/servers via Tailscale--and accessing my homelab
| remotely. For the first case, the public Yggdrasil network
| was much better than a mesh VPN like Tailscale: I don't have
| to manage invites or accounts--everyone who knows the address
| can just connect.
|
| For the second case, assuming addresses are discoverable
| (since 128 bits would make them quite hard to enumerate), I
| think a firewall gating by incoming IP will take care of that
| (since your IP is just a hash of your public key), though for
| now I've kept most sensitive ports unbound from it. I hadn't
| yet tried anything like Tailscale bridging (exposing a LAN
| address without configuring the client on the endpoint), but
| I'll try once I have a bit more free time.
|
| Tailscale is a nice abstraction on Wireguard, but Yggdrasil
| feels less like a solution to your specific infra problems
| and more like a coherent vision of how the internet ought to
| be. You can just rely on IPs as identities, link-layer
| encryption with Noise Protocol, and out-of-box hole punching,
| with relatively low latency (though I haven't tested the
| speed). It's the same feeling of awe as when I first saw how
| easy it is to host Onion Services, only not hampered by the
| abysmal speeds.
| uyzstvqs wrote:
| Yggdrasil is great. It's high-performance, uses regular IPv6
| TCP/UDP, and automatically forms one big, open network, where
| routes are available.
|
| Reticulum enables the creation of many different smaller
| networks, optimized for high-latency, low-bandwidth links
| (LoRa, packet radio). It uses its own addressing and transport
| system, with applications which are specifically made and
| optimized for it.
|
| Both are mesh networks, but have different use cases. Want to
| build your own private data network over longer distances?
| Reticulum. Want a fast alternative to the internet that's far
| more decentralized and secure? Yggdrasil.
| ogurechny wrote:
| This is something a clueless TV marketer would say, I
| suppose.
|
| Both tools can be used to both build private networks managed
| by a single entity, and to connect to global shared
| volunteer-run network.
|
| Reticulum is not a general purpose protocol-agnostic data
| transfer network into which you can plug anything. Also, when
| you want any kind of serious bandwidth over long distance
| radio, you have to meet with agencies managing national
| frequency plans, and they won't lease you anything for free.
|
| Yggdrasil is hardly an "alternative to Internet" as long as
| it runs on top of Internet links. Moreover, when public
| Yggdrasil network becomes big enough (assuming that it still
| runs on volunteer public nodes, just many more of them), the
| core of the network will have to form a backbone with links
| shaped by user concentration and user traffic flows, just
| like network of physical cables used by providers is shaped
| by demand, concentration of computing resources, geographical
| features, and so on. Someone will probably have to collect
| funds to pay for that. Or some new smart multipath routing
| with dynamic load balancing will be invented.
| ogurechny wrote:
| Those are different weight classes. If I recall correctly...
|
| Reticulum is a protocol and a set of ideas about basic building
| blocks for data exchange.
|
| Let's say you have some rusty wet wires (a serial link) or an
| antenna. You need to send some data. Typically, it goes like
| that: "Well, 0x01 is HELLO command, 0x02 is BYE... No, 0xFF is
| BYE... No, 0xFF should be reserved escape code for two byte
| commands", and so on. Then you realise (or find out) that
| someone else might accidentally or deliberately send similar
| messages, and their correctness and validity should be checked.
| You add hard-coded encryption keys (because surely no one is
| going to look for them), re-invent key exchange protocols, then
| wrap everything in TLS because it's the only thing that is
| expected to work globally (usually with hard-coded soon-to-be-
| expired certificates or without certificate checks at all). If
| you use some standard bus, some of those things have already
| been offered to you.
|
| Reticulum message payload is signed and encrypted by default
| (except for local broadcasts, but clear text can be treated as
| encrypted with a key everyone knows). Its destination is an
| abstract identity (tied to a pair of asymmetric cryptographic
| keys) which does not correspond to any physical network. They
| all are simply assumed existing and unique in some global
| space. No assumptions about protocols are made. You get some
| lower level data pipes -- shared medium (radio, bus -- the
| difference is in the shape electromagnetic waves take anyway),
| real or virtual point-to-point links (e.g. over IP). You can
| announce your presence, that's Layer 0 packets. You might not,
| and only listen passively. You can exchange some routing data
| and other gossip with peer nodes. That's also Layer 0 packets.
| You run some application, and destination it creates for is no
| different from node destination, and its announcements are no
| different from node announcements, and they are also Layer 0
| packets. One application on one node sends data to another, on
| another node? Same Layer 0 packets to some abstract identity.
| If you imagine a graph of node-identities, application-
| identities are also there, on the same plane, directly peering
| to their nodes. Same for multiple service-identities or user-
| identities under the hood of one application.
|
| Obviously, some kind of smart routing should support such
| identity graphs. First of all, we start with no routing, that's
| why one of the examples in the documentation is a temperature
| sensor that simply sends packets to a pre-defined identity over
| radio. It does not care whether the rest of the network exists,
| or whether anyone is listening to it. It might be a single
| board computer on the other side of the room, the only other
| node in the local network, with that destination as a sink for
| temperature data. It might be the same device with a globally-
| connected node that relays those messages, and over multiple
| hops over various types of links it gets to the destination at
| the other side of the world. The sender sees no difference.
|
| Then we have announcements that are re-broadcasted to peers of
| peers (if they have available announce bandwidth). As a result,
| nodes in the network (or some part of it) grow a list of routes
| based on how fast they got that announcement, from which peer,
| and with which retransmit (TTL) value (to reach destination
| abcd..., send packets to peer P). It is understood that those
| events are "rare enough", and the backbone "transport nodes"
| should be "stable enough". It is totally relative, though:
| default announcement rate might be on each restart or once a
| day, to accommodate for long range low bandwidth radio links,
| but on fast fat frequently changing local networks you can
| choose to re-announce each second, just like with routers
| checking each other via STP. On the other hand, we might not
| what to announce ourselves to the whole world ("Name's Bond,
| James Bond, destination 007..."), or someone might connect to
| the network after the announcement. There's an option to send
| WHO-HAS message from the other side if there is no known path
| to the destination yet. Without deliberate announcement, only
| the direct peer (our local node in case of some application
| destination) will know that we are present.
|
| Basic communication is unidirectional, and each message is
| independent from the other. You don't know whether someone
| received your message until the other side decides to send you
| the confirmation (if it knows where to send it using data
| provided inside the message or external knowledge). If two
| people meet, write down each other's destinations, and agree
| when to be online to use some application just sending
| individual packets, they don't need any high level protocol.
| Otherwise, there is the same freedom to adapt as in routing.
| One option is to establish a bidirectional link between two
| online destinations. It is a higher level abstraction provided
| to manage stable virtual circuit along multiple hops,
| disassembly of data into packets and correct assembly of them,
| one-time session keys for forward secrecy, and so on. Other
| option, supported in LXMF, is to store and fetch the data with
| the help of an intermediate participant. Obviously, store and
| fetch might happen at different points in time, so
| intermittently connected participants might choose to use that.
| At the moment, those intermediates ("propagation nodes") are
| simply chosen from random volunteers, but the system can be
| extended to provide fault tolerance and load distribution with
| common methods at higher level.
|
| There is built-in anonymity option (obviously, not "complete
| anonymity", just anonymity among Reticulum network users). If
| Alice and Bob want to chat in presence of some adversarial
| nodes matching opaque traffic, they can do that. However, if
| Alice or Bob is secretly working with those spying nodes, it's
| a bit different story. That's probably not that important with
| current number of users.
|
| So even if Reticulum can transfer IP packets as payload, and
| theoretically be used as a general purpose IP overlay network,
| it makes little sense. It is also, most likely, not optimised
| at all for that specific task.
|
| Yggdrasil is quite different. It's a practical test of an
| implementation of universally scaling routing algorithm (a
| number of such algorithms, if we take previous versions into
| account). It uses common IP transport, and therefore is aimed
| at systems with complete network stacks. Its goal is not being
| a cool mesh virtual private network (though it is cool), but to
| prove that decentralised global network with random user-
| generated cryptographic identities can converge and efficiently
| route traffic all by itself. But, yeah, all the cool kids these
| days have the [2xx:/[3xx: addresses, and even mine vanity ones.
| snickerer wrote:
| Reticulum is a production-ready full network stack. Cryptography
| and anonymity are first-class citizens there. It is transport-
| layer agnostic, not just tailored for LoRa. I like it, but is see
| two main problems that prevent the wide adaption, and they are
| related:
|
| 1. The library is written in Python. If you want to design phone
| apps, Linux server daemons in C, or embedded software (for
| example for the Lilygo T-Deck) this is a bad choice. Somehow
| doable (execpt for embedded), but no fun. A small lib with C API
| and C ABI would be better.
|
| 2. Most of the end user software has a horrible UI. But it gets
| better with software like the Android messenger Columba
| (https://github.com/torlando-tech/columba).
|
| If we would solve 1., we would have more end user software.
|
| Currently, there are 4 project who try to solve 1. by writing a
| Reticulum lib with a low-level language, everybody does it in
| their favorite language and on their own, of course: C++, Zig,
| Rust, Go
|
| The Rust implementation from Beechat seems the most mature. But I
| did not see it used in the wild, outside of Beechat's own
| devices.
| the__alchemist wrote:
| Surprisingly, the Rust impl is Std only, so it doesn't solve 1
| snickerer wrote:
| I took a deeper dive in Reticulum-rs. It is std. It
| implements 20% of Reticulum functionality. And it has 2 major
| protocol incompatibilities (like a different size for the MTU
| / Maximum Transfer Unit).
|
| It looks like a quick vibe coded hack to implement a subset,
| tailored only for Beechat's own devices.
|
| If someone would want to implement a full no_std Reticulum
| lib, they would need to start from scratch.
| the__alchemist wrote:
| My surprise level at your finding is low. I regularly start
| from scratch in embedded rust for precisely this scenario.
| A typical response is "Why not use [reticulum-rs] etc.".
| Your elegant description could be described with the "But
| we have McDonald's at home" meme.
|
| There are many cases where a library will be posted online,
| be mentioned in a blog post, and demonstrated in a
| demonstration workflow. If you try to use it for practical
| means, it becomes immediately clear it is "totaled" or
| easier to start over than fix or adapt it.
| mcny wrote:
| Practically, my biggest concern is deliver ability
|
| > The Zen Way: "I am <327c1b2f87c9353e01769b01090b18f2>. Wherever
| I am, my peers can reach me".
|
| > When links are intermittent and latency is measured in minutes
| or hours, "real-time" is an illusion. Reticulum doesn't encourage
| Store and Forward as a mere fallback, but as a primary mode of
| existence. You write a message, it propagates when it can, and it
| arrives when it arrives.
|
| Let's say A and B are talking.
|
| A sends message A1.
|
| B receives message A1.
|
| B sends message B1.
|
| A receives message B1.
|
| A sends message A2.
|
| Something happens and B doesn't receive it.
|
| A sends A3.
|
| B receives A3.
|
| Later, B receives A2.
|
| Now what does B do with this information? Does the envelope
| contain all the metadata about when A sent it so B client
| software can order the messages properly?
| andybak wrote:
| So not this Reticulum networking stack: https://github.com/Hubs-
| Foundation/reticulum
| the__alchemist wrote:
| Here is what I'm confused about: There is no published
| protocol/spec. It's nominally for radios like LoRa (Semtech)
| which are programmed with microcontrollers. To run it, you need
| Python software, or more recently, std Rust, both of which can't
| be used on the devices that would make sense for the hardware.
| heywire wrote:
| Sounds like you're looking for the RNode firmware
| the__alchemist wrote:
| I hadn't heard of this. It sounds like then you'd need a
| dedicated radio co-processor that is just running their
| firmware. Then, connect to it via [SPI?] to your main MCU or
| similar.
| heywire wrote:
| You can run it on a common board like a Heltec LoRa 32
| (can't remember if it supports v3 or just v2). I played
| around with it some, but mostly stick with Meshtastic.
| AyyEye wrote:
| Reticulum is not nominally for lora/sx radios. It is designed
| to operate over any transport from a serial link or infrared to
| high speed wireless lan or multi-gigabit ethernet.
| throw7 wrote:
| Doesn't look like a free software license. No purposeful harm to
| humans and no AI usage direct or indirect.
| ronsor wrote:
| I dislike these "non-free" licenses because the actors they
| purport to stop aren't going to care (why would a terrorist
| cell care about licenses? if AI training is fair use, then why
| would AI companies care about licenses?). All it does is create
| obstacles for legitimate people.
| egberts1 wrote:
| What all three need is a multiple-spanning tree for its master
| node and supporting slave nodes, much like eBGP.
| otikik wrote:
| > The Old Way: "I trust this site because the browser says the
| lock icon is green".
|
| > The Zen Way: "I trust this destination because I have verified
| its hash fingerprint out-of-band, and the math confirms the
| signature".
|
| PGP already tried something along those lines. It did not see any
| adoption.
|
| Problem with that approach is: UX is horrible. If someone
| technical like myself struggled to get it up and running
| correctly, what chance do less technical folk have?
|
| If you want to build a really boutique environment for 3 guys to
| feel good about themselves, the Zen path is the right path.
|
| If you want the public to adopt it, you need that green lock
| icon.
| blacklion wrote:
| Does anybody know how good routing in this Project protected from
| malicious actors, or simply badly configured nodes?
|
| As far as I know, most mesh routing protocols is very sensitive
| to rogue nodes, even if it is misconfiguration and not malicious
| intent...
| Evanito wrote:
| > Does anybody know how good routing in this Project protected
| from malicious actors, or simply badly configured nodes?
|
| Reticulum requires you to manually define your uplinks,
| including remote servers. If this remote server is blackholing
| your traffic, you are SOL.
|
| If you define multiple remote servers, then you may be in luck
| iff your destination is advertising its route on a path (chain
| of servers) that has no such hostile nodes.
___________________________________________________________________
(page generated 2026-01-20 23:01 UTC)