Polywrap: web3 interoperability from any programming language.

This is a full transcript. Listen to the podcast here.

Nathan: So today I have with us, Kevin Ngo, and Jordan Ellis from Polywrap welcome to the podcast.

Jordan: Thanks for having us.

Kevin: Yeah. Thank you, thank you.

Nathan: Jordan is one of the original contributors to Polywrap and Kevin Ngo is the developer relations engineer at Polywrap. Can you gentlemen, start off and give us a little bit of the vision behind the company and how the project was conceived and give us a little overview of who you all are?

Jordan: Yeah, sure thing. The initial intention behind the project is to facilitate better integrations for web3 projects for applications. And the whole need for this comes from our experience building in the web3 space. We found that protocols are continuing to do a lot of the same legwork over and over again so our particular problem that we're solving is the legwork being done around developing SDKs for web3 protocols. And for example, for all your favorite let's say Ethereum smart contract protocols there are JavaScript SDKs, and we find that with this there's lots of problems that exist.

And so we can talk a bit more about that, but our main driving mission is to create this next generation SDK development experience so that you can not only support applications outside the browser and, also including the browser of course, but allow you to enable lots of other cool functionality that is not possible today with JavaScript SDKs.

Nathan: Now I've been in the space for a little while, as I'm sure you guys have, and there's been a lot of interoperability working groups and development shops. Can you go into the specifics of what makes your background critical to the development of this industry?

Jordan: Yeah, certainly. So speaking just for myself I had been thinking about this problem ever since I joined the web3 space. Where I come from is from a game development and also operating systems background. And I was particularly interested in really efficient toolchains for creators and for the game industry, and then also for multi-platform support so that you can build once and use it everywhere.

And so this applies itself very well to this problem that we're discussing because in the web3 space there's a lot of friction in between smart contracts and the applications that integrate them. So that's like the efficient integration plans. That I was referring to. And then additionally we currently only see web3, really being used in-browser based applications. And so it's not very multi-platform today. And so that's the the build once and use everywhere problem that I was discussing previously.

And so for myself I saw this very much so when I first joined the space and I was thinking of ways to solve it. I wanted to gain more experience.

So myself and other colleagues at the dOrg development shop over the past years we've been working with lots of web3 startups, helping them build different solutions that that they were requiring, and through doing so we realized that, yes, this is a major problem that's hindering these startups, and then additionally we found a way to solve it with the solution that Polywrap presents today. And soon after finding that magic bullet we built it at the hackathon a year ago, and then we spun up the DAO, I think seven months ago. And yeah that's where we are today.

Kevin: Thinking a little bit my background I was working on developer tools for React, then earlier this year, I became very excited about the crypto industry. I learned about polywrap through a job posting and just spoke with the team and became really excited from their background at dOrg, working on some of the major projects in web3 today. And so I chose to be a dev relations engineer, I always liked a role that's half technical and, but also half dealing with people. And in this role I'm working with a lot of our launch partners like Gnosis and WalletConnect to see how they could integrate Polywrapping to there.

Nathan: Oh, wonderful. Thanks for that clarification. Do you want to talk about the DAO? Can you explain to the listeners how you formed it, and what jurisdiction, and I think a lot of people are trying to figure out how to replicate or even just build a DAO. I'd love to hear about that.

Jordan: Yeah, definitely. We had a lot of experience starting up different DAOs in the past for client projects and we formulated an approach for this project that we thought suited it well.

First off it's not itself like an organization that has a jurisdiction. So it doesn't have a legal entity in any state. And so instead it is a combination of many different entities that are coming together in this kind of a neutral organization, which we call the Polywrap DAO and we purely just have a governance token currently.

And the aim of this Polywrap DAO is to steward the development of the toolchain and the eclipse. And so we, spun it up on Aragon. We did an initial fundraiser, which you can read about on our blog. And that's been funding all of the developers working on the project over this past eight months now, like seven to eight months.

And we have members of the DAO that are, not only the funders, but also the early contributors we call those kind of like the pre-seed builders. And then we also, as we build this project over the course of 2021 which is like what our current roadmap is set up for. And we're currently building a future roadmap So over the course of 2021, we're issuing out our what we call our dev mining allocation.

So it's basically a set of governance tokens that we're issuing to builders, along with the stable coins, they earn to to basically seed out the governance to the people, actually building the project along with the initial team of let's say like 10 people. And so it's like a gradual decentralization approach where we started off with the founding team and set up a set of funders.

And then we're expanding that set of governance holders to all the builders working on the project. And we want to continue with this approach going forward because the goal of this is to be an organization that governs a toolchain that is open, free software. That lots of people are, we hope will be dependent upon.

And we really want this to be user owned infrastructure, as much as possible. And so that's where the gradual increasing the set of token holders come from.

Nathan: So w when you survey the landscape of foundations, the ETH Foundation, the web3 foundation the Algorand Foundation, why did you guys choose to issue tokens in the States without a foundation or without any legal entity.

Jordan: Yeah, so we, we're not just doing this in the United States, it's all over the world. And yeah and the reason is because we view this more as a cooperative where these different interested parties can come together and co govern what, what happens and in the future, we may choose to spin up a Foundation, let's say for some legal reasons, but based on the legal counsel that we had this was the lightest weight and best approach to go do.

Nathan: Do you want to give a plug to the counsel who was the counsel that you guys use?

Jordan: Yeah yeah. We worked with a lawyer who was previously, or I actually, I think currently works at the Tezos Foundation. And so he was very familiar with crypto law and how the foundation model worked. And yeah we chose to go with this route.

Kevin: Yeah. And just adding on a little bit to what Jordan's saying, like having a DAO is very low. friction for us. So we can onboard very high, talented contributed very quickly. We have dev shops that have started basically the next day. And they're, motivated because they're working flexibly as contractors, but they also get a stake in the DAO itself. And yeah. I think that's a good reason for why we started as a DAO.

Nathan: So the only legal entity is really the sort of GitHub link that people use to make posts and make pull requests?

Jordan: Yeah, so it's the DAO is a collection of other organizations. And so each party that is involved in the project has their own legal personhood.

Nathan: So then the DAO is just a bunch of personal LLCs or people actually just accepting that risk themselves rather than an entity.

Jordan: Yeah, it's a personal LLCs and then also also organizations like for example, we have a few different development shops that are, getting paid through the DAO, dOrg is one of them. There's also a development shop called Node Factory. And then another one called Consider It Done. And then in addition to that the funders all have their own organizations as well. And yeah, it's a collection of different organizations just coming together to basically co-fund something and and co-govern it in the future. It's strictly just to see this project take off because all the parties are interested in the advancements that it brings to the space.

Nathan: So walk us through that a little bit. Let's say the DAO evaporates, like how does the toolchain stick around and how do people keep using the toolchain if the DAO somehow evaporates?

Jordan: Just as all other software lives on the internet our code is all open source and if something, let's say were to happen to the DAO, let's say our plan with, furthering the decentralization of governance leads it down, like a path that we didn't intend, and since all this, source code is openly available, if there was a body of users that wanted to use it, they could, fork it create their own their own organizations to steward it. Yeah there's really nothing that links the success of the toolchain to the success of the DAO's governance.

But merely I think that the the DAO was just a coordination mechanism to try and help the stewarding of this of the toolchain.

Nathan: It's really interesting. I know we'll get into the tech stack, but I'm fascinated with this as well. Is there another example, like an analogous example?

Jordan: No, I don't think so. But I think that if you think of like early developer communities that have spun up over the years, so for example, let's say Linux or yeah, I think that Linux is a great example because It was started very grassroots. There, there were a few initial contributors. They would collaborate over Git but the governance of the project was all pretty centralized. Cause there was like a central like route to the project. And then additionally, as specifications were created, there was no way to like co-govern these things. And so what ended up happening is there was a fracturing of organizations that had spun off of the initial Linux software code base.

And so this is why today, like you see lots and lots of different distributions of Linux. And so I think that one of the problems that we're trying to solve is that fracturing problem, where we can bring people together that are interested in this project and we can allow them to have stake in the governance of the toolchain and the specification. And this way we can try and balance balance people's needs of what they're looking for from the standard. And the same way, let's say you have a standards body for browser standards.

And so that's like another example you could think about kinda like the browser wars between Internet Explorer, trying to write their own and be a player at the table, versus the Chromium team building the Chrome browser. And today, it all has consolidated to the Chrome standard and it's hard to actually get a say at the table of what goes on there as an organization who was using it. And yeah we're trying to solve that problem with this project so that let's say tomorrow, somebody says, "Hey, we really want to use Polywrap, it's a cornerstone of our technology solution, we want to become a member of the DAO." They could make a proposal to let's say gain governance rights maybe in exchange for maybe some of their token or just, an exchange for, let's say more funding or something like that. So it allows you to have an openly governed thing that that can try and balance the interests of all interested parties and limit the need for hard forking.

Nathan: That's that's a brilliant analogy into the Linux group, but the Linux foundation is actually a foundation. But they probably weren't initially started as a Linux foundation. They were just a group of devs.

Jordan: Yeah. And I think that, the process for how to get involved in the Linux foundation may not be as easy as something as like a token holder governed DAO.

Nathan: Yeah, I'd love to understand that a little bit. Can you can go in and discuss, like what's the best way to get started creating Polywrap rappers and I guess you call them Polywrappers?

Jordan: Yeah. So Kevin here actually did a ton of great work working on our documentation. And so we have a website https://docs.polywrap.io/ . You can visit that to get an intro to the project which we'd love to walk you through a bit today so that you can actually understand like what we're talking about and why this project is exciting. Kevin would you like to add anything?

Kevin: No. Just from a contributor standpoint, like if you want to contribute and build Polywrappers, join the discord and intro yourself. And we can explain the project to you and walk you through the docs and then help you get started.

Nathan: Awesome. Can you give us some promising you key use cases and some examples of some partnerships who are excited to use it?

Jordan: I just wanted to add one quick thing. Anything you can build with JavaScript today, the idea is that you can build this with a Polywrapper and it's going to have all the benefits of what Polywrappers can do. And we can describe that a bit. So the possibilities are really limitless, but I'll allow Kevin to speak on like some of the exact use cases that we're working on.

Kevin: Yeah. One of our most exciting use cases has been working with the Uniswap grants. So we received a grant for building the Uniswap Polywrapper.

And what we did with that is we built the business logic of Uniswap. So all the swap functions and we put it into this Polywrapper deployed to a decentralized endpoint, which is IPFS in this case. And we took the Uniswap interface, forked it, and replaced all their installed JavaScript as the case with Polywrappers.

What that means is like when the Uniswap interfaces launches, it's able to query the functions exposed by these Polywrappers the Uniswap Polywrapper, and it's able to use that at runtime. So that's the kind of advantages that we can get into. Yeah that's one huge use cases that we were able to do in the past few months.

Nathan: So let's go over that. Why specifically, were you interested in doing in compiling those function calls?

Jordan: It's not compiling them at runtime, it's just fetching them at runtime. The idea was to recreate the type of usability you have when building a web2 application. For example, you want to integrate Stripe's API or Twitter's API.

All you have to do is send a HTTP request to their endpoint to try and initiate a payment or to make a post. And in the world of Polywrap, what we wanted to do was allow you to simply say, I want to execute a swap on Uniswap and just send that query to the decentralized endpoint, which is in an ENS address, let's say, for example, which then resolves to an IPFS package. And so that IPFS package, it contains the WebAssembly code. So we're getting a bit into the details here, but the WebAssembly code contains all of your business logic, and that gets downloaded into your application and executed at runtime.

And so what this means for developers, if you're an app developer, what this means is that all you need to add to your application is the Polywrap client, it's just a simple JavaScript package you can add to your JavaScript app or in the future, let's say a Rust crate you can add to your Rust project and you can use that client to query any Polywrap that exists on the decentralized web. And so it allows you to use anything at run time and it doesn't bloat your application. So you can theoretically have an infinite number of web3 integrations into your application without having to bundle them all in to your app.

Nathan: That is super cool. So when you guys consider this, like what do you imagine in your infinite string of a web3 API calls that currently don't exist?

Jordan: Yeah. Thinking of all of the SDKs that exist today for web3, let's say for IPFS, they have SDKs for Ethereum, all the different smart contract protocols that exist today.

And so we expect all of those, some of them already exist as Polywrappers, and this would allow them to be used in any language. It allows them to be, fetched at runtime, so your applications can remain lightweight. A quick note on that is that this whole lightweight application thing is very important for not only like memory-constrained devices like IOT devices, but it's also important for composability and aggregation.

In web3, the whole idea is that it's an open field of innovation that can be extended upon into the future. And if you think about the DeFi aggregators that exist today, this allows them to more easily do what they're doing inside of their app. And, potentially like through the use of standard interfaces do so without having to rebuild their application.

So tomorrow when a new swapping protocol gets released or when a new staking protocol gets released the application could automatically and dynamically show those. So it, it in the same way that money Legos works on the blockchain where you have open extendability, we're bringing that same sort of extendability to the applications that display these protocols.

Nathan: Got it. Can you give me some examples of what you've considered as you're building these? Like I know there are DeFi aggregators, but what about where do you see them when they implement the Polywrappers? What do those products look like?

Kevin: So potentially if you integrated like the Uniswap Polywrapper with the Maker Polywrapper and execute a swap in your Dapp that you're building, and then take that as collateral and mint DAI with it, all using Polywrappers. That's one use case that comes up.

Jordan: Yeah. And another kind of interesting use cases thinking about extendable protocols. So let's think about a DAO protocol with different types of voting machines. You could make it so that your application automatically shows all of the new voting machines that get published to your marketplace and users can just choose them inside of the app and use them at will. And because it's all functioning off of these dynamic SDKs that get downloaded, there's no need to rebuild your application.

You deploy your application once using these standard Polywrap interfaces. And then it can automatically show all of the new functionality that gets published to the chain.

Nathan: That's super cool.

Jordan: Yeah. And one more note on that, not just for user-facing applications, but this is very important for nodes. There's a really great protocol that I got released recently called called ceramic. It was a spin out from the 3box team and it's all about decentralized data schemas.

And so schemas is for, let's say your profile or for let's say your different addresses on different blockchains and they built it in such a way where these ceramic nodes can have different extensions added. They call them streams so different stream types. And currently today, if you wanted to add a new stream type, you would have to add the JavaScript files to their node their nodes code base, and then all the nodes would have to update themselves in order to support this new stream type. But if in the future they chose to, nodes could dynamically fetch different stream type Polywrappers for handling these different types of documents. And so the nodes don't have to, upgrade themselves and redeploy themselves, they can simply just persistently run. And then as soon as a new stream handler gets deployed, they'd be able to use it. And so users would be able to use these nodes with this new type that got added. So yeah it's really important for the like building of nodes that are future-proof.

Nathan: Interesting. And where do you see this fit into the currently existing sort of bridges in the blockchain ecosystem? Like the Avalanche-Ethereum bridge, then there's Cosmos itself, being at the bridge of bridges. Where do you see this fitting into that ecosystem?

Jordan: Yeah, that's a really great point. So when you think about how a bridge works there are the smart contracts that live on the two different blockchains that you're bridging in between. And then there is the logic inside of the bridge node that knows how to handle requests and process them. And currently, our solution would basically give new capabilities to this node.

And again it would allow it to handle new types of bridges that get released. If you built a node for bridging in between xDAI and Ethereum and it used to Polywrapper and that Polywrapper had this like standard interface, you could publish a new bridge, let's say for Ethereum to polygon and these these kinds of like Polywrapper enabled bridge nodes could then just automatically fetch that and now use that inside of themselves without having to be redeployed. So yeah, like this kind of extendability when it comes to like dynamically fetching things, can be used in any place where you want to have lots of support for lots of different things. And you're not sure what new support you'll need in the future.

Nathan: So if you're moving assets between two chains, can you do that with a Polywrapper?

Jordan: Yeah, definitely. It's, it's important to remember that it's just arbitrary code that's executing inside of your app. So anything you can do with JavaScript, anything you can do with Go, Rust, any other programming language you can do it inside of a Polywrapper.

Nathan: That's interesting. But it sounds like from reading the website, that it's mostly focused on dev tools rather than the sort of interoperability jargon that we see in other ecosystems.

Jordan: Yeah. I think that it's just where we live in the stack. So it's the same way when you visit, let's say JavaScript's website they don't necessarily say build awesome NodeJS applications, right? JavaScript is a language, NodeJS is a platform for building multi-platform JavaScript applications, and then also backend services.

To answer your question where we live in the stack, we don't necessarily want to say, "Hey, use Polywrap for this specific use case." We obviously some have some ideas of what those use cases are, but that's up to our launch partners. Like we said, we're working with lots of great partners the team at Gelato, Gnosis, Fleek, WalletConnect, they all have different use cases that, some are really interested in this chain, interoperability, some are interested in the multi-platform support, they all have different interests of why Polywrap makes sense for them. And yeah, on our website, we highlight our key benefits, but we don't necessarily say, "Hey, we're a solution for bridging between blockchains," because that is a project on top of Polywrap.

Nathan: Interesting. Got it. And can you go into how people create plugins and can they be open source and what happens if plugins get deprecated? Can you go into the plugin idea within Polywrap?

Jordan: Yeah. So plug-ins is the terminology we use for using an existing SDK. So think of like an existing JavaScript SDK. We know that it's impossible to, rewrite the world of JavaScript SDKs in WebAssembly for both practical reasons and also technical reasons. And so there are still going to need to be some JavaScript packages that are used alongside the Polywrap client. As well as let's say, you're using the Polywrap client in Rust or in C#, there's native Rust or C# packages, you would want to be able to use with your Polywrappers.

And so plugins allow you to take these SDKs that live in the language of the client, so they live like in the clients host environment, and you can plug them in as if they were a WebAssembly based Polywrapper. And so it really just creates a little shim between the SDK and the client. And this allows WebAssembly to call into JavaScript let's and then, the other way around as well for these plugins and Java script to call into WebAssembly modules.

And so currently today we use plugins for things that are needed inside of the host environment. So things like networking for like HTTP and websockets and things like that. And then also things like signing with a private key for a blockchain let's say, so having a blockchain provider added into a blockchain provider. It allows you to add hosts capabilities to your Polywrap client to do things that the web assembly code may not do. And then additionally, it just helps you move faster because you may not want to rewrite something in WebAssembly. You can just use a plugin for it.

Nathan: And how many plugins currently exist? Are you guys incentivizing the plugin ecosystem through the DAO?

Jordan: Yeah, so it's important to note that like plugins are a subset, like it's plugins are not the superior way to go. It's kinda just a It's a solution to a problem, but Polywrapper is like the ideal solution that, we've created. We hope that, in the future and we're already moving towards those goals, that all of the logic for interacting with Ethereum, all the logic for interacting with IPFS and, Uniswap, all of that lives in WebAssembly, cause that's the ideal case. But for things that we can't necessarily do in WebAssembly, send HTTP requests, that lives in a plugin.

And then to answer your question of like, how are we incentivizing the creation of Polywrappers? We are currently doing this within our team and then other teams outside of the main core developers.

First off the core devs, we focus on high priority Polywrappers. And so we, we started with IPFS, ENS and Ethereum. And we also got a grant from Uniswap to build the Uniswap. And then in addition to that, we're working with other teams that are outside of the core development team to build other high priority use cases.

So like for example, like we're talking with Nathan here and his team for creating a Tezos Polywrapper. And then additionally we're talking with a few other teams for example we're talking with ChainSafe to see if they were interested in building a Polkadot Polywrapper that could be used with a substrate based chains.

And how do we incentivize this? The DAO has governance tokens. Yeah. It can give to these teams that build these Polywrappers. And so it, it just goes along with the ethos of, if you're building on Polywrap building these cool Polywrapers, we want to give you governance tokens because you have become developers of the project and you should be able to help govern the project as such.

Nathan: Awesome. Yeah. I'm excited to see ChainSafe takeoff. They've done some great work and we'd obviously love to integrate with Tezos. So that, yeah, that's exciting to hear that there are other folks working alongside us. Can you talk a bit about. Inside of plugins. Can you talk about can anyone publish them or like, how are they vetted? What happens if a bug is found in a plugin?

Jordan: Yeah. Or are you referring to, JavaScript based plugins or are you referring to Polywrappers? Written in WebAssembly?

Nathan: Let's run through both.

Jordan: Okay. So with plugins, as I said, in the case of JavaScript applications it's just a JavaScript package. The same way you would publish an NPM package you can publish an NPM package that is a Polywrap plugin. So nothing really changes there. And then as far as security and deprecation and all that stuff goes, the same rules apply there.

JavaScript is not the most secure. If one of your dependencies is compromised, it can really mess with your application and expose the user to hacks. And there's nothing we can really do there. But if you build it as a Polywrapper, which is built using WebAssembly those are actually executed in a secure environment, so those are secure packages. They can't access your application. And so you do get a enormous security benefits if you build it as a Polywrapper, as opposed to a plugin anyone can publish them, anyone who can upload files to IPFS or pin things to their ENS domain can do that to, store and name a Polywrapper. And then in order to make the concept of, deprecating functionality more easy for Polywrap developers, we're building a a Polywrap registry. And so you can think of this as similar to NPM for JavaScript packages, where you can publish different versions of your packages.

We're doing the same thing for polywrappers. And we're currently developing this now. And the idea is that you can one have them all, in a central registry, so you can search through it see what all the different factors are. And then two, we can give stronger guarantees for backwards compatibility, when you upgrade a package to a different version let's say. And so this allows you to ensure that your dependencies don't break in the future. If they publish a new version that changes the scheme on or something like that, or they, remove a function that you were dependent upon.

And we can talk more about how that actually works if you'd like, but yeah we're trying to build a much better version of NPM tailored towards the Polywrap ecosystem to help with the versioning and compatibility problems.

Nathan: Oh that's really cool. Wait, where where are you guys in the roadmap of that development?

Yeah. So we, have a really talented developer working on this. His name is Yuri. He joined the DAO I think three months ago he has been doing amazing work. And I've been collaborating with him because this had been an idea in my brain for awhile, that I had very like minimally fleshed out and he's taken it and ran with it.

So where we're at or where he has brought this so far, is that we have a completed spec. It looks really great. We are planning for an initial integration with ENS. So if you have an ENS domain, you can convert them into a Polywrap registry domain, and we have the initial contracts are written out for the version registry and what we're working on now is the addition of a Oracle solution to ensure that backwards compatibility is able to be enforced.

If you're familiar with how semantic versioning works for packages for example, 1.1.1 is an example of version number. If you change that version to 1.1.2, just doing a patch upgrade with that third number, we want to make sure that you don't actually change the schema for example, so that, that way you don't break users because patches should never change the interface. And so that's something that we're using the Oracle network for is to basically enforce the semantic version and guarantees that you should have.

That's great. That, that's really interesting. We have, do you guys have just one main dev working on it, or how do you imagine scaling.

Jordan: Yeah myself and Yuri have been collaborating on it, but he has been driving it. It's really not too much. A lot of the work comes into play with spec'ing it out.

But then when it comes to the implementation of the contracts it's straight forward. Cause it's just like a simple registry contract with a few additions on top. And then, we're definitely building on the shoulders of giants. In order for our Oracle solution we are using some existing solutions that are already out there, like for example, reading xDAI so that Oracles can they basically vote on proposals in a very very gas efficient way.

And also, like we're still we've looked at lots of different layer, two solutions out there. But currently we're looking at xDAI. And yeah it's not too much work, but we would like to scale this up in the future. The scope actually isn't that big it sounds like it's something big, but it's really not that, that rough, it's just a registry contract, a simple voting contract. And then you write like a node to fetch and validate packages.

Nathan: That's awesome. I thought it would be a much larger infrastructure. Let's talk about folks who are already node operators and those who are familiar with running staking nodes. Do you imagine that those people will be drawn to run the Polywrap node of sorts to become like a relayer in between chains. What's your thought on that?

Jordan: Yeah. Yeah, this is great that we're talking about this, cause this is a path that we're looking at moving into, but it's very unknown right now. So a big reason of why the scope is low is because our solution for the node I was talking about for verifying package upgrades, we're planning to just use a simple set of validators that are whitelisted.

So we're not going to be doing this as like a public network yet. But we're very interested in moving in that direction. And yeah we're interested in potentially using nodes to validate packages in the registry. Like I had said also, participate in source code verification, which is another piece to our puzzle that we're planning on initially doing with a set number of of waitlist validators.

And then thirdly, we're looking into solutions for persisting packages on IPFS, let's say. And so that, that way you can pay on chain, for example, you, you publish your Polywrapper to the registry and then you pay, for a year lease maybe you pay an ether or something.

And the nodes would basically make sure that it's kept online. We're looking into potentially using Pocket Network for this. There are another one of our launch partners and they've talked about wanting to support IPFS pinning with their nodes. And I think that sounds like a great idea.

So yeah there's a few things here that we may end up doing with a Polywrap node, but there's lots of solutions that already exist out there. We're definitely not trying to roll our own if we don't have.

Nathan: That's cool. I didn't realize that pocket was doing that sort of work. But that sounds like a really interesting pivot for not only for node providers, but also for people who want the larger business of verification.

Jordan: Yeah, definitely. Another group that we've talked to was the the radical team.

And they're very interested in this concept of a repository for packages and also for CICD or workflows that can run on radical repositories. And they're also interested to see what solutions we come up with for our own versioning registry to see if we can potentially collaborate there.

Yeah there's definitely lots of web3 infrastructure related projects that are either doing something that we would love to use or interested in something that, we're starting to tackle ourselves first.

Nathan: This has been great. Do you want to run over anything else for the listeners?

Kevin: Just one big project that's on our roadmap, which is the Polywrap hub. And this is just a really nice UI for people to come and explore different Polywrappers that have been made and deployed already. And also try them on the spot using the Polywrap hub. And yeah, they can deploy, they can test it out all in the same spot.

Nathan: Great. And just once again, give us the links that work. We'll obviously share them in the show notes, but give us the places that you want people to go. So that's the Discord and the GitHub?

Kevin: Yeah, definitely. We're trying to build out the community. So the priority is try and join the Discord and then coming and introducing yourselves, regardless of whether, you're a developer or a biz dev person or an artist we want to talk to you. So we'll share the link to the recording.

Jordan: Yeah. And it's our website is polywrap.io. So feel free to go there and you can find everything there. Polywrap.io.

Nathan: Great. Kevin, Jordan, thank you so much for your time, I appreciate you coming on the show.

Kevin: Yeah. Thank you.