Weekly update for 7th May 2026

Development Updates
1

Bux posted on discord the following weekly update

It’s Thursday (… no idea how that happened so fast!) We’ve a fair amount to cover this week - most relates to the kind of progress that can only happen post launch , when operating (and seeing issues) in the real world.

Upload reliability

This has been the main focus of this week (there is a lot sitting behind this as a credibility/experience blocker). Multiple fixes are landing that target the dominant failure modes on production - tightening how the client handles bad quotes from misbehaving nodes, resurrecting a clock-skew tolerance fix that fell between release branches, and fixing how storers verify chunk closeness during Merkle batch payments. Standard file uploads through the desktop app are now succeeding reliably, and the fixes for larger Merkle-based uploads are currently being tested on production. A major transport layer overhaul also landed - the relay tunnel issue causing intermittent connection failures is fixed, along with improvements to send reliability, delivery acknowledgements, and backpressure handling for large payloads. 50MB uploads through mixed-NAT testnets are now completing in 65-74 seconds consistently. We’re getting close to something solid across the board now.

Network defence

Some node operators are running modified setups on production - crossed identity keys, manipulated quotes, attempts to get around the system. The emotional reaction would be one of disappointment, especially given this is mostly long-term supporters at this stage. But the practical (and better) one is: thanks. This team will not ‘police’ the network. We won’t be the centre. When it’s ready, the auto-upgrades will stop and Autonomi will be - controlled by no one, and run and owned by everyone. The network cannot and will not be dependent on any group or person - the protocol must do the heavy lifting. It’s starting to, and it will.

Connected to the above, the trust engine has now got its first decent workout: nodes signing quotes with someone else’s key now receive a strong negative trust event, dropping their EigenTrust score below the swap threshold and getting cycled out of close groups. Honest peers that fix their configuration rejoin naturally within about a day. The network will continue to learn to police itself - no bias and no central actor in the loop.

Reading Room and Indelible

Following on from last week’s tease - the Reading Room production server is now live with SSL, hardening, and automated backups. Nearly 200 papers are ingested and enriched, with the collection expanding to 300 as new narrative threads are written across the archive. This is the baby version - we want 10,000 papers up this month via the ingestion pipeline. Reading Room is the showcase for archive builders/users - demonstrating that Indelible is a perfect tool for any organisation holding important data that should be preserved, safely and unedited.

From the Internet Archive to arXiv, PubMed Central and Semantic Scholar - every source we’ve drawn from for RR, could use this capability, and there are many beyond them. We’re not competing - we’re showing what Autonomi enables. The Indelible SDK has been updated and file ingestion can be done via API token - meaning scale!

Autonomi Desktop

Version 0.7.0 shipped this week with bug fixes and the latest client baked in, plus a pre-release channel for those who want to run ahead of stable. Internationalisation is next on the list.

x0x

Soak testing is running at scale - millions of subscribers per topic, pub/sub capabilities being stress-tested, and the early shape of what we’re calling agent symphonies - specialised agents coordinating as groups to take on complex tasks. x0x is now dogfooding itself as its own test harness, replacing traditional tools for secure remote access across machines. Documentation automation is expanding across all repos and a video series is in production. More on this soon.

Onwards!!
Bux

24 Likes
3

Thanks so much to the entire Autonomi team and community for all of your hard work and dedication! :sweat_droplets:

6 Likes
4

Glad to see focus on upload reliability, that plagued the v1.0 network

1 Like
5

(My emphasis).

I find that concerning.

2 Likes
6

I would argue that “stress testing” should be carried out much longer than seems necessary for this network. It needs to seem perfect by our current standards at the very least.

The more robust it is, the longer it will survive in the wild. It is naive and foolish to not expect this to be targeted with extreme prejudice by very wealthy and resourceful “bad actors”.

If any part of this system is compromised, the whole would effectively be broken.

8 Likes
7

I agree with all of that.

Is the production network the best place for it? Is without being asked to ‘have at it’ the best approach?

I’m sure the argument will be made that people are going to do it anyway.

Would it be better to invest the time and effort into putting quality nodes on the network in the early stages and leave the stress testing and attempts to subvert it to the developers to start with?

1 Like
8

I expect it’s better for the weaknesses to be shown up ASAP so that the network can be hardened rather than starting to get real momentum & then embarrassingly getting shut down by bad actors.

So, while it may be annoying, it’s probably good for the network’s development.

5 Likes
9

Never been a fan of “auto-update your nodes with our prebuilt binary blobs that are auto-executed” on a user’s machine. Im not saying that the Autonomi team would ever do anything malicious, but it certainly leaves the door open for abuse in the case their systems are ever compromised.

I believe thats a much scarier scenario than a few bad nodes up to no good.

4 Likes
10

Totally agree if a few node operators can do that,what happens when expect hackers try, the fact that it seems to have gotten under the developers skin means they must have gotten close .

1 Like
11

Actually, that’s a pretty good reason to not run nodes. Thanks for pointing that out.

2 Likes
12

Also, I don’t trust that much to the AI written code.

I don’t understand any code, but I do read comments of PR’s every now and then. I’ve seen several occasions in Saorsa codebase, where fixes are in because “on a detailed analysis, the wadewa was not actually wired in”, or “was actually dead code” or “the function actually never got called” etc.

So it seems to me that there has been, and probably still is kind “make believe code”, that the AI has just kind of done.

2 Likes
13

How would they know this?

14

If these ‘bad actors’ hadn’t been motivated to cheat would the devs have done it themselves? Stress testing is arguably THE most important thing to do before release. Theres nothing annoying about bad actors trying to game the system, releasing software without preparing for this after the last ball drop which ended autonomi 1.0 is annoying.

15

As the saying goes: dont trust verify. When Signal started doing this on desktop I stopped using it. Its a such terrible idea to force install binaries that I wouldn’t trust any developer who suggests doing it, even if they have good intentions, it shows poor understanding of security.

16

At least Signal has a “Click to update” button instead of just auto executing it.

1 Like
17

Aye, ye urny happy, hen…

We know…

1 Like
18

True, but its also mandatory if you don’t want to lose your chats.