RNS Logo

rns.recipes

◈ 9ce92808be498e9e05590ff27cbfdfe4
NomadNet 1.4.0 released with experimental image support https://pypi.org/project/nomadnet/

Introducing PRNs: High-Performance Reticulum built to run on any Device (And how you can help)

Locked

Started by KenAKAFrosty ·

Zenith Admin
edited #81

imagio wrote:

No, it does not.

Maybe a better question to ask is "why" instead of slopcoding together the 9th millionth Rust port that will be abandoned in 2 months.

The firmware uses the same exact RNode flasher that can be done via the web or with rnodeconf. It targets nearly any ESP32 or nRF platform. Atterman also wrote microStore which is of incredible benefit to microcontroller based Reticulum nodes and it's integrated in the microRNS firmware. https://github.com/attermann/microStore

Something I have yet to see any vibecoded Rust port, or microcontroller targeted project in general even bother with.... which means that RNS is not usable in any capacity in the long term on a microcontroller platform.

Anonymous
#82

Obviously people have free will and can vibeslop stuff together willy nilly, but they never ask why they should, lmao. I certainly wouldn't want to reinvent the wheel, nor would I have the necessary time to maintain an implementation to stay congruent with the reference implementation.

imagio 29e9ca9346785ff9...
#83

Presumably we're all here because we think reticulum is a good idea and want to see it flourish. Denigrating people's efforts toward that goal (that they undertake in their own free time) either isn't helpful or is actively harmful toward what we all presumably want. If you don't like someone's code for whatever reason then don't use it. If you don't have anything positive to contribute then please don't. Life is short, negativity and infighting just aren't worth the time when there's so many more interesting things we could do, at least IMO.

Anonymous
#84

imagio wrote:

Presumably we're all here because we think reticulum is a good idea and want to see it flourish.

If this were genuinely true, then developing 1000 different implementations that have questionable interoperability is antithetical. Mesh networks only work well when the nodes interact predictably, repeatedly, and reliably. Every "Newer! Greater! Better!" implementation created only increases the risk of meshes becoming unstable and dysfunctional.

Denigrating people's efforts toward that goal (that they undertake in their own free time) either isn't helpful or is actively harmful toward what we all presumably want.

See above.

If you don't like someone's code for whatever reason then don't use it.

For as easy as it sounds, it doesn't work. Your broken node will still attempt to connect and interact with the rest of the mesh. We already have problems with the public mesh.

Life is short, negativity and infighting just aren't worth the time when there's so many more interesting things we could do, at least IMO.

Would love to avoid arguments with people who think they know better. But, they think they know better and willfully disregard criticisms for attempting to make implementation #1000.

imagio 29e9ca9346785ff9...
#85

Telling people they're wrong rarely gets the results one hopes for. If you're concerned that OPs implementation isn't conforming to the reference well enough why not help correct concrete issues you've identified? Or work on making an official spec so all implementations can easily verify conformance if that's your chief concern? Those would be helpful and useful actions. Complaining that you don't like how some people choose to implement a public domain protocol simply isn't going to change anything, much less improve anything.

Anonymous
#86

Well reading this conversation. I'll just say. You are all incredible engineers and you all act and sound just like engineers lol. The subject changes. The people never do.

"Presumably we're all here because we think reticulum is a good idea and want to see it flourish. " - the best of us . . . who is not yet burnt out

Let's all work towards a pattern of eventual consistency. It never eventually gets there but it can get close and the quality and value of the result is purely dependent on the process. We all do our best to build on what those have built before us. Instead of pointing out the things that bother you and pointing them out as the failure of others try and ask what you can do to fix that problem. Large development teams are chaos and anyone who has built tooling for other teams can tell you just how hard and important it is to guide them towards intent. Abstract interface/contracts, strict custom linting, git hooks, class abstractions, packaging, documentation, and governance are things that really are only learned through anagorisis experiences for developers. It is also the type of epiphany I fear we lose in this AI world when we need it most.

@Zenith is right, but I also think they are framing the problem wrong. Guiding collaboration to an intended model is an art in itself. Leadership on clear communication are as important to these sorts of large projects as the code itself. There are no perfect system and no development team I have ever worked on contains a naturally unified view on open questions in development, instead you get a natural result of a process and that process decides the quality of the answers. It sounds to me like some action towards building tooling that assists in distributing work towards the project's true needs and guiding principles on how to best to broach these problems when they occur would be so valuable.

"This looks like it was a lot of work, but I fear it lacks validation and may be a duplicate of another project, perhaps you can help them test their solution and suggest changes"

"This project doesn't meet our minimum standards but here is where you can find tooling to improve on that"

"At the moment we are inundated with unverifiable code that is difficult to review and stands outside our more common packages, please run these validation steps and respond here"

"Our automated system has evaluated the codebase and prioritized review based on adherence to these basic principles. If you would like to raise visibility of your project you must meet the following standards"

Perhaps someone here could make this their next contribution.

I will tell you my fear and I have a regional concern, and a vision for this system that likely does not fit the framing for everyone here. This system needs adoption to fulfill that vision and would be defeated through several vectors of attack. One is the very thing @zenith is concerned about poor code quality creating security concerns in the codebase or worse malicious vulnerabilities introduced. But what I think companies and governments would do to kill this is not that at least not as a first attack. They will paint it as a channel for criminals and only criminals. They will target maintainers. They will regulate its channels through captured regulatory bodies restricting ism band utilization. They will criminalize manufacture. This system is a threat to the status quo and will in turn as it is already inevitably growing due to various global concerns become mainstream across the anglophone world. That puts this project on a clock in my opinion. It must achieve mainstream adoption prior to that inevitable escalation of force due to commercial conflict. That's why I've been building out the tooling I presented in the showcase, and I released it all at once. Sudden capabilities. (and if my analytics are accurate wow ya'll got real interested in rns-shop not worried about that at all lol). My point is that in my singular opinion we need to channel the interest this project has garnered into providing accelerated development of the system itself.

imagio 29e9ca9346785ff9...
#87

To become a target of governments and malicious (more than nuisance) actors would almost certainly require some userbase and notoriety. Nobody is going to target us few geeks on the internet toying with our distributed protocol projects. Having that be a tangible concern might even be a good thing because it would mean tons of people know about and are using reticulum.

If the real worry is about fragmentation due to multiple implementations then IMO a good next step is to put effort into a formal protocol specification so it's easy to ensure implementations are compliant. I'm not sure there's really any other way to address that concern. The protocol is public domain and the code is open source. People will make their own implementations. If we (as people interested in reticulum) want to ensure those implementations are compliant and secure we should probably try to make it easy to verify them.

At least IMO I don't think incompatible implementations are likely to last long. The incentives don't line up. Everybody who's acting in good faith wants their implementation to be 100% exactly compatible with the reference so it works well on the wider network otherwise it would be kinda pointless, no?

Zenith
edited #88

imagio wrote:

To become a target of governments and malicious (more than nuisance) actors would almost certainly require some userbase and notoriety. Nobody is going to target us few geeks on the internet toying with our distributed protocol projects. Having that be a tangible concern might even be a good thing because it would mean tons of people know about and are using reticulum.

If the real worry is about fragmentation due to multiple implementations then IMO a good next step is to put effort into a formal protocol specification so it's easy to ensure implementations are compliant. I'm not sure there's really any other way to address that concern. The protocol is public domain and the code is open source. People will make their own implementations. If we (as people interested in reticulum) want to ensure those implementations are compliant and secure we should probably try to make it easy to verify them.

At least IMO I don't think incompatible implementations are likely to last long. The incentives don't line up. Everybody who's acting in good faith wants their implementation to be 100% exactly compatible with the reference so it works well on the wider network otherwise it would be kinda pointless, no?

"Make"
Carefully omitting the fact that "making implementations" (whatever your definition of that is) has never once been stated as the issue. The issue is with entirely vibecoded, black-box proompted implementations shat out by a machine in a language that the sloperator doesn't even know the basics of that are a sprawling monorepo of millions of lines of code sight unseen. Very interesting how you did not include that at all in anything you wrote.

 

image.png

This thread is locked. No new replies can be posted.

Quote
Copied to clipboard