After months of building, our finalists are putting the final touches to their apps on the Autonomi Network. Friday, August 22, 2025 is when apps will be up and running on the live Autonomi Network, ready for judges to start exploring every feature and diving deep into what makes these projects special. More here.
The team met yesterday to discuss remaining hurdles standing in the way of Impossible Futures (IF) developers after @jimcollinson fielded their comments. An issue with scratchpad identified by several devs has been fixed and will be updated shortly.
Another issue that may be blocking developers concerns a fix we put in place to resolve a failing test. @loziniak has reported issues with this PR. Again, we are testing. Other issues under investigation include WebRTC handshake issues affecting network stability reported by @riddim and performance improvements noted with AntTP with pointers/registers (@traktion).
The deployment deadline for Impossible Futures projects is today, but participants can continue updating their apps after deployment. Your patience is much appreciated. Our devs have agreed to spend some time each day on Discord, so any Qs please find them there.
We also discussed how and when we release new features. The streaming feature will be available very soon (2 weeks max) allowing downloads of files of any size using the client. This doesn’t break any API rules. Some other changes to the autonomi architecture may be better left until later as instability could cause issues with IF.
In future we’re looking at moving towards a more automated, continuous delivery approach for client app updates, similar to how many modern apps are updated, while node upgrades will likely still require a more coordinated, rigorous testing process.
Dave (our in-house built network front-end, still in alpha) can now do parallel uploading and downloading rather than one or t’other.
Our recent hackathon yielded Indelible, another in-house app which is an asset platform that sits on top of the Autonomi network providing easier access to its services for developers, similar to the media transfer protocol (MTP). In particular we are targeting large institutions such as museums with large archives to upload in bulk who do not wish to pay ever-increasing subscription charges to cloud providers.
You can hear more about all this, as well as @dirvine’s thoughts on privacy and agentic AI, by checking out Tuesday’s Spaces session (no X account required).
Jim pushed another video. In this one where he reacts to Signal president Meredith Whittaker’s warning that AI agents will seep into every corner of your personal life, and considering how autonomi could help us stay private and secure. Like and subscribe!
General progress
In our pursuit of supporting all devs, @bzee looked into Go bindings for the autonomi APIs. This turns out to be more challenging than Python etc since Go is a compiled language. But we’ll get there.
Ermine has completed most of the doc work for the Indelible application and is currently working on getting Inedible to connect with a local network. Currently the Docker container is not able to access the local network’s endpoint, so this continues.
@mick.vandijke worked on Dave, including the UI and back end build operations. He fixed a crash on Windows, improved folder navigation for archives with no name and updated the UI.
@vphongph worked on the docs, adding scratchpad examples and removing outdated content.
@roland removed RPC from antctl, removed a RPC client crate and implemented a fine grained progress bar for reachability check. He also raised a PR to prevent a race condition while adding an address to the bootstrap cache.
@qi_ma worked to split fundamental parts of the autonomi crate as autonomi_core for simplified workflow management. autonomi_core represents a significantly simplified API designed for core network operations, removing high-level operations like File, Register and Vault, and abstracting away direct network access.
@chriso worked mainly on getting data streaming ready for release and planning the improved release process mentioned above.
@shu has been playing around with optimising antnode to allow more nodes to run on the same hardware. Even with initial tweaks he was able to reduce the CPU by 20% against the native CPU release build, which in itself was already 25%+ faster compared to our generic musl release binary targeting just the normal x86-64 CPU. This shows the kind of improvement we can expect when devs get their hands on the code. 
