When the code update breaks the network, the update code must clean up the ‘hidden’ folders and files, so the code actually works and not leave it up to the Node Operator to do it. This is what production ready code looks like.
As such, the last two updates broke the Linux Ubuntu install of nodelaunchpad 0.6.1 on my daily driver IA64 HP i7 notebook with 16 TB of RAM and 1 TB of storage, a system which I had been operating 8 antnodes via standard launchpad updates successfully for many months and, as a result of the last network breaking code update, I have yet to get this latest 0.6.1 code update to boot and work in terminal, so I gave up trying to fix this, given I have two contract day jobs which need my attention.
When the team get’s time at Maidsafe, please let me know when the code stabilizes on Linux Ubuntu 24.04 LTS and is closer to ‘production ready’ as described above and, I will be more than happy to re-install a ‘production ready’ update, which should clean up the mess other updates left behind which stopped further updates from working properly.
Otherwise, this project I fear, is locked in ‘perpetual science experiment’ mode, a mode which unfortunately causes me personally to now withdraw from this long running project, after 8 years of tracking it closely and now going on 24 months doing black box testing of same, since imo, it is time Autonomi Network project Community and Maidsafe core development to pivot and work together to take the necessary, design, QA and release management steps needed to grow up and deliver ‘production ready’ code equivalent to commercial quality code being delivered by some of their competitors, moving forward.
I understand your frustration with management and am looking forward to clearly defined goals and a coherent scope of work for 2026 per the End of Year Post made by Bux.
In researching what the core foundation should consist of, prereqs seem to include ant-quic + saorsa components + everything now live or currently in test (Merkle Trees, Paymaster and Relay Removal) per the official roadmap. Then your code audits should be made.
The above allows us to unlock maximal utility and exponential scalability from everyday devices to mission-critical infrastructure while also future-proofing the network.
If marketed and executed well, this foundation also gives us the first-mover advantage of being the only network—centralized, decentralized or otherwise—that is fully CNSA 2.0 compliant. The advantages we get from successful implementation could more than make up for the years of delays we have withstood.
I really hope that Saorsa is not required. David just said on Discord, that:
Saorsa is a 7 layer network that does have 2 DHT’s actually (ip4 and 6) as well as geo protections, greedy routing (small world hyperbolic) as well as some other stuff, but also potentially software attestation.
Sounds amazing if it works. And I genuinely think he may well pull it together. But it also sounds that it would mean radical changes to the many aspects of the network and those would take time. Also I’d expect that this software attestation could be a real game changer, but come with some edge cases and limitations and require a lot of real world testing etc.
I think the first-mover advantage will come to those, that have easy and polished UX, not those who might be just the first having a technically working solution.
I hope my negative views are not read as a critique to the individual developers. I don’t see fault in them. They seem like good and dedicated people, who need to take too much responsibility.
Personally, I hope that anything Saorsa oriented is not on the critical path. It sounds interesting, but speculative. I hope the executive team keep focus on delivering what is known to work, in polished, production form, first.
I think care needs to be taken to keep radical R&D somewhat isolated from the core. Let the ‘out there’ stuff spin off as other products, etc.
Just my opinions as a long term supporter, though.