Named Data Networking

[samuk]

Is this similar to Reticulum? Better? Worse?

Could it run over Reticulum? What would be the point?

https://named-data.net/project/execsummary/
https://github.com/named-data
https://named-data.net/

Can someone smarter than me ELI5 how these projects differ, could compete or collaborate.

[faragher]

Disclaimer: I didn't know about this project until today, and have only spent an hour going through their documents. I don't pretend to understand it, since they're ponderously dense in theory with little in intent or implementation. ELI5 begins.

They're different tools for different jobs.

Intent

RNS is a network stack built on efficiency and security. It is end to end encrypted by design and is very lean. Example: the Fernet token was replaced by a custom implementation that saved nine bytes per token.

NDN is a network stack designed to replace access to content. It is built to be modular and extendable. Based on their introductory video, they intend to, somehow, solve dead links by using NDN to store the data as opposed to relying on the destination server remaining online. Their packet structure is variable and requires header information for each data section of the packet.

Target Network

RNS is built to transfer messages, and supports RNodes and other low speed high latency devices.

NDN is built to replace all functions of the internet and then some.

Ecosystem

RNS is an effort started by a single person and a number of contributors have made major contributions.

NDN was a university collaborative project with grant money. It has a wide number of listed contributors, many of which were likely university students collaborating as part of their program.

Analysis

Again, as someone who's invested in Reticulum, please take this with a grain of salt.

RNS is designed with a singular vision (that others have adopted, adapted, and expanded) built towards a technical goal. If you're looking to use low speed connections, primarily interested in messaging and security, and wish to build your own networks with minimal investment, RNS is a great tool.

NDN is a university research project, and creates a large amount of peer reviewed articles, many of which are describing theoretical solutions for future implementation. If you're interested in replacing TCP with a future technology that requires substantial bandwidth and focuses on many, many more goals than message transfer, security, and routing, then NDN may be a good tool. It's a little too theory-heavy for my tastes, but in the fullness of time it may become a very useful standard.

I am wary of some of the things NDN describes. It sounds like they're looking to retain data permanently, have no hatchetman saying "the feature creep ends here," and they have prioritized being everything to everyone over being suitable for a specific task. More on this below, but it's a different vision.

Competition and Collaboration

Their goals and targets are fundamentally different, but there is some overlap. There's no real reason to use both, but either could carry the other, again, for no good reason. If TCP disappeared tomorrow, either could be pressed into service to carry the other, but that defeats the entire point of their routing schemes. Both are designed to run on similar hardware (excepting low-bandwidth devices, which are very heavily the domain of RNS) and could run side by side without incident.

Collaboration is difficult. The intent is so wildly different that while the people working on the projects could absolutely collaborate, I'm not sure if either system has anything to offer the other.

Opinion

I'm afraid I need to bring in the Latin here, sorry. The Sine qua non of a data transport layer is to transport data. If it does that thing, it is a transport layer; if it does not, then it is not.

Reticulum transports data. It is lean and it is effective. It is highly decentralized and cryptographically secure.

Named Data transports data, and it may be some of those things, but it is not lean. It looks to replace TCP/IP with a "yes and" mentality which moves it away from a transport layer and into a whole new ecosystem.

Many of the things NDN lists as core concepts are dealt with in apps that run on RNS. NomadNet does a tremendous amount of heavy lifting on the network and is distinct from the protocol itself. By keeping these concepts separate, Reticulum keeps the barrier to entry low and the documentation short, as opposed to NDN having sprawling, meandering documentation that explains nothing despite the claim of "it has to be so simple your mother can use it."

Similarly, I am against data scraping and protocol level data retention. Intellectual property, automatically collected and retained in perpetuity, is still the property of that person and shouldn't be rehosted without express consent. Similarly, I've seen what people do with Freenet. (If you don't know what I mean do not look into it)

Ultimately, I see NDN as a grand research goal, but not really something I'd use at this time. I also think they fail to see the lessons of the past. For all of their theoretical ideas, I fail to see how they're fundamentally different from Usenet or Fidonet, just with more overhead and a different transport layer.

However, I wish to close by repeating that I am not intimately familiar with the NDN, and it's possible that their major failing is a poor representation on their public-facing documents. They're daring to do great things, and that's always a worthy project. However, I want lean data communication over packet radio. Everything else is a happy side-effect. For that application, the tool is RNS.

[samuk]

Thanks for taking the time to look into that and write it up.

[markqvist]

Thank you so much for this concise and informative comparison!

[lixia]

whoever supplied that long explanation about NDN: I am afraid it is a bit too far from being correct -- it is not your fault but the fault of the NDN designers (myself included) for not providing a simple, clear explanation of exactly what NDN really is, which resulted in others speculating. I hope we can fix this problem in some near future.
But as one sentence explanation: NDN is true to its name, named data networking, it is all about directly using names to communicate securely, resiliently, and efficiently.
Why using names? As Geoff Huston argued at end of a recent post: although we do not route “names” in today’s Internet, "but it is certainly operating in a way that is largely isomorphic to such a named data network."
here is the post, enjoy: https://www.potaroo.net/ispcol/2024-10/ipv6-transition.html