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.

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'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/

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.

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

As far as I know, most mesh routing protocols is very sensitive to rogue nodes, even if it is misconfiguration and not malicious intent...

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