Welcome back to another exciting episode of Data Driven!

In this show, we delve into the fascinating world of Web 3 and decentralized databases. Join us as we explore the insights and experiences of our guest, Brennan Lamey, the founder of Kwil - a revolutionary company that builds decentralized databases for Web 3 applications.

Throughout this episode, Brennan shares his journey and the inspiration behind Kwil, as well as the cutting-edge technology that powers their database solutions. From complex access control rules to collaboration between competitors, we uncover how Kwil is transforming the way companies approach data storage, privacy, and sharing.

But it's not just about the technology - we also dive into Brennan's personal story, from their humble beginnings in Idaho to their entrepreneurial success and passion for data engineering. Plus, don't miss their recommendations for AI programming and an intriguing sci-fi audiobook they're currently enthralled by.

So, whether you're a tech enthusiast, a data-driven professional, or simply curious about the future of the internet, this episode is a must-listen. Tune in as we unravel the intricacies of Web 3, decentralized databases, and the exciting possibilities they hold for a better, fairer online world. Let's get started on this illuminating journey with Brennan Lamey and Kwil in this data-driven episode of Data Driven!

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.