I don’t think there’s anything sinister. It’s just a shame how, especially at a time which you’d think they’d feel it worth putting effort into rallying the community that they continue to (at best) sideline it in favour of what, idk.
After all, they just said they’re restarting marketing. Or did I imagine that 
There’s an opportunity with 2.0 to reset this and mend things. But yes, I think from here we should just watch and see how it goes.
Hold off on running saorsa-node for now.
According to David, its changing so fast that there is little to be gained by establishing a node right now.
@blvd Saorsa Labs was a way for a whole different experimental tact and architectural approach to how the network is built and utilized. That’s was the real point of separation. There was a X spaces all about it awhile back. To be fair, I don’t think it could have gotten far enough to be considered for 2.0 if everyone thought that Autonomi was pivoting or rewriting the entire codebase. Just take a step back and realize how unhappy this is making some, just because it’s a seemingly drastic change and slightly uncomfortable. There’s been a lot of change but out of all of it, I think this is the most positive. Just as some see 1.0 as a failure (it is still quite resilient with someone still running nodes), it was really informative. Now 2.0 is addressing the vulnerabilities that plagued 1.0 and how node operation was being gamed to benefit those who could afford and centralize large node deployment.
At the root of everything Saorsa, is the user’s privacy, security, freedom, and ability to leverage cutting edge technology. ANT and Autonomi are very close to the base of that root in x0x, Fae, and Saorsa Core and Saorsa Node are for all intents and purposes Autonomi 2.0, just developed outside of Maidsafe the company. All utilize ANT in some capacity and deliver on the fundamentals, using Autonomi as a permanent, private, secure, decentralized data store. Same as always. There is a minor change to local storage first to increase networking (local or partitioned networks) resilience and data availability in case of catastrophe, outages, etc. That is something we could be very thankful for in the event of a war, catastrophe, etc
There’s plenty to be excited about but for now let’s just all reserve judgment. I’m not sure what we accomplish by calling anyone crazy or not seeing how they had to adapt to their approach.
@rreive ran these prompts in grok
If you have a grok acct - check Autonomi DEPIN Marketing Strategy | Shared Grok Conversation
or you could drop the prompts into the AI of your choice
As a certified professional Marketing Consultant for DEPIN “Decentralized Physical Infrastructure Network” Services, anlayse the information on this site " https://autonomi.com/ " then,
posit a strategic marketing plan for use by the core development company Maidsafe in Scotland which details the associated Marcomm campaigns needed to be put in place by their CEO, CMO, CTO and VP of Engineering together with their community of OG “Original Gangster” users and developer supporters of their DEPIN value to rapidly attract and generate use of their services by the wider worldwide Enterprise and Consumer Markets to make extensive use of their key value propositions as both uploaders and downloaders or private permenant data and developers of enterprise and service apps which make use of that core capability.
Include a tabular analysis which analyses their differentiated capabilities, pros and cons of the core company and the DEPIN value created relative to the tiehr top 10 competitors, ranking each competitor and their capabilities accordingly and in the far right column posit the reason for the ranking.
and then
As a certified professional Software Architect expert in both distributed decentralized systems and cybersecurity In tabular form Summarize the technical software design, test and validation hurdles which face Maidsafe in creating, launching maintaining and growing the Autonomi Network 2.0 by examining the software technology used and the development workflow and methods used, positing improvements or a remedies and the reason why same were selected by grok in this role.
Have lots of fun. ← As the old SuSE distros used to say
Thanks, Nick. This is very helpful.
im still very much missing ipv6 in autonomi / safenet and one thing that bothers me maybe most is, that i missing to find out if there every will be the possibility to run autonomi really in the most possible autonomous way, e.g. as little as only having packet routing and maybe the internet dns root-servers available, and nothing else. everything, and i mean everything, else should be inside the client(s) software(s). i am not very fond of money stuff and finances and everything that comes with that in human societies, back in the days, was it 2010 already (always a pleasure david 
) i was getting the idea and assumed that there would be eventually a way for example only to run ones own nodes and make absolutely sure that the data you yourself deem worth of protecting and storing, are being stored and distributed, early days of wuala back then (and before that) were kind of to my liking, and also DHT bootstrapping, torrenting ideas and the general really distributed internet technologies i fancied a lot, NDN (named data networking) and more appeared on the horizon and in academics, i pictured maidsafe, safenet and autonomi move in this direction. in the recent years I have not very actively followed around, but every now and then tested this project, i am still very much undecided if it was not very well be possible to have this kind of a system and structure up but without the whole wallet, payment, exchanges, and what not stuff. maybe internally obviously representing some kind of nodes reputation and measuring of data flow and how effective and well-playing a node is to the overall network, but not buying coins or that stuff in general. so maybe i am just allergic to money and everything that is related to it 
but then again maybe i am just not up to date on autonomi and if there will be a possibility to actually be part and make use of it but skipping all the bollocks that dont get me excited. thanks for all the work nevertheless to everbody involved. cheers.
IPv6 is most definitely a feature of the upcoming Autonomi2.0 antnode
dont just look at the screenshot, read the whole doc for yourself.
BTW, if I understood David correctly, IPv6 is not essential for the new antnode, but it certainly helps.
Wow! Been busy, team. The whole thing makes a lot of sense (from my admittedly limited tech grokking).
With all the check and balances, how does this play out as to more limited/legacy hardware capability for running nodes?
given the latest announcement for Autonomi 2.0
the fix path to consider for DHT and some background information…
yeah its Brave AI Assisted Search , naysayers get over yourselves.
Reducing DHT Convergence Times in Kademlia + CRDT Systems
This is a well-understood but nuanced problem. Here’s a structured breakdown of the most effective levers:
The most common cause of slow convergence is stale or unresponsive peers in k-buckets.
Aggressive liveness probing — ping peers proactively before they’re needed, not reactively
Replace-on-failure with a candidate queue per bucket, so a dead peer is immediately swapped
Bucket splitting policy — ensure you’re splitting buckets aggressively near your own ID prefix to maximise local resolution accuracy
Reduce k (replication parameter) if your close group size allows it — smaller k = faster convergence, at the cost of redundancy
Standard Kademlia’s iterative lookup is the bottleneck. Key changes:
Increase parallelism (α parameter) — default is 3, bumping to 6–10 dramatically reduces round-trip latency at the cost of bandwidth
Recursive (server-side) routing — instead of the client driving each hop, nodes forward the query themselves; cuts RTTs from O(log n) hops to near-instant at the cost of trust assumptions
Early termination — once the k closest responding nodes have been stable for 1–2 rounds, stop; don’t wait for full convergence of the entire lookup state
For payment systems specifically, all nodes must agree on the same close group — this is harder than just “finding close nodes”:
Canonical sort with tiebreaking — XOR distance alone can be ambiguous; add a secondary sort key (e.g. node join timestamp or public key hash) to make close group membership fully deterministic
Epoch-based membership snapshots — rather than real-time routing tables, publish periodic signed snapshots of the network graph; nodes compute close groups from the same snapshot, not their individual views
CRDT-backed routing state — model the routing table itself as a CRDT (e.g. an Observed-Remove Set for node membership); merges are conflict-free and eventually consistent by design
If routing state is CRDT-modelled:
Anti-entropy gossip with Bloom filters — nodes periodically exchange Bloom filter summaries of their state; only diff the delta, not the full set
Causal broadcast (CBCAST) — ensures updates are applied in causal order, preventing temporary divergence from out-of-order delivery
Vector clock pruning — aggressively GC old vector clock entries to prevent metadata bloat slowing merge operations
Prioritise close-group gossip — nodes in or near a close group gossip more frequently with each other than with distant nodes; locality-aware gossip
Persistent connections — maintain open connections to k-bucket peers rather than dialing per-query; eliminates TCP/QUIC handshake overhead
Combine lookup + replication — when a node finds the close group, it simultaneously pushes the chunk rather than doing a separate round; saves a full RTT
NAT traversal reliability — on 100-node testnets, NAT failures silently fragment the routing table; ensure hole-punching success rates are measured explicitly
If you abandon pure Kademlia, the most effective alternative for payment-grade close group agreement is:
Rendezvous hashing with consistent rings — deterministic, no lookup required, O(1) close group computation
Augment with a small BFT agreement layer only for close group membership changes — not for every lookup, just for joins/leaves
Sparse Merkle Trees for membership proofs — nodes can prove they are/aren’t in a close group without full routing table knowledge
| Fix | Expected Impact | Effort |
|---|---|---|
Increase α parallelism |
High | Low |
| Bucket liveness probing | High | Low |
| Deterministic tiebreaking | Critical for payments | Medium |
| CRDT anti-entropy gossip | High | Medium |
| Epoch snapshots for consensus | Critical for payments | High |
| Recursive routing | Medium | High |
The deterministic tiebreaking + epoch snapshots combination is likely your actual root cause on the testnet — nodes are computing different close groups from slightly different routing table views, not that the routing itself is slow.
The mangled messy prompt that did the above…
Given For the Autonomi Network 2.0 payment system to work, different actors on the network need to agree on which nodes are closest to any given address. Testing on 100-node testnets found that routing tables weren’t converging reliably enough. Two approaches are being pursued in parallel - one improving the existing DHT implementation, the other building purpose-built routing logic for our specific trust and replication requirements. This is (somewhat obviously) the critical path item for launch. Autonomi Network 2.0 h
how does one change the logic to reduce the DHT convergence times effectively for this Kademlia and CRDT based system to be performant in determining which nodes are closest to form the close group for the purposes of replicating chunks to those nodes.
