# Re: Discontinuing the GitHub Mirror _General · started by LinuxinaBit on Thu, May 7, 2026 9:46 PM_ --- ## Original post **LinuxinaBit** · Thu, May 7, 2026 9:46 PM 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 :) --- ## Reply 1 **Mark** · Fri, May 8, 2026 12:30 AM 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. --- ## Reply 2 **Mark** · Fri, May 8, 2026 12:33 AM Also, regarding trust, the new `rnid` in 1.2.4 makes package verification very easy: ```shell 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. --- ## Reply 3 **aetherlab** · Fri, May 8, 2026 6:11 AM https://youtu.be/m5t08CREHcE - The GitHub situation just got worse... --- ## Reply 4 **Mark** · Fri, May 8, 2026 10:56 AM Ouch, that's an unfortunate one! --- ## Reply 5 **Mark** · Fri, May 8, 2026 10:58 AM Ouch, that's an unfortunate one! --- ## Reply 6 **Mark** · Fri, May 8, 2026 11:00 AM 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. --- ## Reply 7 **LinuxinaBit** · Sun, May 10, 2026 1:56 AM 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. --- ## Reply 8 **LinuxinaBit** · Sun, May 10, 2026 2:09 AM For the record: imo GitHub does, in fact, absolutely stink. Just remember what they say about babies and bathwater ;) --- ## Reply 9 **itsme** · Sun, May 10, 2026 5:20 AM I think if an internet mirror is still wanted, using forgejo / gitea would be a good alternative for github --- ## Reply 10 **Mark** · Sun, May 10, 2026 7:10 AM Yeah, probably not a bad idea with all the pretty important updates in 1.2.5. It's done :) --- ## Reply 11 **calebm** · Mon, May 11, 2026 12:02 AM 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. --- ## Reply 12 **sprell** · Mon, May 11, 2026 1:20 AM 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. --- ## Reply 13 **Ivan** · Mon, May 11, 2026 3:22 AM 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. --- ## Reply 14 **qbit** · Mon, May 11, 2026 7:29 PM 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) --- ## Reply 15 **Mark** · Mon, May 11, 2026 8:29 PM 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. --- ## Reply 16 **Mark** · Mon, May 11, 2026 8:31 PM 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. --- ## Reply 17 **welo** · Mon, May 11, 2026 10:23 PM **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. --- ## Reply 18 **calebm** · Mon, May 11, 2026 11:49 PM 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. --- ## Reply 19 **sprell** · Tue, May 12, 2026 2:35 AM 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. --- ## Reply 20 **joakim** · Tue, May 12, 2026 6:50 AM **welo** wrote: > ***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) You're right, that is an uninformed opinion :) The manual is really comprehensive and does include examples. Reticulum is very complex network software, it requires a good understanding and a mininum of skills in order to build upon it. But it's all there in the manual, if you take the time to read it. It is possible to contribute to Reticulum, the old school way with communication and patches. Heck, even I have. But the bar is relatively high, as it should be for a project like this. I know people often react to the way that this project is run. It's not your typical open source project. I could list some reasons why I think that's a good thing, instead I'll quote E. F. Schumacher: > The modern industrial system has a built-in tendency to grow; it cannot really work unless it is growing. The word “stability” has been struck from its dictionary and replaced by “stagnation”. Its continuous growth pursues no particular aims or objectives: it is growth for the sake of growing. No one even enquires after its final shape. There is none; there is no “saturation point”. That is the mentality of our society, and by extension of open source. For a project like Reticulum, I believe stability and integrity are much more important than metrics like speed of growth or numbers of contributors. That said, I think *some* kind of bug/issue tracker would be good. Users need a way to report issues for developers to be aware of them. --- ## Reply 21 **Mark** · Tue, May 12, 2026 10:16 AM Instead of answering comments individually here, I'll just say that Joakim's reply pretty much sums it up. The E. F. Schumacher quote perfectly illustrates the ontological schism that makes it so tiresome to deal with stuff like this. There is, in this day and age, between different people, widely different base conceptual integrations of what "open source" means. For many people, "open source" has become synonymous **not** with skilled people working together in a coordinated and careful way on complex engineering challenges, but a sort of growth- and attention-focused "free-for-all" *behavioral* codex that must be followed above all else; a *social* modus operandi of fake inclusivity where everyone "should have their voice heard", and adherence to the process is weighed much higher than the final results. I do not subscribe to, and consequently do not operate the Reticulum project under any versions of this idea. **Here's the statistical, boring reality:** - Around 90% of pull requests and "recommendations" I received when people could just submit stuff via GitHub would have *severely* broken things, introduced bugs or security issues, created roadblocks for future work, or otherwise damaged the software. Usually just for the sake of satisfying a random newcomers "idea" or personal preference. - Similarly, around 90% "bug reports" were actually people asking for help, because of having failed to read even the most basic parts of the documentation. - The people with the least amount of understanding, skill and effort invested tend to be loudest and most vocal. When all you have is "opinions", those are iterated upon ad infinitum, apparently. Can you imagine how much time that wasted? Can you imagine what we could have accomplished with that time instead? The only thing that this creates is *noise* and confusion. Clogging up the mental and physical workspaces, of people who are actually investing time and effort on the project with stuff like that is objectively just taking time that could have been used on development, and replacing it with *nothing*. Even this thread is, in *some* regards, an example of this phenomenon. In the time I have used to read, carefully consider, and formulate a reply to this, I could have gotten a good deal of the way with implementing fork and mirroring support in `rngit`. What do you think would have been best for the actual users of Reticulum? What has really *happened* here, other than stating personal opinions? --- ## Reply 22 **Mark** · Tue, May 12, 2026 10:17 AM I was receiving *actual* bug reports, pull requests, proper technical investigations and patches via methods outside GitHub and "public" internet-based channels *way* before GitHub interaction and similar was closed down. That was were almost *all* of the real contributions were coming from, anyway. Apparently, and not unsurprisingly, the people who has invested the time and effort to understand Reticulum also prefer to collaborate in this way. Since leaving that madhouse behind, the signal-to-noise ratio has **significantly** increased. Managing a public "issue" tracker with global read/write access is a futile and useless endeavor. Consider this: - User A reports a "bug" that is really just a failure of understanding. - User B sees this and seconds is, proposing a "fix" that in continued failure of understanding would actually break functionality X. - User C joins the bandwagon and asks why this hasn't already been implemented like that? It's obvious! The sensible response here from the developer is closing the issue with "No. Go RTFM". Today, though, this usually results in hurt feelings, animosity towards the developer and in some cases (as experienced and documented in the case of RNS), months of perfidious personal vendetta against the developer for being so brazen as to suggest the user was wrong and wasting people's time. When this pattern repeats, over and over, the only sensible, measured and constructive course of action is to shrug your shoulders and say: *"This system is fundamentally broken. It ain't working. I can give up here, or I can go build something better that has a chance of working."* So, now it's your turn. Go look at the diffs for the last six months. What does it look like I have been doing? But I will be damned straight with you all, and say that part of that solution is **absolutely** to erect barriers to entry. You can fucking bet your arse on that. I don't want opinionated man-babies running around in my living-room at 3am. I don't want to clean up the floor after a wannabe "dev-ops stars" with LLMs and a peripheral case of influencitis has puked all over the office. - If you want to join the fun of changing core networking code that thousands of people rely on for communication daily, you better know what the fuck you're doing. - I'm not here to provide validation and hugs to random strangers. I'm here to make sure the reference implementation of Reticulum works. - If you cannot figure out how to submit a patch or valid bug investigation over RNS, you cannot expect I will take you seriously. At all. If someone can't handle that, they should find their entertainment elsewhere. I've said it before: I've provided the information and code required to make Reticulum *work*, and build networked systems, protocols and applications on top of it. That information is deep, complex, and requires you to read hundreds of pages, and put in weeks of efforts to get the full picture. This is a full networking stack, based on some pretty complex principles, for crying out loud. It's **not** a `hello_world` designed to make you feel good about yourself. It turns almost everything about networked systems on its head. That's **challenging** for *anyone*. Climb the mountain, and it will be satisfying in the end. Refuse to climb... Well, what do you think will happen? As for barriers to entry of *using* RNS and related programs, utilities and clients, it's not my task to teach every single user how to do X, Y and Z. The information *is* out there. If it wasn't organized optimally for your way of learning, you can choose to "raise your concerns" about it, discuss "the fact of it" on a forum or chatroom, or: *You can choose to remedy that, and help others along*. I sure know what *I* would have done. --- ## Reply 23 **Mark** · Tue, May 12, 2026 10:29 AM In case stuff like this comes up again, my full reply is available for referencing here: a8d24177d946de4f1f0a0fe1af9a1338:/page/work_doc.mu`g=reticulum|r=reticulum|id=4 If future invocations of similar discussions are interested in my opinion on the matter, they are very welcome to be directed to that, since that stance is immensely unlikely to change. --- ## Reply 24 **Anonymous** · Tue, May 12, 2026 1:13 PM I think issues can be posted in this forum. It will be better than the stupid github. --- ## Reply 25 **calebm** · Tue, May 12, 2026 1:36 PM Is it? Because I posted a genuine, reproducible issue that has been utterly ignored. I have been involved in open source for almost 30 years. I am not sure I have ever seen a project with such utter disdain for its actual users. Good luck with all that. --- ## Reply 26 **joakim** · Tue, May 12, 2026 2:19 PM **@calebm** You posted it 4 days ago, don't you think that's a bit early to start complaining about not receiving help from strangers for free? It hasn't been ignored, it just hasn't been seen yet by someone who has the knowledge and the time to give you a good answer. I've been in open source for about as long as you, and I've gotten used to issues being "ignored", at least for a while. That's normal. What is it about open source that makes people feel so entitled? Someone you don't know have spent countless hours making technology that's pretty amazing, for you to use for free. Rather than gratitude and patience, there are unrealistic expectations of amazing support, having a say in development, etc. --- ## Reply 27 **calebm** · Tue, May 12, 2026 2:56 PM @joakim Who was asking for help? I ran across an error with rnode. I couldn't find a solution. So, I found a workaround. I simply want to share the issue and the workaround - firstly, because it might help someone else. Secondly, because if it is a genuine bug, I would like to see it fixed. I don't want to assume that it is a bug simply because my testing is limited. Maybe it is a quirk with the older heltecs. God knows, it has its share of issues and limitations. My frustration isn't over the issue. My frustration is figuring out the right place to share the issue, and have some sort of acknowledgement of it. And by acknowledge I don't mean Mark needs to send me a thank you card and flowers. I just mean, I need to know it is logged somewhere where it can eventually be seen when someone gets around to it. But somehow that makes me an entitled open source user? We are entitled now for finding an error, doing the actual leg work to verify the issue, documenting the versions and hardware it is reproducible with, testing it across multiple versions and then wanting to share those findings? Then spending hours tracking down where the hell to post said findings? God help us if this was something serious like a security vulnerability, instead of a vague, annoying error message. I get it. There is not a lot reticulum alternatives out there because this type network coding is hard. But this level of animosity toward people genuinely trying to help is beyond absurd. --- ## Reply 28 **sprell** · Tue, May 12, 2026 4:14 PM Well im going to attempt to solve this problem for myself and others per Mark’s suggestion. Shout out to @Ivan for all your awesome work on Reticulum-Go. What I’m experimenting with currently is modifying Gitea to be able to connect to rngit nodes thus bringing a full frontend and ‘github’ like interaction to the rngit system. I’m not 100% sure if it will work the way im hoping but at least i’ll probably learn something. I want to make it very clear I don’t feel entitled to support, a say in development, or anything of the sort. My questions posed earlier in the thread were general not specific to me and largely applied to those already contributing. I hope to get my python skills good enough to truly contribute to Reticulum, squash bugs, etc. BUT for now, this gopher will be in the Reticulum-Go codebase ;) tinkering away @Ivan if there are any tasks you need handled in your codebase I am more than happy to help to the best of my ability. @calebm if you want id happily pair up with you on fixing your rnode issue and work through the patch process and we can create some documentation for other users on how to do the same. Barriers to entry doesn’t have to equal no support documentation! ;) Also if anyone reads the above and has interest in the gitea project shoot me a message i’ll have it up on rngit sometime this evening post my work day. --- ## Reply 29 **joakim** · Tue, May 12, 2026 4:35 PM **@calebm** You asked for help in the Help section of the forum, which seems to be the correct place. And yes, you do seem a little entitled by expecting acknowledgement of your issue after 4 days. As for animosity, *you* then said "I am not sure I have ever seen a project with such utter disdain for its actual users. Good luck with all that." I get that it can be frustrating if you expect something like a typical GitHub project. Long story short, *because of* GitHub, it's not. While Mark is (understandably) not a fan of issue queues, I still think it should be possible to have *some* sort of bug reporting functionality without all the downsides of burnout inducing issue queues. But it does seem like a hard problem to solve if the goal is to make both sides happy. As for security vulnerabilities, I'd raise the issue in this forum or on RRC. --- ## Reply 30 **Anonymous** · Tue, May 12, 2026 5:52 PM Looks like we're back to the old Matrix channel drama... --- ## Reply 31 **joakim** · Tue, May 12, 2026 5:55 PM Yeah, I think aetherlab's gravity well theory holds :/ ---