ZeroDB

I'm McLane Wilkinson. I'm Michael Diborov and you're listening to the Changelog. Welcome back everyone. This is the Change Vlog.

I'm your host, Adam Stikoviak. This is episode 190 and on today's show, Jared and I are joined by McLean Wilkinson and Michael Egarov, the guys behind Zero DB, an end to end encrypted database and Allstate protocol. We talk about lights up and source, how it's different from other encryption techniques if there's a performance hit for running encrypted queries. We also talk about the business side of this thing and also interesting topic all itself, proxy RE encryption and so much more.

Free sponsors we have on this show today were Codeship, TopTAO and DigitalOcean. Our first sponsor is Codeship. If it works with Docker, it works with Codeship. For those out there with established Docker workflows or those looking to leverage native Docker support while automating your testing and deployment, check out Codeship's new docker [email protected] changelog and for those looking for great resources to automate your development workflows with Docker, you should download Codeship's free ebook covering why consistent environments are so important, how a company lost $400 million in 45 minutes due to inconsistent environments, and also how to build an app to run inside an isolated Docker container.

Head to codeship.com changelot to check out Codeship's new Docker platform and head to resources.codeship.comebooks to download that free book I mentioned on automating your development workflows with Docker. And now onto the show. All right, we're back today talking about zero DB with McClain Wilkeson and Michael Egrov. Talk about an end to end encrypted database.

Also a protocol. Dive deep into that. Got Jared here as well. McLean, Michael, welcome to the show.

Thanks guys. Just excited to be on here. I guess maybe the best way since we have two guests on the show today. Jared, let's kick off real quick with some quick introduction.

So just to kind of pinpoint voices. I know when listeners listen to any podcast, there's more than a couple voices. It's hard to kind of put a name or who's speaking to it. So we'll go with you first.

So give an introduction to who you are and what you do with zero db. Sure. So again, I'm Clint Wilkinson, one of the Co founders of ZeroDB Software Engineering. Also do business stuff now that we're an official company@zerodb, have a background both in software engineering as well as more traditional finance.

Worked in investment banking for a few years and has a positive conversion from that. And during that time covering tech, media and telecom companies before getting into startups. Awesome. And Mike, what about you?

Yeah, so I'm a software engineer and basically I'm the guy behind the tech here, even though McLean is also working with its own tech in our company. And I also have a physics background and how this got on our radar. So I think Jared, we chime in here on this because I thought this is kind of interesting before I recall Jared and I have some sort of sync up, right, to think about, like what's this showing you about who's on the show? What's their background?

And Jared said to me, I don't have a radar, Jim. What did I say? I kind of stuttered a little bit. I had no idea.

But yeah, you didn't know. You were like. Well, we had to backtrack a bit. It was December.

I know that. Yeah. I'm guess Hacker news. No, you would think Hacker news.

Now this is how cool we are. This is a slight pat on the back to us because we've been trying, right. So we have this email called Change All Nightly. And that email goes out every single night.

It's essentially top new repositories, top story repositories every single day from GitHub. And that hit Change All Nightly. Your repo would Open Source on December 7 and so that hit the top news repos. And then the very next day, December 8, jumped to top star repositories and then days after that, kept training for several days.

And that's how we discovered you. And gotcha almost immediately. I was like, this is gonna be pretty interesting because it's obviously, you know, encryption database related. Sent you a, sent you a tweet the very next day on December 7th.

And second. Congressional launch was catching on the show sometime soon, so took about a month. You know, we're after the New year, we're here in the New year finally. And so now we haven't shown.

That's kind of how this hit our radar. Gotcha. Yeah. When we open sourced it in the beginning of December, we had a little bit of a positive feedback loop or follow effect there for a little while because I guess it caught some people's attention, got a bunch of stars and then it hit the GitHub trending page and once you get there, sort of it feeds on itself for a while.

So we had a nice little ride there for a few weeks. Yeah. Jared, you want to mention anything about Gentle Nightly? I love it.

We love it. I mean the fact that it's our own radar. Yeah. I mean there's no secret to how we find awesome stuff.

Stuff that we put in change on weekly clear ends up on the show is 10pm U.S. central. What's interesting, I'll get them for the day. And like you said, certain things pop into that new repositories list and they pop in, they pop out, never see them again.

And then other things will pop into that list and then you'll find them in the bigger global list of top stars altogether. And yeah, you can start to see what is trending, what's interesting and what's worth clicking through and checking out. Well, that's a good example of dog food, I guess. Well, I want to mention that top of the show mostly because of the discussion that Jared and I had earlier.

Like normally we don't come on the show and make it about us but I thought just for a second we can talk about that simply because it was literally from our own dog food that we use that metaphor that we found out about zero DB and immediately we should get the guys have on the show. Um, but let's, let's dive deeper into some, some better interesting things. By the way, if you want to subscribe, it's a good transition. ShaneFall.com Knightley Go subscribe that every single night.

But let's dive in I guess to the topic of how you guys got started. Obviously we've dive deep into zero DB databases encryption later in the show but let's find out where you came from. How did I guess you two meet? What was your background?

Seem to cross a bit in terms of you know, tech and financial and things you've mentioned but how much you guys need. Yes, we're go back a little ways and actually even before jdb we're doing a lot of blockchain cryptocurrency stuff. Sort of the intersection of our respective backgrounds. We actually first met at a at the SF San Francisco Bitcoin Users Group and so we met there, sort of hacked on a bunch of different bitcoin cryptocurrency blockchain related stuff for a while and that was sort of the initial meeting and overlap with interest and out of that process sort of we had inspiration for Zuri DB after many different experiments.

You guys still attend that meetup, that bitcoin meetup? We do, yeah. Actually we are not in Silicon Valley at the moment for the next couple months. We're in London for some reason.

Clint, you got real soft there. Did you back up the mic? I'm soft? Yeah.

Did you step away, did you move away or something like that? No, I'm actually pretty close. Is it still bad now? You sound okay now that I don't know if anybody else if you found you like I noticed it, I'm noticing it.

Yeah, you kind of softer, but if you're back, you can hear you just softer, like you're volume down, like you're back to the mic. Yeah, I'm not sure what happened to then because I've been pretty close. All right, sorry about the glitch there, everybody. We'll see if we can edit some of that out, but we might sleep it because that's.

Hey, that's radio. All right. So Mike, what about you? I mean, what's your story in terms of that meetup?

How did you get attracted to that bitcoin meetup? Yeah, so I've been attracted by bitcoin even before I came to the US and at the time while I was in Australia and I was wanted to go to Silicon Valley to do some startup, I don't know which one. So I went there just to work for a tech company for LinkedIn for a while and I started attending these meetups, especially bitcoin and bitcoin meetups. And that's why I've met McLean and yeah, so I've been fascinated by bitcoin, decentralized applications, things like that.

And that's what sparkled this zero db idea. At what point did you know was that first meetup? That's when you first met. But at what point did this discussion happen?

What was the problem you guys were solving? Was it just like what was the situation there? Yeah, we didn't really start working on zero db at all until I guess after a year of working on other stuff sort of in that blockchain area. We were looking a lot at these newer frameworks like Ethereum, Restorage with a J.

And actually how's your ADB came about? We were thinking, okay, if you have a decentralized application, presumably like every other application is going to need data and some of that data is going to be sensitive or need to be private. But if you don't know where that data is sitting and you're not trusting the server necessarily, how can you have that data be secure and usable in this decentralized world? And that was sort of the original problem that zerodd was solving, although we end up looking for a certainly more traditional client server architecture.

But that's the original origin story. And so from there, how did you, what was the conversation like? Hey, we should create this technology. There's these problems and we should open source it.

We should create a business together. Like, how'd that happen? Well, I think throughout all these different experiments, we have been planning on eventually having something that would become a business. I think that was in the back of our minds the entire time.

Also having the flexibility to work on cool stuff. And originally when we first had the idea, we didn't really think that it would work. We just thought it would be too slow. And eventually we got around for packing together a really quick and dirty prototype and realized actually you can tweak some things and turn it around and actually make it perform enough that you can use it for real world stuff and crush applications at that point.

This was back in March of last year, so 2015 at that point we decided it was kind of an interesting little technical trick. We posted about it on Hacker News and it blew up there and hit the front page twice in one week, which for me is a, I would say, very frequent reader. Hacker News was a cool thing. And that was when we sort of realized, hey, this could be something that could go into actual business.

Well, I was just gonna ask, you know, where it goes from there. I mean, we have more and more of these open source projects that, you know, have a GitHub page and they also have an Angellist page. And so it's a bit of a newer phenomenon and we're talking to more, you know, co founders, slash, open sourcers. It'll sound like it's open sourcers.

Open sourcers. And so, yeah, I would just wonder is like, okay, so you have this cool technology, you obviously both want to do startups or being a startup or startup, and you had something that's interesting on Hacker News, you know, which shows it has at least some technical merit. Where you go from there, from there in March to here we are in January of the following year and now it's, you know, a business. So what's the, the process?

What's that look like? Yeah, so what happened was we had obviously the little really quick and dirty prototype and once we realized there's a lot more interest in this beyond just the two of us, from the second, we sort of go through that a little bit more, started giving access to some of our friends that were interested in potentially building stuff on top of it and kept sort of on Product development for a few months and then I guess the summertime we started reaching out to some banks because we realized beyond decentralized applications, which are really cool in general, but I think in reality it's not clear there's not a whole lot of these in production. There's maybe more media opportunity to sell this to industries like financial services or healthcare. Governments that are very security sensitive have to deal with a lot of regulatory compliance constraints and see there's a use case for an identical database in that area and obviously that's where you potentially build an actual big business as opposed to in this decentralized world which is I think very interesting that still maybe a few years away from actually really taking off.

So started having those conversations realizing this could be a tool that could help banks move a lot of their on premise infrastructure to the cloud. In general, banks have been very late adopters of cloud infrastructure and not a whole lot of clouds that are running infrastructure on AWS Azure. The big reason for that is because they want to give up control over the data to a cloud provider which even if they're encrypting their data at rest, if they're actually querying it, they're going to have to send the key to the database server at some point with zero db. The kind of keys on premise still have the database and so potentially offload a lot of that on premise infrastructure to the cloud.

And obviously there's a lot of economic benefits to that as well as scalability performance. So went through a lot of those conversations. Actually the reason we're here in London today is actually got announced on Monday this week. So I can say it publicly.

We're in fintech Innovation Lab out here which is a really good chance for us to talk with the 15 or actually 20 banks that involved with this program here and potentially help them with that long term cloud strategy. Tell us about FinTech Innovation Lab, exactly what that is and what it entails for you guys. Sure. So FinTech Innovation Lab is sort of an accelerator, but not really the way most people think of accelerators out, you know, in the States, like in Y Combinator Textar so much it's more.

So it's a consortium of 20 banks. There's one actually in London as well as one in New York where the London one of course. And it's really sort of a mentoring sourcing mechanism for them to find new interesting technology that they can potentially use internally or help go to market. So we're working, you know, the opportunity to work closely with a lot of senior IT executives and application developers inside of a lot of leading global banks and figure out where zero DB would actually fit within an organization.

What the other use cases are beyond the ones that we've already identified. There's 15 other companies in this program with us divided into three different tracks. File companies, needs track. We're in the tech track, which may be obvious.

There's a retail banking track and then a commercial and investment banking track as well as. So you said you're in London, where are you normally at? I assume London's foreign. Yep, this is first time I've really spent any time in London.

We're usually out in the valley, so we're in and out. I was gonna say you met this bitcoin meetup. You're interested in blockchain chain and decentralized things and obviously security as well, and then decide to, you know, get together and build some technology, start a startup and ends up not being you know, specifically using the technology that bitcoin relies on, but nonetheless here you are. And I guess I'm just curious going back to the bitcoin is if you guys, maybe Michael, you can address this one first is are you guys as bullish on bitcoin as you were back when you first started a meeting up in San Francisco?

Well, probably not as much bullish as we were initially, but we still strongly believe in bitcoin and in decentralized applications and things like that. So that said, I would say now bitcoin infrastructure growth is at much more sustainable rate rather than this explosive craziness. Have you seen any interest from the fintech and the banks about these types of technologies like the bitcoin, the blockchain based technologies for infrastructure or anything like that? Yes, certainly there is some interest.

Interestingly enough, they recently called blockchain as B word. As what? B word. Oh, B dash word is a bad thing or a good thing?

I don't know, it's pretty much this word is used too often I guess and they jokingly call it B words just to emphasize that that's funny. People are talking about so much to become the B word. I see. Gotcha.

Well, I think this might be a good chance to step back, take a break. Of course we're here to talk about zero db, which is your guys startup and your open source project. We'll probably start with the conversation around the open sourcing of it and you know, why and why it's open source and all those things and we'll dive deep into not just what it is, but how does it work? But why is it cool?

And all the things that developers love to hear about. So let's step back for a moment, hear from one of our sponsors, and we will talk about all those things on the other side of the break. We know you listen to the podcast. Don't worry, we're not upset.

We know the Changelog isn't the only podcast in your list. And you know what? You may have heard advertisements on other shows about other hiring platforms and other places like our friends at Toptao. But let me tell you, there is no match to how invested Toptown is to both sides of the equation.

You have companies out there who need great engineers, great designers, and you have great designers and great engineers out there needing great opportunities. And Toptop plays both sides of that fence very well, helping make sure the right kind of opportunities are there and the right kind of developers and designers are there. And if you're a cto, listen to this. Or someone on a team who knows you need to expand and add more people to help reach your goals.

Tao Tao is the best place to go and find the best designers and the best engineers out there. And if you're one of those best engineers or best designers looking for great places to do great work and freelance and travel the world and have a lot of freedom, but also have the same kind of support you would want from working somewhere, Toptal is that place you can blog with them, you can travel the world with them. They have meetups all around the world. They absolutely love to encourage and to support and help their developers and designers that are in their network all around the world grow and be better and do better.

Head to toptao.com to find out more. That's t o p t a l dot com once again, t o p t a l dotcom but if you want a personal introduction on either side of the fence, whether it's an introduction to find the best designers and developers or if you're a designer developer looking for great opportunities, get in touch with me. I'd be glad to give you a personal introduction. Email [email protected] and now back to the show.

All right, we are back speaking with McLean Wilkinson and Michael Egarov of Zero DB about Zero DB. And as we teed up before the break, our first question is often our first question on the show about open source software is why is zero DB open source? Well, I think it's, I mean, there are a lot of reasons fundamentally. Obviously we're developers, we believe sourcing the things that work on the open source.

But even beyond that, just from a business perspective, I think in 2016, now that it's in the air, I think it's just super hard to have a closed source proprietary business software business, particularly when you're dealing with infrastructure tools or dev tools. And even moreover, when it's something that's so security focused on ZeroDB, you of course don't want your, you have security to obscurity. Obviously the more eyeballs we can get on ZeroDB, the more we can be sure and confident in its security and our implementation of it. And then beyond that, just looking at where the, you know, where the software industry has gone, you know, if you're a developer and you're selling developers, developers first choice is going to look at an open source tool.

If you're closed source, you're sort of starting behind the eight ball. So I think it's very difficult to build a closed source tools company today. Looks like you've selected the AGPL license. Would one of you speak to that decision what all that implies as an open source license with ZeroDB?

Sure. So we've looked at very closely attention on UNDB as kind of a model for what our business could potentially look like. So agpl, which is an open source license, people are free to usedb for their projects. The requirement there is if you're building on top of their extensions to it, you need to open source what you do on top of it as well.

And for a lot of people that's fine. For some people, particularly maybe enterprises that aren't as into the open source movement quite yet, they prefer to have what they build still be closed in proprietors. In that case we can sell them a commercial license. And then we're also considering if we include extra features in potentially Enterprise Edition that we could license as well.

We haven't done that quite yet. We're still thinking around that. And then obviously on the business side you can, in addition to selling licenses, you can sell support and things like that. I'm curious on that licensing front.

Jared, I don't know about you, but I still feel like licenses to me, they run together. I have a good memory, I try my best, but it's like documentation. I have to go back and look it up. And I'm just wondering a claim for you if you had any advice from somebody like to have a lawyer step in and sort of walk through that with you.

So as we have people listen to the show, I'm just wondering if there are resources out there aside from say the ones that are known like choose license from get help is really helpful. What resources do you use to make the decision you just made? Yeah, we did talk to lawyers to sort of sanity check everything we're doing. I wouldn't say we went to lawyer to start.

I mean there's obviously tons of resources online in terms of advice around building an open source business and what the different models might look like. Of course, even though it's not super fun reading through the actual licenses, particularly when you just probably do that at least one device that you actually waste the time, waste of time nobody reads. And then obviously talking to people that have done an open source business and have used a particular license. One caution I would say is it's generally better, at least in my opinion, to choose from a standard license.

It's something that's known and people are relatively familiar with. Obviously have the MIT licenses, the Apache licenses, the GPL ones. As long as something's standard and not, I think where you could potentially get troubles, you have some sort of bespoke license and that just sort of, that makes it harder for someone actually using your software that much higher because then particularly if it's a company, you're going to have to have a legal department look at it and understand it. Nothing gets split.

But you involve those guys. Things that get slow, you have to do things you wouldn't normally do and you can't quite be quite as agile run decisions. Yeah, and one of the benefits of having an open source in the first place is lowering the adoption hurdle where if you're forcing people as a legal department that entire purpose. I like that process of looking at a company that you like their model, you've seen it, it seems to work at least with regard to the way they're going about building business on open source and then just saying, well, I like for tension like you said, that's the kind of model that we want to follow with our business.

And so let's check out what they're doing and use as a starting point at least to having conversations with lawyers or if you're able to, you know, get somebody's ear at Tangent who's in those decisions and ask like how do they feel about the fact that they have this license and how it's working out for them. I think it's a great way of going about it as opposed to just starting with place like yeah, the interesting thing also in open source businesses it's in reality the entire lifecycle, the entire sort of open source movement is very early, particularly thinking around business models with it. So I don't think anyone really has yet. So everyone's still sort of experimenting and seeing what might work, what doesn't work, and trying to figure out how you can build, you know, a sustainable business on top of open source software.

It's further on our notes. So Jared, not to get a notes reach show and it's further on our list than the first question, which was the obvious one, wide open source. But it makes sense to bring up here, which is the patent pending algorithm piece. How does that play into having a patent on software?

I guess I'm not sure what the exact patent is for, but how does that play into the open source nature of this project? Yeah, so we have a provisional patent file and I think the reason we have a provisional patent is to get a date on it until you have up to a year after you file a provisional to apply for the actual patent. And I would say that was done out of an abundance of caution. So we don't know obviously with open sources that is available for people to use.

And I think also in practice it's unclear if the software patents really work, you know, and so it's sort of an abundance of caution. A little bit of a check the box from an investment perspective. You know, obviously a big question you get when you're, you're going to raise money is, you know, what does your IP look like and is that defensible? I wouldn't say the patent is really a core piece of our strategy going forward, but it's, it's something that we did just just in case, you know, obviously when we were thinking through this, we didn't know exactly what things will look like, you know, a year from now.

So we just wanted to be, have had that option if it, if it was something that we thought would be valuable for the business going forward. That makes sense. Interesting. Well, let's dig down into what zero DB really is and what it's going to offer us as open source developers.

You know, what it does and how it works. You call it an end to end encrypted database. Michael, could you unpack that for us and tell us what zero DB does and why it's different than stuff that's already out there? Sure.

What it allows you to do is pretty much to use this database to do queries without the database server knowing anything about your data or knowing your keys. So all the keys always stay with the client and still from this client you're able to query your data obviously without pulling the data down to the client. So for those out there who may be thinking, well, couldn't you just use full disk encryption? There are offerings out there.

You have record level or column level encryption, you have full dis encryption. And so I just want to put a stressing point on how this is different than those things. So could you compare, contrast it to like, well, I'll just encrypt the entire disk on my server and I'm good to go. Yeah.

So basically when you encrypt your entire disk on the server or use column level encryption, every time you query, at least you expose your encryption keys to the server. So these keys are at least in memory. And any attacker who is sitting on the server can pretty much take a snapshot of memory and figure out where the keys are and decrypt the data. And it wasn't so much of a problem when the threat was somebody physically stealing your hard drives.

But now in a very networked world, most of attacks are remote. So if somebody infiltrates into the server, this is actually really a problem. There's a nice little analogy which isn't necessarily exactly technically accurate, but if you compare it to a physical vault, so you have your valuable inside of the physical vault, you're going to lock the door, you're not going to hang the key up on a nail next to that door and go home. But in a way, an exactly in a way, that's what you're doing when you're encrypting data at rest.

So you're still having to send the key over this database server where your data is, and that's the window that we're trying to close with zero db. I think that's definitely a helpful analogy. Like you said, probably not exactly 100% accurate, but I think it does help paint a picture a little bit. One thing that's always advised with security is the defense and depth principle, which is to say don't just lock the door, also don't just have a key, also have a padlock and then also do this and I'll just add layers of depth to that security.

Is would you guys consider zero db that case a layer of security? Or do you say if you're using zero db, we don't need the fullest encryption? You obviously can't really even do call encryption, I guess. But are these instead ofs or are these alsos?

Well, I would say with grdb we call it encryption in use. And so by default encryption use you still have, it's still encrypted at rest. It's still encrypted in flight as the data's moving between client and server. And of course you could also layer on top TLS RSSL to that if you liked.

But I would certainly not suggest that someone just use your ADB and totally forget about the rest of their security posture. That's definitely not what we would advise. But what we tried to do with ERD is. So if you assume the database server is compromised, how can you still mitigate the potential for your data to be the actual underlying unencrypted data to be stolen on the server?

So that's the way that we can have it. And the answer is your server should never know anything. Basically, yeah. I mean, if you never send the encryption key to the server and assume you're using install encryption like NEGS256, then all an attacker is going to see is just a bunch of encrypted gibberish.

So how does it work? You got the server's dumb in the sense of the encryption technology. I guess it's just storing crypto text. How does that work?

Tell us how it works, guys. Yeah, so basically apart from encrypted records, we have encrypted index and that's what makes the thing working. And the way it works is really easy. So the encrypted index is a tree like structure, pretty much B tree.

And it is pieces of this big B tree. The buckets are encrypted before they go to the server, right? So the server observes only already encrypted buckets. And the way we do queries that major, the key piece in it is that the client traverses this B tree remotely.

So pretty much it pulls down the root of the tree, decrypts it, figures out what piece of B tree to request, next requests it, and in several steps it finds what it was looking for. Of course it's not all that easy because it becomes a little bit more involved when you need to do some operations like set intersections or things like that. But the key piece is this traversal of the tree from the client. So let's talk a little bit about the ergonomics of the database and the kind of database it is.

Because I think you mentioned more that encrypted database and also have protocol mentioned. But at the end of the day it has to be a database, right? So what kind of database is it? An SQL compliant relational database?

Is it a Q value store? Document store? What kind of database is it? How do you work with it?

It's more like an index document or somewhat similar to MongoDB. Interestingly enough, we base it on something called ZODB, which is a part of the Zoe framework, if you remember this thing. And zodb wasn't super popular at the time when it was the same. The reason, I think is because it's more like a key fob using databases rather than a database on itself.

So we used that to zero db. The name is similar, as you can recognize. And from that we inherit such features as compliance, we can do replication and things like that. Again, harvested from zero db.

And yeah, that pretty much explains how we have all these features. We just add the end to end encryption piece on top of that. That makes a lot of sense because I was starting to think when I was reading through what you guys are up to with zero DB is at the end of the day, like, wow, there's a lot of stuff you have to build. If you're building a database, right.

Your key differentiator is the encrypted part of it, but you're also offering a database. Right. And I was like, they just decided to just redo all these things. And now I'm finding out Zo object database, you know, has transactions, history, undo, transparently plugged, forward, all these things that you guys could just build on top of and you know, leave that to somebody else, so to speak.

Or at least the foundation is there for you, which is. Looks like a Python based thing. That's the video of open source. Yeah, so good idea.

So is that a fork though? Are you using actually ZODB behind the scenes and you're following and tracking that project, or is this something that you've forked and you're using your own version of it? Yeah, basically the way Zodb is built, it's super modular, so you can actually use its pieces as a library and you'll still be okay. So that's how we're using it.

Of course we could fork it, but it seems like it wasn't necessary so far. I guess my other question on that is, since your dimension is Python based, what made you choose this database? Why this one and not some of the other options out there available to everyone? It's actually being built in Python.

It allows us to move pretty quickly, to develop things quickly, faster than if we would do that in C. And if you think about performance, well, it seems like performance is good enough. I mean, all the limitations come not from Python by itself. You have encryption overhead, things like that.

And that pretty much outweighs the fact that the database is written in Python actually zodb, if you use that properly is pretty fast. Yeah, I think Vicki said that was as you said before, we don't have to rebuild a new database from scratch and we need not something that's existing. DODB is as Michael said, a good kit for doing that. But as you pointed out before there's a word protocol there.

So in principle you could build a database from scratch that does udb. You could potentially build it on top of another database, SQL based database for example. That's what I was thinking about when you said that was like if is this obviously you're at a certain point if someone else preferred a different database, could they take the same principles of the same things you've done with the idea of being a protocol they apply that to XYZ database. There are a different preference at least you certainly could and I'd say it's not trivial thing to do.

And one thing we've actually thought about is is there a way for us to potentially sit alongside of existing databases particularly when we're talking to a lot of the banks like they're running Oracle, MySQL Postgres, a lot of sort of DB2 inside of stuff. Is there a way potentially for us to sit alongside of that? Of course, you know a large bank isn't going to rip out all their existing databases and replace them with ZeroDBDB as much as much as we would like that. So in that case and we don't have this ready today, but our thinking around there is potentially they can keep using Oracle for example for the storage throw encrypted records in there and have a ZURDB index that would sit next to that.

And actually when they want to go query doesn't encrypt their records, they'll go through our index. So I would say still forming our thoughts around that piece, but that's a possibility for the future. Yeah, well, let's be honest, I mean this is fairly, fairly new like in this last year. So in 2015 this whole entire thing for you guys was born right?

Like you guys connected in March it sounded like I'm painting back to history and then by the time December we had an open source project that was spawned off and all business. You're still in the forming your ideas innovation stage to stick to these subject, right? Yeah, certainly still super early days and working through everything both from the technical engineering, product development stuff to thinking through the business model stuff that we talked about earlier. Gotcha.

Well, let's take another break we come back from this break, we cover the deeper sides of the client side of this database. So stay tuned, we'll cover that when we come back. Our friends at DigitalOcean Simple Cloud Hosting built for developers, launched a new feature recently we absolutely love. It's called Droplet Multi Create.

For easily launching up to 10 servers at once, you can deploy multiple droplets when you create your droplets with the exact same configuration. And this is a huge feature. We absolutely love it. Head to digitalocean.com and when you sign up, use our code changelog to get a ten dollar hosting credit when you sign up.

All right, we're here with McLean and Michael talking deeply about zero DB, the protocol, the database and all the odds and ends of this. And you know, the encryption is about the client and right now there's only a Python client. So it seems like your bullet on Python, which is a good thing. And at one point we mentioned you could go faster.

Python you couldn't see. But I guess the question we have here is that roughly around the clients, will this always be the case? Are you playing other clients and how much work does it take to create a new client, say for Ruby or JavaScript, for example? All right, yeah, that's a very interesting question.

So obviously now we support JSON API so that you can interface it from anywhere, but that means that you have to run the JSON API server on the client machine, which is not always very convenient. And the first thing people are requesting is actually JavaScript client, right? So of course nothing prevents us from writing that. The easiest way is to port Python code using something like PYPY js and apparently it can work, but probably the more proper way would be to actually write a JavaScript client.

And that's something we're playing. Another thing is that in this financial world, when banks want to outsource their databases to the cloud and do things like that, they often use Java and they obviously need some way for their Java code to interact with zero db. And for that we would need some JDBC connector and that is possible to do. And I think with Java we can go with Jython, actually.

So that begs the question of why at this point maybe on the client side at least maybe a C library that's portable and can be interfaced and wrapped from these other high level languages might in the long term become faster moving because it seems like there'll be a lot of smarts in the clients. And so you may have, you know, you may end up with six implementations of the same encryption stuff yeah. Thoughts on that? Yeah, we'll see how it goes.

I guess we will start from porting from Python code which is certainly possible to do. You can do that with JavaScript, you can do this with Java, you can do mobile clients from like Python ported to there but long term you quite can be right. I guess it kind of depends too Jared. If it seems like this is for everyone but obviously financial text has the most or financial people have the most initial benefit from this but you know, obviously other developers are thinking how can I use this and then encryption on my own account?

Kind of depends maybe on their motivation on who they're focusing on. So maybe open source, but they may be focusing on financial tech. They're kind of hacked with Python for example. That's right, yeah.

I'm just thinking about it in terms of other databases again MongoDB as an example, like as a business it's in MongoDB or 10gen's best interest of having as many client libraries as possible and keeping those up to date and like awesome and everything like that. And as the technology matures you know they have to maintain all of those, you know, they're open source and of course it's in their best interest to do that. And similarly I would think that sincere DB's and best interest to have any clients as possible. Is it the case?

Yeah, I mean I think. Is that the case guys? Yeah, that's definitely the case. Yeah.

And so then my question was like your guys clients have to be really smart, right? Lots of surface area of code because of all you're doing client side. And so I just would see that that might be a bottleneck for you like you know, software wise potentially is an issue. I mean, yeah, obviously I think you're probably, you're pretty, you know, as good as I think in general it's always a struggle in allocating resources from your super early stage company, you know, thinking long term versus you know, like what are some quick wins.

So yeah, I mean that's certainly one of the challenges of doing any business, particularly software business. Is that a place where you guys are looking for help from the open source community or is that more like your bread and butter? Actually open source community already offers some help in that. So I've seen some people who want to support zero DB to mobile platforms for their own purposes and we are actually, we are happy to accept this help because this was one of the reasons why we Open source.

Yeah, I mean if someone wants to build an alternative client we'd be super happy to see that. And we definitely support, support them in that effort. Cool. So speaking just more about the client side of things, since you're putting so much of the smarts in the client and you have the decryption client side.

Right. The key handling client side and the server is encryption store. Basically there's some smarts in there. Like he said, if it doesn't have the secrets, it can't share the secrets.

Or just kind of, is it just kind of moving the ball around a little bit? Because now instead of your server being the source of truth to a certain degree and it gets compromised, you're in big trouble. If, when your clients gets compromised, is the whole game up or is there, is there something that segregates where a client gets compromised? It's not a big deal.

Well, even today you have this problem with the smart server model. If your client is compromised, you still get the data exposed. But we just close one window on the server. But this is actually not the only thing we do on the server.

You can of course, throttle the data so that when a client is compromised, the attacker couldn't steal absolutely everything just a little bit. Another thing is we have this sharing or proxy encryption piece. The way it works, we can enable somebody else, be it third party or yourself, using a different device, we can enable the third party to query your data still without the server knowing anything. So let's say you can share data with your friend and your friend can still do the queries, which you allow him to do.

And the server doesn't know anything, but the server can revoke the access so that your friend with his kid cannot access this data after a day or two. How does that work? Yeah, so it's based on a technology called proxy encryption. It's a pretty young family of encryption algorithms.

The first one appeared in 1998. The way it works is you have, let's say you want to share your data with somebody with a different key pair. You take their, their public key, your private key, and calculate a special thing called transformation key. And you give this transformation key to the server.

The only thing the server can do with the transformation key, it can transform data from being encrypted to you into being encrypted for the third party you're sharing your data with. So we combine this encryption primitive with our query algorithm, and this allows us to pretty much share data on a granular level. So you can say, I want to share everything mentioned in this query with a guy who has the public key, and then that guy can pretty much query the data, like data in that subset until this transformation key expires. When the transformation key expires, the server removes that and that guy cannot query this data anymore.

So, for example, if you are afraid that the third party can get the key compromised, you limit the time span of it to be very short. And you don't have to re encrypt all your data again and again because you're not sharing the key with which actually the data are encrypted. And that sounds like a real advancement. Proxy RE encryption.

That just sounds cool, right? It does. Very cool. Very impressive.

Proxy recursion, of course. Yeah, it's been around for not a super long time. It's been around for a while and there's actually been a couple companies that have tried to commercialize it in sort of the file sharing context, where you have files that are syncing up in the cloud, they're encrypted on your keys, you want to share them with someone else. And I wouldn't say that's been super successful or hasn't really taken off.

But I guess what's potentially interesting about Proxy RE encryption in the context of DirtyDB is that we can pair it with a lot of our other query protocols that you can share stuff on a much more granular level. Yeah, I was going to ask about use cases because it was like incredibly impressive in my mind. I kept thinking like, how exactly would somebody use this to application advantage? I think file sharing is the one that comes to mind.

Are there other ways that you guys see that being used that maybe even isn't currently being used or that can go to market? Right. So yeah, one kind of cool example would be, let's say, a healthcare app. So let's say you have a mobile application for storing people's personal medical records, and obviously those are quite sensitive.

If you're a user of this app, you don't necessarily want that app provider, that service provider, to have access to your medical information, medical data. So if someone were to build something like that on top of ZeroDB, they could guarantee to their users that their phi was totally secure and totally owned by them. They control the keys and of course they need to share it with, let's say, an insurance provider or their hospital or their doctor. They can use the proxy encryption keys for that.

So I always think that's a pretty cool example for how something like that could be used. Yeah, that is very cool. That just brings up my thoughts of HIPAA and other such compliance things. If you guys run into Any of those.

And like you said earlier, your main customer currently is banks. And so hip is not a thing you're gonna work out, perhaps. Dci, I don't know whether regulations take the banking industry under you guys probably do, but have you come against regulations so far when it comes to zero db? So in a way, obviously a lot of our customers have to deal with these things.

Us, ourselves as a company or how we think about our products, we wanna be sort of enabler and we're obviously providing infrastructure, a developer tool for people to build applications that potentially could be compliant with these types of regulations, like HIPAA or Dr. Rank types in financial services. And you have a whole other set of regulations in the eu. So we don't, you know, we're obviously building applications ourselves at the moment, so that's not something that we are having to directly deal with.

But obviously to the extent that our customers could potentially be using zero db to be in compliance with these regulations, that's something that we at least need to be aware of. I can give you one interesting use case for me here. Has to do with data sovereignty laws. So let's say you're a bank in Europe and you have, you operated in a bunch of different countries and you generate some customer data in Germany.

It's very difficult for you to move that data, that customer data in the clear across country borders, even inside of Europe. If you encrypt it in a various country by country, for example, social is quite strict, so it doesn't work there. But in general, if you encrypt that data, you have more flexibility in terms of what you can do with it, where you can move it. But of course, historically the problem is then once you encrypt it, you can't use it anymore, you can't query it.

So a lot of banks actually will have a data center in every single country that they operate because of the state of sovereignty issue. Whereas if they were to use something like zero db, they could have the keys in country, encrypted data in country, ship it off to datacenter in Luxembourg, for example, still have a decryable and only ever decrypted inside in country as well. So in that scenario you could consolidate 25 datacenters, 25 countries, down to potentially a much more manageable handful. And that is actually one of the reasons why we are in London at the moment.

We see a bunch of regulations which don't stop us from operating, but actually help us, and we are actually exploring that. So you said you're at the fintech Innovation Lab and London. That's what you're going to learn now. That's your incubator joint, right?

Yep. That just started actually this Monday. So we're sort of signing though we have a few more questions on tech side things, but since this is the topic, I was just talking behind the scenes about whether we should bring this back up again. So what are your goals, I guess for this?

How long is this process for it to be part of the incubator? Yes, the FinTech lab lasts until mid April, so we'll be primarily here in London, obviously. We actually sit in Canary Wharf, which is sort of one of the banking districts in London where a lot of the banks are located. We'll be traveling a little bit to visit some of the banks in Italy and Germany for example, and then occasionally back to the US obviously because we have things going on there as well.

But it's standards for a three month program that a lot of these accelerators last. It's actually run by Accenture, so they're obviously quite helpful from having experience working with a lot of these banks and selling into banks, which we don't have to get into it, but that whole enterprise sales process. Yeah, that's a whole other bug that they're trying to sell into banks, which in general is quite difficult. Is your goal to move the company forward in this incubator or is your goal to move the technology forward in this incubator?

Yeah, they pretty much go hand in hand, I would say. You know, obviously it's important for us to make the product better and not only more secure, but obviously for us is performance and limiting the trade off that people are making. So obviously you have encryption, decryption, overhead, things like that, but you want to make it as dropping as possible so that people aren't really getting hit on the performance side, when you're using something like zero to be opposed to, you're just having it in the clear or encrypted at rest. And obviously when you're dealing with banks that have just massive amounts of data, performance is a pretty big concern for them.

So yeah, I think as you improve the product here, you're moving the business forward. At the same time. We have a few more questions on the performance stuff, but prior to that I'm just thinking how, and maybe the question is really easy to answer, but how do you or how have you been able to financially set yourselves up to be able to take this time off and still live your lives and still do whatever you do I don't have ideas against your families, you know, dads or whatnot. So I'm just making assumptions.

You know, human beings have lives, so how do. Obviously we have lives, but how are you guys able to take this time to spend to develop the company, you know, away from, you know, Silicon Valley normally? What have you done? You have back and get funding.

What is that scenario like for your company? Yeah, so we've actually spent bootstraps so far. I've been using rma. It's just two of us, co founders and developers on, so we don't have a ton of expenses, you know, outside of sort of.

Of course you have to support yourself, you have to eat, you have to have somewhere to live. So there's some baseline sacrifice too. So it sounds like you're okay with that. Yeah, absolutely.

I mean, I think the reality of being doing a startup a lot of times is you're going to go through that ramen stage where you're of course not able to spend a lot of money because there's just not a lot of money there. We are hopefully, fingers crossed the next couple weeks going to have a small angel round that'll obviously help quite a bit and help us potentially hire engineering to move even faster. So potentially April, May time frame that'll happen whenever the incubation stage is over or is that. Yeah, so we would raise around sometime early summer, late spring and towards the end of this.

And so Jerry, chime in here where you want, but I mean as we mentioned before, this, we've got this growing trend of, you know, RethinkDB and you know, we can name a number of others that have come on the show and talk about, you know, building up the source product, but also building a business alongside of that. Metabase rings bell as well. That especially had there seems like databases are easy to get. You know, we're not so easy, but seems like a prime for this kind of infrastructure infrastructure, these tools.

So I guess that's just kind of an interesting thing. We're seeing this trend of companies building up source products. How does that span for you, I guess moving forward? Like what does that look like for you know, what is.

I guess you're offering to anyone who'd want to fund you. What is their, what is their get? I don't know if you watch Shark Tank or not, but no one gets so many money thinking they'll never get it back. Yeah.

And obviously for us as entrepreneurs and business people from that side, we're obviously doing this. Obviously we want to build Something cool, awesome. The people who need it also, of course, you want to build a sustainable business as well. So I think, in general, I think if you think about going back to some of the things we talked about before, with banks moving a lot of infrastructure from on premise to the cloud, starting to hit that wave, that's starting to happen over the next, well now a little bit in particular over the next three, five years, that's something that we can really help them with and accelerate that process.

But even beyond that, I think just in general, with all the data breaches that have been happening and security becoming increasingly top of mind, not only for business people, but for developers and technical people as well, I mean, you think about how you can build applications that are going to lose your customers data and your business. That's exactly what Jared and I were talking about. As I mentioned before, we call, we had some sort of sync up and Jared asked me how the situation radar. He wasn't asking in an argumentative way.

He was like, you know, genuinely, you know, how did the situation radar was interesting to you, Adam? And I was like, well, I mean it was, it hit nightly. So that was one thing, that was our own radar. But then also I was thinking over the last four or five years, I'm sure it's happened lots more of that, you know, lots more before those times.

But it become more clear to me that we've had more and more like, you know, you know, cyber crime, so to speak, you know, where, you know, Sony was down for, you know, I mean, it's a shame I can't play my PlayStation for a month. But you know, Sony was down, that was a big one there. And they've had lots of different, you know, compromises, so to speak, get targets, compromises and next thing you know, credit card data, all this data and then knowing that, you know, they've got my password, if they did that stuff on crypto. Right.

Or whatever, I don't know. But then, you know, everyone's not secure at that point. So it made sense to provide some guys. I think over the last year there happened maybe 13 or 14 big security compromises.

And yeah, that is something. It was something which just started popping up again and again and that's increasingly a problem. Yeah, and I think also like part of the bet of our company is if you look at the last generation of big tech companies like Facebook, Twitter, LinkedIn, a lot of the value that they're creating is based off of their users data. So they're monetizing that.

But if you think about potentially what the next wave could look like and actually, Lawrence, Les, I got an interesting post a week or so ago about this topic is how companies are not offering anything to customer data, access a liability and not necessarily the source of value. So if you're, let's say a financial services company or a new insurance startup, insurance tech startup, and you have data on your customers, that's a potential risk for your company if you could have to use that, particularly when you're starting to build trust with people, your business is basically dead. So if some, if you start to build on top of things like crdb and other options where they're not necessarily having to access that data directly, they remove that liability and that's their business. Well, let's talk about that.

Let's talk about building on top of 0dB after the break, our final break, by the way, we will talk to you guys about what's the matter. Rebuild zero book. You know, we want to build a huge worldwide social network on top of 0 dB. Technology scale implications, performance implications, day to day management, those type of things, and of course getting started as good as well.

So today's conversation after we hear from this last sponsor, and then we'll be right back. Every Saturday morning we ship an email called Changelog Weekly that covers everything that hits our open source radar. It's our curated editorialized take on what you need to pay attention to from this week in open source and software development. There's no algorithms, there's no machines.

It's just us paying attention to what we pay attention to. So you don't have to head to changelog.com weekly to subscribe. And now back to the show. All right, we're back and we're ready to talk about using zero db practical applications, performance scale.

What have you getting started? Let's start with performance because you guys do have some posts on your blog about performance. And anytime you add a layer to the conversation which you know, you're sending encrypted bits down the wire and decrypting them in the client, there are performance implications. So we'll just kind of lay down the table and say if I'm using zero DB versus some other db, which is exactly like zero minus encryption stuff, what penalty am I paying?

Right? So basically the biggest implication for us is that the way we work is the client talks to the server while doing the query more than once. So a typical database is sending a query to the server. The server is doing something and returning a result.

In our case, the client Talks to the server a little bit. So it sends a little bit, gets some information, decrypts it sends something again and that repeats several times. So what that comes down to is pretty much latency between client and server. For each query you have a performance penalty of this multiple times.

This latency most helps with that a little bit is client side caching of the top of the index and that makes queries faster by a factor of two about that. But I would say there is a positive thing as well since a lot of logic and encryption description happening on the client. If you have some database server and multiple clients, each client decrypts its own data on its side. So you have this decryption load parallelized between multiple clients and this kind of takes this load of the server.

So in certain cases you can have actually performance higher than in a typical situation it seems like. And I guess this is the same for traditional databases, but a write heavy application where a lot of clients are writing, busting that client side cache more often require more round trips. That's true. Okay, so there is a penalty sometimes there's sometimes mitigated down to zero or negative.

But something to definitely think about as a concern and as it is with anything that you're going to adopt, there are trade offs. What about scaling? So like I mentioned before the break, I'm building this thing I don't know if you've heard of, called zero book. And it's going to be huge.

I've just got my first 5 million users. I don't know who they are because all their data's encrypted, but I'm sure they're awesome. And I'm trying to now expand my server side infrastructure, my zero DB based database infrastructure, past one machine. I'm thinking of sharding or replicating or whatever it is these people do at Facebook.

What do I do? Yeah, so basically replication and sharding we inherit from zodb or things built for that pretty much one is called zrs, which is just replication. And there is a thing called neo, which is actually already sharding and actually using that we can scale it up. So I guess for actually scaling the thing you need all your data to reside on multiple servers.

So when you get to the situation when all of your customer's data doesn't fit onto one server. So for this you can use these things I mentioned, which I already built and they are integrating pretty well with zero db just because we use this existing technology stack. But of course there are some scalability thoughts about Doing certain queries in an encrypted manner. So that is something we are constantly improving.

Are there best practices that are coming about or things that you or your users are learning over time, kind of gathering together a corpus of knowledge about how to go about it? About the performance and scalability? Yeah, just the scalability. But you said that there was.

There are things you were learning about how to do the queries or is that in turn to the protocol and not to the person who's actually. Yeah, it's actually internal to the protocol. So I don't think at the moment developers should worry about that. If there is something they should worry about that we will definitely publish that.

And if there are some recommendations. How about the getting started stuff? So it seems like it's easier onboard if I'm building Python client, something that's gonna rely upon Python. So let's just start with that one.

Let's say you sold me on the idea of zero to be a ready to start coding up zero books. How do I get started? Yeah, so we got a little quick start tutorial on docs 0db IO and then you just grab a 0db dash server from GitHub repo and it's pretty easy to sort of get around, get started and start playing with it. You populate it with some dummy data and we give you example of how to build data models and how to query the database.

So pretty easy to at least to get a sample of it. Seeing this is kind of a brave new world of databases, I'm assuming that there's some of a lack in terms of tooling around 0dB and query generators or any sort of like that. Is that an area where you guys are looking to innovate as a company perhaps? Or is that something that you just completely open up to the open source community and hope that they would build these kinds of infrastructure around your infrastructure?

Yeah, I mean there's obviously things that we have in our app for the company itself that we'll plan on doing and then to accept the other people do them first. That sounds great. Who are building stuff around 0dB on top of 0dB. And even just in the couple weeks that it's been open source, we've seen some of that already.

I think in the first week maybe someone started playing around Docker and put it into a container. I think a couple people have written plugins for various web frameworks. So we're seeing some of that already. And yeah, obviously to the extent that that continues or increases, we're very happy to see any activity on zdb.

What do you say to the person who's not interested in Python at this point, when you guys still, you know, the jobs for clients in the works? Python client is all we have, but they're willing to get involved in actually doing implementation, getting started for that person. Is the protocol documented or is it open up the Python client and start to emulate what you see there? What's the kind of process that you'd imagine somebody go through to implement their own.

You mean to implement their own client in a different language? Yes. And then also just like that you say, not the database, also protocol. Is the protocol documented or like, is it out there?

How you know, do you just read the code? Yeah, so we're actually publishing a paper hopefully in the next week or so, maybe a little bit longer. Don't hold me to that. It'll have some more specifics and also has sort of more on our threat model security assumptions as well, some of the crypto primitives that we're using and potential for future optimization.

So from understanding the protocol and more depth, that'll help quite a bit there. Actually the protocol itself is derived from what was internal for ZoldB. And I will talk to the founder of ZOLP and zoldb, Jim Fulton, who pretty much sees the future of zoldb as allowing alternative clients which are non Python to work with that. So, and since web based on that web is much in line with his vision, so I guess we can pretty much work together with people who work on Zebra DB to enable these alternative clients.

I guess having somewhat the ask here, but not directly, you know, talked about the protocol, you know, if somebody wanted to create their own client, you guys are an incubator right now, you've obviously got the next, you know, three or four months kind of to the most part mapped out in terms of what some of your goals are. But if you had the ear of the open source community and they're thinking similar, hey, you know, I'm not digging Python, for example, I'm digging something else. That's what's just happened. How can, how can the community step in and help you to move the ball along?

If it's not, you know, your financial, or not your financial, but your goals around your business? If it's not that, if it's around this technology and moving it forward, what are the best areas that the open source community can step in and help out? It's very much around building alternative clients, writing plugins. Another thing actually that helped a lot during the first couple weeks that we open sourced, it was having people look at our implementation and we had actually a lot of good feedback around things we could potentially do in the future to even make it even more secure.

One of the things that we do is access patterns. And what I mean by that is the server can observe to see which encrypted buckets that are being queried. And in theory over time they can deduce things like the order of the database from those access patterns. So one of the sort of active research areas right now is something called oblivious RAM or O ram and that's designed to obfuscate these access patterns.

That's something that we potentially add in the future. So things like that, obviously that help us sort of map out the roadmap for what ZeroDB will look like in the future. That's helpful as well. So if someone's out there listening, okay, I want to go to the org on GitHub, which is GitHub.com 0db.

Would it be okay for them to hop into the ZeroDB repo and just drop an issue there and share some ideas or is there different ways to communicate with you guys? Yeah, that's certainly an option where we're actually paying attention to GitHub and new issue there. We have a Slack channel too that we're on this time and can be very responsive there. I mean we're pretty much online 247 over on Twitter too, so it's pretty easy to hold us.

Gotcha. Is that Slack channel mentioning we're on zero db IO? Oh, I guess it's right there. Right there.

Top I missed it. It's too obvious. So obvious that I missed it. So you got a mail list too.

So you're sending out emails. How often do you email people about what's going on? We don't email very often. I think we sent out two emails in the entire life of our mailing list.

So one was, you know, back. This was back in March. One was a follow up blog post. We talked about a little bit in more detail how the protocol worked and then the second was when we actually open sourced it in December.

So we're not going to spam you too much. Well, if you're heading to 0dbio, link the GitHub there obviously, which is the order just mentioned the Slack channel to sign up too. If you want to talk real time or the minimalist and never get an email or at least infrequently, that would be good. Just send you important stuff.

Yeah, well that's good, right? They didn't promise a weekly email, but email's really interesting, so. All right, fellows, we don't have any more questions for you. I know we want to talk quite a bit about that.

We're running out of time for our show anyway, so we'll skip to closing questions here. This is Spice and Red. Now we're doing it here in this show to get the closing question. So maybe it's becoming a trend.

Crazy, crazy. We'll see. I don't know. But fellas, want to thank you guys for taking the time to come on the show and obviously to, you know, think proactively about the future technology and be able to, as you said earlier, claim to bet on this technology, want to build a company around it to open source it.

You know, obviously you guys will have some fun games in the future with what you do with it, but it's generous of you to give back so much to open source and trust the process of open source and all that good stuff. So that's really awesome. I want to thank our listeners for tuning in and also our members for tuning into the show. This week our sponsorship episode this week our code ship Toptal and DigitalOcean and if you're not a member yet, you can join the community for just 20 bucks a year and we'll give you an all access pass everything we do.

Head to chainplog.com membership to hear more about that. Our next show is actually already recorded. It's already in the can, but it's episode 191 with Richard Feldman. He's from Nored Inc.

Discussing ELM, which is described as the best of functional programming in your browser. Jay, it was an awesome show, right? Yeah. It wasn't some awesome news.

You might have read a no Redding just last week was it? This week we had a post on it on the website. He had a conversation with him about what's going on. You want to play that real quick?

Well, they haven't announced it. We share it on our blog. It's on SoundCloud as well. But we talked to Richard briefly about Evan Jabliki, which I'm not sure that's exactly how he say his last name so forgive me if that's wrong, but he's joining the ready which is a really interesting thing.

They are stepping up to support him. He's committed to work and he's creating, you know, the Foundation Software Foundation. Really interesting to see that happen there. So check out the blog changelog.com to find that there's an ag pie piece there as well.

It's not the main podcast feeds. If you're looking there, you're going to find it there. But we mentioned both of our emails also in the show. I'm going to mention that one more time.

Change All Weekly. We ship that every Saturday. It's our hand curated editorial take on the week. And we also ship Sheen all nightly, which is our radar as well.

So as you can see, we create new shows from this. We're constantly watching this. We ship that every single night at 10pm Central Standard Time. Covers the daily trends of Open Source on GitHub.