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.
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 :(.
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.
> 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.
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 :).
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.
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.
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.
>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.
> 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.
> 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.
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.
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.
>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.
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.
>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.
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.
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.
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.
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.
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.
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.
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.
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.
Yggdrasil can peer over the internet, but that's just convenience. In a global internet blackout, you obviously wouldn't have a global Yggdrasil network in a week, month or year, but you can have a reasonable regional network in that time. Every user is a node and can expand the network to new people. It's a P2P mesh, not volunteer-run. As regional networks start to peer to each other, it forms one big network automatically. You need cables and hardware, but that's not a problem when everyone has the incentive of wanting to use it.
You could build a public network over Reticulum, but why deal with the inconveniences of the protocol just to run it over high-bandwidth? It's specifically optimized for very low-bandwidth transports, so that you can cover long distances with just a small group of participants.
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.
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.
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.
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 2¢ 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.
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.
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.
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.
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?
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.
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.
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.
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.
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)
- 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.
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!
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.
With current size of the network, it's probably managed by sending messages to operators chat “Hey, IP a.b.c.d is doing that again”.
Remember that Fido and Usenet relied on independent server admins voluntary enforcing the rules for global groups (and allowed the alternative sister hierarchies or local appendices with different rules). It is possible to give more power to local decision maker, and share the global ideas.
Link establishment mentions validation of the circle by the intermediate hops. I suppose that someone who is sending a lot of packets without participation from the other side can be put into exponentially worse and worse queues. Or maybe not. There's a lot of things to test.
I mean, this is not a solution if we want winder adoption.
I was FIDONet node (and even hub) sysop, and I remember well, that FIDO was rigid hierarchical structure — you have your NC, and NC can discommunicate any node in his network. Yes, it was elected position, but after elections it was mostly dictatorship.
It doesn't seems like «Fully self-configuring multi-hop routing over heterogeneous carriers» advertised by this project, rather opposite.
> 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.
> 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.
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.
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.
> 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?
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.
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.
> 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
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)"
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.
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.
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?
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.
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.
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.
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
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
To be fair, satoshi stepped back too.
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.
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
> 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.
So what mesh stuff do you recommend for the uninitiated?
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/
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.
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.
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.
>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.
> 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/current/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.
So numbers stations fall under as otherwise provided?
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-...
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.
>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.
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.
>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/#region
> 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)
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)
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
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.
If you're talking radio mesh, then MeshCore and Meshtastic. Meshcore does chat much better than Meshtastic.
Meshtastic is good if you're in a remote location, and you want to connect a bunch of sensors and trackers.
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.
Surprisingly, the Rust impl is Std only, so it doesn't solve 1
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.
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.
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/
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.
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.
Yggdrasil can peer over the internet, but that's just convenience. In a global internet blackout, you obviously wouldn't have a global Yggdrasil network in a week, month or year, but you can have a reasonable regional network in that time. Every user is a node and can expand the network to new people. It's a P2P mesh, not volunteer-run. As regional networks start to peer to each other, it forms one big network automatically. You need cables and hardware, but that's not a problem when everyone has the incentive of wanting to use it.
You could build a public network over Reticulum, but why deal with the inconveniences of the protocol just to run it over high-bandwidth? It's specifically optimized for very low-bandwidth transports, so that you can cover long distances with just a small group of participants.
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.
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.
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.
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 2¢ 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.
I currently use Headscale, can you give some more details on how you use this to the same effect as Tailscale / Headscale?
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.
ygdrasill is very very big! reticulum use small band ygdrasil cant work on this small radio network
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.
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.
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?
Sounds like someone is a fan of Anathem!
That's an amazing book, and I highly recommend it, for anyone who isn't familiar.
Popular in 2022 (95 points, 15 comments) https://news.ycombinator.com/item?id=30870187
... urgently needed now ;)
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.
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.
Sounds like you’re looking for the RNode firmware
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.
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.
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)
- 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.
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!
there is a pretty compatible rust implementation as well which claims to target microcontrollers https://github.com/BeechatNetworkSystemsLtd/Reticulum-rs
Did you use it? I've never seen it used outside of Beechat's own devices.
so you mean it would work from Iran?
How does this differ from meshtastic? Is meshtastic just more chat based and this is more generic?
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.
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.
Give a try to Meshcore, their design has proven to be reliable in realworld use.
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...
With current size of the network, it's probably managed by sending messages to operators chat “Hey, IP a.b.c.d is doing that again”.
Remember that Fido and Usenet relied on independent server admins voluntary enforcing the rules for global groups (and allowed the alternative sister hierarchies or local appendices with different rules). It is possible to give more power to local decision maker, and share the global ideas.
Link establishment mentions validation of the circle by the intermediate hops. I suppose that someone who is sending a lot of packets without participation from the other side can be put into exponentially worse and worse queues. Or maybe not. There's a lot of things to test.
I mean, this is not a solution if we want winder adoption.
I was FIDONet node (and even hub) sysop, and I remember well, that FIDO was rigid hierarchical structure — you have your NC, and NC can discommunicate any node in his network. Yes, it was elected position, but after elections it was mostly dictatorship.
It doesn't seems like «Fully self-configuring multi-hop routing over heterogeneous carriers» advertised by this project, rather opposite.
> 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.
So, looks like no «Fully self-configuring multi-hop routing over heterogeneous carriers».
> 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.
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.
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%...
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.
> 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?
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.
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.
Not sure GitHub has such a clause. Just looked at their terms and don't see it.
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
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)"
It doesn't matter what the original purpose of the terms was it matters what they do.
[dead]
Doesn't look like a free software license. No purposeful harm to humans and no AI usage direct or indirect.
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.
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.
So not this Reticulum networking stack: https://github.com/Hubs-Foundation/reticulum
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?
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.
What all three need is a multiple-spanning tree for its master node and supporting slave nodes, much like eBGP.
Anybody have any experience running this on a tdeck? I'm kinda toying with the idea of ordering a couple just to play with.
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.
Ahh, yes. I see that now. I appreciate the correction.
Such a nasty name for a good project ;-;
The name comes from Neal Stephenson's book Anathem
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.
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.
Sounds too close to "rectum".