Wen DePIN for Explorers?

 Conor Svensson: Hey everyone, I'm Conor Svensson, founder of Webthree Labs and creator of chainlens. this is the first space that we've been hosting as part of chainlens. And we're really pleased to have Reuben here, who's joining us as a guest. Ruben, do you want to tell me a bit more about yourself and what it is that you're working on at the moment?

 Ruben: Hi Conor. Yeah Ruben, I'm the CEO of DB forest. We're a cloud aggregator that is fighting vendor lock in. And when I say cloud aggregator, obviously this includes DePIN projects and we ourselves are a DePIN project, given that we, or rather we just do things a bit different from other DePIN projects in that we focus from day one on reliability. So we have a set of decentralized validators that every time a new provider registers in a network to let's say provide postgres hosting or provide s three, they immediately test this provider to make sure that they're fully compatible with the others and do this on a continuous basis. So yeah, basically a DePIN project that's focused on quality.

 Conor Svensson: Nice. And certainly I think the area of databases, it's one that's probably, there's not been as much activity on compared with some other areas of dePIN. I think the natural, one of the leaders obviously in all of this was IPFs and Filecoin. but we're seeing the breadth of DePIN just grow. There's obviously other projects working on things like gpu, access. There's other types of storage technologies as well there like with I guess with databases. What is it that leaves you feeling so strongly that should be decentralized?

 Ruben: honestly, the biggest point is that there is a low market competition on this one in DePIN and I think that's because you shouldn't decentralize a database. And Yeah, just to be clear, what we're decentralizing is the market and the quality control of the databases. But you know, also for the backend of chainlens, I mean I don't think that you want to run that on top of let's say tableland or glacier or maybe on orbisdb. But most likely you need to have guaranteed performance from a node that you control privately. So yeah, I would say it's because there's a market, everyone needs databases. And I think we have a good take on it.

 Conor Svensson: So if you talk us through the process, people right now when they're looking at a database service, either they'll run it themselves and more generally use a cloud specific database offer where they talk about how much computer, how much storage they need. So what's your vision in terms of with DB Forest, how that would work from their point of view, both from the user's perspective, but then also behind the scenes in terms of what's actually happening within the DB forest network as well?

 Ruben: Yeah. So let's first take the user's perspective. So good user experience is fundamental for anyone to get adoption, which I think is again a thing that many DePIN projects haven't succeeded at so they typically succeed on the supply side, but there's not that much success on the demand side. So what we offer the user right away is an ability to objectively compare providers. We've benchmarked all the providers. They're being benchmarked by independent validators that shouldn't collude amongst each other because there's financial slashing that can happen if you go against the majority as we typically have in consensus, and that immediately is a value prop. So they see a list of all the providers, some they've heard of, others they haven't heard of, they see a price, they see performance and now they can start filtering on what they need. Exactly how many cores, how much disk is it shared, is it okls what compute is underneath all of that with some third party validating the performance. So I think that's good user experience from the beginning. And then one more click and you can deploy.

So one interface where you can deploy to any cloud that's integrated is another thing that a lot of people like. If you know, whenever I ask people would they like to be multi cloud, everyone says yes, because it's resilience. It means you're not dependent on one party. But do they do it? No, because it's a lot of effort. So putting it all into one place is part of the process of reducing the effort needed to be multi cloud resistant.

 Conor Svensson: So in that respect it kind of provides a standardized access point for people to use these postgres services online.

 Ruben: Yes. So the postgres itself is already a great standard, right. You don't only have postgres main branch of the postgres open source project, but you have many compatible databases. So cockroachdb is one gagabyte db. there's many that also Aurora or neon other things that are really cloud and closed source. They can also participate in the network as long as they support the exact same features without compromise. So that when a customer wants to switch aka not getting logged in, they don't have to change any of their SQL code. And yeah Postgres is great for that because it is a standard.

 Conor Svensson: So from the point of view of the users then is it they wouldn't need to know who's actually servicing their demands in that regard? It could be someone running their own postgres service on some service to try and service capacity. That way it could be that the big cloud providers this sort of information is not visible to them.

 Ruben: in our case, it is many people ask for this and maybe we'll end up creating an offering where there's an automated selection of who's currently the cheapest and fastest. but I currently think that it's important to also take into consideration things that are not automatically evaluated. So the biggest one would be the reputation of the company that as you have heard it through the grapevine from your friends. Do you know anyone that's running a production database on neon postgres? Do you know anyone that's running production database on crunchy base or crunchy data on? Yeah this is. it's not like the review count on Amazon.com doesn't matter nearly as much as a trusted person telling you they use this product, right? And so because of that I think the name of the cloud provider needs to be there and it's information that there's no good reason to throw it out.  I think we can keep it there. It's part of the decision process. So we do expose that information and users get to choose.

 Conor Svensson: So I guess there's some parallels with some of the other web3 protocols out there in terms of where there's different groups running infrastructure on behalf of say token holders. I think within eigenlayer for instance, I know that there you've got in effect companies who are running up sets of services for that and then people can delegate their Eigen tokens to them. And I presume it would be a similar sort of model with respect to these different exposed services hosting capacity on the network. And that there's almost like a brand associated with that provider and this trust associated with it.

DBforest provides a value proposition for projects that want their network not on AWS

So as you say, people do want to know about this.

 Ruben: Yeah, definitely. Let me maybe expand some more. You brought up Eigen layer and others running decentralized services. So the beginning product that we're working on is postgres and other services that are like the most widely used that you need. But we also have a value proposition for projects that want their network not to all be on AWS. So the first partnership was with Ceramic and then OrbisDB, which are connected, they're on top of each other and neither of them had by default had a way for a developer to have a one click, deploy an OrbisDB or deploy ceramic because they didn't want their network to be all hosted by them, because then it's kind of pointless, it's not decentralized. And now with us they have the option that in their docs they can have click here, deploy a ceramic or deploy an orbisDb. And then through our interface they see ten different providers that will give them orbisdb. Maybe the top one will be actually managed by the Orbis DB, the company, and then the others will be managed by a bunch of other people. This is in fact what is recommended. So with customers of these products, you tell them, okay, we'll run one node for you, but you have to run at least two others somewhere else. And so because DBforest integrates a bunch of different providers, this is really easy to do and they have a lower risk of their network being only on aws.

 Conor Svensson: And then from the actual I suppose capacity size, I mean presumably with different providers, is there quite a strict kind of base of capacity they need to provide? Because of course as project scale, for instance, they start off with maybe a fairly cheap postgres, with a certain amount of capacity, but it might be over time they need to increase like the amount of IO it supports, they need to increase the amount of computer it has. And presumably there's this cost, real cost though for actually then having to do data migrations if they have to switch to a different provider as their usage grows. So it's the idea that when someone onboards like with DB forest that they'll kind of have a range of capacities that they can support. So is the idea that those customers would generally stay with those providers or is it that they'll, as their needs grow they'd naturally get migrated to a different service ideally?

 Ruben: Validators define the minimum requirements for each product category. And postgres can be multiple. And in fact it is, there are multiple postgres product categories, there's super low latency ones, there's low cost ones where the latency can be larger. in terms of a minimum disk size, we never had the problem because they typically, typically are big enough. but yeah, basically the validators in this protocol are free to set the rules as they please. And this is of course in accordance to what customers want. So if we were to see that providers are putting up postgres that have 100 megabyte in storage, then of course we would set a minimum of some amount of storage that you have to have there in terms of the actual capacity that a provider needs. There isn't a minimum capacity. So they, that's not true. they have to have at least number of available instances as there are number of validators in that product category. So if this product category has ten validators staking it, you must be able to at least simultaneously start ten databases or whatever it is in this case. And yeah, but mostly I would say it's up to the provider to decide how much capacity they're going to put into the network.

 Conor Svensson: Got you. So how far off are we from being able to just turn up and say hey, I'd like to provision a database, right now, this sort of capacity on DB forest.

 Ruben: I mean you can go to app dot dbforest.org right now and deploy. We aren't advertising it publicly, but just last weekend we sponsored eth Warsaw and it was a pretty big success. So there's a faucet set up right now still from Eth Warsaw. So if you go there and sign in with your wallet you can automatically get tokens and gas and deploy a database right now.

 Conor Svensson: Yeah.

 Ruben: so Eth Warsaw was actually great. there are other sponsors, there's worldcoin, there are celo, ah scroll. A lot of big names out there, Starkware. But our team managed to get over 50% of all the submissions in the hackathon had DBforest integrated, which I think was pretty awesome. Well world coin, maybe they're losing popularity, but they had like less than five actual deployments. Yeah, it felt a bit good. Everyone was very happy about the hackathon.

 Conor Svensson: Yeah, absolutely. That's a great start to it, especially when it was the first sort of proper hackathon you guys had sort of positioned DB forest as being like a viable technology for people to build on.

 Ruben: Yeah, I mean it's clearly still in testnet, hence me paying for all the gas. And we have a warning saying you should use this for a dev, not for production. But it was the first hackathon that we sponsored and Yeah, I just want to make a point there to say how great the web3 community is. We started at a hackathon. The first implementation of DB Forest was built at east London just a couple months ago I guess, five months ago. and now, you know we got investment and we're already sponsoring hackathons ourselves so like the money keeps going around. Yeah, I really, everyone's so open to trying new things in the community. It's really great.

 Conor Svensson: Yeah, that's definitely one of the really cool aspects of it.

So like thinking in terms of, you know, where we are with regards to DePIN adoption, more, more broadly because of course, one of the key questions that we want to talk about here is, what are kind of the things that are going to help bring this to a more mainstream audience. Because the proposition that you've outlined and how it works, it makes a lot of sense and certainly you hear it time and time again from big corporates as well as from smaller players that you don't want to have that tight dependence on specific vendors. So it's a very relatable value proposition that you guys have. But say us with Chainlens, we've started a long migration finally onto postgres. but don't get me started on why we weren't there in the first place, but what would need to be in place for someone like us who provision service for networks, like explorer services using a postgres backend to actually utilize the service in production for big customers that say where you've got hundreds of thousands or millions of transactions a day that we're having to process.

 Ruben: Well I really hope that I'm going to be able to convince you to be a customer, let's say within the next three months I'll give myself a target, should be possible! The things that are missing I would say. Well okay, so I'll say for us, and then I'll say in general for deepening because the question was in general, the software right now for us is just moving quickly so we don't want to have production use cases on the platform because we want to be able to ship a lot of features and break things so that's just a decision point. Whenever we make the decision that it's general availability, then we'll start taking production customers.

In terms of DePIN in general, I think there's a number of people, I would say the number one problem is, crypto payments. Almost nobody wants to, actually, nobody that's running a legit business wants to pay with crypto. I wish we would. It's part of the ethos, it's part of why I'm here. I want to pay for my rent in crypto, I want to pay for my food in crypto, I want to pay for my service in crypto. But it's just how it is at the moment. If you have a company, you get investment. You get that investment typically in us dollars, or your customers are paying you in, credit directly. So that's the first thing I found. And it's not just amongst our users. I've talked with many people in the DePIN world that their best customers are always wanting to pay with credit cards or other kinds of fiat transactions. And that might just be a thing we have to wait on. We might just have to keep enabling people. And I, pushing for actually having crypto payments be the mainstream. But then there's also actual technological issues. So, for instance, recurring payments, the most standard postgres you would pay for, would be, let's say $50 a month. So how it works for us currently is that you top up a smart contract that is basically like an escrow on the amount of money that the provider can then withdraw from that. And this works, but the user has to think about topping it up. So that recurring payment, no one has built this yet. Yes, I know there's liquid finance, but that's not really what you want. I've talked with someone at ETh force, actually, that's building this tech. So it further confirms to me that doesn't exist yet. but that basically says credit cards are still, sadly, still easier to make purchases with. so that's one. And second part is, I think, quality control and the age of the reputation. So let's take a cache network. A cache network is cool, and they were quite early on, but because of this, maybe they don't have too much quality control inside of, basically they have none. So you deploy a container to Akash and the service goes down. There's no way for you to get your money back or to have them get slashed. That's not a part of the protocol. and there's a lot of different projects like this and I think it's because they focused on the supply side, they didn't focus on the demand side like my pitch at the beginning. Now I think there's a number of web3 projects that are coming out that are focusing on good stability and user experience on the demand side. I mean I can name a couple. Like there's someone who we're partnering with soon, pandora IO they focus on quality control. They actually aggregate multiple other DePIN projects. Storej Super Stable a project that hasn't released yet, Akave they're basically like a L2 on top of Filecoin but again focusing on demand side, impossible cloud, focusing on an enterprise sales pipeline. It's just I think that the supply side DePIN projects were first to market, were first to grow fast and now we're seeing companies like DB Forest and some of the others that I mentioned that are actually focusing on the supply side and a good user experience. So yeah, it won't be too much longer.

 Conor Svensson: Yes that's cool to hear. And especially in terms of focusing on the UX side of things, it's so important because this whole cycle there's not really been enough of a focus on that part. And certainly I feel like the whole thing of whether the feasibility of being able to pay for tokens, I'm sure we could do a whole space on this. because as you say with credit cards it's great from a business perspective because you know what your outgoing is going to be. And if you bring in the price volatility of crypto assets on top, it can, can make life harder and then there's wage bills and all these other things. And unless your whole company is working using crypto rails for everything and tokens, there's going to be these kinds of areas where regular currencies kind of come in and it's a challenge basically. But I know that we're up on time now and so we'll just do a quick wrap up. But certainly for people who want to learn more about dB forests. Ruben, do you want to share the URL again just for them to hit it up? I'm sure everyone's following dB forest on X, but if you aren't, please do, if you want to share some socials, there Ruben.

 Ruben: Yeah, if anyone wants to try it out, like I said, for true hackers right now we are building up the community. The earlier you are in, obviously, the more you're going to be connected to early rewards and, you want to be on the cutting edge. Dbforest.org dot you can also just search db and forest on google. You'll find it, then you'll find a link to join Discord. We're super active on Discord and if you want to directly try it out, app, dot. Dbforest.org dot. You can just go right ahead. Any questions? Come join our discord and someone will help you very quickly. Yeah. Conor. So thanks so much for having me on your space. And, yeah, look forward to convincing you to be my customer in the future.

 Conor Svensson: Awesome. Yeah. let's see where we are in three months from now. Thanks, Ruben. We'll speak soon. Cheers.