After last week’s slightly downbeat update, we’re pleased to announce that things are very much back on track, with uploads and downloads now producing minimal errors as we scale-up tests.
In addition to these fixes, the latest version of Autonomi
also features client light networking (CLN). In case you need a reminder, CLN represents a significant code cull replacing 12k lines of code with a minimalistic 2.3k lines that the client can use. It’s huge code simplification client-side that should lead to significant performance and maintainability improvements. It also allows us to refactor node networking without having to worry about the client as both are separate.
So, it’s a stripping down of the code base, removing stuff that’s out of date, didn’t work, or was getting in the way. It’s a back-to-basics move as we focus on creating a reliable and high-performance infrastructure. And the good news is, it’s working. We’re still testing, but the worrisome errors we were seeing last week on scaling up seem to have gone.
Prioritising performance
Right now we’re making sure we have a reliable network so that applications like the Impossible Futures finalists can become a reality. For now that means putting NAT traversal and equality of earning on the back burner. It’s a complex issue, but the number of combinations of home routers and constantly changing ISP rules means we can’t yet guarantee that every node can earn. All cloud nodes should be capable of earning (as there’s no router), and most home setups will too - but not all. Reliably traversing symmetric NAT is a recognised ‘Hard Problem’ in decentralised networking, and rather than continuing to bash our heads against this particular wall we’ve decided to revisit at a later date. If your particular router/ISP combo is blocking you (i.e. you’re not earning), take comfort in the fact that you’re not alone, and don’t worry, you’re not missing out on life-changing earnings at the moment anyway! We’ll get there when we can.
The recent changes mean that only the latest version’s nodes are going to be earning from now, so make sure you upgrade without delay! Latest versions: antnode: v0.4.1, antctld: v0.13.1, antctl: v0.13.1, ant: v0.4.2, nat-detection: v0.2.21, node-launchpad: v0.5.10
In summary then:
The latest version of Autonomi is a big step towards seamless uploading/downloading and permanent data. Are we there yet? Time and testing will tell. Once that’s in place our partners and our fantastic Impossible Futures projects can get going in earnest.
A small number of home nodes will sadly not be able to earn yet. Our vision has always been that anyone should be able to provide resources and earn ANT, but reliable workarounds for symmetric NAT are just not out there in the technosphere just now. We’re not giving up, but uploading/downloading is our priority for now.
But a surefire way to lose out is to avoid upgrading! So upgrade! Remember: Old nodes get nowt!
Community stars
Massive props to @josh for Atlas, a place where you can share things that you find interesting on Autonomi. “It’s amazing! This is the best thing done with the network ever. Fact. An entirely new social platform birthed on a brand new network,” writes a Mr Guy Storage.
@zettawatt introduced Colony Utils – a CLI interface for Colony, a local-first, metadata sharing and semantic search library for Autonomi.
And @safemedia spoiled us with a Rust client that runs dweb, AntTP and Ant on the Autonomi Browser Extension, with functionality to change AntTP and dweb ports on the local client.
Comms and social**
@dirvine has always been fascinated by the relationship between data, information and knowledge, and how we exchange that knowledge. Hear how he was initially inspired and later disappointed by Bitcoin and blockchain as an enabler to the free transfer and sharing of knowledge, how corporations have co-opted the web, and how Autonomi can do for knowledge what Bitcoin did for money (No X account required).
General progress
@chriso has been labouring away at the release candidate (RC) that fixes many of the issues documented in last week’s update. This should mean more reliable uploads and downloads and fewer errors.
@anselme has been looking at how libp2p
handles retries when uploading chunks. There seems to be a lot of replicated activity there, and together with @qi_ma he is looking at how to simplify things.
Lajos tested the paymaster and client front end and looked into how to transpose the Typescript PoC that uses the Pimlico SDK to Rust, to be used later with the client.
Ermine is working on ironing out the bugs in Launchpad and its upgrade process.
@qi_ma has been working with Anselme to remove unnecessary retries. Along with @bzee, he’s also been looking at an upcoming release of libp2p
and considering whether that will solve some of our connectivity issues for lower-performing nodes, or if we may need to fork some parts of the codebase to make it work properly for us. As mentioned above, this is now on the back burner.
@roland’s been the main man crushing the upload/download bugs, putting in overtime to create some inspired fixes that have seen these tend to zero. Elsewhere, we’ve fixed a couple major things w.r.t. how connections are established and who node let into the routing table. We no longer accept a node’s self advertised ID, and we also delay dialling newly connected nodes until UDP connection has died (180 seconds). Live UDP connections were making nodes appear to be reachable when they weren’t. We now need to gradually remove non-reachable nodes from the network. These are nodes that are behind an unsupported NAT setup or one that’s is not port forwarded. Relayed nodes are not affected by this, in fact they should see some performance improvements.
@vphongph has been engaged in logging spawned nodes for testing purposes, which is a challenge as node ID is generated after spawning.
And @shu, as always, has been providing invaluable visibility into the results of our testing.