New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

Swarm Community Call — March 2025

SwarmThu, Oct 9, 2025, 12:00 AM

The March Swarm Community Call covered significant progress on network stability, multi-chain support, enhancements to node usability, and ease of node spin up. It also presented the new Bee-JS release, OCI registry implementation on Swarm, and an informational SWIP on data provenance. Read recap: https://blog.ethswarm.org/foundation/2025/swarm-community-call-27-march-recap/

Transcript

[Music] electric universal life. All I see that you're reality [Music] H. I wanted to play something different today. I hope you enjoyed as much as I did. And if you managed to get what it was, eternal bragging rights and my undying respect are yours.

Hello everybody and welcome to March Storm community call broadcasting live to all the corners of the interweb and that includes streaming on X also or Twitter as I like to call it. So hello there and you are very welcome to join the conversation in discord. Thank you for coming. My name is Antonio and I am very glad to be your host today wherever you are within this pale blue dot. Well, what can you expect of expect of the call today?

Here's the agenda. We will start with core development feature uh updates featuring Nikki Papado. We'll have in focus BJS giving another boost and nodes simplification community talk OCI registry implementation on swarm with Ata and Andrew from Debboot uh unccloud and community talk we will will go through swarmbased data provenence framework. Finally to conclude we'll have a community AMA and open space for debate and and as an additional comment uh Swarm Foundation team will be present at several conferences starting at Lisbon and then moving to Prague in May. We'll see you there maybe.

All right, if you're there just give it a ring to some some members and we can grab a coffee or a beer or something more daring. So let's start with the core development updates and for that I would like to invite Nikki to stage because there are many things to talk starting with the update 250. Hello Nikki.

Hello. Hi Antonio. Hi everyone. Um welcome to this month's uh community call. It's great great to have you all here.

Whether you are deep deeply involved or just curious. Thanks for showing up and helping push the project forward. So let's dive into the latest updates. Um first of all, we have officially re released B2.5 on March the 11th.

Um this release focused on major improvements across performance, stability, and uh resource users. Some of the highlights included better garbage collection, smarter postage stamp handling, and overall faster and more reliable uh data retrieval uh and uploads. Um you can check out the full release notes on our blog and so far the the results are looking very promising. Around 70% of the nodes have already upgraded and the network appears to be stable and performing well. As a follow-up, we will be running the same performance tests we ran before the release so we can make a proper before and after comparison and officially validate the improvements.

We will share the updates of these results once we once they are in. Um as mentioned uh last time we are working on a solution to better understand node network behavior. This will now uh be implemented through storm scan uh and it's already in progress. The idea is to measure things like upload download speeds and latency um across different regions giving us clear clearer insight into how the network performs in the real world. We are currently working on the implementation and we will share all the details with the community as soon as it's ready.

Um we have also made uh progress on improving uh the node spinner process making it easier and faster for people to get um a node up and running. Aron will share more about the objectives and milestones of this project but for the moment being our update is that the team is actively working on the tasks belonging to this epic. Um going to the next item, the research team is doing great work um on the multi-chain support. The MVP is ready. All the functionalities are there and now uh we're fixing they're fixing uh the last bugs, making sure that um we offer a seamless experience.

Later on today, Dan will be on the stage with a demo um of the tool and hopefully this will give you a nice insight. We're very happy with the efforts and good progress. um there and very soon we will be in a position to share the tool the tool with um all of you. So what's next? Um looking ahead the big uh next focus is network stability.

The epic is currently in the hands of the research team and once the specs are ready we'll jump straight into implementation. This will likely be a major step forward in strengthening the reliability and robustness of the swarm network. Um, as always, swarm grows through its community. Whether you are running a node, providing feedback, or just curious about what we are building, your participation matters. Stay connected, stay tuned, keep the feedback coming, and let's keep building together.

Thanks all for being here today. Back to you, Antonio. Thank you, Nikki. Uh, well, I heard that there are some other news regarding the nap node package 2.5 that was also released.

So, for anyone who is using DAP node to spin nodes, that's that's very good news. And also I would like to comment about the sweep that uh Victor Tron has put out uh that basically is about free uploads uh without requiring posted stamps and that enables uh low priority data like chat messages. So I just would like to bring those two things into into stage so that um if you're curious to it just have a go for that and without any more um any more wait I will like to invite to the stage uh Dan to comment about this uh little sneak peek that we will give you uh with this um with this uh multi-chain app. All right. Hello.

Hello. Dan, are you here?

Hello.

Yeah.

Can hear lovely voice.

Thanks, Antonio.

On enjoying this.

If I can share my screen. Uh, one, two, three. I'm going to play a video. So, uh, and it's not stopping. So, don't don't miss any part.

Okay. So, I've been I've been drafted in as B team to uh show off Cardinal Error's very nice DAP. Very nice looking and very nice working. So, it's it's the I think the first time I've seen Swarm directly connected to a to a wallet extension in the browser. And um the key functionality here has been to enable crosschain swaps um that directly result in the purchase of a stamp uh that is also connected to our gateway and enables users that don't have a node of their own to use ours to upload data to the swarm.

So as this is the various kind of crosschain steps working through and then pretty soon the upload dialogue will appear and so this is a sneak peek. We're in the process of as Nikki said finalizing things. probably not the last bugs, but we're kind of getting through the majority of them. And yeah, that's it. Upload successful.

So that's the the hash and then the file coming back out of the gateway. And then that of course will come out of other gateways and your own nodes if you're running them. And then we're looking these are the the the start of some functionalities to manage the stamps and enable you to upload again to various what called here buckets but also batches and yeah so that's basically it. Look out for beta testing opportunities in the Discord which will be coming soon. And we'd love uh your help and feedback, any ideas that you've got to move that forward or if you find any anything that you struggle with, then get in touch, reach out.

We'd be happy to hear from you coming soon. All right, thank you so much Dan for that uh for that voice over over the video. It was was great to hear your insights on the on the on the thing. Uh so get ready everybody to main release. The date is going to be announced pretty pretty soon.

You can follow up on Discord. Thank you guys and uh keep it keep it around just in case something pops up in the chat or further

on on the main channels. Thanks Antonio.

All right and for our next section we are going to go in focus. We are going to focus addon because he has two things to talk to us today talk with which is which are nodes spin up and bjs. Hello Aaron.

Hi Antonio. Hi everyone. So please bear with me a little while I share my screen. This should be it. Yeah, you should be seeing my browser with some node spin up is of use text.

Can somebody please confirm and then I will

I can see it.

Cool. Okay. So first off I would like to share some insight about a ongoing multi-team effort currently in swarm foundation uh which is going under the code name uh node spin up ease of use and the purpose of this is to make the node spin up part easier and faster and to make uh using swarm using your b node also easier. So there are five milestone to this project and I will go through these these five that you can see here. The very first one is the quick start guide which is related to the uh node spin up and we have actually already delivered this.

This is the uh quick start guide of the official swarm uh documentation and it gets you through the steps uh from getting a b node uh funding it creating your first postage batch, uploading some data and downloading some data. Now this quick start guide is very straight to the point, easy to follow. Not too many commands are required to execute. So it's a very big improvement over the previous version. Uh huge kudos to Noah for delivering this.

The next one is the postage syncing improvement. So the postage syncing is the process when you are after after running your bnode for the very first time. there is about 30 minutes when it's uh syncing postage batches from the blockchain and you cannot really use uh your B node at all during that time period. That's uh one thing it's it's long and slow. The other problem is is that uh Swarm's very first uh postage batch uh block on the Agnosis chain was about uh 8 million blocks ago and many of the current publicly available free JSON RPCs they are no longer keeping those blocks.

So you will have trouble syncing your B node if you are using uh free JSON RPCs. This is why uh we always recommend to uh run your own nosis node so you don't run into this issue. Uh in this uh item what we are looking for is to replace this positive syncing um with a much nicer approach such as such as uh creating the snapshot of what your B node should be syncing and putting it either on boot nodes, putting it in the binary, putting it on swarm or just eliminating the need of syncing postage batch information when you are running a light node since you probably don't care about data. You're not going to be storing chunks in light mode. There are multiple ideas.

This is being researched right now. The next one, the warm-up improvement is about the 5inut period after you run your B node. So, this happens every time. every time you uh launch your bin node there is 5 minutes when it's waiting for connections trying to fill up all the uh cadmia bins um and it's waiting with the I believe with the pushing and pulling uh to start them so it's a fixed 5 minute uh delay in every case and you can actually configure it yourself with a warm-up time in your configuration you can bring it down to 1 minute and it would still uh have enough time to warm up and you can still use it. So there's obviously uh some room for improvement here.

We can bring this uh warm-up time uh down much more so you can start using uh your B node much faster. Something that we have already done is that uh B node uh exposes whether it's in the warm-up period or not. So we can use this field uh to uh add an indicator in the client tools such as the dashboard or the CLI that uh you are not supposed to use your B node yet. It's still warming up. The fourth item, the DevX improvements.

Uh this is uh the documentation of V.JS. For example, if you want to start developing the apps on Swarm, it also entails the create swarm app uh quick starter. So you can run mpm in it uh sore map and then it creates the uh project for you. So you can just mpm install mpm start with some basic example.

Um and also some other things uh something that comes to my mind is improving feeds. Um there are some minor issues there which could be improved for a much better uh developer experience. And lastly, the node funding improvements. Uh that also rel that is also related to the node uh spin up. So when you launch your B node for the very first time, uh B is going to uh keep printing a message uh cannot continue until there is a sufficient X die on the address and you need to take care of funding your uh B node before you can start using it.

So now with the multi-chain app on the horizon, we could possibly use some modules from there which take care of the uh bridging or swapping to uh bring in some improvements to the node funding part to make it more convenient for end users. And something that I want to show you some data about the node spin up uh for the very first time. Um, so I did a recording of myself uh doing the quick start guide of our official documentation and I recorded which uh step took uh how long exactly. So getting requirements the first one that's doing an AP update upgrade and uh getting NVM uh one minute installing B and uh installing swarm CLI that's like another 1 minute and then comes the postage syncing and I was actually pretty lucky with this uh 23 minutes I've heard um 30 minutes 40 minutes uh for the very first time and to create a stamp uh it's almost 2 minutes. That's because you are waiting for blockchain events and confirmations for your postage batch purchase.

That's why it's so long. But then uploading some data and downloading the very same data to confirm that you can fetch it from the swarm network. That's half a minute. So what's the moral of the story here? Uh even though it took almost 30 minutes to start a node from scratch.

By the way, this was on an uh Ubuntu VPS uh absolutely from zero. That was my very first time sshing to the server. So even though it almost took 30 minutes, the active time that I spent running commands was less than 5 minutes. So I'm pretty confident that that this number can be uh maybe even reach uh below uh 4 minutes from hearing about swarm for the first time running following the uh quick start guide and then putting data on swarm like under five minutes. That should be possible if you can figure something out for the postage syncing.

So yeah, that's uh that's pretty good stuff. Um that's the end of uh the node spin up and ease of use segment. So now unless there are any questions or other announcements, I will move on to the uh BJSQL and I think I'm I'm good to go. All right. Uh so at the last not the last SEC it was in January.

So January I presented some upcoming changes about BJS and this was the very last uh segment of my um presentation there. I listed five points as well on what the next steps will be and it took 27 RC's published on MPMJS but we finally have it. So this is how those five points are looking now. Uh we released the new BJS version. uh it's uh under the major version 9 and we did actually do a lot of QA on this to make sure things are working.

Uh we redid the uh complete testing suit to make sure we are testing for actual use cases and making sure that they work. We were using real B nodes for those tests to keep it as close to production as possible and it's it's looking good so far. We are still working on the docs website for B.JS. Um but the first preview version is already there.

Uh probably by the next SEC we will have a mature uh documentation website for BJS ready. The create swarm app uh which you can use by running mpm init swarm app has also been updated to use BJS 9 uh 9 and it's out. Um we don't have this item yet which is about creating more projects uh for ideas on what you can do for swarm. Uh but this is on the way and actually some of these might also get uh inside the create swarm app. So when you are creating a default application from template you can enable features for some use cases that you want to use swarm for.

And with the release of uh BJS version 9, we could unblock unblock some issues in swarm CLI and dashboard they have also received uh the new version of B.JS. For example, in SAM CLI, now you can uh remove mentor forks without removing the children under the same prefix. Uh just for one example, I will give you a recap. I will try to be as quick as possible on what the major changes in BJS version 9 are.

And the first one is when you are working with tokens, there's two new classes, the BZZ and the D. You can construct them in a friendly way. You can give it give them a decimal string or or plur or for the XDI uh you can use way and then have convenient methods on them to uh print them in different format but also to do some calculations with them or exchanging D to BZ uh or the other way. Next one is working with uh the elliptic curve and keys of course. So the new classes here are the private key, public key, ETH address uh and the signature.

So you can conveniently create a private key for example have a message sign that private key you get a signature with that you can recover the public key from a signature given that you know the original message and of course you can get the address of that public key. Uh you can also like starting from the private key also known as the serer you can get the public key from the public key you can get the address and you can also print or get different formats of these classes like the compressed format of the public key or the check some format of the address. Uh I've also introduced some swarm types. The most common one is the reference. You can pass it a CID or a swarm hash and then have some convenient methods on them.

Uh like converting it to hex, converting it to a CD, getting the uh raw byte array presentation. And of course, this reference along with uh hex strings and bytes are accepted in pretty much every BJS method where it makes sense. There are some other uh new classes like the topic uh for um feeds the identifier for SOC's the feed indices uh for also feeds and they also have uh some methods for better uh developer experience and there are even more like the batch id span peer address uh when you are working with BJS types or BJS methods and you see the return time, return type. Uh you will very often get these back so you know exactly what they are, what they do, what functions they have and so on. Uh we also have client side chunking now in BJS version 9.

Uh it's uh available on the Merkel tree class. So how it works is that first you create a function. What should happen when a chunk is ready? uh nearly in every case you want to upload that. So you call the upload chunk with a batch ID and the chunk and with this Merkel tree you can keep streaming data to it.

So for example, if you have a read stream or if you are in a browser and you have a file reader, you can keep appending data to the tree. It will trigger your onch function uh many many times and when you are done with the data, you can call the tree finalize method to finish it up and receive the root chunk that you can uh then use or share with others. We also have the client side stamping or the stamper. Um, this example is very similar to the one before with the client side chunking except we have a stamper here. So, it it needs three things.

It needs a it needs a private key. The private key which was used to buy the postage batch. It needs that postage batch of course. and it needs to know the depth of that uh stamp. And the way you use it is very simple.

When you have a chunk, you want to call stamper.stamp on it. And it will automatically create the envelope uh which is used to upload the chunk. And in that case, if other bodes have this enabled or with gateways, you don't need to use your own B node anymore to upload. You can use any gateways or other bodess on the network who have this enabled and they will relay the chunks on behalf of you because they no longer need to stamp it.

You have already done that on the client side. So this enables a lot more use cases. Uh and it's pretty cool. Uh after you are done using your stamper for one upload, you can call the get state method on it to get back all the 65,000 buckets that your stamp has. and you very likely want and need to persist it somewhere.

So when you are using the very same stamp for the next time uh you can create the uh your stamper by calling the stamper from state by and and pass this state. So you retain the previous uh uh bucket information like which bucket has been filled up how much you want to know that on your fir on your next go otherwise you would be overwriting your previous chunks which you very likely don't want but there might be a use case for that too. Okay some more uh new stuff about postage batches. Uh there are new methods for working with postage stamps. Now you can maybe I will start with this bottom section.

So now you can create a postage stamp without having to know about what they are. You can use the new buy storage function and you don't need to care about amount and depth. You can just specify a size and the duration. So you can use size from gigabytes and duration from days or weeks or year. Um there are many methods on these uh classes and it will figure out what uh depth to use and and what amount to use and we'll just simply give back the batch id and very similarly to this you can also extend the storage duration and the size.

These are the previous top up and uh dilute operations. And here you can also use the uh duration and size classes uh to tell your bode what you want. You don't need to care about amount and depth. And for each of these methods, these three, you have a corresponding function to get the cost, which is going to tell you, for example, if you want to create a uh batch for 4 GB and for one day, it will tell you how much bzz that is. And there are also some new properties on postage batches.

For example, when you call the um B.get get uh all postage batch function. So there are new properties on the returned uh postage stamps. Those are duration, usage, usage text size and remaining size. They should be uh selfexplanatory.

So that's that. Um in the new BJS version, we have a new uh manifest API also known as the mentor node. Uh they are key value collections that you can use to create websites or or file structures and to use that them is simply just uh uh invoking a new node and adding forks to them and then saving that to the swarm network. You get back the root hash. uh to load an existing manifest from the swarm network, you can use the mandrain node unmarshall method and then call load recursively to get all the uh children uh all the forks as well of the uh node and it has a lot of functions that you can use for example the collect and map which gives you the whole structure of the manifest.

You can also uh change existing data within the manifest. This is the scenario that I uh described earlier. You can add two forks fu and fu bar remove fu and fu bar is retained. So I'm just saying this example because previously it did not work if you were trying to use it with mentor ajs. So now this is part of bjs and has been fixed.

GSOC also made its way into the BJS uh version 9 to mine the uh serer for the SOC that you will be using for messaging. It's a very simple oneliner uh function call. Overlay is the overlay address of the node who you will be messaging and who will be listening. And identifier is something that you to agree on to be the identifier of this exchange. To send a message again just a oneliner uh you need a patch ID because of course you are writing the serer that you mind here and the identifier and your message which can be uh UTF8 string or arbitrary uh binary data and on the service node side who is listening for GOP messages there is the B doc subscribe method that you can call this is again the same signer that we mined the same identifier and just very simply two function call backs what should happen on message and what should happen on an error.

So you can use uh the GSOC feature with these three methods. So I talked about create swarm app and this is what it looks like. Uh so I first run ran the npm init swarm app command. uh it prompted me to install and then it gave me the help or the usage guide. So you just need to type mpm in its warm app and then give a name to your project and the type for your project.

So for example, my app and node ts the possible types are node if you want commonjs, node esm if you don't want typescript but want modules, node ts if you want to work on backend or cli projects and you want typescript and the only currently available front end uh scaffolding is uh vit uh with uh tsx and for example here I ran mpm init swarm app. I gave my project the name message board and uh chose the type v tsx and it uh simply creates a folder and tells you to uh go to that folder do an npm install and you can run mpm start to get like a basic project basic application that does some things like uh creating a postage stamp uploading uh data and fetching data and then you can start building your application from that checkpoint. You don't need to set this up yourself from zero. And I just want to quickly mention swarm CLI that it has been also released uh with a new uh BJS under the hood. And also one new command the uh CI command to convert any reference or CD either back to a swarm hash or to a CID.

And that's actually the end of my list. So thank you everybody. Uh so BJS is released under mpmjs ethersphere/bjs and you can also find it on github. It is of course uh fully open source and that's all. Thank you very much.

Thank you so much Aaron. That's been amazing. A lot of lots of stuff. Uh if you want to give any questions to Aaron or it appears to you along the way, please use the state chat or the other channels. Thanks so much for that Aaron.

Really insightful. All right, moving on to our next section which is community talk and we have two community talks today. The first one it's uh called OCE registry implementation on swarm. What is this? Well, in December 2024, one team built a way to store Docker container images using Swarm instead of traditional cloud storage, connecting Swarm to the standard Docker registry system.

They also looked into how to handle things like permissions, payments, and human readable names using ENS and onchain payments to make it easier. I would like to invite to stage Andrew and Ata from Debboot/ancloud team to present a proof of concept for a working container registry on swarm. Hello Andrew.

Hi thanks for having me. Uh can everybody hear me? Okay.

Yeah, loud and clear.

Okay, great. Well, um yeah, before I get started on the demo, I'll say a little bit about uh the why and the what of what we did. Um first of all, why containers? Well, uh containers are basically how most web services are deployed. So that's a huge amount of software being deployed by uh via docker and similar OCI spec tools and hence that's like potentially a really big addressable market for swarm storage if we can connect the two together.

Basically anything that has to do with containers can reach millions of DevOps professionals around the world. Just to give a couple of numbers, um I just looked up what Docker quotes its usage rate as. Uh Docker claims that to have 17 million registered developers as of 2024 and 25 billion pulls per month uh from Docker Hub. So let's get all of that activity on Swarm. Secondly, um distributing software is a potentially an interesting niche for swarm storage.

Basically uh considering the price point of Swarm, it's fairly expensive. It's priced near towards the upper tiers of some of the managed centralized cloud services. On the other hand, it's far cheaper than other decentralized storage systems that offer permanent storage like Arweave and Ethereum state. Um, so while it's not, you know, while it's probably too competitive for storing pabytes of uh climate data or archive archival or backup data, um, it's quite believable that somebody might pay 50 bucks a month to use Swarm to distribute a few hundred gigabytes of software. Okay.

Now, what I'm going to try to share my screen now and uh Okay. Right. So, um containers are distributed um by something called a container registry. Container registries have an open specification called the OCI distribution spec. So you can see uh provided my screen is actually appearing.

Yeah. Um you can see here the open container initiative which is started by docker.

One second. One second. Sorry. Sorry Andrew. Yeah there are some people who cannot see.

I cannot see it. For instance I have this

yellow exclamation mark. So for anyone who cannot see it,

we enabled a link because this thing is recurrent. Discord manages to play with us

very often. So we have created this link up on the stage chat where you can click and see uh Andrew's presentation just in case you can't. That was it.

Okay. Um do I need to do anything different or should I just continue?

No, just carry on please.

Okay. Um yes. Well, for everybody who can see, uh, yeah, well, you can see I'm just showing some GitHub repos at the moment. This is the, um, distribution specification. It basically specifies an API for pushing and pulling containers.

So, um, all you have to do uh, to plug say swarm into a container registry is to implement this API, do whatever you like on the back end, and then ordinary container tools like Docker or Podman can just interact with it without modification. So this is going to work to be something that works with a modified registry but just completely vanilla tools like in the demo I'll use podman and as you can see uh there's basically a list of um 13 or so endpoints or blobs manifest and tags I won't go into the details of that but uh you know if you're into nerdy stuff it's kind of interesting to read through that spec. Um, now

can I ask real quickly is any is anyone seeing the screen?

I'm popping in. So, apparently, yeah, there are people who can see it, but I can't. So, I would share, but I can't share because I don't see myself.

Oh, okay. I Yes. I can't see either. Okay.

Oh, Dan sees it. Oh, okay. Heropic sees it. Can somebody just go to this uh screeny and share it for everybody else? Like go to to the link I pasted in YouTube

and then share screen and come back with Oh yeah. Excellent. Or just head to to Twitter I mean X

cuz we're also broadcasting there.

Okay. Sorry for this interruption.

Okay. Um, yeah. So, that's the OCI spec. Um, what's more, as well as the specification to work with, there are multiple open-source implementations of this specification. So, you don't have to start from scratch with this API.

You can go and try to modify uh or fork something that already exists. And uh what we've done is we've gone into the uh reference implementation of the distribution spec which is called uh distribution/distribution on GitHub. Uh basically the reference implementation of a docker registry and this thing it's written in Golang and it has a pluggable system of storage drivers which I'll quickly show you. So um basically this allows you to configure your storage backend for from local storage or multiple different cloud providers. So you can see we've got in this is this is the vanilla um implementation.

There's like an Azure provider Google cloud um AWS and in memory and a file system one. Um so what we've done is we've gone and implemented our own driver for this distribution uh this uh implementation of the distribution spec uh which connects to swarm and what it does is you're going to run a copy of the registry locally configured to use this swarm stuff and then your docker is going to connect to which I'll demo in a second. Your docker is going to connect to this local adapter that's going to pass the request onto a b node also running locally and then that's going to spray your containers into swarm or fetch them back from swarm. And now uh if I can figure out how to change the stream um I will show you the actual uh demo. Where is Okay.

Um, yep. So, what we're seeing here, uh, if you can actually see anything is, uh, I've got three shells into this HNA node where I've got a B node running with the logs displayed in the top left. Uh, I haven't set the log level high enough. So these logs are not going to be very interesting to look at. And um now I'm going to fire up this registry and then do a few commands using um Pogman to show how it works.

Uh but maybe first thing I'll do is show you what the configuration looks like. So you can see around line 12 here there's the swarm. Line seven is the storage configuration and within there we've got swarm. And then there's a few things uh listed in there. Uh this private key is um you know, obviously you shouldn't normally share that on a live stream, but this is just a demo.

All you can do if you write down this private key is um publish to the same registry that we put up for this demo. Um which is not that I'm not that worried about. Um uh this is where it's going to find the B node and uh this is a postage stamp batch to use for pay for the upload. Now let's fire it up. So uh this is the registry blasting out logs in the bottom left now.

And what it's doing is it's mapping out a bunch of paths. I don't know if anybody can see the actual messages. Um these are from the sort of internal path layout of the way that the reference implementation implements its um its storage. Right? So it's going to it takes your containers and distributes it up to these paths.

They're all mutable uh treated as mutable paths and they're implemented with a swarm feed. Now if we go back to the big screen on the right, let's have a look at our images. So this is a list of the locally stored um container images on the system. Uh the names have a prefix which basically tells the client which registry it thinks that the um the container comes from. So what I'm going to do is I'm going to pull a uh to demo it, I'm going to pull a container from a standard repo.

Uh let's I've chosen to use the uh Alpine one because it's a nice compact size. And I'm going to rettag it. So that as to tell my podmat that I'm now going to connect that container image to the local registry uh which is running on port 15,000 that's here. So I need to do a podman tag uh docker.io/ libraryalpine to localhost 15,000/demo.

And uh now is the moment of truth. We're going to push this thing and hopefully it should do something. So on the left you can see things going wild. It's creating new um metadata and blobs. Uh it's got a readout that's podman client showing me the progress meter.

Unfortunately, the uh swarm like the reporting of progress from the swarm uploads is not compatible with podman's understanding. So, the progress meters that podman displays uh pretty useless. It says it's done now, but it isn't done. It needs to uh finish updating a bunch of feeds and copy a config file. It hopefully shouldn't take too ridiculously long.

If it does take a long time, now would maybe be a good time to shoot in some questions. Maybe I'll fill in the gap a bit. Um, basically the the all of the implementation here was managed by uh Aloc who couldn't be here today unfortunately. Um, like we we did the some initial strategy about the design and um put together the grant application but uh Aloc and his um his cousin basically did all the implementation. So big shout out to him.

Uh it was based a lot on the ideas used for the file system he developed a few years ago also based on swarm.

So yeah I just had first of all this is great. I'm really impressed. Um I was wondering uh with Docker then they have the different sort of layers of the container to reduce the um amount of data that needs to be transferred. Is that integrated here or

Yeah, that is a great question. Actually, when we started out, I was imagining that we would try to come up with some way to um like make the dduplication of Docker layers talk to some somehow linked to the immutability of swarm storage. uh as it happens like the dduplication is implemented um but it's not implemented in a way that's somehow swarm aware or anything like that that the reference implementation just splits these things up into blobs which are content addressed and then it maps to them to these parts but we haven't done anything like special to respect the fact that for example some of these parts are known to be immutable because they're content addressed um so yeah that that is something that I I'd like to explore because obviously it's kind of a waste of resources to store these immutable blobs under mut mutable paths.

Great. Thanks.

Ah, we've actually finished. Okay. So, that has uploaded. Now, in order to demo this, um, what I should do is I should delete this images from my local machine. Uh, which I will do now.

and I should also delete the original copy because as was just mentioned uh Docker stores the um duplicates the blobs for this uh these containers. So if I've got two container I've got two containers which have the same data but a different name um trying to pull when it tries to pull uh the one that I've just removed if there's another copy of it under a different name it's just going to figure out that that's the same content and just work immediately so it won't really be testing any downloads there although we will still be testing um pulling the manifest from swarm if we try to pull now maybe I can just demo that actually might be informative Yep. So that was very quick. Uh ah another reason that was very quick which I forgot to mention is that uh the district the registry itself implements an in-memory cache. So actually we didn't go out to swarm to do that.

We just went to the uh registry in memory. So we needed to pull that down and um bring it up again. to really uh show you what's going on here. So, let's delete that again. Let's give the registry a little bit of time to find all its paths again.

Maybe maybe another comment while while this we're waiting for this to happen. Um on performance, obviously this is kind of slow compared to what you might hope for for a container registry. Um maybe you don't have an opinion about how long it should take to start up a container registry because most people are using remote container registries but at least to upload and download you you know one would hope things are going to be pretty fast. Um one of the reasons we think that this might be happening is because um the default storage layout for this um reference implementation of the regist OCI spec uh uses a lot of mutable paths and uh these are implemented with swarm feeds. Uh currently the performance of using loads and loads of swarm feeds is not that good.

Um Aloc has an idea of how we can implement it using just one top level swarm feed to point to the latest version. The registry and everything else is immutable and that um might do give significant performance improvements but we haven't implemented that yet. Okay. And now the uh moment of truth. Let's pull this.

Um, yeah, that's a success message. Says it's time to try it again. Okay, so now there's a bit of a pause because it's going to have to go out to swarm, but it shouldn't have to go out to swarm for the full blob. It's only going to go to swarm to get this manifest which tells you what the content blob is. And uh, yep, there it is.

It's um, it's pulled it. And maybe I can do a proper full poll demo where it paused a blog as well. Blob as well. And you may have to cut me off if this takes too long and you need to get on to the next item. But let's give it a try.

Okay. Podman images. We're looking for um this ad image. We're just making sure we've got rid of it. It's not there.

Okay, let's pull it. And it's having to copy the blob. It's really going out to swarm for this. You can tell by the fact that it's zero still on zero bytes because it can't report the download progress properly. Um yeah, this will be the last thing that um part of the demonstration.

So also again, if there are any sort of final questions, um you might as well pose them while it's downloading this thing. Y success. Okay, that's the end of the demo. All right, thank you so much, Andrea and Ata. Uh, I don't know if we have any more questions here on this ch state chat.

Let me have a quick look. No, I don't see any. All right, so thank you for this. Uh, it's impressive work. Thanks.

Thanks for that. Uh and now let's please stay with us just in case something something pops up and let's move on with our next community talk which is talking about provenence swarmbased data provenence framework. provenence that by the way it's a great name for a Marvel superhero is the documented history of a data set's origin and transformations and is increasingly important for regulatory compliance ethical AI and data accountability. I would like to invite to stage CH who will follow up from last month's presentation with an update on the informational sweep on data provenence. Hello Chart.

Hi Antonio, can you hear me?

Yeah, loud and clear.

Okay, great. So, hello. Thank you for having me here today and everyone in the audience audience listening in. So, we're continuing with updates about data provenence on swarm. Uh Antonio has already reminded you what data provenence is about.

Under the fellowship awarded to data fund by swarm for data and model provenence for decentralized AI, we are proceeding with the steps towards building a toolkit to allow for swarm to be used as a data provenence storage solution. Today I will present a sweep proposal for data provenence framework on swarm. You can find the proposal as a PR in the sweep repo uh PR71. Um the sweep describes what features the toolkit would have and how provenence data would be stored on swarm. So let's touch upon the key features of the proposed framework.

Decentralized storage. The framework will provide a decentralized storage layer for provenence metadata and data ensuring immutability. This will mean that once data is stored, it cannot be altered or deleted providing a reliable record of data origins and transformations. The framework will be designed to accommodate various provenence standards without enforcing a specific format which will allow flexibility for users to choose the standard that best fits their needs ensuring compatibility with different systems and applications. It will use JSON for metadata which will include essential fields um in addition to help manage the data specifically in regard to swarm storage and um it will have support for tracking of time to leave for stamps and top-up mechanisms which will allow users to manage the availability of their data on swarm more efficiently ensuring that it remains accessible and uh when as needed and controlling the storage costs and this uh should bring forth benefits for developers.

ers and users uh in the ease of use which is the most important factor for easy adoption by both swarm developers and nonswarm savvy users and should help bridge the gap between decentralized technologies and mainstream users. It should open Swarm to web to communities providing a seamless way to leverage swarm decentralized and immutable storage for provenence data and could attract new users and applications that require secure and transparent data management. And finally, regulatory compliance. It has the potential to help users comply with emerging regulations like the EU AI act which require transparent data provenence. The framework is currently in the design phase with the sweep serving as a foundation for its development.

So, you're invited to review it and provide feedback. This is crucial for refining the framework design and ensuring it meets the needs of developers and users. So, thank you for having me. Uh, and back to you, Antonio.

Thank you, Chart, for this comprehensive uh followup. Thank you. All right. Uh any questions of course in the chat in the chat stage. Um and now let's move on to the AMA questions and community.

Anything you would like to to say, it's your moment to voice it out uh in the chat or in the chat u box or you can also come here to stage if you want to voice it over. I have a couple of them that I will read out and try to comment on them because they are addressed to to particular things. For instance, the first one it's uh why BCC was delisted from OKX. They are asking if there's any changes in fundamentals and uh because the market has been hit hard. Another question in a similar line, any any plan to improve the liquidity of BCZ and decrease the the bad effects caused by the listing uh when the will the multi-chain function be released?

This one was addressed earlier, but well, I have we have a couple of them about the getting the listed and the strategies. Uh I would like to comment or to address them together, but essentially the the there's no change in fundamentals if that's if that's your worry. Swarm is has the same vision and keeps building the same uh the same keeps walking the same path since its inception. Uh but the the market is as it is and the centralized exchanges have certain requirements particularly these days in terms of regulatory concerns and well they have regulatory concerns and they have regulatory pressure. So,

Automatic transcript — names and jargon may be misspelled.