rns.recipes

I saw https://github.com/markqvist/Reticulum/releases/tag/1.2.4 which says:

...this will probably be the last release that is also published to GitHub, since everything can now run over Reticulum itself

And I have two thoughts:

1. It's genuinely really cool that that is possible now!
2. I feel like there are significant downsides to discontinuing all official IP-based mirrors:

• It makes bootstrapping new Reticulum networks unnecessarily difficult; new people will have to trust a middleman
• It will likely be bad for publicity/public visibility; even more people will think Reticulum is 'dead' despite the efforts of the general community
• It unnecessarily removes redundancy if the Testnet were to ever become inaccessible and require a protocol-level change to fix

Bootstrapping a Reticulum network requires a certain level of TOFU because even signatures of things are verified with it, so starting with an untrustworthy or compromised version of Reticulum makes it much harder for people to trust anything else they use Reticulum for.

My main point is that, as long as all development happens over Reticulum itself, I see little downside and many benefits in continuing to host official mirrors on the IP-based internet.

Thank you for reading :)

It says right in the release notes that I'll continue to push releases to pip:

| Updates to pip will continue at least until rnpkg is complete, and RNS is completely self-hosting.

I don't think not putting release notes on github is really gonna make it any harder for people to get onboard. Personally, I think github is horrible to work with, and the release functionality is cumbersome. Now I can just do:

rngit release

And it's done. One command, and all the resources are out there :)

I also don't (personally) think less visibility is a bad thing. The large amount of attention lately has mostly (not entirely, but relatively speaking - mostly) resulted in:

• Vibe-coded weirdness projects that completely misunderstand the point of Reticulum, changes peoples config files without them knowing, spamming announces every 10 seconds and generally not having a clue what they want to do, after which turning to abandonware after three days.
• Silly attempts at DDoS attacks, announce spam en masse, automated LXST call harassers.
• LLM-generated "Reticulum Implementations" that are most likely as secure and reliable as a wet paper in a war-zone.
• Me getting around six "CRITICAL CVE SECURITY ADVISORIES" every week. Yes, it's all LLM output, and it's all utter nonsense. And the people who "operate" the machines (or whichever way around it is) gets tricked again and again, and think they've found something real (but no, they have no actual understanding of it, they just see the text and get excited).

That kind of attention never really brings anything constructive.

All of that being said, there are some really cool and awesome new stuff going on, and more people are building more actual neat things with Reticulum, which is a joy, and a more optimistic note to leave this message on.

Also, regarding trust, the new rnid in 1.2.4 makes package verification very easy:

rnid -i bc7291552be7a58f361522990465165c -V rns-1.2.4-py3-none-any.whl

You just need the package and the associated rsg file. Works completely offline even without access to any network.

https://youtu.be/m5t08CREHcE - The GitHub situation just got worse...

Ouch, that's an unfortunate one!

Ouch, that's an unfortunate one!

Hmm.. I just realized that back/forwards navigation can apparently double-post messages on the forum. I'm not sure if this is happening bacuse back/forward now includes the request vars as well, or whether it was always there. As for as I know, I set it up so only URL vars are included, but not the field data. If anyone figures out whether this is a handling bug in nn and/or the forum, it would be interesting to know what's going on.

Do you think you could do a final GitHub release that just links to https://pypi.org/project/rns for all future releases?

I believe that's a good way to at least stop the (few) people who use the GitHub releases from running 1.2.4 in perpetuity.

For the record: imo GitHub does, in fact, absolutely stink. Just remember what they say about babies and bathwater ;)

I think if an internet mirror is still wanted, using forgejo / gitea would be a good alternative for github

Yeah, probably not a bad idea with all the pretty important updates in 1.2.5. It's done :)

It would be nice to have something, because from the outside it just looks like reticulum is a dead project. I understand the animosity toward github. But there are alternatives, and right now there is nowhere to report bugs or look over current issues when you are getting started, or share solutions. Having development occur on reticulum itself is neat and all, but it isn't callaborative and is yet another barrier to entry. I spent over a day trying to get an rnode working on a very popular lora device, just to find an issue in the python code of rns itself. If I struggled that much, normal users are just going to give up. They certainly aren't going to waste time trying to hunt down which magical realm on reticulum they can report the issue. After a couple of days of messing with this, I am just burned out. And I am technically competent. I can fix the issue locally, and write a script to patch the code on updates, but it would be nice to share this information with other people. This just doesn't feel like a community that wants to grow. At this point I think I am just done.

throwing it out there that codeberg [https://codeberg.org/] could be a a middle ground location for the code to live on the clear net, and solves the problem of collaboration.

A barrier is good for many reasons, and I personally like it. It forces people to put in the effort. There are plenty of threat actors and disruption efforts ongoing, and some target the mind, so developers should protect themselves. My Gitea instance at git.quad4.io, with a few public repos, is constantly getting hammered by bots and scrapers to the point where it sometimes becomes unusable. I am tired of tuning fail2ban, and I am not interested in these javascript PoW or WAFs as they just cause other issues. The best solution by far is rngit, it is lighter and easier to setup multiple rngit instances for redundancy.

Numerous people have reported issues to me over LXMF and some have submitted patches.

ooo, the input fields are not great when a light theme is used.. .. anyway - excuse any spelling..

I maintain the openbsd ports, ideally there will be releases on pip that continue .. alternatively maybe an official "http" thing can be exposed. .. baring that.. I guess I could mirror the release files on one of my servers (i host files for a few othre ports atm)

qbit, can the openbsd packaging system use the source tarballs from pip? I'll keep pushing releases there, so I can push the tarballs as well. The only thing I'm kind of iffed out about is that I have no way to upload release signatures via pip, unless there's some kind of way I've missed that allows you to sign whl files. It's always annoyed me that you can't do that.

Is there no way for the openbsd port to pull something via RNS itself and check the rsg signatures? Or what are the requirements actually? Sorry, I have no clue about how openbsd packaging works ;) I can set up something if there's a way.

Completely agree there Ivan, having some sort of barrier to entry is a good thing, especially when you're the one on the receiving end of a lot of nonsense and bs that the public doesn't see. True that, on targeting the mind.

Mark wrote:

Completely agree there Ivan, having some sort of barrier to entry is a good thing, especially when you're the one on the receiving end of a lot of nonsense and bs that the public doesn't see. True that, on targeting the mind.

With all due respect, I don't gatekeeping reticulum, which becomes more powerful as a concept the more people use it, simply because of a few bad apples, is a good idea. I understand having attention and having people scream at your face every day is fucking tough, I've dealt with this before, but that should prevent people from taking real utility at something that I believe could be useful and powerful. The "negative" attention you speak of eventually nurtures into something time and effort, but not if you have a jaded attitude and try to tear it down.

If you can't personally deal with that and want to be left alone, that's fine, nobody would blame you for that. If you just want to have some trusted people occasionally send you emails about anything important for your mental health, that's fine. If you want to ignore everything random people send you, that's fine, their not entitled to your brain cause they send you something.

Now here's my 2 month lurker opinion that I'm trying to be genuine with but I may be entirely wrong about. I think you've made yourself the main failure point for this project and I see your name being thrown around more frequently than reticulum itself. if anything breaks, if there's any issues, you end up being the person solely responsible, having to do every little chore and respond to every little critic and have to implement every single feature is obviously gonna wear you down like it has. You make yourself responsible problem and every ill-written app based on reticulum if it's actually your responsibility or not, Humans are not built for that stuff. You cannot truly back away because for better or for worse you might the only person who actually understands the entire codebase and edit it, and pawning off your own health is the only to get things done. Micromanaging everything just doesn't work for you. But you just don't have to do that anymore if you don't want to.

in my uninformed opinion the main thing lacking from reticulum is the documentation (be it of the implementation and how to build ontop of it), it's not impossible right now, but functionality of how the network works already took me a few weeks to understand (some examples would have been nice), making things harder by not really having any good starting places to make software, well, that's how you get people vibe coding entire programs. Plus it's a good force multiplier, you answering a common issue once prevents you from having to answer it 100 times and lets 10000 people build on top of it. The main domain of stuff that needs doing is software to built on top of the protocol to give it real utility. Hell I mentioned wanting to write in the wiki earlier because I see that as a big issue, that no matter how cool and resistant the protocol is, if it takes 5 months to build anything, nobody will ever use it. But I want it to be used, I want to build stuff on top of it because I think it's neat, I think it's good software and I think I could actually help people one way or another. Wanting a higher barrier of access is the exact opposite of this, it doesn't bring less "negative" attention, it just snuffs out the "good" attention that could have turned into something great.

I'm sorry people made you feel this way about reticulum. There's not much else I can say.

And people who have the skillsets to troubleshoot, triage issues, write documentation, etc., are never going to find a way to contribute because the project has decided to erect "barriers of entry." This is how good open sources ideas die. But I digress, I have no vested interest in the project or how it works. If anyone cares to tell someone who actuall knows a gatekeeper, there is an issue in RNodeInterface.py that impacts Linux and Heltec v2 devices - maybe others using CP210x but I don't see any point in making the effort to do more testing. It is apparent us unwashed masses are unwanted. The serial port is opened with dsrdtr=False but the driver in Linux is going call DTR regardless. Adding self.serial.dtr = False and self.serial.rts = False after the self.serial stanza resolves it. If it isn't a true bug, then someone should probably post something in the rnode guide, because the heltec v2 fails in way that is going to be cryptic to a user. If you still want those.

I share a lot of the concerns and some of the frustration that others have expressed in this thread. I would really like to better understand if there is any community involvement desired in the future of Reticulum. Mark I truly admire what you have built, and I deeply respect your decisions regarding interacting frequently with the public. With respect, what is the direction you want to take this project? Is it essentially open source but closed to all outside contributors, suggestions, etc.? As close to closed source as an open codebase can be? Or are you open to having a larger open source community working on the project with you? In what ways can all of us support the future of Reticulum? Obviously you don't owe me a response or answer to any of those things, but I figured it wouldn't hurt to ask. I really want to see this grow as a platform and splintering at such a huge moment of growth will only hamper everyone's efforts.