Yep, indeed, I’m already discovering differences too. :) A good document for techies to read seems to be here.

https://reticulum.network/manual/understanding.html

I also think I see a problem on the horizon: announce traffic volume. According to this description, it seems that Reticulum tries to forward all announces to every transport node (router). In a small network, that’s OK. In a big network, this can become a challenge (disclaimer: I’ve participated in building I2P, but ages ago, but I still remember some stuff well enough to predict where a problem might pop up). Maintenance of the routing table / network database / <other term for a similar thing> is among the biggest challenges when things get intercontinental.

Interesting project, thank you for introducing. :)

I haven’t tested anything, but only checked their specs (sadly I didn’t find out how they manage without a distributed hashtable).

Reticulum does not use source addresses. No packets transmitted include information about the address, place, machine or person they originated from.

Sounds like mix networks like I2P and (to a lesser degree, since its role is proxying out to the Internet) like TOR. Mix networks send traffic using the Internet, so the bottom protocol layers (TCP and UDP) use IP addresses. Higher protocol layers (end to end messages) use cryptographic identifiers.

There is no central control over the address space in Reticulum. Anyone can allocate as many addresses as they need, when they need them.

Sounds like TOR and I2P, but people’s convenience (easily resolving a name to an address) has created centralized resources on these nets, and will likely create similar resources on any network. An important matter is whether the central name resolver can retroactively revoke a name (in I2P for example, a name that has been already distributed is irrevocable, but you can refuse to distribute it to new nodes).

Reticulum ensures end-to-end connectivity. Newly generated addresses become globally reachable in a matter of seconds to a few minutes.

The same as aforementioned mix networks, but neither of them claims operability at 5 bits per second. Generally, a megabit connection is advised to meaninfully run a mix network, because you’re not expected to freeload, but help mix traffic for others (this is how the anonymity arises).

Addresses are self-sovereign and portable. Once an address has been created, it can be moved physically to another place in the network, and continue to be reachable.

True for TOR and I2P. The address is a public key. You can move the machine with the private key anywhere, it will build a tunnel to accept incoming traffic at some other node.

All communication is secured with strong, modern encryption by default.

As it should.

All encryption keys are ephemeral, and communication offers forward secrecy by default.

In mix networks, the keys used as endpoint addresses are not ephemeral, but permanent. I’m not sure if I should take this statement at face value. If Alice wants to speak to Bob tomorrow, some identifier of Bob must not be ephemeral.

It is not possible to establish unencrypted links in Reticulum networks.

Same for mix networks.

It is not possible to send unencrypted packets to any destinations in the network.

Same.

Destinations receiving unencrypted packets will drop them as invalid.

Same.

P.S.

I also checked their interface list and it looks reasonable. Dropping an idea too: an interface for WiFi cards in monitor/inject mode might help some people. If the tool gets popular, I’m sure someone will build it. :)

If Chat gave me a broken answer, I would appreciate if someone said “hey, look - it’s broken here”.

The solution is obvious: wind energy can be collected outside a building, on an empty field, or at sea for maximum emptiness. Which is what people already do.

instead of having me listen to your gripes

Not my preferred way of dealing with criticism. You wrote a proposal (well, you let Chat write a proposal and presented it). I read it through, and considered if it was OK. I found parts that weren’t and said so. If you don’t want to listen to that, why did you post?

I am splitting a hair, but the goal is pointing out - Chat is nice at producing text and searching for information, but unreliable at actually evaluating if something would work. Unless you’re extremely good at asking, it will spew proposals that won’t work.

P.S.

As for non-rotating wind generators, yep, I’ve read about them. They aren’t efficient. In the equations determining performance, there is a term named “swept area”. For a non-rotating generator, swept area is the surface of its profile viewed from upwind/downwind. For a rotor, swept area is the surface of the circle reached by blades. The difference is huge.

…and that is why Chat cannot be trusted to build houses. It hallucinates:

Exhibit A:

At its core, this building incorporates an innovative vertical farming system. Towering gardens thrive within its walls,

Exhibit B:

The building’s walls are constructed using rammed earth or compressed earth blocks, utilizing the surrounding soil and natural resources abundantly available in the area.

One can go vertical, or one can go rammed earth. One does not go vertical with rammed earth. :) And wind turbines attached to building structure are a nuisance. An efficient turbine needs to be clear of obstacles.

Beyond that, it has done a good job. The write-up was streamlined with my cultural sensibilities, before it collided head on with my sense of engineering. :)

I tried, and that GitLab page requires logging in. I don’t have an account, so I can’t comment more.

More information can be found here: https://veilid.com/framework

I read it, haven’t tested it - commentary below.

Before I go into commentary, I will summarize: my background is from I2P - I helped build bits and pieces of that network a decade ago. As far as I can tell, Veilid deals in concepts that are considerably similar to I2P. If the makers have implemented things well, it could be a capable tool for many occasions. :) My own interest in recent years has shifted towards things like Briar. With that project, there is less common ground. Veilid is when you use public infrastructure to communicate securely, with anonymity. Briar is when you bring your own infrastructure.

• Networking

Looks like I2P, but I2P is coded in Java only. Veilid seems to have newer and more diverse languages (more capability, but likely more maintenance needs in future). I2P has a lot of legacy attached by now, and is not known for achieving great performance. A superficial reading of the network protocol doesn’t enable me to tell if Veilid will do better - I can only tell that they have thought of the same problems and found their own solutions. I would hope that when measured in a realistic situation, Veilid would exceed the performance of I2P. How to find out? By trying, in masses and droves…

• Cryptography

Impressive list of ciphers. Times have changed, I’m not qualified to say anything about any of them. It leaves the appearance that these people know what they are doing, and are familiar with recent developments in cryptography. They also seem to know that times will change (“Veilid has ensured that upgrading to newer cryptosystems is streamlined and minimally invasive to app developers, and handled transparently at the node level.”), which is good. Keeping local storage encrypted is an improvement over I2P - last time I worked with I2P, an I2P router required external protection (e.g. Linux disk encryption) against seizing the hardware. With mobile devices ever-present everywhere, storage encryption is a reasonable addition. I notice that the BlockStore functionality is not implemented yet. If they intend to get it working, storage encryption is a must, of course.

• RPC (remote procedure calls)

Their choice of a procedure call system is unfamiliar to me, but I read about it. I didn’t find anything to complain about.

• DHT (distributed hash table)

Looks somewhat like I2P.

• Private routing

Looks very much like I2P.