Impossible Futures Timeline & Network Updates

First off, thank you for being the community that shows up - with ideas, efforts, and persistence in helping this Network to change the course of the internet, for the betterment of us all. Builders have made real progress. Backers have committed some serious support. And some of you have challenged, cheered and engaged with the team throughout (we see you, thank you!).

In this update I want to take you through two major items: a timetable update for the conclusion to the first season of Impossible Futures and also a rolling series of updates, upgrades and improvements coming to the Network over the next three weeks. These two things are linked of course, so let’s get stuck in to the detail…First, Impossible Futures.

While in many ways Impossible Futures has delivered on its key aim: showing what’s possible when you bring ambition, experimentation, and the Autonomi community together, it can be and should do more, for the builders, for the network and for those who hold the $ANT token. With that in mind we have come to the decision to shift the final phase of the program back by one month. We believe everyone connected to Autonomi will feel the benefit of this.

Why this matters

Recent updates to the Network introduced a set of technical issues that affected both stability and consistency.

Specifically:

  • Node connectivity and discovery: Some nodes have had trouble consistently reaching one another, affecting overall network stability.

  • Client upload/download consistency: Apps have seen intermittent issues with files or data making it up to (or down from) the network.

These are critical paths for every app deploying on Autonomi. Rather than push Builders to deploy into an environment which is still stabilizing and being tweaked, we’re going to take the time to test and implement the necessary improvements.

Speaking to that, under the hood, the core team at MaidSafe are currently:

  • Reworking low-level networking (Kademlia, libp2p)

  • Removing relays and introducing reachability checks to reduce unreliable peer connections

  • Improving the client experience with smarter retry logic and clearer error messaging (e.g. retrying only failed chunks)

  • Simplifying and clarifying the codebase to make debugging and maintenance easier over the long term

Together, these changes will restore the reliability that Autonomi Builders experienced earlier in the Alpha phase, and create a fair, consistent platform for deployment - as well as judging.

At the same time, we’re improving how we better support teams during this very first IF in final phase.

While some Builders have been racing ahead, others are developing their MVPs around jobs, life, and limited time. Going forward we’re going to be offering dedicated support (including drop-in clinics or ‘office hours’) to make sure each and every team gets the help they need to launch, not just so they can succeed as part of Impossible Futures but so that they can grow and thrive well beyond it.

What this unlocks

Taking this step not only gives us space to support teams properly through deployment and ensure the Network is in tip-top shape to receive new users, but it also means we can promote the Networks first MVP products and provide an interaction that people beyond the community can understand and feel excited about.

Maximizing the visibility and impact as a result of Impossible Futures isn’t just good for the builders of applications, but it will also strengthen the Network itself. We want to ensure all projects have a strong foundation to onboard users and to drive real network activity, and the flow of data that comes with it.

In short: executing on the original timeline would be a compromise for all, working a month out, we believe, puts us in a much better position to deliver on the potential of Impossible Futures — for Builders, for Backers, and for the ecosystem as a whole.

Updated Dates

So some new key dates for your diary:

  • Deployment deadline: 21 August 2025

  • Judging period: 22 August – 5 September 2025

  • Voter Reward Airdrop: unchanged — 13 August 2025

  • Awards announced: 16 September 2025. (This includes prize payouts for both builders and backers)

  • Token unlock: unchanged — 13 June 2026

Builders, you should already be seeing the MaidSafe devs dropping into your channel (there is an schedule to help us stay on course with internal requirements but so that there isn’t too much of a gap when you ask for support), hopefully having them on hand will make these last few weeks run nice and smoothly for all.

Upgrades, Improvements and Sure Footing

When it comes to the alongside this, we have of course not forgotten the backbone of it all the Network itself. Over the next three weeks, starting this Thursday, we’ll be rolling out a series of updates, fixes and releases to get us to where we need to be: practical, substantial steps to a sure-footed network, ready to receive these deployments, apps, and the users that can come with them.

Here’s how that will go:

Thursday 31st July

A client update will be released that contains a raft of fixes for Bootstrap cache, as well as a key solution for downloads — the ability for clients to swerve non-KAD peers — something that has been giving lumpy, frustrating and suboptimal download experiences.

Wednesday 13th August

We’ll be rolling out a network-wide update for nodes which will have two major changes.

First, a broad set of work and improvement around reachability of nodes and how the network handles those that can’t.

And secondly, we’ll be removing relays from the network. This may seem, at a glance, as a step back, a removal of a feature, but in reality it should be a major leap forward when it comes to stability, reliability, and network health. We want Autonomi to work seamlessly every time, at all times - from there we will then continue to evolve and focus on the unwavering mission to give the ownership of the Internet back to the people.

Currently relays are being used by a small proportion of nodes that find themselves behind tricky home router setups. Relaying nodes give these nodes a helping hand onto the Network - but once there, they remain and draw a disproportional amount of resource from the Network. More than they put back in; to the detriment of the overall system. We believe these situations can be better handled through a combination of UPnP, port-forwarding, and better handling of the UX when connection troubles are encountered.

These two key updates, rolling out through this final (and now extended) phase of IF will give us the step change improvements we need to not only round out Impossible Futures, but allow us set sail into clear waters; ready for data uploads and inflows, new users, partners, all of which we can package up in the marketing we badly need in order to shine a light on it all.

I appreciate that was a long message, so will close as I opened by saying thank you, for your patience and unwavering support - and also thank you, in advance for your prompt updates (as always) - it’s very much appreciated.

Regards,

@Bux @JimCollinson

15 Likes

Thanks so much to the entire Autonomi team for all of your hard work! :man_factory_worker: :man_factory_worker: :man_factory_worker:

And many thanks to our team members! This community is the best in crypto. :1st_place_medal:

7 Likes

Hopefully this doesn’t hinder decentralization for the sake of stability, reliability, and network health. We need a wider range of nodes to fulfill the mission :slightly_smiling_face:

2 Likes

A few folk on discord also raised concerns about decentralisation due to the removal of relay.

Can someone educate me as to why that is a legitimate concern and not just stubborn ideals.

It feels like any such statement should be backed up by numbers.

I don’t know if we have them, maybe Maidsafe does, I think David referenced (1%?) on discord.

Not clear to me why people are freaking out.

Arguably it raises the bar to enter by 1/2 percent.. for a few.

5 Likes

Apologies if it seemed i was freaking out. I thought it was a valid concern, but I guess Ill will hush.

1 Like

Not directed at you sorry. :slightly_smiling_face:

You are definitely not alone in raising the question.

3 Likes

In my view, it’d be a worthwhile compromise if it did.

What good is a maximally decentralised network that doesn’t work well?

Excluding a small portion of node runners for the benefit of network health & performance doesn’t necessarily reduce decentralisation in any way that matters… once there’s sufficient decentralisation to counter any of the down-sides of centralisation, adding further decentralisation doesn’t bring further benefits. If it brings costs, then it may not be worth having.

Long term David and the team have said they want as many devices as possible to run nodes, so that’s the aim, but if poorly performing nodes that damage network health are not excluded, the network suffers.

5 Likes