Hello, dear listeners, Bailey here. Today, we are diving into the fascinating world of web three and decentralized databases. Join us as Andy and Frank interview Brennan Lanay, the founder of Quill. Quill is the 1st decentralized, Community owned SQL database solution for building advanced dapps and protocols. From the demand for web3 solutions to the nuances of trustless applications, we delve into it all. Don't be alarmed at Frank's absence early on in the show. He
shows up later. As an added bonus, for the first time in data driven history, Andy does the intro. So sit back, relax, and get ready to embark on a journey that will expand your understanding of the ever evolving landscape of technology and data. Now on to the show. Hello, and welcome to Data Driven, the podcast where we talk about artificial intelligence, Machine learning, data engineering, and all things kind of related to to those topics.
Frank usually does this introduction. That's why I'm kind of skipping through it. I'm trying my very, very best to not say, in any of these. Frank's gonna join us a little bit later. He had something else he needed to do. Our guest today is Brennan Lamy. Did I say that right? Brennan, both names? That is correct. Yes. Awesome. And, Brennan, I usually go to LinkedIn and read through the lengthy bio. And and here we go. Brennan is a
founder and dev. That's a pretty lengthy bio. That may be the shortest LinkedIn bio ever, Brennan. Yeah. I would say, I I don't know. I'm still working on stuff to put there. But I I'm open to suggestions. I'm open. Awesome. No. I I think it's great. I think, you're spending your, your time wisely And you've got your priorities, pretty much aligned there. You're you're you're doing the work and then later once you've done the work you can come and fill in
the blanks. That's the goal. That's the goal. Awesome. Well, why don't you tell us a little bit more about yourself? Maybe what you're working on, your company? Yeah. Yeah. So, I mean, my name is Bruno Marney, and I am the founder of Quil. So it's just k w I l, kinda like the Quil that you, that you can write with. Cool. And Quill, we are building, decentralized databases. So relational databases, specifically. Okay. And
really the niche that this This fits into. I don't like to say that it solves an existing problem, because I think it more allows people to Capitalized on previously uncapitalized opportunities and solving some, you know, massive problem. But what a decentralized database is for is It allows you to build new types of applications with different trust assumptions. And it it also allows you to accrue value from your data in new
ways. And so this very much falls into the web three space. I'll sort of give a high level overview here, and then, Andy, you can sort of choose where you want to go deeper. But with Quill, you can build data stores with, complex access control rules, complex guarantees on the scheme of the data, who's able to write to it, How they can write to it, when they can write to it. And you can set
this for parties that don't trust each other. So maybe you and Frank are competitors or maybe you have to agree on some sort of, legal standard and collaborate in that way, but in all other sense of the word, you are competitors. And so this allows you to convene around a shared data store with rules set beforehand. And you can now use this, in real time to power both of your applications. So kinda at
a high level, that's what we're doing. There's some really interesting caveats In value accrual as well, but I can sort of jump into anywhere that you want me to. You know, I'd love to hear more about the value. Yeah. So the the the real value of this so it might be helpful with an example. I'll try to high level, and then I can sort of dive into a couple examples we see right now. But so, you know, the a lot of companies use data as a moat.
Data protects them from their competitors, but this also means that you can't collaborate on data in a lot of ways that you might like. And I think a cool example of this might be user identification data. So this is pretty low hanging fruit. And for what it's worth, I don't think it's, a particularly interesting example, But it is basic. Things like Reddit, Spotify, and Instagram, they they all have the concept of follower relationships, but they all have different
applications otherwise. And I think in a better world, no matter what application you go and use, you would have the same follower relationships and the same interests on all those different platforms if you consented so. That is a massive, identity problem, so you now need a way to your identity across those as well as your your follower relationships and your interests. And all of those companies are maybe somewhat competitive with each other.
Maybe not totally, but they are somewhat competitive. But in an ideal world, they would be able to convene around some of the same sets of data To power their application, this does give them less of a data moats effect, but it does make the experience much more convenient for your for their users. Okay. So now, once again, I don't think that is the most compelling, application, but, that's like a very high level example. It's a
good example. I was able to follow it. And, you know, it's always a good sign. Yeah. Right. Glad to hear. I, So I'm concerned about, as a person who moves data, I'm a data engineer, and I'm concerned a little bit about, Personally identifying information, not picking on your example, I promise, from the for the user's perspective. And then also, that, you know, there's there's legal, stuff that goes along with that in some fields. I do, I do
health care. I do financial. Those insurance. Those all both health care and legal come together there. Sorry. Healthcare and finance come together in insurance companies. And so It you said something that I found compelling. You said that you could convene around the data, but you could do it in such a way Where you share just what you wanna share, I think. And then, you, you know, you've got a firewall essentially or some kind of separation of
concerns Between that and the rest of the data. So could you elaborate on that a little bit and, you know, specifically with, With regard to regulations? Yeah. So I I think we can sort of split this up into 2 different topic areas. So one of them is the the logical way of accessing data. So This is like your application business logic. Should Frank be able to should he be able to see my name, my age, my social security
number, and what can he see from this dataset? But then also there is, there's sort of a an issue of legal regulations. So whether that's GDPR or, you brought up health care data. A lot of health care data, it matters where physically that
data is being stored. And so to sort of jump into the first one, this actually gets to really the of our application or maybe one of the cruxes of our application, which is configurable access control for your data all within a single a single file or you can you can do it across multiple files, but the the idea is that you can do it in a single file. So we have our own language. It's a DDL language, data definition language called Cuneiform.
And so with Cuneiform, it allows you to do a lot of, you know, regular SQL DDL for tables and And things like that, but it it also allows you to specify more complex access controls. So who can write data? Who can read data? What data can they read from this? And then we're also working with a couple partners right now designing a system of role based access control.
So you can assign different roles, roles might apply to different individuals, or to different companies or really however you want to administer these roles. And these define, like, with business logic defined in cuneiform what a specific user is allowed to access. Moving a bit more to the regulatory side, this is less of a question of the actual features of our product itself and more of, a deployment issue. So you can sort of think of our when you're using a Quill database,
it's distributed across multiple databases. And we work with clients to help them distribute those databases as needed, for their application. And this is, across an entire spectrum. So On one side of the spectrum where there are no data privacy rules, you could actually have a network where anybody is allowed to come in and sync this data from your database. They're able to To get these updates in real time, and then they can directly join in foreign key and, subquery
against this in their own application. And this obviously no data, like, no legal restrictions, no access control restrictions. It's like a totally public, read only dataset. And then on the other side of the spectrum, you might have 2 companies that
wanna convene on health care data. And that health care data might need to be geographically located in the State of Texas or maybe in the case of GDPR, it needs to be, 1, it needs to be located in European countries, but, 2, they also need to be able to identify what companies are responsible for storing this data
so they can go after them to make sure they delete it. And so we can also make sure that, as opposed to the other example that you are gating who is able to store this data, Where they're storing it, are you KYCing the other people that are running this physical infrastructure that is, holding the data for your database? And we work with clients sort of across that whole spectrum on what they need for their specific deployment topologies. Well, that
sounds Complex. I think that's the first word that comes to mind on that, but it also sounds like, an interesting collection of problems that we have with data. One of the reasons I get employed as a data engineer is to solve these kinds of problems where we keep data in one location, we set, we sometimes ship data to other locations so that other people can use copies of it. An advantage that leaps to mind, based on your description, Aquil
is you don't have to make a bajillion copies of the data. You are able to just share, it sounds like, access. And you're, defining in in this language that is it, you you pronounce it, I believe, cuneiform? Yeah. Yeah. Cuneiform. Isn't that the Egyptian characters For hieroglyphics. Am I getting that right? Or Yeah. So Cuneiform, it was the 1st written language. I should now ours is Quill for us is spelled with a k. It's Unifor, also spelled with a k. Other than that Interesting.
That's kinda cool. I I like it. And, yeah, it sounds like Based on the problems you're trying to solve, that it would also be a very, very flexible and and very, cool language to to learn. And and I'm just curious if somebody, someone like me so I'll use me as an example because I would like to know more about it. Is there some way that I can get in and play around with Quill, get a feel for it? Yeah. Yeah. So just ide.quill.com. So IDE and then Quill, k w I l.com. That pulls up
an IDE. It also gets preloaded with 3 different, Somewhat basic examples, for a type of application you might build on Quill. So and I'm just pulling this up right now as a reference, but we have, like, an example video game that's storing data. We have, a token. We operate a lot in the cryptocurrency space, and then also an example social network. And all these show how you would use Cuneiform,
to to do this. And it's it's very straightforward. If you know if you're familiar with the SQL 90 2 standard, I am fully confident you'd be able to look at this and tell me exactly what is going on in this Application. It's, it's pretty straightforward. Awesome. I'll take your word for it. And and I'm fascinated by the idea, the, just the whole idea of this. A little bit of company background. I'm just curious how long has Quill been around? So Quill's been around for a little over 2 years
now. Started under a different name and doing something different, actually. So, we're building a decentralized social media. So, decentralized communication platform trying to incentivize serving of data in, areas where you're not, where you're disincentivized through data. So think Non Western countries where there's enforced censorship, and our goal was trying to serve data in those areas. No. That's
a massively hard problem, and there's Yeah. So many, so many issues with, I mean, consistency and the Cryptographic, like, verifiability of that data that, we we were trying to solve that. And in solving that, we sort of solved this, Database use case of building this decentralized database. And we ended up just running with that instead because it was much more applicable to, A wider variety of applications than just the specific one that we were
building. And so we spend about the 1st year building that social. And then Last, January or February, we, or yeah. Last January or February, we transitioned to just doing the database specifically. Okay. Well, I love the pivoting. I just do. I think that's always a good thing to go with. And, you know, I've seen many companies kinda go through these phases where
they'll do exactly what you did. They'll start out trying to solve 1 problem, realize there's this other niche That they could really serve. And then later, sometimes even expand back out. That happens sometimes as well. But I'm old and I've seen a lot of companies, so that that kind of happens. Well, so we talked about, Cuneiform, which is a language. You guys, I guess, invented that? Yeah. You know, it's It's it's it's really a DDL language. Like, it's not a whole, like, you know, full, full
language, but it's yeah. It's useful for defining access control. But, yes, that was That was an old house. So talking about access control, I know one of the, you know, one of the challenges to that is Row level or even cell level, you know, the access control. How how fine a grain do y'all go to? It's a great question. So, there's sort of 2 things I can touch on there. So the answer is technically both. So, with Quill, or with with Cuneiform, we have this concept of actions. And action, you
can sort of think of it like a function that Anybody can call. It's like a it's an RPC call that anybody can call or you can set rules for who's able to call it, and it executes some query against the database. So this can be an insert statement. It can be a select statement. And so you might have a select statement that is able to get some users data, and maybe from May maybe it gets some data from a
few rows and retrieves a couple of the columns within that row. And so in that way, you can sort of make custom access control for columns. And then another thing we have and, let me know if this doesn't make sense because this is a bit more of, like, a web three native concept. But we have we call it a caller modifier. And so what this is is that when you're interacting with Quill, you have a key pair, and
this is how we do User identification. And so, when you are using, when you're using this key pair, it takes the address of that sort of thing like a public key On that, either you're signing your, your your your insert statement with or your update or your select or anything else. And it can use that Public identifier as a parameter in an action. So, let's say we have an
application that is storing a list of user data. Let's say let's say it's just storing your your name and your age and you're identified by your by your key pair. You might only be able to go and update the row where the, where the caller matches your key pair. And so that means that You and Frank can both have rows in the same database, but only you are able to update yours. Only he is able to update his. You can also set access control restrictions on Who is able to read from which ones?
Okay. Does that make sense? It does. That's a great example. And, you know, especially using, like, customers slash people table. And I I I'm I'm impressed by the answer itself. I mean, that's that's a hard problem to solve as well. So, and doing that and then when we talk about user access, is this something that is designed for use? Obviously, it's happening between companies. You talked about competitors. Is this is this setting in the wild Or are there, you know, ports open to the
big bad web? Sorry. Could could you restate that question? I think I might have misheard you. That's okay. So I know you mentioned that, the database and the access control controls access between, competing entities, maybe companies that compete with each other, But they wanna share some portion of data. So I'm wondering, does is Quill hosted in such a way that it can be accessed From the, you know, the web at large, the entire interweb or Internet rather. I said
interweb. I was thinking that and going, don't say it. Don't say it. The entire Internet. And and and if so, you know, what are your concerns about security? Yeah. So that's a great question. So, once again, this does sort of come back to the the 2 prongs of, Cuniform access control and then Mhmm. General network
access control for your database. So cuneiform access control, you can sort of think of this like a rest API where, they they can you know, It's a client server architecture and anybody can make calls to the actions you have defined. So maybe it's get the Get the most recent, you know, record inserted into the database, or in into a table. May maybe that's an action you have and anybody can call that and get the most recent record. And so in that way,
you have, I mean, configurable access control. So you can make that totally public where anybody's able to access that. You can also make it so only a specific white list of individuals that you want are able to access that. And right now, how we identify those individuals is with Key pairs. So, now we're not specifically tied to the key pair structure. This is just, it it's really just what our, early clients have needed, and so that's why we
use key pairs for, user authentication. And then getting To, like, the general because you had also asked about, people, just anyone in the Internet being able to access this data. This gets a lot more into network deployment topology. And so with this, you might have a database network Where you know everybody that's running these, you
know, the infrastructure for it, and they are running that closed. So, you know, like a private Postgres or, you know, MySQL server, nobody like, you are the only ones that are able to access that or you know everybody who's able to access it. But on the on the I guess the flip side of that, you can also Run a version where anybody can come and hook into your data, and it doesn't really cost you anything extra. So the white list in that case would just be
everyone? Yeah. So, I I think a a useful way to think about it would be in that case, everybody is able to see the logs that are coming into your database. So Mhmm. You know, we have the the actual consensus layer. So we don't use wrap. You can sort of think of it like a wrap consensus layer. And then below that, we actually have the data storage. So, they can essentially come and be a part of that consensus layer. Maybe they can only, read from it, But, they can come and read from these logs
before they're executed on the database. When you use Q2Form, that is defining access control for them coming and accessing your database. They can't see all of the logs. Does that make sense? It does. And it's a interesting and and very powerful sounding, paradigm that you've That you've surfaced there. And it's not that I'm not throwing off on traditional relational databases
when I say that. It's, almost like a combination of What you would expect from relational databases or maybe even NoSQL databases, but built on top of that is a little bit more beef In the access control space. And that, you know, has typically been the, kind of the purview of the application developers. They manage that part. And it sounds like you've baked that right into your, your database control. So I I like that a lot. They're part of it.
It's a really interesting trade off because, you know, a lot of early databases and this is true for, I would say, you know, I mean, Most major ones, I believe SQL Server, but I know Oracle, MySQL, and Postgres, they have baked in user access control that most people don't really use. Most people actually go for access control, you know, at
their on, like, their API layer. Mhmm. But for our case, because of the unique Environments that this is being used into, we need to bake an access control logic in a different way than these databases already do, but we need to bake that in directly to the data itself. And that is what allows us to sort of open up new use cases that previously were not possible. Go ahead. Again, sounds very Powerful. And, I imagine business is growing. Yeah. Yeah. It's going quite
well. That's that's excellent to hear. I always, I enjoy hearing success stories. They, they inspire me as well. Gosh. I'm trying to think of Some more stuff about it. I got I got my head around the basics, I think, but it's gonna be I know me. It's gonna be, like, 8 o'clock tonight. I'm gonna go, I should ask him this. It's all good. Yeah. I think you're running this 1 this 1 solo without Frank right now. So Well, yeah. And Frank thinks, So Frank thinks differently,
than I do. We're we both started as, developers and then we moved into data. And in Frank's case, I had to beg him for about 10 years to get him to go into data, specifically business intelligence, Because Frank is an artist at heart, so he already does pretty pictures, you know, and I still can't color in the lines. So I was like, you can do this whole analytics thing, Frank. You've got a good eye for it. And he got there. It was
just he kinda Came around it at a different way. And he's told me about a 100 times, you were right. Should've done that years ago. But, And he's a he he because of the way he thinks, it's it's different than the way that I think. I kind of approach I don't know. I'm not saying right or wrong. I'm not Comparing and contrasting. It's just different. And and I work with a number of people in in different fields where It's it's very productive to work with. Frank's as a Frank's more of
a data scientist, but he's also a data engineer. He's old school data science. And I I work, of course, I work well with him. We were we were friends before we started working together. And then, a handful of database administrators, I find it because I whenever I see a problem that needs to be solved, my developer roots are my first response. That's my knee jerk. Let's go write some code, you know, to do this in some language and try
and figure it out that way. And my DBA friends are all, well, You know, we can store some business logic here in a view or a store procedure and access it that way. And it's it's it's a different approach. I but I'm You know, I know enough about both to be dangerous, I'd say. And that's why I'm I'm very it's very appealing to me. I I've done a little bit of web work, there for a while. Not not in your
league. I built a website that began to get a little popular and I hired a web developer to take a look at it And he looked at it. He cut he his first response to me was, this looks like an engineer built it. And I'm like, I am an engineer. That's I thought I took it as a compliment. You laughed because you know it's not a compliment. Yeah. It's interesting. We I kinda suffer from the same thing. You know, very very
engineering focused. We have a very engineering focused culture. Like, everyone at our company writes code, even the guy that does our finances and payroll. Wow. Everybody here is now in different amounts, obviously, but Sure. Everyone writes code, and so when it gets to a bit more of the creative side, I I don't wanna say we we struggle there, but it's where we have struggled a bit in It's something we've gotten quite a bit better at. But, yeah, we you can tell our
applications were built by engineers. They're it might not be the prettiest thing in the world, but they're they're very Pragmatic. Yeah. Absolutely. So And and see, I don't even notice, when I see things like that. I don't I don't even notice them. But Frank's back so we have to stop talking. Well, talking bad about him. We can talk about him still but we only have to say the good things. Welcome back, Frank. That's
funny. Thank you for your patience. One of these days, I will explain all of this publicly to our listeners and And whatnot, but, there's a good reason for my absence there. Yeah. No. I heard about, it it I heard this funny thing, and this is how Andy and I met where, you know, you You said these apps look like they're written by engineers. And that's kind of this back and forth Andy and I have about, like, Design and whatnot.
So Rank food designer. Yeah. So Brennan was explaining to me that everyone at Quill codes. Really? Even the even the finance people. Interesting. Well, Fortis, we're we're a 7 person team. You know, it's not like we're a we're a huge company. But, yeah. Everybody I mean, everybody knows how to code and writes some amount of code. They might not have done that when they came in, but they they picked it up in one way or another. How do people react to that? Do they like
the idea, or do they kinda bristle? Or you tell them in the interview That, hey. We're doing this. So it's interesting. We it's not like we hire people, like, yeah. You will learn to code when you come here. It it's almost just an inevitability. We're we're solving a very technical product for a very technical group of users. Right. And so it's sort of inevitable that, you know, you're you're gonna learn how to How to code to some extent, working in that job,
really no matter what, like, what role you have. And so it it's not like a hard fast rule. We have the company where you to learn how to code. It just it inevitably has happened every time. So Interesting. Yeah. And Frank, the I'll give you my understanding of a synopsis of of what what their database does. It's It's like a relational database, but built
into it is this user access control. And it's, like, coupled, to that to the extent that they can do not only row level, but row column level security and access control. Interesting. How do I do, Brennan? Yeah. No. I I'm I I I think that's good for a high level overview. I think it's good for a high level. But I'm happy to sort of jump into any of the specifics that you'd like, Frank. So so tell me, How do you
how does that work? You do role level control or cell level control? Is it is it role based access control, attribute access control, Some combination? Yeah. So, kind of neither. So, we do authentication with key pairs. So anybody who wants to use a database, they have to have a, a public private key pair, like an e c v e c d s a key pair. And you can set rules for what keys are able to do what in your database. And and so we have our own language for defining this. We call it cuneiform. It's
cuneiform was the first ever written language. We thought that might be fitting for our our language. And so our language, it's a it's a DDL language. So, it sort of specifies the structure for your database, and then all of your DML is done with, SQL. But, with this DDL language, you can specify what we call actions, and you can sort of think of these like RPC calls or functions Where, they they're gonna execute some DML against the underlying database. So this could be an
insert or an update or a delete or it can be a select. And you can set all these interesting rules for who is able to do this, when they're able to do this, do they have to transfer some sort of value and able to do this Either once or every time they do it, or do they have to have, some role that applies to them that
allows them to do this? And, You know, since we're able to identify people by their key pair, when Andy comes in and uses and, you know, interacts with the database, I can tell that he is distinctly different from you, and I know what Andy is allowed to do. And there's even
a small amount of programmability that can be fit into that. So, you know, when Andy is hitting one of those actions or RPC calls, that might give him, results or allow him to do certain things that you would not be allowed to do if the database is configured that way. Interesting. Interesting. So you have really fine grained control over what who can do what? Yeah. You know, I I might hesitate to say Fine grained because it's
it it is fine grained. You can really set whatever, however you can think to specify what someone can do in SQL, you can you can really do that with access control. But we don't implement it with a fine grained approach. I think a lot of the time, databases that are really trying to iterate on the access control front, they they get really into row and column level access. And that's not quite what we do. We sort of see our role as, you know, an iterating for access
control on 2 different layers. The first one is on the actual consensus layer. So, you know, if you think in a traditional data system, this is where your raft consensus logs are are sitting before they get executed on your data layer. We don't use Raft, but, so that is the 1st place where we able to have access controls. So this is, you know, network wide access control, Who can read what data coming in?
And then secondly, we define, and this is for more client server access control, or for people that are trying to read from the database, at any point in time, but you can think of this I don't wanna say like a REST API, but a little bit more like a REST API than traditional database where you can have preset queries and, preset functionality that certain people are able to do or Certain groups of people are able to do
in certain instances. But the ways that you can combine these things, You can you can you can combine it to do very granular access control, but that's not really where we attack the problem. Where did you get the idea for this? Because this is fascinating. Yeah. So it's interesting. It's been a little bit of a of a of a ride. So, we started by building a a decentralized communication platform. So really trying to incentivize,
serving data in places where you're otherwise disincentivized. So think non Western countries where there's enforced censorship or IP blocking. How can we incentivize people to use things like HTTP tunnels to, spread data? Not really hard to build a business on that. And so sort of how we iterated from there was we took the data infrastructure for that, and we started providing that as a stand alone service. And this is actually where the access control
part of this Really interesting. We started talking to a lot of projects that, you know, they're building some sort of data store. They have some data intensive application, but they're not looking to build that as a data moat. They're looking to build that as a composable, you know, data building block that other applications are
able to directly import. Just like how you import a line of code or, you know, a package of code into your application, you should be able to do that with data as well, assuming you you're applying to all the different access
controls. And so what we're helping a lot of customers do now is they can take their different datasets and, people whether they're collaborators, clients, or competitors, they can use that data in the ways that, that that the, you know, originator the original data creator specifies. And then also they can set interesting mechanisms for how value accrues
back to them. But it's really just been a process of iteration from, You know, that initial idea of building shared data stores and then, building more complex access control mechanisms on top of that. Does that make sense? No. It makes a lot of sense. It's a fascinating it's just fascinating, because every time you think that we've we've we've Kind of solved all the problems, particularly in the in the in the
data storage, in the data querying side of things. There's a whole new layer that gets on call unfolded, and There's just enormous opportunity, and, it's really cool because, like, I'm reading your bio, and, like, you were still in school when you started this company, like, that's and you you started Your first company when you were 16, and you had 15 you had 15 employees before you even go on 15 or 16 employees before you even go on to college, man. That's that's impressive,
I have to say. Yeah. I mean, I appreciate it. It's honestly just been a lot of being in the right place at the right time. Not my first company. It was not a tech company. It was Digging holes and, cutting down trees and digging up bushes in Idaho. But that was that was my first company. And then this one, I started, during COVID on a gap year, from college. But Very cool. It's honestly just been, Being in the right place at the right time and, doing something that people find
interesting. That is so cool. I mean, like, you think about the last couple years, A lot of people would say, oh, it's a terrible time to start a business, but we've seen a couple of instances where it's actually turns out to be a really good, like we talked to a bunch of folks, some, So probably by the time this goes out, the shows will be out, but, like, this whole there's this whole opportunities that I think are just popping up left and right because of data, Because of AI,
because of, you know, distributed applications and stuff like that. There's just it it's We're gonna look back on the as these as the good old days of entrepreneurship and and opportunity. Yeah. Hopefully. And and, you know, I I I would say that is actually, like this the last, year, maybe 18 months has been probably the only time where we could have
started a a, a product like this. So particularly in the growth of web 3. A lot of our beachhead markets are sort of bridging that gap from, the traditional space to web 3. We find a A lot of our initial partners, they have a lot of their clients are based in the traditional world, but their data engineering problems are uniquely solved by what is provided in web 3. And there's enough demand for this, for our specific solution to
to warrant a product. You know, it's only really existed in the last, year or so. And so yeah. I you know, whether or not this is a good time to start a business, I would say, 1, I don't know, but also, I don't think, I I care too much. Like, the need for what we are doing has really only just started existing, But it very clearly does exist, and that's that's something that's pretty exciting
about it. So you said web 3, and I It's interesting because when when most people think of web 3, they think, they think blockchain. Right? And thanks to SPF that is kind of cratered, I would say, although I I I am still don't the crypto kids better not hate on me, like, I'm still a believer in blockchain as a whole, as as an idea. I don't think I think currency is only one of the things that you can do with it. And
2, the the the metaverse. Right? And obviously, I think the metaverse, Obviously Facebook is stumbling on it like but but it's interesting that the data portion of it is probably more relevant than any of the other 2 and you don't hear the negative press about Kind of this distributed data stores in into the, I I just interesting. I think that you're part of the web 3. Have you found that the labeling yourself part of web 3 has been a, has turned from a positive to a negative, basically? Yeah.
I think so. Yeah. You know, some people, they might get kinda turned off on it. You know, you might talk to a candidate, and when we say we're because we do classify ourselves as a web 3 company. Right. And when we say that, they're like, oh, like, you know, I I don't really believe in that cryptocurrency stuff. And I I I think that's fine, but I don't think web 3 is cryptocurrency. Right. I mean, web 3 is a new type of distributed application or distributed databases, honestly. We do,
I I I would say not just distributed, permissionless. Decentralized Mhmm. List. That makes sense. With Web 3 applications were able to relax a lot of the trust assumptions that are made in other applications, in particular trust assumptions Between the client and the server. And so that's like, just forget about cryptocurrency and the metaverse And tokens with dogs on them and everything else, that is what web
3 is. It is relaxing trust assumptions in, you know, otherwise More traditional, you know, client server and oh, not in client server, but it's just like general, computer architecture models. And so that's what we are doing. You know, I don't really care what the price of cryptocurrency does. I don't own any cryptocurrency. Right. We're just building, you know, trustless
applications. That's a good way to put it because when you, you know, you're obviously your company's doing well and and and and you're growing and and you've had a pretty, you know, good run. Well, so you just said web 3 and I'm like, but but you're doing well. I was like, but but but then then then then like, you know, after you That's why I wanted to ask that. Now you explain it. You're right. Like, web 3 is, you know, it's kind
of like, kinda like Beyonce. Right? Like, nobody hardly anyone remembers What group she was part of. Right? I think, God, Destiny's Child.
There were like 3 or 4 singers in there. Right? But but, you know, one of them one of them Has the the the fame and staying power, the other ones not so much, no disrespect to them, if the weird off chance that they're actually listening to a show About AI and data science, but, you know, no. I just it's just interesting, like, you know, and we think of all these technologies, like, I'm old enough to remember
1 web one o. Right? And all the crazy ideas, particularly one of them was, you know, downloading Java applets. Right? Downloading software from The Internet and running it locally. Right? Well, that's called the app store now, we don't even think about it. Right? But obviously, there are a lot of things that failed in that
era. Right. Same thing with web 2 point o, we're kind of saw that kind of come and go, and I think the same is gonna be true here, you know, like, you know, did we really need, You know, sock puppets to sell us stuff, you know, sell us dog food. Right? And but, you know, I remember very early on there was a startup called, they were all the Java people who made Java basically, started a company called Castanet or
Rumba, I forget Which one it was. But their big thing was they wanted to create what we would call an app store, but for applications. Right? And and that idea Resurface somewhere completely different and now it's just part of, like, just the daily world we live in. So it's it's interesting. I think that We always seem to remember the Hindenburgs of history, but not necessarily kind of the The the the the stuff that actually does work
out. Oh, absolutely. And I I think that'll be the the case with, you know, web 3 as well. A lot of the people, in particular, a lot of the really loud people that we're that we're operating in web 3, you know, now that the The the prices of things are down. They've kinda gone on to whatever the next thing it is they're gonna do to try to make a quick buck. But the people that are building really useful and interesting things, Most of them will stay around. You know, some of
them will fail. You know, businesses fail. But, you know, it's something I've noticed, because I was also here when web 3 was really popular, right, when when working in web 3 was the cool thing to be doing. And something I've noticed is that The people that are building actually useful applications and solving actually hard problems, they're still here. You know, they're not as loud as the other people that were here Or but that that's fine.
Like, the the actual core problems that we want to solve are still being solved, and and I I think that there's a lot of value in solving those problems. And so, there's less people, but there's a higher concentration of High quality people building in the space now, and I think that's what matters. Well and now that it's quieted down some, y'all can get more work done. That is, very true. That's very true. Yeah. Which has also been quite helpful. Well, we are gonna transition, to
the questions part. I hope you got a copy of Questions in advance. If you didn't, I put them in chat. So if you'd like to, peruse them. The very first one is, I think you've explained it, But, it's a it's a softball, for you. How did you find your way into data? Did, data find you or did you find data? Yeah. So I kinda inadvertently found my way into data. So I wanted to solve this other problem that was present in the messaging application. And, that really required me to dive I
don't wanna say super deep into data. It required me to dive super deep into a few things, but it was in building infrastructure for that that I found that there there was a real opportunity if I went and, you know, doubled down and went even deeper into data. And so, you know, for me, it was really just kinda looking at, at what the market wanted, you know, when we're working with design partners and potential customers, What is their feedback? And it
kind of pointed towards going deeper into data. And so that's how I found my way into it. Nice. Interesting. So what's your favorite part of your current gig? So I would say, like, the the team I work with. So our team is really tight knit. Most teams now are remote. Almost every startup now is a remote startup, especially in the, you know, quote unquote web three space. We're in person. So, you know, the entire team is in the room right next to me. And, honestly,
we're all really close. We all really believe in the problems we're solving. We do believe we're building a better and more fair Internet. And so that makes it really fun to work here, you know, even if the hours might be a little longer than they would be at another job. It's it's really fun to work here. We all really get along, and, we work well together. And so that's certainly my favorite part. And you're in Austin now. Right?
We are in Austin. Yeah. Our team is a really thriving tech scene right now. Yeah. Yeah. If you're if you're young and work in tech, it's the the place to be. And so it's very Awesome. Awesome. So we have 3 complete the sentence statements, not really questions. The first is when I'm not working, I enjoy blank. Yeah. So I am I'm a not a I live in Texas, I guess, not as much. But, I'm a really big skier. So I grew up snow skiing. That's cool. Yeah. I I'm from Idaho, and so it's kind of a
common thing there. And so, yeah, I did a ton a ton of skiing growing up. I do, I ski raced. I do backcountry skiing now. So a lot of, like, hiking, skiing, like, like, avalanche training, stuff like that. Yeah. I would say that if I, you know, if I was no longer working, and I I couldn't, You know, I I love what I do, and I would do it, you know, even if I wasn't making money doing it. But if I was no longer working, I would probably go skiing. Very cool.
Another complete the sentence. I think the coolest thing in technology today is? Yeah. So, I'm I'm a little torn here. I think either, permissionless networks. So, I mean, people usually think of this as cryptocurrency layer ones, but I think it extends sort of beyond that. But Any network that is permissionless and allows people to it it functions as as a protocol, and it doesn't have biases towards individuals. I think that's really
interesting. It has a lot of potential, or SQLite. I really like SQLite. I think it's a really awesome piece of technology. I know it's Not exactly the newest thing, but I think it's still of the things I've worked with, SQLite is really cool. Nice. Alright. Our last one, I look forward to the day when I can use technology to blank. Oh, interesting. Interesting question. I think for me, I I'm really looking forward to being able to use and I I I think we're we're almost
there. But being able to use, AI programming to help us write unit tests and get full context of our code base, I've been using GitHub Copilot for, I think, maybe 9 months now, 8 months now, and it's honestly changed my life. It's I don't know if you guys have used GitHub Copilot. Would highly recommend trying it. It has just my productivity has skyrocketed. And now it's only able to handle a fairly small set of context. Like, I believe it only has context for the file or maybe a couple of the
most recent files you've worked in. But, you know, there there have been a couple, demo models, and, unfortunately, they're in private beta right now. But where there are AI AI models that can help you generate unit tests, and they can read through an entire package of code you've written and see, oh, you might have a security vulnerability here, or, Are you sure you actually meant to expose this in your public API? Just those are sort of a lot of the foot
guns I still find myself running into. And I think we're almost at the point where, that that, is is solved. Wow. Very cool. Would highly recommend trying out Copilot if you haven't. It's been it's been pretty crazy. I will check it out. Yeah. I've done a couple of demos with it, you know, just to it's kinda like, you know, walk through, follow the instructions type stuff. It's not the same as when you're trying to solve a real a real problem,
real world problem. So I know enough to know that. I was still impressed, But I haven't yet taken it to that next level. Yeah. You know, it it's not super useful for writing large blocks of code. Mhmm. It is useful as autocomplete. So, I mean, like, a place I use it, most of our stack is in Golang. Golang has pretty verbose error handling. It's really helpful with that. Like, just with that alone, it's doubled my productivity because it pretty much handles all
of the error handling for me. Wow. So That's impressive. Very cool. Share something wait. Which question did we do? Yes. Just share something that's next in that list, But that's my list, and it may be out of order. No. No. No. It is. Here's something, different about yourself. But remember, we like to keep our Itunes, clean rating. Yeah. Oh, man. That's a that that's I think that's the toughest
one yet. I I had scanned through these questions before the podcast, but I, I did not think of this one. Man, let me think about 1 for a sec. I don't know. If you don't mind me asking, what would, what would your answers for this be? And maybe that'll help me come up with something. Oh, I mean, like, one of 1 of mine was, because we did this on on each other. We should probably reupdate, Andy. Because I used one of my first jobs was I was an EMT in the Bronx. Okay.
Yep. And for me, I I have a similar one to Frank. I played guitar in a country rock band. Okay. Wow. That's that's really cool. Oh, man. I already brought up the the skiing thing. That one's tough. I mean, how did you here's here's 1. I'll help you out. Like, how did you start a landscaping company? Like like, when you were 16, like, how many 16 year olds do you know that just say, you know what? I'm gonna, Like, how did that happen? Like This is impressive. Sure. Yeah. The the thank
you. I appreciate the help here. No problem. It's, so I I grew up in Idaho, and we were we're a ways outside of Boise. And so we had quite a bit of land, and it wasn't, you know, nice. I mean, it it it built around. It's just like a Great place to live, but it wasn't like, like like you know, we had to do it like firebreaks, you know, a lot of irrigation work, things like that. And so, growing up, we wouldn't you know, me and my brothers were really young, we had a guy
who would come and help us do that. But as we got older, we started our family did it ourselves. And he hired me, and I would just kinda help him as an extra hand. He did this for people all over. And I just kinda had a realization not that far into the job. It was like, man, I could definitely do this myself, and I think I could, you know, probably pay myself a little bit better. And so I just, I I started small, started with 1. Like, I didn't immediately quit my job or anything. I did quit my
job fairly quickly. But, I started with a couple small clients just seeing if it was something I can handle. None of it was rocket science, and so I figured that out. I started scaling up more from, like, you know, mowing lawns to fire breaks And digging in drainage ditches, a little bit of demolition work. It's just a a bit higher margin. But, yeah, honestly, just started 1 step at a time. I got 1 client. I got 2 clients, and then I got 10. I had a couple buddies that would
come out and help me. And it was just really you know? As opposed to a business like like this one where it's, It was very technically focused, and you're raising VC dollars and things like that. This was, I I I worked out of a Ford Escape until I could afford a pickup truck. And then I bought a pickup truck, and then I So it was it was it was a little bit of a different process. But, yeah, that was kinda how I got into it. No. That's cool. That is cool. Do you listen to
audiobooks? It's funny. I just saw that question. I just got an Audible subscription 2 days ago. Wow. Yeah. One of my coworkers recommended a book to me, And I don't have a lot of time to actually sit down and read, but I walk a lot. And so, I got Audible for that. So, I'm It's a really good book. Would really recommend. It's called Children of Time. It's like if you're into sci fi Mhmm. It's like a postapocalyptic sci fi book where, they're humans.
They've they've left Earth, and they're, I I forget how far, but they're they they've been traveling for, like, 2000 years, and they're now trying to recolonize a new planet. And it's just sort of all the I don't wanna spoil too much, but, it's about that. But it it's it's really good. If you like sci fi, I would highly recommend. I'll check it out. And, you can check it out too to our listeners. Audible is a sponsor of the show, and you go to the data driven book
.com Or the data driven book .com depending on how you want to pronounce it. Andy assures me that that link is working and, I have my faith in Andy. It was working a couple of hours ago. We did another recording. It's a 2 recording day, and it's working then. Yeah, no, no. It could have been, it could have been my setup. Cause I was, I was doing some weird stuff with DNS to get something else working on. It's always DNS Frank. It's Always DNS.
So where can people I'm sorry. Go ahead, Andy. That's okay. You you do it, Frank. I was gonna say the same thing. Where can people learn more about you and what you're up to? Yeah. So, I mean, the first one is just our website. So quill.comkwil.com. I've also got a Twitter. That's probably the easiest way to get to me. So my Twitter is just my name, so Brennan underscore Lamy. But you can also find links to Quill's Twitter and inevitably to
to mine as well on our website. So I would say the biggest one is just go into quill.com. It's probably the easiest. Okay. Excellent. That sounds good. Yeah. And, any parting thoughts? No. I don't think so. I mean, really, thank you thank you all for having me. I it it's hard to find people that, are as passionate about, you know, weird data engineering problems as I am, and so it's really been a pleasure. Awesome. We're
happy to talk to other people who are into Data engineering, too. Well, that was quite the show. Alright. I'll let go of it. It's always good to hear a good entrepreneur origin story. One last thing before you go. We know you're busy and we appreciate you listening to our podcast. But we have a favor to ask. Please rate and review our podcast on Itunes, Stitcher, or wherever you subscribe to us. You have subscribed to us? Haven't you?
Having high ratings and reviews helps us improve the quality of our show and rank us more favorably with the search algorithms. That means more people listen to us, spreading the joy. And, Can't the world use a little more joy these days? So, go do your part to make the world just a little better and be sure to rate and review the show.