All About Walrus

Recorded: Aug. 15, 2024 Duration: 0:46:19
Space Recording

Full Transcription

Good afternoon or good evening to you wherever you are in the world. Thank you all so much for joining our X-Space where we are going to talk all about walrus. We will get started in just a minute.
Thank you all so much for joining us.
We will get started in just a second. We are getting everything ready to go. We will be talking all about walrus today and get kicked off in just a few seconds.
Hi, everyone. I'm Wayne Cunningham from SWE and welcome to our X-Space. Today we're talking about a very exciting new decentralized storage network from Miston Labs.
Decentralized networks often offer open and resilient environments, letting developers deploy apps and users transact assets. Most blockchains focused on transactions rather than storage.
SWE broke the mold by including a built-in storage fund and capacity, making it feasible to store things like NFT images.
WALRUS is a completely new decentralized storage network filling a crucial need in the blockchain world. Joining me today are George, Carl, Left Harris, and Janet from Miston Labs to explain what WALRUS is and how you can use it.
Thanks, everybody, for joining today. Let's begin with introductions. George, do you want to tell us a little bit about what you do and who you are?
Sure. Hi, Wayne. Hi, everybody. Good day. So I'm George. I'm one of the co-founders of Miston Labs. And my remit within the organization is chief scientist, which means that I oversee all the new stuff, broadly speaking.
We're trying to design and we're trying to improve. And as part of that, I'm part of the team that kind of conceptualized WALRUS and designed it along others in this call.
Great. Thank you, George. Janet, do you want to jump in and tell us a little bit about yourself?
Yeah, absolutely. Good morning, Wayne. Good morning, everyone. My name is Janet Wu. I am on the product team here at Miston Labs.
My area of focus is actually anything relating to a core developer platform and, of course, developer experience.
Great. Thank you, Janet. Carl, let's tell us a little bit about yourself.
Hey, everyone. I'm Carl. I'm a researcher at Miston Labs, and I'm part of the team that designed and developed WALRUS.
Thank you, Carl. Left Harris, your turn.
Hello, everyone. Good morning. Good afternoon. I'm Lefteris. I'm a research scientist at Miston Labs, working in distributed systems.
My expertise in consensus. I'm a co-inventor of Pulshark, Narval, Mysticeti, and super excited to also work on WALRUS.
Great. Thank you, Lefteris. So let's jump right in and talk about what exactly WALRUS is.
George, since you created the thing, can you describe it?
Sure. Yeah. So WALRUS is a security-centralized blob store. So let's double-click on each of these terms, right?
So as a blob store, it allows everybody to upload blobs. These are unstructured files.
They can be pictures. They can be movies. They can be machine learning training data.
Whatever, basically, is a largest, more than a few hundred kilobyte file, up to maybe a gigabyte or more.
And, you know, it's decentralized in that it allows you to store these files across multiple different storage nodes that are not run by a single organization,
but are run by multiple different organizations and people.
And, you know, that allows you to then make sure that it is secure in the sense that even if some of these people fail, some of the storage nodes fail,
the data will still be available. And through cryptographic techniques, you're always sure that the data is what you uploaded when finally, basically, you download it.
So this is, broadly speaking, what WALRUS allows us to do. It allows us to upload blobs. It allows us to download blobs.
It also allows us to prove to third parties that a blob is available. Namely, if I was to try to download it, it would actually download,
which kind of helps with kind of proofs of availability and other kind of needs blockchains have in that space.
George, you mentioned one thing about cryptographic techniques to ensure that the files are the files. Can you drill down on that a little bit?
Sure. So WALRUS offers many kind of security properties. Integrity is one of them, right?
So once you actually have a blob ID, no one can lie to you about what the actual file behind that blob ID is,
or even parts of that file, because that blob ID, in effect, is the result of a bunch of cryptographic hashes that fully commit to that file.
So once you have a blob ID and a file that hashes effectively to that blob ID or encodes and hashes to that blob ID,
you're sure that this is the file the uploader intended.
No one will be able to change a single bit without actually that being detected.
And that also goes for the whole file, but also that goes for some parts of the file that you can read in chunks.
So using that mechanism, it seems like the uploader is the person who owns the blob, the file.
Is that true? Similar to like how somebody owns an object on Suite?
The uploader is the one that defines what the blob ID is. It's a public store.
So to some extent, owning public data is a bit of an elusive concept.
As maybe others will discuss down the line, there is a concept of actually a blob that is on Suite that is associated with a blob ID.
And that allows you to extend the lifetime of a file or maybe delete your version of that file.
But ownership is a difficult concept to fully capture what's going on here.
Great. Thanks for that clarification.
George, I want to ask you a bit about when you first began working on Walrus.
When did you decide it was needed and what motivated its development?
Yeah. So as folks know here, you know, we started designing the Suite network a few years back.
Right. And when we first talked to people about the promise of Suite, we said, look, you know, Suite allows you to store your data on chain.
Right. And what we really meant is that it allows you to store hundreds of kilobytes.
You can do computations on that data. You can store attributes.
You can run complex programs on them, et cetera.
But what a lot of the people we spoke to actually heard is, hey, I will be able to store my pictures on chain.
I'll be able to store like 3D meshes of my games on chain.
Maybe I'll even be able to store my whole app as a as a website on chain.
Right. And the truth is that, you know, Suite by itself can store a lot of data and has a good model for actually pricing it.
But it is still quite expensive to store this kind of bulk data.
Right. Like big pictures, whole websites, et cetera.
So so as soon as basically Suite matured, we're like, let's go back to that problem that we heard lots of people have.
Let's actually build a decentralized system that is specifically geared towards storing and then serving that kind of data.
And this is this is how we started effectively from that need that we heard early on.
Great. Now, if people go to walrus dot X, Y, Z, the walrus site, they'll find a lot of fun animations with the walrus character.
George, how did the name walrus or where did that come from?
Well, as as maybe people who have been following our works know, we we have a kind of aquatic mammal theme for all the systems we build internally.
And walrus seems to be a blobby aquatic mammal.
And since basically walrus is a blob store, we thought it would be a good name to to name it after.
It initially started as a joke, but, you know, the more memes we generated and the more characters we generated that are walrus theme, the more we got attached to it.
So now it has basically stuck with us.
That's great. I love a memeable decentralized storage network.
I want to switch gears here, move a little ahead and go to actually using walrus.
So, Carl, I want to ask you this question.
How would someone go about uploading or retrieving a file from walrus?
Yeah, so essentially there are two different ways of interacting with walrus.
One is sort of the direct interaction with the storage nodes that George mentioned.
So we have this network of storage nodes and we can upload and download files by talking to these storage nodes directly.
So in order to upload it there, a client would first on SWE get a storage resource that then allows storing a file on walrus and then locally encode it and basically chop the file up in small pieces and upload these pieces to the storage nodes who then certify that the blob was stored.
And then for download, essentially, you just ask all the storage nodes to give you back all those little pieces and then you kind of reassemble this locally.
And then the second way of interacting is through what we call a publisher and a cache or aggregator where you sort of rely on an additional party to do some of the work for you.
So you can ask a publisher to upload a file for you and then the publisher will do kind of the encoding and all those things for you.
And similarly, when you download the file, you can ask a cache to get the file for you.
And then the cache, if it has a local copy of the file stored, then it's very fast to return that to you.
And otherwise, it will go back to the walrus storage nodes and again, get the little pieces and assemble them.
And especially for downloading, the kind of main way of using it that we envision is through these caches, because that's generally just more efficient to do.
Yeah. And Carl, I noticed on the walrus hackathon site, which we'll get into the hackathon a little bit later, there is a publisher built into that, a web-based publisher.
But that's really just for DevNet currently? Is that true?
Yeah. So currently, all of walrus is in DevNet.
So currently, everything that we have is the walrus DevNet.
The publisher that's linked on the hackathon site, this is actually even kind of a web-based publisher where you can actually upload the file in the browser.
We also have publishers available where you can programmatically upload files.
But this is something that's probably going to change somewhat for testnet and mainnet, where we have a little bit more customization, probably.
Right. And Carl, in the docs, there's information about setting up your environment and going through the CLI to upload and retrieve files.
Does that also allow file management, like deleting files and that sort of thing?
So currently in DevNet, all blobs are non-deletable.
So basically, you store them and they're stored.
For testnet, we will have the option to delete files.
So this is something that once you upload a file, you decide whether a file should be deletable or not.
The reason for this is that we want to be able to prove availability.
So if a blob is marked as non-deletable, then even the uploader cannot delete it for the period that it's been stored for.
But then for deletable blobs, you'll get an object on SWE that allows extending, deleting and all those things.
Yeah, that can be a good safety measure so nobody accidentally deletes an important file.
And Lefteris, I want to go to you and talk a little bit about how Walrus distributes its data over the network nodes.
I know there's been a lot of solutions in the past, sharding and striping and things like that on the NAS level or in cloud level.
How does this work across the nodes on Walrus?
Yeah, so as Carl mentioned, I'm going to go into the publisher route.
Of course, a client can just do it themselves, but we envision mostly publishers to exist.
So this publisher is going to have a file locally.
And, you know, if we were running SWE, this would be a full node that would just take the data and send it full replication in every single storage node.
But this would mean 100, 200 extra applications.
So this is really not what we want in Walrus.
So instead, in Walrus, we split the data into very small chunks and through an encoding procedure, which is really based on state-of-the-art algorithms in coding theory,
we managed to basically split the file into multiple data chunks in a way that the publisher can send one chunk to every storage node and anyone can retrieve simply by receiving only 34% of those chunks.
And all this happening only at 4.5 times the replication cost.
So basically, this means that each storage node can hold only a tiny part of the data.
And at the same time, the system is going to be extremely resilient.
And, of course, the publisher is also going to run all these cryptographic processes that George described in order to make sure that future readers are going to get the correct file.
And it's also going to be readily available.
LeFaris, I can't hear you.
I'm not sure if other people can.
Can you hear me?
Yeah, I can hear you now.
Did you get my reply or should I?
We heard the reply.
At least I'm not.
And, LeFaris, you mentioned 34% is the number of recoverability.
So what that means is that if a number of nodes go down on the network, you'll still be able to get your files, right?
Yeah, yeah, exactly.
So basically, it means that if the file has been stored and we have gotten these availability proofs that George mentioned,
then even if almost two-thirds of the validators go down, you can still get the file with some exceptions there.
And as a result, it's extremely resilient.
Yeah, that's a great feature of Walrus, being able to make sure that your files are safely stored and you can get them.
So, Carl, I want to go back to you and ask about some of the use cases you see for Walrus.
Yeah, thanks.
So, Walrus is very general.
It can be used basically for anything that needs secure, decentralized storage.
So, in particular, that's really interesting for anything where you really need to be sure that your data remains available.
There are some limitations to this that George also mentioned already, namely the data in the storage is public.
So, if you want to store private data, then you need to protect this by encrypting it before uploading, for example.
In terms of the kind of concrete use cases, I think there are some really obvious cases, such as storing NFTs.
Like, there you really want to be sure that you have availability, basically, as long as people are interested in keeping these NFTs.
Other use cases are, for example, something like cloud storage, like a Dropbox, Google Drive kind of thing.
This would be one of the use cases where you need to encrypt the data before uploading.
But I think there's also a really kind of obvious use case that kind of makes sense.
And then one of the use cases that we've also internally developed within the Walrus team is Walrus Sites, which are websites that are completely hosted on Walrus.
And I think based on this, there's also or there are also a lot of possibilities to kind of build on top of this.
So, one really cool application of Walrus and Walrus Sites that I see would be something like decentralized social networks, like a decentralized version of Facebook X or, you know, any other kind of social network that we're currently using.
And, Carl, when George was talking about blobs, now, that's just a distinct file.
That's not like a collection of files or if a collection, it's got to be something that's, say, zipped or, you know, JSON or something.
So, blobs are essentially any large file.
So, blobs actually, in computer science, stands for binary large object.
So, it's essentially just, you know, a large collection of bits.
In many cases, like for many use cases, this could be images.
But, as George mentioned, also something like training data for AI, things like this, really arbitrary data, basically.
The one kind of limitation that comes, or not necessarily limitation, but what this also means is that it's not like a database.
So, you shouldn't imagine a database where you have kind of small entries that you constantly update.
But it's really, you know, you store large pieces of data and then you retrieve these large pieces of data.
Thanks, Carl.
That's a great clarification.
And quickly, using it as a storage for NFT images.
So, if I have an NFT on SWE, it can refer to that image on Walrus.
Yeah, absolutely.
So, this really, you can basically just include the blob ID, which is this identifier that you get when uploading a blob.
And then that uniquely identifies the file that you uploaded for the NFT and can be retrieved using this again.
Love, Terrace, I want to go to you to ask this question, given that Miston Labs developed SWE, and we've all been a part of that journey.
How does SWE relate to Walrus?
Yeah, thanks.
So, like, if you notice in all the conversations, we are describing always Walrus having those storage nodes, and they get a file and they store it.
But the question is how do they know how to get a file, and that's basically where SWE comes in.
SWE is kind of the brain or the control plane of Walrus that allows for programmable storage resources and handles all the metadata that the storage nodes need to know and download in order to do their job.
And as a result, Walrus can now be data plane, it doesn't need to deal with all these complex decisions that might need consensus because it distributes systems, we just have SWE.
As a result, SWE allows Walrus to be extremely specialized on this one thing of reliably storing data and having some lightning fast performance, right, and because of this very linear architecture, we can really reduce the cost.
So, basically, SWE is the mind of Walrus and the signals, like Walrus is the body.
That makes a lot of sense.
And I can see there'd be a lot of efficiencies gained by using Walrus as the storage layer.
But I understand you can also use a different blockchain to access Walrus as well.
Yes, totally.
Walrus is basically a storage solution.
It just needs to know what to store and there needs to be agreement on what to store.
So, any blockchain could basically be the one signaling this information.
But, of course, with SWE's performance, that's the one you want to use.
Janet, I want to go to you.
Wayne, if you don't mind me jumping here, right, so that we avoid any misunderstandings, right?
I mean, SWE is the control plane for Walrus, but folks from any ecosystem can store their stuff on Walrus and access it through the web, right?
And, in fact, we are very enthused about the fact that we are suddenly, you know, working with other communities, right, that might need to store NFTs, to store proofs of availability, and they could use Walrus to do that.
We're really excited to see what kind of use cases cross-blockchains people come up with.
Great. Thanks for that clarification, George.
Janet, we haven't talked to you yet, so I want to bring you into this discussion.
And can you talk about who should be building on Walrus or who can build on Walrus now?
Yeah, let's talk about that.
I think George alluded to this a little bit already, but like any other protocol, developers is one of our most important audience and usually our earliest audience.
The way Walrus is built, it is chain agnostic in many different dimensions.
So actually any builders from any ecosystem are welcome to build on Walrus.
So whether you're from Polygon, you're from Solana, Avalanche, Cardano, like you name it, right?
Like any other ecosystem, we would like you to come and check out Walrus and see if it actually fits your decentralized storage needs that could not be solved before.
Another thing that I really want to draw attention to is that we would also like to invite Web2 developers to the Walrus ecosystem as well.
If you think about sort of the process and the cost of developing on the blockchain today, it's still quite a high friction endeavor compared to regular Web2.
You know, you have to learn all these new concepts like accounts, ledger, consensus that are just not very widespread.
Usually you have to learn a new programming language.
Everything looks different from chain to chain.
You have to learn to work with auditors.
So, you know, I think for a lot of Web2 devs, it's the actual developer friction is quite real and it just all seems very complicated.
It's very mysterious and it's actually not quite, it's nearly impossible to sort of just try Web2, just try Web3 for a couple hours for a day or two, right?
So it's either you have to really invest yourself or you have to stand on the sideline and just observe.
Now Walrus is actually not quite like that.
It doesn't quite have the same complexities that all the control plane would have.
You know, if you have some storage needs, you've got some data, they are, you know, they are much, much bigger than tens of kilobytes.
Great, come try out Walrus.
You can use JavaScript, regular JSON APIs.
You can back up some data.
And Walrus actually is a really good entry way to start your decentralization journey.
That's a great point because storing data and accessing it is so, you know, fundamental to most computer operations.
We're actually quite excited about that universal appeal Walrus has to all developers alike.
Absolutely.
And Janet, you kind of got onto the subject of cost a little bit and, you know, open this up to everybody here if anybody wants to talk about the cost of storing.
Well, I guess we're not really there yet as far as determining all that stuff.
But I know there's been some discussion about, you know, Walrus being as efficient as a lot of other storage solutions.
But yeah, let's move on from that and talk about how Walrus compares to some other decentralized storage solutions, because there are things out there that people probably want to bring up.
So, Lefteris, can you compare Walrus to things like Filecoin and IPFS or any other storage networks?
Yeah, yeah, totally.
But, well, first I would like to really recognize Protocol Labs and the vision they had when a decade ago they introduced IPFS.
They're really the first to build decentralized storage in Web3.
However, Walrus is a decade later and we have a lot of learnings to apply.
And there is also a lot of science that has happened in between.
And as a result, this gives us kind of an advantage.
So in comparison to IPFS, I would say that Walrus can provide much more guaranteed resilience, meaning that there is an availability proof and you know that you can retrieve your data, even if, as we said, a large chunk of the network is down.
And you also can get a quite good predictability of how fast this is going to happen because you really just need to contact a subset of the nodes.
You don't really have to find exactly where your data sits.
Everyone has a chunk.
On the other hand, Filecoin has been developed a bit more for archival purposes.
A storage in Filecoin is usually provided in bulk.
You need to store gigabytes.
And it's further sealed into what they call sectors in order to provide incentives in miners.
As a result, if you want to download what you've stored on Filecoin and it's not on IPFS, you might need to wait for a very long time, minutes to hours.
In comparison, again, Walrus is very reliable.
Thanks, Lefteris.
I kind of lost it there on the audio for a second.
Hopefully, we got rid of everybody else heard you.
And I want to move on to as we're kind of starting to get towards the end of our time here.
Carl, I want to talk to you about Walrus sites, because I think that's a really interesting use case here and something that a lot of people can easily get into.
So when we talk about Walrus sites, are we serving up standard HTML and how do domain names work?
Yeah, that's a great question.
Yeah, so Walrus sites essentially serves standard HTML plus JavaScript and all these things.
So basically anything that is a static website you can store on Walrus sites.
And the way this works is basically that we have portals that deliver like a small piece of code to your browser.
And then your browser fetches the data from Walrus and then displays it.
And so this means that essentially we have static sites.
There is no real back end.
But you can, of course, connect it with Suite to provide some back end functionality.
So if you want to have some kind of interaction where you update some state based on user input, then you can use Suite for this as well.
And so you get a little bit more than what you just get from some Web2 static website.
For the domain names, there we have quite a nice integration with suite NS.
So the suite name service.
And essentially if you register a domain name on suite NS, then you can point this to the on chain object that kind of represents your Walrus site.
So this is sort of the entry point to the Walrus site that gets served.
And once you point the suite NS name to this, then you can access the Walrus site by using this as a subdomain on one of the portals.
So for example, one of our portals that we currently have for DefNet is walrus.site.
And then if you access docs.walrus.site, this will look up docs on the suite NS.
And then this basically gives you an object ID on suite that then contains the resources like the blob IDs for all the HTML and JavaScript and images and so on that make up the website.
And then this gets served to you.
I really like that integration with suite NS because suite NS gives you your own name of, you know, very much an identity.
And on Web2, if you wanted to do something like that, it's okay.
Register a domain, a separate domain and do this.
And whether that's actually related to you or not is, you know, up in the air.
So this is a great way of personalizing sites.
Can you, Carl, can you speak a little bit towards future development of serving up sites?
I mean, are we looking at maybe getting more dynamic or something like that in the future?
So there's actually not too much that I can speak to there.
So there is, like, for dynamic sites, a lot of the things that happen kind of happen in the backend where you have some database accesses and so on.
And this is something where, you know, for a website without the backend, many things are quite hard to do.
And, of course, this is something where if we can make it easier for developers to integrate with suite to get some more backend functionality in a sense, then this is definitely something that is sort of on the roadmap.
But generally, I wouldn't expect, you know, Walrus sites to be able to do anything that a website can do that has a backend server and can do a lot of computation and database lookups in the backend.
Although I imagine with apps being built on Walrus, we might end up with something like that, which is kind of a segue into my next question here.
And, Carl, I'll ask everybody this one, but, Carl, I want to start with you.
What apps do you want to see built on Walrus?
What are your favorite use cases?
Yeah, that's a good question.
I already mentioned some potential use cases for this.
And I actually think that two of the ones that I mentioned would be really, really cool.
One is kind of decentralized cloud storage.
So kind of like a Google Drive replacement.
And the other is social networks, decentralized social networks, where I could see this as a combination of using SWE for some of the storage.
Like if you have something like Twitter, then it doesn't really make sense to store a 140-byte message on Walrus.
So you might store this on SWE.
But then if you post images, you store this on Walrus and so on.
And this is something where you can then use SWE to kind of coordinate all of this.
And I think these kind of use cases would be really cool.
I'm also really looking forward to just seeing what builders come up with, because I think there's probably a lot of very inventive people.
And I'm excited to see all of the kind of solutions that people come up with.
Great. Thanks, Carl.
George, I want to pose the same question to you when you were developing Walrus.
What apps did you think would be really amazing on this network?
Yeah. So as Carl said, you know, I always wanted to build kind of independent media sites, kind of blogs that are not controlled by a single platform where people can exchange ideas and views and stuff free from censorship.
So I'm always very interested in what folks come up in that space.
And the combination of Walrus and SWE is a great platform for building these things, both for hosting content, but also using SWE and how Walrus interacts natively with SWE.
Building complex kind of like collaborative behavior so that, you know, people can come together and edit and, you know, upvote, downvote, kind of have governance processes and collective editorial lines effectively for some of that independent media.
So that's something very interesting to me.
Generally speaking, both Walrus and SWE are social and shared by default, right?
So they are a platform where you can basically build something and suddenly you natively are just next door to other people who are using this platform, other people's resources, other people's objects.
And yet it's all secure because it's mediated through smart contracts on one side on SWE and cryptographic protections on Walrus.
So I'm really looking forward to, you know, applications that really tap into this kind of like innate sociability, if you want, of these decentralized platforms.
Great. Thanks, George.
Yeah, that collaboration is a great feature or a great fundamental aspect of both SWE and Walrus.
Lifteris, I want to go to you with the same question. What apps are you excited about?
So maybe other than what they already mentioned, I think one app I would love to see is around open sourcing data sets.
Basically, what I've seen is that there is a lot of data sets around and people want to share them, but they don't know how.
And in Walrus, it's quite simple, right? You just upload it. And then if it's valuable, you don't even have to pay forever because someone else can come and support that it's available for everyone.
And then on it, we can create like reputation systems where we can curate better data sets and then people can actually get access to all this big data everywhere instead of having to ask around and only get data if you know someone.
That's a great point for the open source community and not just open source software development, but also open source data, which is a whole other side of that movement.
Janet, I want to go to you on this question as well. What apps are you looking forward to seeing?
Yeah, I think I'm going to take a little bit more of a personal angle to this.
You know, I am a mother of two young children and one of the social issues that actually deeply concerns them, even at their age, is climate change.
You know, they love animals. They're very sad to see all the news and documentaries about sort of wildlife disappearing due to climate effects.
I think, you know, at the personal level, I would actually love to see applications, you know, where people that are working towards this cause.
Like I could see imagine a platform where people are taking photos of kind of endangered animals in different places and kind of help document that trend and have that be preserved forever on walrus.
And I think that's that's very suitable for a platform that is named walrus.
So that would make me very excited. And I think that may actually make my kids proud of me for working on walrus.
Those are great points. And yeah, you know, using it for a social good is a great use case for, you know, not only walrus, but the blockchain in general and SWE.
And Janet, I hope everybody was taking notes here about the favorite use cases, because can you talk about the walrus hackathon?
Yeah, absolutely. So since developers is one of our most important audience, of course, we need to have a hackathon.
You know, this hackathon is very aptly named breaking the ice missing labs is sponsoring a total of $50,000. You know, if you add up all the fine prints for this hackathon.
It starts now, it's been kicked off earlier this week, and it's going to run through the middle of September. So we wanted to make sure that developers have a good five, six, five, six weeks to kind of go through a full engineering sprint.
We explicitly made this a very unbounded hackathon in that there's really no tracks. There's really no very specific themes.
And really any type of applications from whether it's dev tooling, whether to create a platform, whether it's a nonprofit social causes are really all wide open. Right?
So no matter this, I think this will really make it an open and broad hackathon so that builders from different verticals with different backgrounds and different interests, different expertise can all come and have a place in this hackathon.
The website for breaking the ice is actually hosted on warwurst itself. So the URL is actually breaking the ice.warwurst.site. You know, just like Carl mentioned, you can actually use the sweet names, the sweet name service to create a custom URL for your warwurst site to actually qualify for a price.
There is a requirement that you have to create a site on warwurst for your submission, but that's okay. You know, we think that this will really help our developers see the potential of what they can do with warwurst.
They are building their app and then they can actually make a website for it. And this will, we think that this will make the developers feel inspired with these very practical and very approachable examples of how to leverage warwurst in different ways.
And the last thing, you know, I really want to know is that we value early participants in this very young ecosystem, right? Our journey on warwurst has just started. We've just really unveiled warwurst to the world in recent months.
So anybody who joins breaking the ice will be our earliest developers who play a big role in helping us mature and shape this protocol. So we really are looking forward to getting to know the developers from breaking the ice very closely and very personally.
Those are great points. And this hackathon is super exciting. I'm really looking forward to seeing the apps that come from this.
Janet, we're going to wind up here. So any final thoughts about walrus?
Yeah, you know, for me, we really, you know, we're excited about this journey, but we also want to jointly build this protocol with the community, right? So please join our discord.
Please join our social. Please have dialogues with us. We are here. We're ready. We're on standby.
So whether it's questions, whether it's ideas you have for wars, please bring them forward because we're ready for it.
Great. Thanks, Janet. Love Terrace. I want to go to you. Is there anything we didn't cover in this discussion that you want to talk about with walrus?
I just wanted to mention that in general, we built walrus because we really believe in decentralized storage and our main goal here is to get more people using decentralized storage than just getting a few users from another solution.
Because we really believe that we need the transparency of centralized storage. We need the open access. And we really believe that Web3 needs walrus.
Those are great points. Thanks.
Karl, anything that we didn't cover that you'd like to get in?
I don't really have much more to add. I'm just really looking forward to seeing all the cool projects that people come up with in the hackathon.
So really, yeah, really excited to see what what people come up with.
Great. Thanks, Karl. And George, final thoughts and last word.
Yeah. I mean, I don't have much to add besides what everybody has said here.
I mean, to us, walrus like SWE is a work of love.
Largely, we build infrastructures because we're very passionate actually about building decentralized systems and decentralized apps.
And every time we we encounter an infrastructure that we are missing and we wish we had.
Well, that's that's what we're focusing our energy into building it to make our life and other builders lives easier.
So so Walrus is the next step in that journey for for Miston Labs.
And as everybody else said, super excited to see all the things that we have imagined appearing on Walrus,
but also mostly all the things that we could never have possibly imagined being built by by builders and impressing everybody.
Great. Thank you, George, Karl, Lefteris and Janet for explaining Walrus and its exciting opportunities for the Web3 community.
And thank everybody for listening from wherever in the world you are.
I want to urge everybody to visit the Walrus dot XYZ site to take a look and you can get started by joining the discord,
which is linked to there and you can engage in the community.
Also, highly recommend subscribing to the new at Walrus dot, sorry, at Walrus protocol on X to get the latest news about Walrus.
That's our Twitter feed, the X feed on about Walrus.
So again, that's at Walrus protocol.
And finally, if you want to join the hackathon, check out breaking the breaking the ice dot Walrus dot site.
All right. Thanks, everybody.
Thanks a lot, Wayne.
Bye, everybody.
Thanks, Wayne.
Bye, everybody.
Thanks a lot.
Bye, everyone.