Speaker:

Hello, dear listeners, Bailey here.

Speaker:

Today, we are diving into the fascinating world of web three and

Speaker:

decentralized databases. Join us as Andy

Speaker:

and Frank interview Brennan Lanay, the founder of Quill.

Speaker:

Quill is the 1st decentralized, Community owned SQL

Speaker:

database solution for building advanced dapps and protocols.

Speaker:

From the demand for web3 solutions to the nuances of trustless

Speaker:

applications, we delve into it all. Don't be

Speaker:

alarmed at Frank's absence early on in the show. He

Speaker:

shows up later. As an added bonus, for the

Speaker:

first time in data driven history, Andy does the intro.

Speaker:

So sit back, relax, and get ready to embark on a journey that

Speaker:

will expand your understanding of the ever evolving landscape of technology and

Speaker:

data. Now on to the show.

Speaker:

Hello, and welcome to Data Driven, the podcast where we talk about

Speaker:

artificial intelligence, Machine learning, data engineering,

Speaker:

and all things kind of related to to those topics.

Speaker:

Frank usually does this introduction. That's why I'm kind of skipping through

Speaker:

it. I'm trying my very, very best to not say,

Speaker:

in any of these. Frank's gonna join us a little bit later.

Speaker:

He had something else he needed to do. Our guest today

Speaker:

is Brennan Lamy. Did I say that right? Brennan, both names?

Speaker:

That is correct. Yes. Awesome. And, Brennan, I usually

Speaker:

go to LinkedIn and read through the lengthy

Speaker:

bio. And and here we go. Brennan is a

Speaker:

founder and dev. That's a pretty lengthy bio. That may

Speaker:

be the shortest LinkedIn bio ever, Brennan.

Speaker:

Yeah. I would say, I I don't know. I'm still working on stuff to

Speaker:

put there. But I I'm open to

Speaker:

suggestions. I'm open. Awesome. No. I I think it's great. I think,

Speaker:

you're spending your, your time wisely And you've got your

Speaker:

priorities, pretty much aligned there. You're you're you're doing the

Speaker:

work and then later once you've done the work you can come and fill in

Speaker:

the blanks. That's the goal. That's the goal. Awesome.

Speaker:

Well, why don't you tell us a little bit more about yourself? Maybe what you're

Speaker:

working on, your company? Yeah. Yeah. So, I mean, my name

Speaker:

is Bruno Marney, and I am the founder of Quil. So it's just

Speaker:

k w I l, kinda like the Quil that you, that you can write with.

Speaker:

Cool. And Quill, we are building, decentralized databases.

Speaker:

So relational databases, specifically. Okay. And

Speaker:

really the niche that this This fits into. I don't like to say

Speaker:

that it solves an existing problem, because I think it more

Speaker:

allows people to Capitalized on previously uncapitalized opportunities

Speaker:

and solving some, you know, massive problem. But what a

Speaker:

decentralized database is for is It allows you to build new types of

Speaker:

applications with different trust assumptions. And it it also

Speaker:

allows you to accrue value from your data in new

Speaker:

ways. And so this very much falls into the web three space. I'll

Speaker:

sort of give a high level overview here, and then, Andy, you can sort of

Speaker:

choose where you want to go deeper. But with Quill, you can build

Speaker:

data stores with, complex access control rules,

Speaker:

complex guarantees on the scheme of the data, who's able to write to it, How

Speaker:

they can write to it, when they can write to it. And you can set

Speaker:

this for parties that don't trust each other. So maybe you and Frank are competitors

Speaker:

or maybe you have to agree on some sort of, legal standard and collaborate in

Speaker:

that way, but in all other sense of the word, you are competitors.

Speaker:

And so this allows you to convene around a shared data store with rules

Speaker:

set beforehand. And you can now use this, in real

Speaker:

time to power both of your applications. So kinda at

Speaker:

a high level, that's what we're doing. There's some really interesting caveats In value

Speaker:

accrual as well, but I can sort of jump into anywhere that you want me

Speaker:

to. You know, I'd love to hear more about the value.

Speaker:

Yeah. So the the the real value of this so

Speaker:

it might be helpful with an example. I'll try to high level, and then I

Speaker:

can sort of dive into a couple examples we see right now. But so,

Speaker:

you know, the a lot of companies use data as a moat.

Speaker:

Data protects them from their competitors, but this also means that

Speaker:

you can't collaborate on data in a lot of ways that you might like.

Speaker:

And I think a cool example of this might be user identification

Speaker:

data. So this is pretty low hanging fruit. And for what it's worth, I don't

Speaker:

think it's, a particularly interesting example, But it is basic.

Speaker:

Things like Reddit, Spotify, and Instagram, they they all have the

Speaker:

concept of follower relationships, but they all have different

Speaker:

applications otherwise. And I think in a better world,

Speaker:

no matter what application you go and use, you would have the same

Speaker:

follower relationships and the same interests on all those different platforms if you

Speaker:

consented so. That is a massive, identity problem, so

Speaker:

you now need a way to your identity across those as well as your your

Speaker:

follower relationships and your interests. And all of those

Speaker:

companies are maybe somewhat competitive with each other.

Speaker:

Maybe not totally, but they are somewhat competitive. But in an ideal

Speaker:

world, they would be able to convene around some of the same sets of

Speaker:

data To power their application, this does give them less of

Speaker:

a data moats effect, but it does make the experience much more

Speaker:

convenient for your for their users. Okay. So

Speaker:

now, once again, I don't think that is the most compelling, application,

Speaker:

but, that's like a very high level example. It's a

Speaker:

good example. I was able to follow it. And, you know, it's always a good

Speaker:

sign. Yeah. Right. Glad to hear. I,

Speaker:

So I'm concerned about, as a person who moves data,

Speaker:

I'm a data engineer, and I'm concerned a little bit about,

Speaker:

Personally identifying information, not picking on your example, I

Speaker:

promise, from the for the user's

Speaker:

perspective. And then also,

Speaker:

that, you know, there's there's legal, stuff that goes along with

Speaker:

that in some fields. I do, I do

Speaker:

health care. I do financial. Those insurance. Those all

Speaker:

both health care and legal come together there. Sorry. Healthcare

Speaker:

and finance come together in insurance companies.

Speaker:

And so It you said something

Speaker:

that I found compelling. You said that you could convene around the

Speaker:

data, but you could do it in such a way Where you share

Speaker:

just what you wanna share, I think. And then, you, you

Speaker:

know, you've got a firewall essentially or some kind of separation of

Speaker:

concerns Between that and the rest of the data. So could

Speaker:

you elaborate on that a little bit and, you know, specifically

Speaker:

with, With regard to regulations?

Speaker:

Yeah. So I I think we can sort of split this up into 2 different

Speaker:

topic areas. So one of them is the the logical way of accessing data.

Speaker:

So This is like your application business logic. Should Frank be

Speaker:

able to should he be able to see my name, my age, my social security

Speaker:

number, and what can he see from this dataset? But then

Speaker:

also there is, there's sort of a an issue of

Speaker:

legal regulations. So whether that's GDPR or, you brought up health

Speaker:

care data. A lot of health care data, it matters where physically that

Speaker:

data is being stored. And so to sort of jump into the first one, this

Speaker:

actually gets to really the of our application or maybe one of the cruxes of

Speaker:

our application, which is configurable access control

Speaker:

for your data all within a single a single file or you

Speaker:

can you can do it across multiple files, but the the idea is that you

Speaker:

can do it in a single file. So we have our own language. It's a

Speaker:

DDL language, data definition language called Cuneiform.

Speaker:

And so with Cuneiform, it allows you to do a lot of, you know, regular

Speaker:

SQL DDL for tables and And things like that, but it it

Speaker:

also allows you to specify more complex access controls.

Speaker:

So who can write data? Who can read data? What data can they read from

Speaker:

this? And then we're also working with a couple partners right

Speaker:

now designing a system of role based access control.

Speaker:

So you can assign different roles, roles might apply to different individuals,

Speaker:

or to different companies or really however you want to administer

Speaker:

these roles. And these define, like, with business

Speaker:

logic defined in cuneiform what a specific user is

Speaker:

allowed to access. Moving a bit more

Speaker:

to the regulatory side, this is less of a

Speaker:

question of the actual features of our product itself and more

Speaker:

of, a deployment issue. So you can sort of

Speaker:

think of our when you're using a Quill database,

Speaker:

it's distributed across multiple databases. And we

Speaker:

work with clients to help them distribute those databases as needed,

Speaker:

for their application. And this is, across an entire spectrum. So

Speaker:

On one side of the spectrum where there are no data privacy rules, you

Speaker:

could actually have a network where anybody is allowed to come in and sync this

Speaker:

data from your database. They're able to To get these updates in real time,

Speaker:

and then they can directly join in foreign key and, subquery

Speaker:

against this in their own application. And this obviously no

Speaker:

data, like, no legal restrictions, no access control

Speaker:

restrictions. It's like a totally public, read only dataset.

Speaker:

And then on the other side of the spectrum, you might have 2 companies that

Speaker:

wanna convene on health care data. And that health care data might need to

Speaker:

be geographically located in the State of Texas or maybe in the

Speaker:

case of GDPR, it needs to be, 1, it needs to

Speaker:

be located in European countries, but, 2, they also need to be able

Speaker:

to identify what companies are responsible for storing this data

Speaker:

so they can go after them to make sure they delete it. And so we

Speaker:

can also make sure that, as opposed to the other example

Speaker:

that you are gating who is able to store this data, Where

Speaker:

they're storing it, are you KYCing the other people that are running this

Speaker:

physical infrastructure that is, holding the data for your database?

Speaker:

And we work with clients sort of across that whole spectrum on what they need

Speaker:

for their specific deployment topologies. Well, that

Speaker:

sounds Complex. I think that's the first word that comes

Speaker:

to mind on that, but it also sounds like,

Speaker:

an interesting collection of problems that we have with data.

Speaker:

One of the reasons I get employed as a data engineer is

Speaker:

to solve these kinds of problems where we keep data in one location,

Speaker:

we set, we sometimes ship data to other locations

Speaker:

so that other people can use copies of it. An advantage

Speaker:

that leaps to mind, based on your description, Aquil

Speaker:

is you don't have to make a bajillion copies of the data. You are

Speaker:

able to just share, it sounds like, access. And you're,

Speaker:

defining in in this language that is it, you you pronounce it, I

Speaker:

believe, cuneiform? Yeah. Yeah. Cuneiform. Isn't that the Egyptian

Speaker:

characters For hieroglyphics. Am I getting that

Speaker:

right? Or Yeah. So Cuneiform, it was the 1st written

Speaker:

language. I should now ours is Quill for us is

Speaker:

spelled with a k. It's Unifor, also spelled with a k. Other than that Interesting.

Speaker:

That's kinda cool. I I like it. And, yeah, it sounds

Speaker:

like Based on the problems you're trying to solve, that it would

Speaker:

also be a very, very flexible

Speaker:

and and very, cool language to to learn. And

Speaker:

and I'm just curious if somebody, someone like me so I'll use

Speaker:

me as an example because I would like to know more about it. Is there

Speaker:

some way that I can get in and play around with Quill, get a feel

Speaker:

for it? Yeah. Yeah. So just ide.quill.com.

Speaker:

So IDE and then Quill, k w I l.com. That pulls up

Speaker:

an IDE. It also gets preloaded with 3 different, Somewhat

Speaker:

basic examples, for a type of application you might build on

Speaker:

Quill. So and I'm just pulling this up right now as a reference, but we

Speaker:

have, like, an example video game that's storing data. We have, a

Speaker:

token. We operate a lot in the cryptocurrency space, and then also

Speaker:

an example social network. And all these show how you would use Cuneiform,

Speaker:

to to do this. And it's it's very straightforward. If you know if you're

Speaker:

familiar with the SQL 90 2 standard, I am fully confident you'd be able to

Speaker:

look at this and tell me exactly what is going on in this Application. It's,

Speaker:

it's pretty straightforward. Awesome. I'll take your word for it.

Speaker:

And and I'm fascinated by the idea, the, just the whole idea

Speaker:

of this. A little bit of company background. I'm just curious how long has Quill

Speaker:

been around? So Quill's been around for a little over 2 years

Speaker:

now. Started under a different name and doing something different,

Speaker:

actually. So, we're building a decentralized

Speaker:

social media. So, decentralized communication platform trying

Speaker:

to incentivize serving of data in, areas where

Speaker:

you're not, where you're disincentivized through data. So think Non

Speaker:

Western countries where there's enforced censorship,

Speaker:

and our goal was trying to serve data in those areas. No. That's

Speaker:

a massively hard problem, and there's Yeah. So many,

Speaker:

so many issues with, I mean, consistency and the Cryptographic,

Speaker:

like, verifiability of that data that, we we were trying

Speaker:

to solve that. And in solving that, we sort of solved this,

Speaker:

Database use case of building this decentralized database. And we ended up just running with

Speaker:

that instead because it was much more applicable to, A

Speaker:

wider variety of applications than just the specific one that we were

Speaker:

building. And so we spend about the 1st year building that

Speaker:

social. And then Last, January or February,

Speaker:

we, or yeah. Last January or February, we transitioned to

Speaker:

just doing the database specifically. Okay. Well,

Speaker:

I love the pivoting. I just do. I think that's always a good

Speaker:

thing to go with. And, you know,

Speaker:

I've seen many companies kinda go through these phases where

Speaker:

they'll do exactly what you did. They'll start out trying to solve 1 problem, realize

Speaker:

there's this other niche That they could really serve.

Speaker:

And then later, sometimes even expand back out. That

Speaker:

happens sometimes as well. But I'm old and I've seen a lot

Speaker:

of companies, so that that kind of

Speaker:

happens. Well, so we talked about,

Speaker:

Cuneiform, which is a language. You guys, I guess, invented that?

Speaker:

Yeah. You know, it's It's it's it's really a DDL

Speaker:

language. Like, it's not a whole, like, you know, full, full

Speaker:

language, but it's yeah. It's useful for defining access control. But, yes, that

Speaker:

was That was an old house. So talking about access

Speaker:

control, I know one of the, you know, one of the challenges to that

Speaker:

is Row level or even cell level, you

Speaker:

know, the access control. How how fine a grain do

Speaker:

y'all go to? It's a great question. So, there's sort

Speaker:

of 2 things I can touch on there. So the answer is technically

Speaker:

both. So, with Quill, or with with Cuneiform, we

Speaker:

have this concept of actions. And action, you

Speaker:

can sort of think of it like a function that Anybody can call. It's like

Speaker:

a it's an RPC call that anybody can call or you can set rules for

Speaker:

who's able to call it, and it executes some query against the database. So

Speaker:

this can be an insert statement. It can be a select statement. And so you

Speaker:

might have a select statement that is able to get some users

Speaker:

data, and maybe from May maybe it gets some data from a

Speaker:

few rows and retrieves a couple of the columns within that row. And so in

Speaker:

that way, you can sort of make custom access control for columns.

Speaker:

And then another thing we have and, let me know if this doesn't make sense

Speaker:

because this is a bit more of, like, a web three native concept.

Speaker:

But we have we call it a caller modifier. And so what this is

Speaker:

is that when you're interacting with Quill, you have a key pair, and

Speaker:

this is how we do User identification. And

Speaker:

so, when you are using, when you're using this key pair,

Speaker:

it takes the address of that sort of thing like a public key On

Speaker:

that, either you're signing your, your your your insert statement with

Speaker:

or your update or your select or anything else. And it can

Speaker:

use that Public identifier as a

Speaker:

parameter in an action. So, let's say we have an

Speaker:

application that is storing a list of user data. Let's say let's say it's

Speaker:

just storing your your name and your age and you're identified

Speaker:

by your by your key pair. You might only be able to go

Speaker:

and update the row where the, where the

Speaker:

caller matches your key pair. And so that means that You and Frank

Speaker:

can both have rows in the same database, but only you are able

Speaker:

to update yours. Only he is able to update his. You can also set access

Speaker:

control restrictions on Who is able to read from which ones?

Speaker:

Okay. Does that make sense? It does. That's a great example.

Speaker:

And, you know, especially using, like, customers slash

Speaker:

people table. And I I I'm I'm

Speaker:

impressed by the answer itself. I mean, that's that's a hard problem

Speaker:

to solve as well. So, and doing that and then

Speaker:

when we talk about user access, is this something that is

Speaker:

designed for use? Obviously, it's happening between

Speaker:

companies. You talked about competitors. Is this is this

Speaker:

setting in the wild Or are there, you know, ports open to the

Speaker:

big bad web? Sorry. Could could you restate that

Speaker:

question? I think I might have misheard you. That's okay. So I know you mentioned

Speaker:

that, the database and the access control controls access

Speaker:

between, competing entities, maybe companies that

Speaker:

compete with each other, But they wanna share some portion of data.

Speaker:

So I'm wondering, does is Quill hosted in such a way

Speaker:

that it can be accessed From the, you know, the web at

Speaker:

large, the entire interweb or Internet rather. I said

Speaker:

interweb. I was thinking that and going, don't say it. Don't say it.

Speaker:

The entire Internet. And and and if

Speaker:

so, you know, what are your concerns about

Speaker:

security? Yeah. So that's a great question. So,

Speaker:

once again, this does sort of come back to the the 2 prongs of,

Speaker:

Cuniform access control and then Mhmm. General network

Speaker:

access control for your database. So cuneiform access control, you can

Speaker:

sort of think of this like a rest API where, they they can you

Speaker:

know, It's a client server architecture and anybody can make

Speaker:

calls to the actions you have defined. So maybe it's get the

Speaker:

Get the most recent, you know, record inserted into the database,

Speaker:

or in into a table. May maybe that's an action you have and anybody can

Speaker:

call that and get the most recent record. And so in that way,

Speaker:

you have, I mean, configurable access control. So you

Speaker:

can make that totally public where anybody's able to access that. You can also

Speaker:

make it so only a specific white list of individuals

Speaker:

that you want are able to access that. And right now, how we identify those

Speaker:

individuals is with Key pairs. So,

Speaker:

now we're not specifically tied to the key pair structure. This is just,

Speaker:

it it's really just what our, early clients have needed, and so that's why we

Speaker:

use key pairs for, user authentication. And

Speaker:

then getting To, like, the general because you had

Speaker:

also asked about, people, just anyone in the Internet being able to access

Speaker:

this data. This gets a lot more into network

Speaker:

deployment topology. And so with this, you might have

Speaker:

a database network Where you know everybody that's running these, you

Speaker:

know, the infrastructure for it, and they are running that closed. So, you know,

Speaker:

like a private Postgres or, you know, MySQL server,

Speaker:

nobody like, you are the only ones that are able to access that or you

Speaker:

know everybody who's able to access it. But on the on the I guess

Speaker:

the flip side of that, you can also Run a version where anybody

Speaker:

can come and hook into your data, and it doesn't really cost you anything

Speaker:

extra. So the white list in that case would just be

Speaker:

everyone? Yeah. So, I I think a a

Speaker:

useful way to think about it would be in that case, everybody is able to

Speaker:

see the logs that are coming into your database. So Mhmm. You

Speaker:

know, we have the the actual consensus layer. So we don't use wrap. You

Speaker:

can sort of think of it like a wrap consensus layer. And then below that,

Speaker:

we actually have the data storage. So, they can

Speaker:

essentially come and be a part of that consensus layer. Maybe they can

Speaker:

only, read from it, But, they can come and read from these logs

Speaker:

before they're executed on the database. When you use Q2Form,

Speaker:

that is defining access control for them coming and accessing your

Speaker:

database. They can't see all of the logs. Does that make sense?

Speaker:

It does. And it's a interesting and and very powerful

Speaker:

sounding, paradigm that you've That you've surfaced there. And

Speaker:

it's not that I'm not throwing off on traditional relational databases

Speaker:

when I say that. It's, almost like a combination

Speaker:

of What you would expect from relational databases

Speaker:

or maybe even NoSQL databases, but built

Speaker:

on top of that is a little bit more beef In the

Speaker:

access control space. And that, you know, has

Speaker:

typically been the, kind of the purview of the application

Speaker:

developers. They manage that part. And it sounds like you've

Speaker:

baked that right into your, your database control.

Speaker:

So I I like that a lot. They're part of it.

Speaker:

It's a really interesting trade off because, you know, a lot of early

Speaker:

databases and this is true for, I would say, you know, I mean, Most major

Speaker:

ones, I believe SQL Server, but I know Oracle, MySQL, and

Speaker:

Postgres, they have baked in user access control that most people don't

Speaker:

really use. Most people actually go for access control, you know, at

Speaker:

their on, like, their API layer. Mhmm. But for

Speaker:

our case, because of the unique Environments that this is being used into, we

Speaker:

need to bake an access control logic in a different way than these

Speaker:

databases already do, but we need to bake that in directly to the data

Speaker:

itself. And that is what allows us to sort of open up

Speaker:

new use cases that previously were not possible. Go ahead.

Speaker:

Again, sounds very Powerful. And, I imagine

Speaker:

business is growing. Yeah. Yeah. It's going quite

Speaker:

well. That's that's excellent to hear. I always,

Speaker:

I enjoy hearing success stories. They, they inspire me as

Speaker:

well. Gosh. I'm trying to think of

Speaker:

Some more stuff about it. I got I got my head around the basics, I

Speaker:

think, but it's gonna be I know me. It's gonna be, like, 8 o'clock tonight.

Speaker:

I'm gonna go, I should ask him this. It's

Speaker:

all good. Yeah. I think you're running this 1 this 1 solo without Frank right

Speaker:

now. So Well, yeah. And Frank thinks, So Frank thinks differently,

Speaker:

than I do. We're we both started as,

Speaker:

developers and then we moved into data.

Speaker:

And in Frank's case, I had to beg him for about 10

Speaker:

years to get him to go into data, specifically business

Speaker:

intelligence, Because Frank is an artist at heart,

Speaker:

so he already does pretty pictures, you know, and I still can't color in

Speaker:

the lines. So I was like, you can do this whole analytics thing,

Speaker:

Frank. You've got a good eye for it. And he got there. It was

Speaker:

just he kinda Came around it at a different way. And he's told me about

Speaker:

a 100 times, you were right. Should've done that years

Speaker:

ago. But, And he's a he he

Speaker:

because of the way he thinks, it's it's different than the way that I

Speaker:

think. I kind of approach I don't know. I'm not saying right or wrong. I'm

Speaker:

not Comparing and contrasting. It's just different.

Speaker:

And and I work with a number of people in in different fields where

Speaker:

It's it's very productive to work with. Frank's as a Frank's more of

Speaker:

a data scientist, but he's also a data engineer. He's old school data

Speaker:

science. And I I work, of course, I

Speaker:

work well with him. We were we were friends before we started working together. And

Speaker:

then, a handful of database administrators, I

Speaker:

find it because I whenever I see a problem that needs to be solved,

Speaker:

my developer roots are my first response. That's my knee jerk.

Speaker:

Let's go write some code, you know, to do this in some language and try

Speaker:

and figure it out that way. And my DBA friends are all, well,

Speaker:

You know, we can store some business logic here in a view or a store

Speaker:

procedure and access it that way. And it's it's it's

Speaker:

a different approach. I but I'm You know, I know enough

Speaker:

about both to be dangerous, I'd say. And that's why I'm I'm very it's

Speaker:

very appealing to me. I I've done a little bit of web work, there

Speaker:

for a while. Not not in your

Speaker:

league. I built a website that began to get a little popular

Speaker:

and I hired a web developer to take a look at it

Speaker:

And he looked at it. He cut he his first response to me was, this

Speaker:

looks like an engineer built it. And I'm like, I am an

Speaker:

engineer. That's I thought I took it as a compliment. You laughed because you know

Speaker:

it's not a compliment. Yeah. It's interesting.

Speaker:

We I kinda suffer from the same thing. You know, very very

Speaker:

engineering focused. We have a very engineering focused culture. Like, everyone at our

Speaker:

company writes code, even the guy that does our finances and payroll.

Speaker:

Wow. Everybody here is now in different amounts,

Speaker:

obviously, but Sure. Everyone writes code, and so when it gets to a bit

Speaker:

more of the creative side, I I don't wanna say

Speaker:

we we struggle there, but it's where we have struggled a bit in It's something

Speaker:

we've gotten quite a bit better at. But, yeah, we you can tell our

Speaker:

applications were built by engineers. They're it might not be the prettiest

Speaker:

thing in the world, but they're they're very Pragmatic. Yeah.

Speaker:

Absolutely. So And and see, I don't even notice, when I

Speaker:

see things like that. I don't I don't even notice them. But Frank's back so

Speaker:

we have to stop talking. Well, talking bad about him. We can talk about him

Speaker:

still but we only have to say the good things. Welcome back, Frank. That's

Speaker:

funny. Thank you for your patience. One of these days, I will explain all

Speaker:

of this publicly to our listeners and And whatnot, but,

Speaker:

there's a good reason for my absence there. Yeah. No.

Speaker:

I heard about, it it I heard this funny thing, and this is how Andy

Speaker:

and I met where, you know, you You said these apps look like they're written

Speaker:

by engineers. And that's kind of this back and forth

Speaker:

Andy and I have about, like, Design and whatnot.

Speaker:

So Rank food designer. Yeah. So Brennan

Speaker:

was explaining to me that everyone at Quill codes.

Speaker:

Really? Even the even the finance people. Interesting.

Speaker:

Well, Fortis, we're we're a 7 person team. You know, it's not like we're a

Speaker:

we're a huge company. But, yeah. Everybody I mean,

Speaker:

everybody knows how to code and writes some amount of code.

Speaker:

They might not have done that when they came in, but they they picked it

Speaker:

up in one way or another. How do people react to that? Do they like

Speaker:

the idea, or do they kinda bristle? Or you tell them in the interview

Speaker:

That, hey. We're doing this. So it's interesting. We it's

Speaker:

not like we hire people, like, yeah. You will learn to code when you come

Speaker:

here. It it's almost just an inevitability. We're we're solving a very

Speaker:

technical product for a very technical group of users. Right. And

Speaker:

so it's sort of inevitable that, you know, you're you're gonna learn how to

Speaker:

How to code to some extent, working in that job,

Speaker:

really no matter what, like, what role you have. And so it it's not like

Speaker:

a hard fast rule. We have the company where you to learn how to code.

Speaker:

It just it inevitably has happened every

Speaker:

time. So Interesting. Yeah. And Frank, the

Speaker:

I'll give you my understanding of a synopsis of of

Speaker:

what what their database does.

Speaker:

It's It's like a relational database, but built

Speaker:

into it is this user access control. And

Speaker:

it's, like, coupled, to that to the extent that they

Speaker:

can do not only row level, but row column level security and

Speaker:

access control. Interesting. How do I do, Brennan?

Speaker:

Yeah. No. I I'm I I I think that's good for a high level overview.

Speaker:

I think it's good for a high level. But I'm happy to sort of jump

Speaker:

into any of the specifics that you'd like, Frank. So

Speaker:

so tell me, How do you

Speaker:

how does that work? You do role level control or cell level control? Is it

Speaker:

is it role based access control, attribute access control,

Speaker:

Some combination? Yeah. So,

Speaker:

kind of neither. So, we do authentication with key pairs. So

Speaker:

anybody who wants to use a database, they have to have a, a public

Speaker:

private key pair, like an e c v e c d s a key pair.

Speaker:

And you can set rules for what keys are

Speaker:

able to do what in your database. And and so we have

Speaker:

our own language for defining this. We call it cuneiform. It's

Speaker:

cuneiform was the first ever written language. We thought that might be fitting

Speaker:

for our our language. And so our language, it's a it's a DDL language.

Speaker:

So, it sort of specifies the structure for your database,

Speaker:

and then all of your DML is done with, SQL.

Speaker:

But, with this DDL language, you can specify what

Speaker:

we call actions, and you can sort of think of these like RPC calls or

Speaker:

functions Where, they they're gonna execute some

Speaker:

DML against the underlying database. So this could be an

Speaker:

insert or an update or a delete or it can be a select. And you

Speaker:

can set all these interesting rules for who is able to do this, when

Speaker:

they're able to do this, do they have to transfer some sort of

Speaker:

value and able to do this Either once or every time they do it,

Speaker:

or do they have to have, some role that applies to them that

Speaker:

allows them to do this? And, You know, since we're able to identify

Speaker:

people by their key pair, when Andy comes in and uses

Speaker:

and, you know, interacts with the database, I can tell that he is distinctly different

Speaker:

from you, and I know what Andy is allowed to do. And there's even

Speaker:

a small amount of programmability that can be fit into that. So, you

Speaker:

know, when Andy is hitting one of those actions or RPC

Speaker:

calls, that might give him, results or

Speaker:

allow him to do certain things that you would not be allowed to do if

Speaker:

the database is configured that way. Interesting.

Speaker:

Interesting. So you have really fine grained control over what who can

Speaker:

do what? Yeah. You know, I I might hesitate to

Speaker:

say Fine grained because it's

Speaker:

it it is fine grained. You can really set whatever, however you

Speaker:

can think to specify what someone can do in SQL, you can you

Speaker:

can really do that with access control. But we don't implement

Speaker:

it with a fine grained approach. I think a lot of the time, databases that

Speaker:

are really trying to iterate on the access control front,

Speaker:

they they get really into row and column level

Speaker:

access. And that's not quite what we do.

Speaker:

We sort of see our role as, you know, an iterating for access

Speaker:

control on 2 different layers. The first one is on the actual consensus

Speaker:

layer. So, you know, if you think in a traditional data system, this is where

Speaker:

your raft consensus logs are are sitting before they get executed on your data

Speaker:

layer. We don't use Raft, but, so that is the

Speaker:

1st place where we able to have access controls. So this is, you know, network

Speaker:

wide access control, Who can read what data coming in?

Speaker:

And then secondly, we define, and this is for more

Speaker:

client server access control, or for people that are trying to

Speaker:

read from the database, at any point in time, but you can think of

Speaker:

this I don't wanna say like a REST API, but a little bit more like

Speaker:

a REST API than traditional database where you can have

Speaker:

preset queries and, preset functionality that

Speaker:

certain people are able to do or Certain groups of people are able to do

Speaker:

in certain instances. But the ways

Speaker:

that you can combine these things, You can you can you can

Speaker:

combine it to do very granular access control, but that's not really where

Speaker:

we attack the problem. Where did you get the idea for this?

Speaker:

Because this is fascinating. Yeah. So it's interesting.

Speaker:

It's been a little bit of a of a of a ride. So,

Speaker:

we started by building a a decentralized

Speaker:

communication platform. So really trying to incentivize,

Speaker:

serving data in places where you're otherwise disincentivized. So

Speaker:

think non Western countries where there's enforced censorship or IP

Speaker:

blocking. How can we incentivize people to use things

Speaker:

like HTTP tunnels to, spread data? Not

Speaker:

really hard to build a business on that. And so sort of how we

Speaker:

iterated from there was we took the data infrastructure for that, and we started

Speaker:

providing that as a stand alone service. And this is actually where the access control

Speaker:

part of this Really interesting. We started talking to a

Speaker:

lot of projects that, you know, they're building some sort

Speaker:

of data store. They have some data intensive application, but they're not

Speaker:

looking to build that as a data moat. They're looking to build that as a

Speaker:

composable, you know, data building block that other applications are

Speaker:

able to directly import. Just like how you import a line of code or, you

Speaker:

know, a package of code into your application, you should be able to do that

Speaker:

with data as well, assuming you you're applying to all the different access

Speaker:

controls. And so what we're helping a lot of customers do

Speaker:

now is they can take their different datasets and,

Speaker:

people whether they're collaborators, clients, or competitors,

Speaker:

they can use that data in the ways that, that that

Speaker:

the, you know, originator the original data creator specifies.

Speaker:

And then also they can set interesting mechanisms for how value accrues

Speaker:

back to them. But it's really just been a process of

Speaker:

iteration from, You know, that initial idea of building shared

Speaker:

data stores and then, building more complex access

Speaker:

control mechanisms on top of that.

Speaker:

Does that make sense? No. It makes a lot of sense. It's a fascinating it's

Speaker:

just fascinating, because every time you think that we've we've we've Kind

Speaker:

of solved all the problems, particularly in the in the in the

Speaker:

data storage, in the data querying side of things. There's a whole new

Speaker:

layer that gets on call unfolded, and There's just enormous

Speaker:

opportunity, and, it's really cool because, like, I'm reading your bio, and, like,

Speaker:

you were still in school when you started this company, like, that's and you you

Speaker:

started Your first company when you were 16, and you had

Speaker:

15 you had 15 employees before you even go on 15 or

Speaker:

16 employees before you even go on to college, man. That's that's impressive,

Speaker:

I have to say. Yeah. I mean, I appreciate it. It's honestly just been a

Speaker:

lot of being in the right place at the right time. Not my first company.

Speaker:

It was not a tech company. It was Digging holes and, cutting

Speaker:

down trees and digging up bushes in Idaho.

Speaker:

But that was that was my first company. And then this

Speaker:

one, I started, during COVID on a gap year, from

Speaker:

college. But Very cool. It's honestly just been,

Speaker:

Being in the right place at the right time and, doing something that people find

Speaker:

interesting. That is so cool. I mean, like, you think

Speaker:

about the last couple years, A lot of people would say, oh, it's a terrible

Speaker:

time to start a business, but we've seen a couple of instances where it's actually

Speaker:

turns out to be a really good, like we talked to a bunch of folks,

Speaker:

some, So probably by the time this goes out, the shows will be out, but,

Speaker:

like, this whole there's this whole opportunities that I think are

Speaker:

just popping up left and right because of data, Because of AI,

Speaker:

because of, you know, distributed applications and stuff like

Speaker:

that. There's just it it's We're gonna look back on the

Speaker:

as these as the good old days of entrepreneurship and and opportunity.

Speaker:

Yeah. Hopefully. And and, you know, I I I would say that is actually,

Speaker:

like this the last, year, maybe

Speaker:

18 months has been probably the only time where we could have

Speaker:

started a a, a product like this. So

Speaker:

particularly in the growth of web 3. A lot of our beachhead markets

Speaker:

are sort of bridging that gap from, the traditional

Speaker:

space to web 3. We find a A lot of

Speaker:

our initial partners, they have a lot of their clients are

Speaker:

based in the traditional world, but their data engineering problems

Speaker:

are uniquely solved by what is provided in web 3. And

Speaker:

there's enough demand for this, for our specific solution to

Speaker:

to warrant a product. You know, it's only really existed in the last,

Speaker:

year or so. And so yeah. I you know, whether

Speaker:

or not this is a good time to start a business, I would say, 1,

Speaker:

I don't know, but also, I don't think, I I care too much. Like,

Speaker:

the need for what we are doing has really only just started existing, But it

Speaker:

very clearly does exist, and that's that's something that's pretty exciting

Speaker:

about it. So you said web 3, and I It's interesting

Speaker:

because when when most people think of web 3, they think, they

Speaker:

think blockchain. Right? And thanks to SPF that is kind of

Speaker:

cratered, I would say, although I I I am still don't

Speaker:

the crypto kids better not hate on me, like, I'm still a believer in blockchain

Speaker:

as a whole, as as an idea. I don't think I think currency is only

Speaker:

one of the things that you can do with it. And

Speaker:

2, the the the metaverse. Right? And obviously, I think the

Speaker:

metaverse, Obviously Facebook is stumbling on it like but

Speaker:

but it's interesting that the data portion of it is probably more

Speaker:

relevant than any of the other 2 and you don't hear the negative press about

Speaker:

Kind of this distributed data stores in into the,

Speaker:

I I just interesting. I think that you're part of the web 3. Have

Speaker:

you found that the labeling yourself part of web 3 has been a,

Speaker:

has turned from a positive to a negative, basically? Yeah.

Speaker:

I think so. Yeah. You know, some people, they might get

Speaker:

kinda turned off on it. You know, you might talk to a candidate, and when

Speaker:

we say we're because we do classify ourselves as a web 3 company.

Speaker:

Right. And when we say that, they're like, oh, like, you know,

Speaker:

I I don't really believe in that cryptocurrency stuff. And I I I

Speaker:

think that's fine, but I don't think web 3 is cryptocurrency.

Speaker:

Right. I mean, web 3 is a new type of distributed application

Speaker:

or distributed databases, honestly. We do,

Speaker:

I I I would say not just distributed, permissionless. Decentralized

Speaker:

Mhmm. List. That makes sense. With Web 3 applications were able

Speaker:

to relax a lot of the trust assumptions that are

Speaker:

made in other applications, in particular trust assumptions Between

Speaker:

the client and the server. And so

Speaker:

that's like, just forget about cryptocurrency and the metaverse

Speaker:

And tokens with dogs on them and everything else, that is what web

Speaker:

3 is. It is relaxing trust assumptions in, you

Speaker:

know, otherwise More traditional, you know,

Speaker:

client server and oh, not in client server, but it's just like general,

Speaker:

computer architecture models. And so that's what we are doing. You

Speaker:

know, I don't really care what the price of cryptocurrency does. I don't own any

Speaker:

cryptocurrency. Right. We're just building, you know, trustless

Speaker:

applications. That's a good way to put it because when you, you know,

Speaker:

you're obviously your company's doing well and and and and you're growing and

Speaker:

and you've had a pretty, you know, good run. Well, so you just said web

Speaker:

3 and I'm like, but but you're doing well.

Speaker:

I was like, but but but then then then then like, you know,

Speaker:

after you That's why I wanted to ask that. Now you explain it. You're right.

Speaker:

Like, web 3 is, you know, it's kind

Speaker:

of like, kinda like Beyonce. Right? Like, nobody hardly anyone remembers

Speaker:

What group she was part of. Right? I think, God, Destiny's Child.

Speaker:

There were like 3 or 4 singers in there. Right? But but, you know, one

Speaker:

of them one of them Has the the the fame and staying

Speaker:

power, the other ones not so much, no disrespect to them, if the

Speaker:

weird off chance that they're actually listening to a show About AI and data

Speaker:

science, but, you know, no. I just it's just interesting, like,

Speaker:

you know, and we think of all these technologies, like, I'm old enough to remember

Speaker:

1 web one o. Right? And all the crazy ideas,

Speaker:

particularly one of them was, you know, downloading Java

Speaker:

applets. Right? Downloading software from The Internet and

Speaker:

running it locally. Right? Well, that's called the app store now, we don't even think

Speaker:

about it. Right? But obviously, there are a lot of things that failed in that

Speaker:

era. Right. Same thing with web 2 point o, we're kind of saw that kind

Speaker:

of come and go, and I think the same is gonna be true here, you

Speaker:

know, like, you know, did we really need, You know, sock

Speaker:

puppets to sell us stuff, you know, sell us dog food. Right?

Speaker:

And but, you know, I remember very early

Speaker:

on there was a startup called, they were all the Java people

Speaker:

who made Java basically, started a company called Castanet or

Speaker:

Rumba, I forget Which one it was. But their big thing was they wanted to

Speaker:

create what we would call an app store, but for applications.

Speaker:

Right? And and that idea Resurface somewhere completely

Speaker:

different and now it's just part of, like, just the daily world we live

Speaker:

in. So it's it's interesting. I think that We always seem to

Speaker:

remember the Hindenburgs of history, but not necessarily

Speaker:

kind of the The the the the stuff that actually does work

Speaker:

out. Oh, absolutely. And I I think that'll be the the case with,

Speaker:

you know, web 3 as well. A lot of the

Speaker:

people, in particular, a lot of the really loud people that we're that we're

Speaker:

operating in web 3, you know, now that the The the prices of things

Speaker:

are down. They've kinda gone on to whatever the next thing it is they're gonna

Speaker:

do to try to make a quick buck. But the people that are building really

Speaker:

useful and interesting things, Most of them will stay around. You know, some of

Speaker:

them will fail. You know, businesses fail. But,

Speaker:

you know, it's something I've noticed, because I was also here when web 3 was

Speaker:

really popular, right, when when working in web 3 was the cool thing to be

Speaker:

doing. And something I've noticed is that The

Speaker:

people that are building actually useful applications and solving actually

Speaker:

hard problems, they're still here. You know, they're not

Speaker:

as loud as the other people that were here Or but that that's fine.

Speaker:

Like, the the actual core problems that we want to

Speaker:

solve are still being solved, and and I I think that there's a lot of

Speaker:

value in solving those problems. And so,

Speaker:

there's less people, but there's a higher concentration of High

Speaker:

quality people building in the space now, and I think that's what matters. Well and

Speaker:

now that it's quieted down some, y'all can get more work done. That

Speaker:

is, very true. That's very

Speaker:

true. Yeah. Which has also been quite

Speaker:

helpful. Well, we are gonna transition, to

Speaker:

the questions part. I hope you got a copy of Questions in advance. If you

Speaker:

didn't, I put them in chat. So if you'd like to, peruse

Speaker:

them. The very first one is, I think you've explained

Speaker:

it, But, it's a it's a softball,

Speaker:

for you. How did you find your way into data? Did,

Speaker:

data find you or did you find data? Yeah.

Speaker:

So I kinda inadvertently found my way into data. So I wanted to

Speaker:

solve this other problem that was present in the messaging

Speaker:

application. And, that really required me to dive I

Speaker:

don't wanna say super deep into data. It required me to dive super deep into

Speaker:

a few things, but it was in building

Speaker:

infrastructure for that that I found that there there was a real

Speaker:

opportunity if I went and, you know, doubled down and went even deeper into

Speaker:

data. And so, you know, for me, it was really just

Speaker:

kinda looking at, at what the market wanted, you know, when we're

Speaker:

working with design partners and potential customers, What is their feedback? And it

Speaker:

kind of pointed towards going deeper into data. And so that's how I found my

Speaker:

way into it. Nice. Interesting. So what's

Speaker:

your favorite part of your current gig?

Speaker:

So I would say, like, the the team I work with. So our

Speaker:

team is really tight knit. Most teams now are remote.

Speaker:

Almost every startup now is a remote startup, especially in the,

Speaker:

you know, quote unquote web three space. We're in person. So,

Speaker:

you know, the entire team is in the room right next to me. And, honestly,

Speaker:

we're all really close. We all really believe in the problems we're solving. We do

Speaker:

believe we're building a better and more fair Internet. And so that

Speaker:

makes it really fun to work here, you know, even if the hours might be

Speaker:

a little longer than they would be at another job. It's

Speaker:

it's really fun to work here. We all really get along, and, we work well

Speaker:

together. And so that's certainly my favorite part. And you're in Austin now. Right?

Speaker:

We are in Austin. Yeah. Our team is a really thriving tech scene right

Speaker:

now. Yeah. Yeah. If you're if you're young and work in tech, it's the the

Speaker:

place to be. And so it's very Awesome. Awesome.

Speaker:

So we have 3 complete the sentence statements, not really

Speaker:

questions. The first is when I'm not working, I enjoy

Speaker:

blank. Yeah. So I am I'm a

Speaker:

not a I live in Texas, I guess, not as much. But, I'm a really

Speaker:

big skier. So I grew up snow skiing. That's

Speaker:

cool. Yeah. I I'm from Idaho, and so it's kind of a

Speaker:

common thing there. And so, yeah, I did a ton a

Speaker:

ton of skiing growing up. I do, I ski raced. I do backcountry

Speaker:

skiing now. So a lot of, like, hiking, skiing, like, like, avalanche training, stuff

Speaker:

like that. Yeah. I would say that if I, you know, if

Speaker:

I was no longer working, and I I couldn't,

Speaker:

You know, I I love what I do, and I would do it, you know,

Speaker:

even if I wasn't making money doing it. But if I was no longer working,

Speaker:

I would probably go skiing. Very cool.

Speaker:

Another complete the sentence. I think the coolest thing in technology

Speaker:

today is? Yeah. So,

Speaker:

I'm I'm a little torn here. I think either,

Speaker:

permissionless networks. So, I mean,

Speaker:

people usually think of this as cryptocurrency layer ones, but I

Speaker:

think it extends sort of beyond that. But Any network that is permissionless and

Speaker:

allows people to it it functions as as a protocol,

Speaker:

and it doesn't have biases towards individuals. I think that's really

Speaker:

interesting. It has a lot of potential, or SQLite. I really like

Speaker:

SQLite. I think it's a really awesome piece of technology. I know it's

Speaker:

Not exactly the newest thing, but I think it's still of the things I've

Speaker:

worked with, SQLite is really cool. Nice.

Speaker:

Alright. Our last one, I look forward to the day when I can use

Speaker:

technology to blank. Oh, interesting. Interesting

Speaker:

question.

Speaker:

I think for me, I I'm really looking forward

Speaker:

to being able to use and I I I think we're we're almost

Speaker:

there. But being able to use,

Speaker:

AI programming to help us write unit tests and get full

Speaker:

context of our code base, I've been using GitHub Copilot

Speaker:

for, I think, maybe 9 months now, 8 months now, and it's

Speaker:

honestly changed my life. It's I don't know if you guys have

Speaker:

used GitHub Copilot. Would highly recommend trying it. It

Speaker:

has just my productivity has skyrocketed. And

Speaker:

now it's only able to handle a fairly small set of context. Like,

Speaker:

I believe it only has context for the file or maybe a couple of the

Speaker:

most recent files you've worked in. But, you know, there

Speaker:

there have been a couple, demo models, and, unfortunately, they're in private beta

Speaker:

right now. But where there are AI AI models that

Speaker:

can help you generate unit tests, and they can read through an entire

Speaker:

package of code you've written and see, oh, you might have a security vulnerability

Speaker:

here, or, Are you sure you actually meant to expose this in your

Speaker:

public API? Just those are sort of a lot of the foot

Speaker:

guns I still find myself running into. And I think we're almost at the

Speaker:

point where, that that, is is solved.

Speaker:

Wow. Very cool. Would highly recommend trying out Copilot if

Speaker:

you haven't. It's been it's been pretty crazy. I will check it

Speaker:

out. Yeah. I've done a couple of demos with it, you know, just to

Speaker:

it's kinda like, you know, walk through, follow the instructions type stuff.

Speaker:

It's not the same as when you're trying to solve a real a real problem,

Speaker:

real world problem. So I know enough to know that. I was still

Speaker:

impressed, But I haven't yet taken it to that next level.

Speaker:

Yeah. You know, it it's not super useful for writing large blocks

Speaker:

of code. Mhmm. It is useful as autocomplete.

Speaker:

So, I mean, like, a place I use it,

Speaker:

most of our stack is in Golang. Golang has pretty verbose error

Speaker:

handling. It's really helpful with that.

Speaker:

Like, just with that alone, it's doubled my productivity because it pretty much handles all

Speaker:

of the error handling for me. Wow. So That's impressive.

Speaker:

Very cool.

Speaker:

Share something wait. Which question did we

Speaker:

do? Yes. Just share something that's next in that list, But that's

Speaker:

my list, and it may be out of order. No. No. No. It is. Here's

Speaker:

something, different about yourself. But remember, we like to keep

Speaker:

our Itunes, clean rating. Yeah.

Speaker:

Oh, man. That's a that that's I think that's the toughest

Speaker:

one yet. I I had scanned through these

Speaker:

questions before the podcast, but I, I

Speaker:

did not think of this one.

Speaker:

Man, let me think about 1 for a sec. I don't

Speaker:

know. If you don't mind me asking, what would, what would your answers for this

Speaker:

be? And maybe that'll help me come up with something. Oh, I mean, like, one

Speaker:

of 1 of mine was, because we did this on on each other. We should

Speaker:

probably reupdate, Andy. Because I used one of my

Speaker:

first jobs was I was an EMT in the Bronx. Okay.

Speaker:

Yep. And for me, I I have a similar one to Frank.

Speaker:

I played guitar in a country rock band. Okay.

Speaker:

Wow. That's that's really cool.

Speaker:

Oh, man. I already brought up the the skiing thing. That one's tough.

Speaker:

I mean, how did you here's here's 1. I'll help you out. Like, how did

Speaker:

you start a landscaping company? Like like, when you were 16, like, how many 16

Speaker:

year olds do you know that just say, you know what? I'm gonna, Like, how

Speaker:

did that happen? Like This is impressive. Sure. Yeah. The the thank

Speaker:

you. I appreciate the help here. No problem. It's,

Speaker:

so I I grew up in Idaho, and we were we're a ways outside of

Speaker:

Boise. And so we had quite a bit of land, and it wasn't, you know,

Speaker:

nice. I mean, it it it built around. It's just like a Great place to

Speaker:

live, but it wasn't like, like like you know, we had to do it

Speaker:

like firebreaks, you know, a lot of irrigation work, things like

Speaker:

that. And so, growing up,

Speaker:

we wouldn't you know, me and my brothers were really young, we had a guy

Speaker:

who would come and help us do that. But as we got older, we started

Speaker:

our family did it ourselves. And he hired me,

Speaker:

and I would just kinda help him as an extra hand. He did this for

Speaker:

people all over. And I just kinda had a realization not that far into the

Speaker:

job. It was like, man, I could definitely do this myself, and I think I

Speaker:

could, you know, probably pay myself a little bit better.

Speaker:

And so I just, I I started small, started

Speaker:

with 1. Like, I didn't immediately quit my job or anything. I did quit my

Speaker:

job fairly quickly. But, I started with a couple small clients

Speaker:

just seeing if it was something I can handle. None of it was rocket science,

Speaker:

and so I figured that out. I started scaling up more

Speaker:

from, like, you know, mowing lawns to fire

Speaker:

breaks And digging in drainage ditches, a little bit of demolition work.

Speaker:

It's just a a bit higher margin. But, yeah,

Speaker:

honestly, just started 1 step at a time. I got 1 client. I got 2

Speaker:

clients, and then I got 10. I had a couple buddies that would

Speaker:

come out and help me. And it was just really you know? As opposed to

Speaker:

a business like like this one where it's, It was very technically focused,

Speaker:

and you're raising VC dollars and things like that. This was, I I

Speaker:

I worked out of a Ford Escape until I could afford a pickup truck. And

Speaker:

then I bought a pickup truck, and then I So it was it was it

Speaker:

was a little bit of a different process. But, yeah, that was kinda how I

Speaker:

got into it. No. That's cool. That is cool. Do you listen to

Speaker:

audiobooks? It's funny. I just saw that question.

Speaker:

I just got an Audible subscription 2 days ago.

Speaker:

Wow. Yeah. One of my coworkers recommended a book to me, And

Speaker:

I don't have a lot of time to actually sit down and read, but I

Speaker:

walk a lot. And so, I got Audible for that. So,

Speaker:

I'm It's a really good book. Would really recommend. It's called

Speaker:

Children of Time. It's like if you're into sci fi Mhmm. It's like a

Speaker:

postapocalyptic sci fi book where, they're humans.

Speaker:

They've they've left Earth, and they're, I I forget how far, but they're

Speaker:

they they've been traveling for, like, 2000 years, and they're now trying to recolonize a

Speaker:

new planet. And it's just sort of all the I

Speaker:

don't wanna spoil too much, but, it's about that. But it it's it's really

Speaker:

good. If you like sci fi, I would highly recommend. I'll check it out.

Speaker:

And, you can check it out too to our listeners.

Speaker:

Audible is a sponsor of the show, and you go to the data driven book

Speaker:

.com Or the data driven book .com depending on how you want to pronounce

Speaker:

it. Andy assures me that that link is

Speaker:

working and, I have my faith in Andy.

Speaker:

It was working a couple of hours ago. We did another recording. It's a

Speaker:

2 recording day, and it's working then. Yeah,

Speaker:

no, no. It could have been, it could have been my setup. Cause I was,

Speaker:

I was doing some weird stuff with DNS to get something else working on. It's

Speaker:

always DNS Frank. It's Always DNS.

Speaker:

So where can people I'm sorry. Go ahead, Andy. That's okay. You you do it,

Speaker:

Frank. I was gonna say the same thing. Where can people learn more

Speaker:

about you and what you're up to? Yeah. So, I mean, the first one is

Speaker:

just our website. So quill.comkwil.com.

Speaker:

I've also got a Twitter. That's probably the easiest way to get to me. So

Speaker:

my Twitter is just my name, so Brennan underscore Lamy.

Speaker:

But you can also find links to Quill's Twitter and inevitably to

Speaker:

to mine as well on our website. So I would say the biggest one is

Speaker:

just go into quill.com. It's probably the easiest.

Speaker:

Okay. Excellent. That sounds good. Yeah. And, any

Speaker:

parting thoughts? No. I don't think so. I mean, really, thank

Speaker:

you thank you all for having me. I it it's hard to find

Speaker:

people that, are as passionate about, you know, weird data engineering problems as I

Speaker:

am, and so it's really been a pleasure. Awesome. We're

Speaker:

happy to talk to other people who are into Data engineering, too. Well, that was

Speaker:

quite the show. Alright. I'll let go of it. It's always good to hear a

Speaker:

good entrepreneur origin story. One last thing

Speaker:

before you go. We know you're busy and we appreciate you

Speaker:

listening to our podcast. But we have a favor to

Speaker:

ask. Please rate and review our podcast on Itunes,

Speaker:

Stitcher, or wherever you subscribe to us. You

Speaker:

have subscribed to us? Haven't you?

Speaker:

Having high ratings and reviews helps us improve the quality of our show

Speaker:

and rank us more favorably with the search algorithms.

Speaker:

That means more people listen to us, spreading the joy.

Speaker:

And, Can't the world use a little more joy these days?

Speaker:

So, go do your part to make the world just a little better and be

Speaker:

sure to rate and review the show.