Swarm Community Call — May 2025

Okay. One, two, one, two. Yeah, I think it works. Hello everybody and welcome to Maze Swarm community call broadcasting live to all the corners of the interwebs and that includes X streaming on X also. So hello there and you're very welcome to join the conversation in Discord.

But for the first time ever, we are eating our tasty duck food. So, we are streaming as well into Swarm. Thank you so much for coming. My name is Antonio and I'm very glad to be your host today, wherever you are within this pale blue dot. All right, so what can you expect of the call today?

Here's the agenda. Uh first we'll talk about the core development updates with Nikki and Callum and then we will have the our infocus section where we will report from ETH Prague where this um broadcast is being generated because we are well in other words we're in Prague uh community talk the clients are coming with Pavl MFW78 and ATA and finally we'll close with the community AMA and open space for debate. So that's it. Welcome to have you here. Let's kick it up.

To begin with, uh Nikki will walk us through the items that will be included in the upcoming release. All aim at simplifying nodes, spin up, and impro improving usability across the board. It's an important step. Uh so I would like to welcome Nikki to stage. Hello Nikki.

Hello Antonio. Hello everyone. Can you hear me?

Loud and clear. Stage is yours.

Nice. Nice. Thank you. So hello everyone. Welcome to Maze community call.

Today we are coming to you live from Ethra. It's amazing to see so many of you in here in person and online. I know some of you have not been able to to join and I have to say we really miss you. Um the energy has been fantastic around and we're really excited to share uh what's been cooking in the product and engineering side. So let's dive in.

Um, one of our biggest focuses recently has been improving the node spin up experience, making it faster, easier, and more predictable. Uh, the goal has been to get uh, dnode fully up and running with no dips form knowledge and in a fraction of the time. After exploring different approaches, we found that the most uh, time consuming part of node spin up is syncing batches. So, here is the breakdown. Um, now we generate a process snapshot and instead of syncing batches in real time, new nodes will simply load the snapshot.

This has already been tested and the results are extremely promising. We are seeing a dramatic reduction in spin up time and it's super efficient. Um, we believe this will be a gamecher for node operators whether you are new um in Storm or running uh nodes at scale. Um what's next? We are also excited to announce that we've uh officially kickstarted the in browser node project with pavl.

Um so what it is um run a swarm node directly from your web browser using web assembly. No installation required. Um this is to make your radically more accessible. Um we want to use it for in browser gateways, file crafting and portability deployments. and actually lower the barrier uh to entry uh for everyone you know to interact uh with the network.

This is going to be our major focus for the uh next uh 2.7 release and we have about the possibilities this uh will open up. Um, apart from that, just a quick quick reminder, there is a sweep open around pushing protocol improvements and we want your input here. In case um, if you care actually um, about how data is served and saved across, this is your chance to help improve uh, one of the protocol core components. Check it out, leave your thoughts and help us build it together.

Um, and since we're here at Fbrank, if you're around, please, uh, come find us. Um, most of the team is here, we'd love to meet you. Talk notes, protocols, or just hang out and hear what we're building. That's all from me this month. Thank you all for being part of SH's journey wherever you are.

Um, we've got a lot of moment momentum right now and it's only possible because of this amazing community. Uh back to you Antonio.

Thank you Nikki. Thanks a lot. It was very very informative. We will be speaking more about this in browser client first and on the call. Thanks for all the insights and I would like to hand over the mic to Callum to share updates from the re.

Hello. Can you hear me Antonio?

Oh maybe not. Maybe I can't hear Antonio. Oh, we can hear. I mean, I can hear you, Callum, but I can I cannot hear Antonio because he's sitting right next to me, but otherwise I'm But go. Okay.

Okay. Perfect. Okay. Yes. Hello everybody from ETH Prague.

Thank you all for your time and coming to the call. I've got good updates to give you and kind of holistically what Nikki was talking about as well, like our wider agenda in the org at the minute for what we're trying to achieve. So, take a quick step back. What we're doing in the full org and in the B team and in research team and everyone with the external contributors and everything that we're working on is ultimately this year and as soon as possible to make swarm competitive, performant, and usable. I think everything that we're all doing is in one of those or multiple avenues at once.

And to that effect, what we're here to do is release the multi-chain product beta into kind of the first production release. And for us, that's a real big shift into delivering very, very easy to use products and services that directly make Swarm a bit of a breeze to actually utilize and work. So, we're excited to be at that production level state. So, you will get announcements pending for when that is released. So, just keep your eyes on the socials.

Won't be long at all. So, you'll see that in coming days, effectively next week. Um, equally if there's any last minute feedback or things that you want to do, it's always available to take a spin. There's always more to do. This is just going to be the first version and it's onwards and upwards from here.

But effectively, what do we mean by competitive performance usable? So again, usable, that's where our multi-chain app comes in equally what we're talking about. I'm very excited to hear more of with our in browser clients. This just takes us to a whole different level of product on top of our base layer infrastructure that makes this network just much much easier to use. Same thing with the easy node spin up.

Effectively, we've seen how difficult it can be even for technical people or how timeconuming it can be to just take time out of your day to actually read the docs, do the thing, spin the note up 20 minutes or more. If hopefully we've got that down to less than 5 minutes, which I just think is a massive, massive improvement. So, I just want to make this as usable and as good of an experience everywhere that we go, everywhere that we have to do, and that you don't have to rely so heavily on documentation because the product side of things makes your lives so easy to get the job done that you're you're looking for. Likewise with the pulsync um protocol changes, we've been reviewing things um on the research side of what we want to do equally on a few more uh eraser code changes as well um to try to get as fast performance as possible for uploads downloads. Again, we've been finishing this epic.

So to go back to my first point of being performant, we're trying to compete as best we can across the board for usability, for speeds, for retrievability, reliability of the data, data availability that we'll eventually come to when we kind of look towards this data availability or you know insurance scheme um that we can offer with the network from there. So you'll see some swifts pending um and some activity on that in the coming weeks and months. Um but ultimately at the minute we're excited to get this product out to production and excited for all the other initiatives coming out of the network. Um so hopefully we see usability improve, speeds improve and our competitiveness improve and then as a result our bisdev, our ecosystem, the token, the foundation and all of us and what we're building on top of Swarm. So I hope that the next lot of months are very productive with a lot of good work coming out.

Um hopefully that answers anything that's in the back of your mind for what direction we are going in and the initiatives with what we're working on and why we're working on them. Um but yeah, so stay tuned for the next coming releases and especially the the multi-chain app and any feedback you get. Hopefully that answers everything that's in everyone's minds. Uh back to you Antonio.

Thank you so much Callum. Uh that was that was that was nice to hear. Please stay with us uh to answer any question that anyone can drop in the stage chat channel which is usually above the stage channel in your browser. Uh thank you so much uh for the two for this for this insights. Let's move on to our next section which is in focus.

Um as mentioned during the last call we are live from Prague with uh which is featuring the latest news from the Ethereum ecosystem. It's been a packed event. There's been a lot of Petra updates. Anything related with the last big Ethereum release. Everything related to account abstraction version two also also called EIP7702 has been featured in several talks.

And of course team Verers Lee and Vitalik uh absolutely full creating a full uh scenario a full audience uh putting emphasis on data ownership and how our data needs to evolve for the internet to become better for all of us and talk uh related to swarm we had Victor Victor Tron had a talk talking about incentives on the first day of the of the event also we had a workshop well they allow they allow people to allow the swarm team to take over one uh big uh table in the workshop area, the purple room of the event so that anyone can come there and ask any questions. The team was there featuring and answering answering questions. That was pretty awesome. And in that particular moment, uh we feature Bchen and I don't know if you know what is Bchen and I'm going to tell you right straight away what it is. It's a forum that was set recently set up on swarm where everyone can anonymously meet and talk.

It's kind it's called Bchan obviously referencing the other forum. Uh you can add existing threads or create new ones. Uh initially this forum was first accessible to those running a local node but at the moment and for showcasing purposes this is also available via swarm gateway with no need to purchase a batch or upload to upload any text. I will urge you to try it out. You simply have to type ichan.

bcz.limo in your browser and you're in. Uh if you're not check if you're running http or https you should be on the latter. Happy posting. Uh that's about if prag.

Uh now the next section will speak about the clients. It's called community talk and we will I would like to invite to here to the stage community members to talk about it. We have two community members working on an e browser client. It's a game changer. So I would like to welcome one of them Pavl to the call and on the other hand we're also super happy to welcome MFW78 in the call because single-handedly working on the client in Rust swiping some dust on the way.

But uh let's begin with Pavle. Hello Pavle. Are you around? You have been invited to speak.

Hello. Uh do you hear me?

Yeah. Loud and clear.

Uh do I just like start the way or I guess I'll introduce.

Yeah, please.

Yeah, please. You can start with introduction and what uh what is your what are you building with this in this in browser client?

Yes. Uh so I'm p I'm a front end developer at DNS. Uh before that I worked at Fleek. I passionate about decentralized web and and decentralized front ends and specifically anything about those two together. And um a few weeks ago, I think around four 3 four weeks ago, I started working on uh uh making B the go implementation for swarm node run the browser.

There is already a similar effort for doing it in rust but it start does it from scratch. So I tried to take a different approach and just compile it to web assembly from go. I already had previous experience with compiling go to web assembly. So like I knew some things already like uh conditional compilation and uh like build flags on the stuff and so I thought like maybe it would be something in my niche. So I started working on it.

Um and I was thinking one of the other reasons why I started working on this because I thought that other decentralized storage networks they have they already have some kind of a similar thing. uh they have either like a browser extension or like a in browser gateway and I thought like maybe B could benefit from something like that as well and another thing would be just for people to be able to run a node without installing anything just by opening the browser tab. So I started working on it. So first what I did is I was just tried I tried to compile uh B just like by targeting web assembly obviously didn't work because a bunch of dependencies are not meant for web assembly. So I've forked away a few of them uh such as LOB which is the one the swarm uses under the hood and Ethereum and a few other blockchain based technology.

I did uh like this interpability layer with the file system that is uh right now is in memory but later we'll be using local storage or some some kind of other browser storage. Then I think then I for uh go P2P to support web assembly compulation. I wrote a custom uh web lip transport for websockets because the one go lipb is not meant for web assembly because usually if you want to do a web soocket transport lip tob you just to use the javascript library instead or a rust one. So I managed to get it uh to the point where uh my local B node would be able to uh appear with the browser one and um they managed to establish a handshake and uh like you can query most of the API end points in the browser node because the browser basically how it works it uh starts a web assembly binary of B in a service worker which runs in the background. So, and exposes all the endpoints instead of HTTP endpoints.

They're like service worker endpoints. Uh, and uh you can you can uh request them in inside the browser. That way you can yeah you can query the same points as if you would do that with the local node. Right now file upload is not working and uh download either as far as I'm aware because I've been uh working on reducing the bundle size of uh in browser B because go is not very suitable for web assembly because it ships garbage collector and uh like this uh layout object that like occupies half of the binary. So yeah, I've been working on minifying the binary and uh I've also had already had a few calls with the B core developers and also the guys from solar bank and uh yeah they just they helped me with the setting up a local cluster of B nodes so that I can simulate the B uh sore network because um if there's just two nodes in the network it just hovers the request to the network for a file and then you to find the file because the file is only on those two nodes.

So yeah, my my progress is mostly that I'm I'm just trying to reduce the bundle size for it. So it's not like 60 megabytes as it is now. And uh to try to make download work and the browser node runs as a as a ultra light node. There's no point in uh I think as of now to try to run a full node in a browser. It's also like very memory consuming.

Yeah. Yeah. Then the final product would be something like in browser website gateway that would run this node as a service worker in the background and not require any kind of software installed in your computer besides the browser. So I guess that's the summary.

That's uh not a single not a simple thing and not not a small feature. I would say uh one of the problems that uh the clients the the actual web3 has is the need to spin up a gateway with every and spin nodes and that's that's solving in a very elegant way uh one big big problem. I do believe that this is could be really a a nice changer. Thanks a lot for the overview, Pavle. Stay with us.

I would like to give the mic now to MFW78 who will speak about the Rust client he has been working on. MFW, could you unmute yourself please?

Sure. Um so the Ross file that I've been working on or the the bounty implementation this has its origins in uh when I computed on the swarm Wikipedia uh bounty. Um so I found that obviously I was implementing some of the primitives for handling uh mray manifest and chunking. Um this was highly performant in Rust as opposed to uh JavaScript at the time. So that's where the code base originates from.

Um, and yeah, I do have similar desires to be able to [Applause] like clients uh that are able to be embedded in uh varying architectures be it RAM, be it uh ARM base for mobile or these kind of places. So that there is essentially like a distributable that can be uh targeted to multiple architectures that then enable uh the development of applications to be built on top of swim. Um so currently where things sit at the moment is uh things like hand shaking are working uh discovery is working. Um, and I spent a lot of time on optimizing the the group parameters particularly around BMT function to ensure that uh I'm sorry that I I sound rusty which is funny but uh I don't think there's anything I can do to uh improve audio quality cuz I don't have an external mic. Um sorry about that.

Uh so um yeah I so currently uh P discovery is working. It's not working um yet to establish a full topology, but uh currently like in Prague, I've been hacking on um uh implementing swarm scan uh as a CLI tool essentially um to allow this to essentially replicate what swarm scan is doing but uh using the the rust uh that I've uh that I've written on in developing the the rust clients. I've done quite a thorough review of the wire level protocols that are being used within swarm and have identified multiple areas for improvements uh to to reduce uh I can um I'll try to turn input level down one moment. Sorry guys. Um, is this uh better?

Uh, well actually actually I think I can hear you clearly while still some buzz around. No pun intended. Now you're completely gone. Well, all right. So, I will I will please stay with us and Abdul while

uh we can hear. Oh, yeah.

Yeah. Yeah. All right.

Yeah, now it's better actually.

Okay, cool. I just uh switched to mobile.

Um Okay, cool. Uh so um yeah in regards to uh the protocol work like in implementing the rust client I've done a deep dive through the the wire level protocol used within be and identified multiple areas for improvements um both for like memory management um within clients uh also for uh improving the resilience of the wire level protocols and I have multiple swips out for this. So the coordination um between myself and and NB developers has uh obviously uh presented additional overhead. Um, so client development is not necessarily as fast as what I would like, but um, in regards to this, I I pushed a PR to the B repository uh, a couple days ago, which uh, improves uh, the lib P2P stream handling uh, and avoids the use of trace headers uh, which is um, a something that everyone that's implementing a client would have to handle. And it would be much better to have this as optional um in my opinion.

Uh and uh this also then reduces uh roundtrip times and latency uh within the network and I think that this would have quite a marked effect considering um that uh the topology within swarm network uses boarding for chunks. So this avoids um many many RTS uh when retrieving chunks. So hopefully this gives marked marked performance improvement as well. U but yeah like ultimately like what I'm targeting initially is uh is a light client so that it can be embedded um in other applications and then eventually pushing through towards towards a full client.

Awesome. That's really that's really important the multiclient perspective. Thanks a lot. Thanks a lot for the overview and uh but that's not all. Uh I will I have a we have a little surprise here.

So I would like to invite Ata from Shuka Research Ancloud to take this community talk to another level. Uh I would like you to speak well I as as far as I understand he will lead you into exploring client transport in general network topology and challenges of portb. Hello Ata, are you there?

Thank you for always nice introduction. Can you guys hear me?

Yeah. Uh I think that we are we are listening another mic because I can hear you but uh like like from the other side of the room.

Oh really? Um

so I presume you are speaking to another source. Is it still exchange?

No, I see you're still very far. Very far. 1 to 10. You are at two being 10. You are by my side.

In the meantime and while you while will you try to fix this up there's one question that has just arrived and has been posed to pavl in the state chat around the browser question is from eterotic and it says what additional vectors are exposed from the browser to the was of you accounted for any

uh I can find the question uh could you please repeat The question is in the in the in the channel stay chat, not in the proper uh chat bubble that we have.

By the way, can you guys hear me now?

Oh, yeah. Much better.

I figured out what it was. It was my uh iPhone was actually taking hold of the uh taking hold of the microphone and it was literally was in the other room.

Sorry.

All right, let's let's blame

I found the other room.

I found the boyfriend. Uh what does vectors imply like usage vectors like use cases or

Yes. Uh not sure. It says what additional if you go to state chart you will find the question there. It says what additional vectors are exposed from the browser.

Yeah I'm just not sure.

Yeah I'm not sure what vector means but I guess it means use cases. uh besides in browser gateway you could just have a in browser node or uh that if you don't want to like install one on your computer and you just only need to retrieve files you don't have to upload anything you could potentially do upload as well and uh store like uh private keys somehow securely or like I'm not sure like for example create some kind of vanity account that is uh bound to your regular account or something like that and just run run something like a dashboard for a browser node. Uh, another case is apps that need access to to decentralized storage but they don't want to like request files from a gateway. They just want to do directly from a lip network. They could do that.

So yeah, those are I guess the main pieces.

Thanks a lot. I hope it it answered the questions. If not, you're free to keep putting the finger in the eye. Thanks a lot. And now I will leave you to Ata.

Can you hear us again?

Yes. Yes. I I can hear I can hear you and I hope you can hear me. This should work now.

Uh yeah, stage is yours.

I will actually give a little bit of background not on me but on the background on how how I how I want to ask your questions. Um so as we know uh we've worked a bit on this deboot stuff before but what was deboot for us or for our team it's so deboot has been and and always will be like one of the first types of like a quote unquote cloud busting ideas like taking apart clouds moving things into smaller decentralized pieces uh in particular debu was was uh one thing that it did it uh took a piece of tulage and moved it into decentralized toolage and one of the ideas embedded in that which is where I want to go today is getting node node type of software or node code closer to the hardware or closer to the firmware. So that's that's kind of the angle I'll take today. So I've I've drawn myself a little matrix of um like uh Rust kernel plus Rust to ELF compilation and browser browser environment with go to wom compilation and I'm going to be producing questions by having my mind in the mindset of thinking about a UEFI environment and trying to figure out how to get an EFI module or an executable like that. So if I'm asking strange things, it's probably because of that.

Okay. So, um, so, so I wanted to ask, uh, Pavo first. So, so how many different, um, run times did you did you run through with this gom in order to to figure out what you wanted to do and then how did you settle on something?

Uh, so I tried uh like two two main I mean it's web assembly. There's one runtime. There's no other like browser runtimes. I I think I first was trying to use WY web assembly shar right. I think that's what I'm referring to was it was seeing some of these early discussions about that.

Yeah.

Yeah. System interface. But the problem is that uh like for web go uh grabs net whatever like HTTP request into fetch which are which is a browser API for fetching stuff.

With W doesn't do that. it converts like it just leaves uh all this TCP stack as it is. So you have to write system calls for socket for opening and closing sockets. So you basically have to implement like TCP within a browser which I wasn't in the mood of doing and I felt like a huge overhead at the cost of like of some things compiling better than with basin because uh with there is less interrupt needed since it's like more like unified standardized like as long as the spec supports it will probably compile but web assembly it will compile only like if go spec specific web assembly target will support Yeah,

go ahead.

And I was trying different uh like compilers for go. There is a tiny go and like go there the regular compiler. Yeah, tiny go right now can't compile B at all because there is a there that like very huge dependency on promethos which is a metric service and it like requests a bunch of stuff about u runtime and GC there's no GC in tiny go so like just a bunch of like standard library is missing because of that and it's just a bunch of work of just suppressing those warnings so I think

yeah the the gar you're talking about garbage collection now right like that's exactly where I wanted to go next. Yeah. So yeah what what exactly did did you have to think about much for garbage collection?

I was just No, I was just saying that Tiny Go doesn't have one as far as I'm aware. It's

I didn't know that about Tiny Go. Okay, cool.

Yeah. and and tiny go doesn't implement a bunch of standard library modules that are related to this system stuff because it's different from go how go does it and uh and it's mostly coming from promethos and promethos is this metric service that be uses heavily everywhere and it's just like in order basically for it to be able to be compileable with tiny go we should produce a much smaller much more portable binary for B all stuff would have to be like moved somewhere in a way that is like easier to just switch it back and forth between what gets included in the W bundle and was get included in a regular like binary.

Cool. Cool.

Right now just go. So the binary is 58 megabytes.

Yes.

Instead of so let me ask MFW. So, so Pavo's thing is seems like a very directed and and niche type of uh I guess I would call it a port, but uh MFW your work, would you call it more of a port or rewrite? And is is this this is not so niche? I think it's general purpose and and uh just adding to client diversity. Is that right?

Uh that's correct. Um the the one of the main things that I've wanted to explore with um with the rust client is to build it with modularity from the start. Um and so whereby whereby chunk types and this kind of stuff are abstracted and these can be changed in and out. So be it SOC chunks or CC chunks but you know you can like then you know research teams could then take this and abstract it even further whereby you could actually have multiple methods of authorization. So maybe not even just uh postage stamps like you could have ZK membership sets um as an example.

Um I then yeah like predominantly it's it's about modularity and and being able to experiment. So it's more general purpose in nature. Yes. That was a beautiful answer actually. That's uh I didn't even expect how nice was that going to be.

Okay, I'm really excited to look at this this modularity aspect and being able to switch things out for ZK. That is quite cool. How and how this is a question I guess to to both of you guys. Um so there's lib P2P hanging around. Let me just ask a question for myself.

So, as far as I understand, the the current Swarm implementation doesn't use all of the the possible libid P2P um transport methods. Is that right? Like for example, quick isn't used, I think.

In B.

Uh yes, in in the in the B. So, other Yeah. LIP P2B provides multiple methods of transport. Yeah.

How how many of those are used in the B? Well, just in general B only supports websocket and TCP and u websocket there's a draft pull request for quick support like

how important is websocket for the reason I ask is it possible to run a B if you have access only to TCP and HTTP networking services

well yeah you can that's how most people run be node they just use a GCP transport but

right so in your case you were considering this websocket stuff because you're basically you are encouraged to do that because you're stuck inside of a browser right

yeah and browsers have websocket API uh

I got it I got it cool okay I'm adding to my

yeah that's also why I wrote like a custom websocket transport that that API in JavaScript

yeah and and MFW W you you you basically didn't have to do anything, right? Cuz if in particular for the lib P2P component you were you just able to to import stock R to lib P2P?

Yeah. Um stock RS lib li P2P like with uh TCP works works fine. Um like the Rust Loop P2P implementation from my understanding of it uh does does lag some features of the uh the Gol P2P um and also the JS loop P2P. So things like uh web transport are still pending. Um I know there's been a PR open for this like on upstream for a few months now.

um this would be very nice but also you know that's also like somewhat unstable as well u between browsers at the moment.

Mhm. Mhm. Thank you. And so here's here's another one to both of you guys. So of course your first first target to hit is to get proper light node uh compilation running and working and passing tests like what what what are the what's next?

What kind of strange things do you need to do in order to to keep going past the light node to the to the full node? What's what are the hurdles?

Uh I'm I'm not sure if there is a any point in running a full node in the browser to just nuke your browser because like full nodes are much more intensive bandwidth wise in like CPU operation. I don't think there's a need to write the full node in like for example there's halos that is a draw light for Ethereum that is

a good point in terms of motivation are we motivated to do that yeah cool I guess for the for the rush though there is there's quite a motivation to have a full node working

yeah somewhat there's there's like there there's quite a motivation like um so my my core motivation is driven around application usage um very much so like first and foremost because you get something that can target multiple architectures and you know expose via FFI or whatnot. Um something so that people can write in say like in Dart or like D/ Flapper or or Swift or or whatnot to still get access and this is this I think is still quite important but then eventually yes like full node is is quite desirable. Um I have seen like on on benchmarks the the root hashing primitives um when I actually got the benchmark working correctly um on on rough like it works out to be anywhere between like up to like about two times as fast. So this should make it more performant on lower spec hardware um or andor allow um operators to push more uh more nodes on the same hardware. So both of these work.

Um but in terms of like coming up towards a full node I think um like in in in B the the way B is currently implemented they they talk about ultra light node light node and um and full node. Uh whereas the work that I've done I've kind of conceptually I actually see it as there's actually just two core protocols and one is um you know being able to access and interact with the swarm network i.e. be able to like get and put data.

Um, and then there's the storing like the synchronization of chunks.

Um, so these like in in my mind are are actually like the two boxes.

Um,

yes. Yes. I'm just drawing it here too. Yeah.

Yeah. and and and I think uh I I I do want to like push on on upstreaming some of these some of these protocol changes, but uh so like you know with the like once the like the get input like in in my mind what what I refer to as get input um once these are done then like moving on to the storage then this is going to be all the fun of you know implementing local storage and indexes and you know all this kind of and just trying to find out what is performance.

Yeah, great, great, great. I'm looking forward to hearing more about this. Um, Antonio, how much more time do I have? Do I have time for a little bit more debu oriented questions on the whole take?

Yes, you too. We can Yeah, we can dive into this if you want.

Okay. So,

yeah, just a couple of minutes. Just this go for it. So basically how I've been thinking about what what both you guys have been doing is on on the one side you have um typical kernel typical pix environment and rust compiling to an ELF binary is it that's right right for MFW

this is my understanding yes

yeah yeah cool okay that's my understanding too and then is a bit different so that that's browser environment not exact I wouldn't call it a posics environment and it's go to wom so What one thing I've I've always been interested in back to the deboot thing is being able to push some some node code in particular B closer to the hardware closer to the firmware. So what one would like to do or what one idea in this space is to push both lib P2P uh and B in and ultralight mode into an EFI module or an EFI program which is those things happen to be programmable executables which is the same format as a Windows.exe exe and there there's not much toolage available in terms of compilers mo the most the only thing I've ever seen work in practice is compiling from C. So, do you guys have any comments about how um yeah, here's the picture. If I would like to create an EFI module, which is a program, it's a computer program.

You just compile it into a EFI, which is same same as.exe. What do you guys have any ideas about routes to get there? So, two two things that are are hurdles is you do not have you will not have garbage collection there. Um, and also maybe even harder to work with is that you have only flat physical memory and no memory management.

I don't know. Do you guys have any comments on this? No is also a valid answer.

Um, well there is a C++ implementation for lip and uh,

right?

I guess um, I'm not sure if C++ compiles to EF5. I guess it should. And um

I think to do that. Yeah.

Yeah. And we or I guess we could rewrite like is not that like huge. It has a bunch of components but they're small if they're separate. And um

right that's that's a good insider knowledge actually. Yeah. That that was one of the kind of big blank spots when I was thinking about okay how much work would this take you so you think li P2P is quite smaller. At least we we don't have to rewrite all of it right. Yeah, like there just there's a lot of components but they're all like isolated and indep it's very modular basically.

You don't have to like you can just Yeah.

Yeah. So, so another thing in in this this this third column the UFI side is um we don't really have a a thread engine there. Uh there's no cooperative multitasking or something like this. Um so does that pose do do you guys see this posing any type of crazy problem? I'm not sure.

I guess for a basic implementation it first could be single threaded then like if there's any issues could be multi-threaded.

Mhm.

And uh there there's time go I I don't remember how it's called this go to EFI compiler but I'm pretty sure since it's an alternative compiler it probably is very limited and like a bunch of things are not available similar to

right. Yes, I think we looked that up.

Yeah, I've never seen it, right? We I heard of that with you and but I guess I I can't say that I've seen it work in practice yet, but I know that Tiana core and like these custom compilers work.

Okay. Okay.

Yeah, probably I guess you could compile lip somehow to EFI and uh like add like this conditional support for EFI target like a build flag.

Mhm. Mhm. Yeah, this has been one one big idea of Chris and I for a long time is we were really interested to try to do this lippp. EFI. Um, okay.

Uh, yeah. And then I guess with with file systems, uh, the canonical choice for using UEFI is to use FA FAT 32. Do you guys envision anything strange there? It is possible to use X2, but you need you need to again use some type of EFI module to be able to read X2.

Well, I think the file system doesn't really matter, right? As long as it's able to

store files.

Okay,

it's fine. Okay, I will I will try to not take any more time, but if you guys have any more comments that were uh got missed, go ahead and say them and I guess Antonio can take over.

Just as an FYI, like Ross does have a UEFI uh compiler target. Um

but this is

but this is uh this is also no standard. And um I imagine like yeah as all the stuff that's been mentioned before um there would be like interesting things around all the async uh interesting things around memory management and and this kind of stuff. Yeah,

thank you. Thank you for that comment. I did not know about the Rust the Rusty UFI. Super. Okay.

Thank you guys.

All right. Thanks and thanks a lot at for leading this nice chat. It's been it's been super cool and Pav and MF for the answer and MFW 78 for the answers. Thank you so much for for this brief brief talk. It's been quite informative and I am pretty sure that it has sparked the imaginations the imagination of the audience.

So thank you guys for being here. uh and uh we would like to take I would like to take over for the last section of the call which is the AMA. For that I would like to uh start with one question. The first question coming from Greg Ross uh where he praises the updates and the progress and the question is the following. Could you elaborate on what what clients arriving actually looks like in practice?

Are we talking about enterprise integration, D apps or specific protocols using swarm? That's one question and the other one it's how does increased usage of the network translate into demand for BCZ at the protocol level. Uh we are the team is focused on building long-term utility but it' be great to understand how to economics tie into this growth. For this question I would like to invite Callum to the stage. There you are.

Hello. Can you hear me, Antonio?

Yes, we can.

Perfect. Yeah. Well, obviously the first question there, but I think uh you've answered it for me is what do we mean by client? So, obviously we've discussed that a lot today. So, that's not what we mean.

I suppose you mean partnerships, bisdev partnerships, what kind of organizations kind of get on boarded um and what's the endeavor that we're basically going through to to get those on on our horizon. So, I'll go back to what I started with in saying in that to get the best partnerships and the best clients, we need to be fast, reliable, competitive, easy to understand and use and performant. We're taking all of those boxes and there's a big uptick in the business development side of the foundation at the minute. So our whole focus has shifted for the first time away from the more heavyduty protocol level engineering to much more usability performance and product orientated lines of work and I think that's very visible and very reflected in what we're doing and that should directly tie into our bisdev efforts in getting partnerships and in getting usage on the network. To answer the latter part of your question basically what does what does that pipeline look like?

What's the kind of emergent behavior? or what are you going to notice um as far as BZ goes, I I think you mentioned are or in the network usage with these partnerships, the more projects that we have that reliably and consistently use us, the more they're purchasing BZZ through the likes of the multi-chain app to run their applications to actually store things and retrieve things on our network. when they're buying that BZ and the buying stamps, that's directly impacting the project and the token price all the time as the ecosystem expands and you will see more traction and more announcements on this in the coming weeks. There's a very clear strategy and very clear partnerships in the works already and I think all of our engineering and product is completely aligned in that direction. And so if there's something more specific you'd like me to to answer on that, please do say and I'm happy to to answer here or follow up if you've got very very specific questions.

But I'm absolutely completely focused in this direction. Hopefully that was a reasonable answer. But again, if you want something more specific, we can drill into anything.

Thanks Callum for this. Yeah, I think it was quite a quite a good answer. If if Greg wants to to come again, just leave it a comment right now. If you're listening or not, you have to you know where where to do where to drop the question. Okay.

Thank you. Now the there's there was another question there. Actually, there has been several questions regarding the token about price. It's going to be part of the new next bull run. Uh so I would would have summed it up in this question.

What is the strategy to grow the token? Does anyone uh can anyone reply during the community call? Okay. And I'm I think I'm going to take this one. So the token is in it's actually in this in in a good shape.

It's being used more than ever. Uh I don't know if you have realized but the initiative that has been showcased here only mean that it will increase its usage which is exactly the point of all this infrastructure usage. Will it be part of the next bull run? Well uh swarm is not built for next for bull runs. It's built to last for the next decades.

And also uh if it's one of the few technologies that it's capable of crossing the chasm towards web two. So it means that we can offer an end toend service abstracting away all the complexities of web 3 because the storage and bandwidth it's a common need in both worlds. That means it can provide a fast and and quick way to on board users from web two into web three without them even realizing it. uh I am not aware of a lot of projects that are in this same position. Most are built primarily for the web native crowd or ecosystem.

So I would say it's in a really really good shape. And that's it. That's all we got for you. Uh now the team in Prague is all now headed to the web three privacy now meetup where Victor will talk about signal on swarm. And for those who are not present in Prague, uh you're welcome to read all about it in a recently published article that I will drop in the state chat over there.

And that's it. I hope that we that you have enjoyed the call today. Thanks you. Thank for thank you the speakers who have been here uh for answering the questions and and taking it over. Thanks.

And thank you of course the audience for being here. Is it see you next month speak freely?