August’s Swarm Community Call was, in part, its own demonstration. For the first time, the call was streamed over Swarm alongside the usual X and YouTube broadcasts. Behind the scenes, another test was running in parallel: the team was watching the same stream through an in-browser Swarm node. Both worked. It was a small but consequential moment – Swarm was no longer only the subject of the broadcast, but part of the infrastructure delivering it.
The call also covered the security-focused Bee 2.8.2 release and introduced Etherchunk, a practical form of “deletion” without changing the underlying immutability of Swarm itself.
Bee 2.8.2: Hardening the Network
Bee 2.8.2 was released the day before the Call, with node operators asked to upgrade promptly. The release followed a security review by a Swarm community contributor that identified several code-hygiene issues and one exploitable vulnerability, all of which have now been patched.
Elad explained that the work does not end with the patch. The team is adding fuzz testing and stricter automated code checks to the development process, helping surface similar problems earlier, alongside improvements to tracing, panic recovery, and general code safety.
Another important change already committed to the codebase concerns backward compatibility. Future breaking protocol changes will be able to introduce a grace period during which newer and older clients can continue communicating. Instead of expecting the entire network to switch versions at once, upgrades can become gradual network migrations.
The team has also increased the number of light-node connections that full nodes can support after testing showed that the network could comfortably accommodate more. That matters beyond raw connectivity: light nodes are becoming increasingly relevant to applications such as streaming and, eventually, Swarm clients running directly in the browser.
Work toward the next release is already underway, including improvements to PullSync convergence, Hive, and edge cases in the persistence layer and protocol. The team is also investigating whether postage stamp information can be incorporated into erasure-coded data, with the longer-term aim of making content repair possible by parties other than the original uploader.
Etherchunk: Reclaiming Storage Capacity
Immutable storage gives you a useful guarantee: once data is addressed by its content, it does not quietly change underneath you. It also creates an unusually ordinary problem. Eventually, somebody wants to delete a file or simply make better use of the storage they have paid for.
Áron introduced Etherchunk, a CLI experiment that approaches deletion without trying to make Swarm itself mutable.
The idea is straightforward. Etherchunk chunks and stamps files client-side and keeps track of which postage-batch slots each file occupies. When the user “deletes” a file, the chunks are not removed from Swarm. Instead, Etherchunk marks those slots as available for future uploads. Once they are reused, the new chunks overwrite the old allocation.
This gives the user something missing between Swarm’s existing immutable and mutable batch behavior: control over what gets reclaimed.
Áron described the problem as “upload paralysis”: if putting something into decentralized storage feels irreversible, users may hesitate to put ordinary personal data there in the first place.
Etherchunk makes the model behave more like a familiar disk: deleting something means declaring that its capacity may be used again. The data itself remains subject to Swarm’s underlying storage mechanics, but from the user’s perspective, the scarce resource – the capacity they paid for – is theirs to manage.
There is still a coordination problem to solve. Because Etherchunk currently keeps its accounting locally, using the same postage batch independently across several devices can result in inconsistent records of which slots are available. How that state can be coordinated without introducing a central authority remains an open question for now.