Blockchain Weekly this week CEO Brian Platz and Flip Filipowski of Fluree Produced on Jan 12, 2018

18:22 / 1:00:40

Transcript

00:01
[Applause]
00:01
[Music]
00:06
[Applause]
00:06
[Music]
00:10
hey guys my cool here blockchain week
00:14
league what a week it has been in a
00:18
blockchain space so many things
00:21
happening
00:23
it's incredible to count I will kind of
00:26
give you guys an update I did Day on
00:29
Monday of this week I did an event for
00:33
the Southwest security professionals
00:35
group which is some pen testers some
00:38
sass minions that are interested in
00:40
blockchain I was asked to present at the
00:44
event a month a month ago and I sat down
00:48
in a month ago I jotted down some things
00:50
that I needed to talk about I put
00:51
together some slides what happened was
00:55
when I went to the to grab my slides and
00:57
start my presentation work on my
00:59
presentation on Monday morning I
01:01
realized and it don't have been a couple
01:03
of weeks and most of the stuff that I
01:05
was talking about it already become all
01:07
bad really not that interesting it's
01:12
really there's some things happening
01:14
with etherium there's something
01:17
happening if it goes don't know whisper
01:19
you haven't looked at whisper then you
01:22
probably should if you haven't looked at
01:25
swarm and you probably should swarm is
01:27
the etherium a version of dns whether
01:32
it's hosting whisper is the distributed
01:35
ledger kind of messaging that goes on
01:40
really interesting stuff blockchain
01:44
continues to bang it out of the ballpark
01:47
you know miners if you're minor if you
01:51
can see let's see I've got a testimony
01:54
we're going right now I'm testing 1080s
01:56
doing some mining for ether and I'm just
02:00
watching the GPU stuff go up and happen
02:03
up there's a couple of things that are
02:07
kind of hinting at the fork for
02:11
aetherium the last Vulcan was on a vent
02:17
and I can publish that the link for you
02:20
here fairly quickly he was on
02:23
on an event Monday and was wearing a
02:27
hard fork cafe t-shirt is it a theory
02:30
among itself we can have we can
02:32
automatically assume what he's working
02:33
on lots of things happening in this in
02:36
this world and it's just it's becoming
02:39
mind-numbing the changes and how quickly
02:42
they come anyway I want to thank you
02:44
guys for coming to blockchain weekly
02:46
this is a weekly event when we get
02:48
together and we kind of talk to someone
02:51
or a couple of son ones we've got some
02:53
really interesting guests today Brian
02:57
and flip of flurry which is a database
02:59
company blockchain database company
03:02
they've got some interesting that for an
03:05
interesting product and I think you're
03:07
going to enjoy this I really do and
03:11
they'll be on in just a moment but here
03:13
at blockchain we try and talk about
03:16
things that are that are looking at the
03:20
Internet of trust as opposed to the
03:23
Internet of value what do I mean by that
03:25
you know we have the internet we have to
03:27
eat we have the internet we have the
03:29
Internet of Things and that's the
03:31
frigerator that talks to Amazon and yes
03:34
you Mel we have the Internet of data
03:35
that's remarketing and target marketing
03:38
and that kind of stuff you get the
03:39
internetter value that's like a Bitcoin
03:40
Bitcoin has a way to store value and
03:43
transfer Adamo on the internet really
03:45
quickly we can the internet have trust
03:47
even of their trusses what's happening
03:49
now with aetherium and smart contracts
03:51
were actually able to take trust put it
03:54
on the internet and transfer trust and
03:55
up you know smart contract it's like if
03:58
this that argument for for hang on just
04:04
a second I forgot I need to record this
04:09
the internet value is what we're talking
04:11
about today we're talking about
04:12
different things within the internet our
04:14
value for the complicate matters
04:16
I am administrating this shindig for the
04:18
first time and probably not going to do
04:20
a very good job of it so it's going to
04:21
be a rough ride folks so make sure that
04:24
you keep your your seat in the upright
04:27
position and keep your tray tables up
04:30
and I'm gonna bring on welcome to
04:34
watching weekly works
04:35
about having you here with flurry and
04:38
why don't you take it away it's been
04:40
kind of a rough start for me today
04:43
once you got it kind of go ahead and
04:45
that and take over kind of give us some
04:48
indication of who you are why you're
04:51
here you know some indications on what
04:53
your thinking about the blockchain space
04:55
and what you think might have might be
04:57
happening in the future so yeah so we
05:00
have started a project actually we
05:02
started about three years ago
05:04
to facilitate a platform that could
05:07
power D central application
05:08
decentralized applications and there's
05:11
several components to this and really
05:13
the first and the one that we've now
05:15
released in beta form that anyone can
05:17
sign up for and utilize is a database
05:22
and it's a we call it flurry DB so we're
05:25
not too creative about this pretty
05:27
simple name flirty DB and it is a
05:29
database for blockchain technology ah
05:34
yes so this really aim to do two things
05:38
is Fleury DB and besides being a
05:41
foundation for sort of distributed
05:43
enterprise application but it aimed to
05:46
be a better database so we have a very
05:48
long history of working with databases
05:50
especially flip who hopefully will be
05:53
able to pull line here he's been working
05:56
on database technology since the late
05:58
60s and and built or been the leader of
06:00
some of the biggest companies in the
06:02
space and I've been working with Flip
06:06
now for about 20 years and we have just
06:08
built a lot of enterprise applications
06:10
and worked with a lot of database
06:12
technology and a lot of different
06:14
contexts and we thought there was an
06:17
opportunity to build a better database
06:18
and of course black chain is something
06:21
that we're very passionate about and
06:23
some of the implications that it has
06:25
again a little bit more focus towards
06:27
enterprise software here although it's
06:28
applicability is pretty broad and we
06:32
thought there would be some
06:33
opportunities to really merge the two
06:35
together in some unique ways and so in
06:39
addition to creating hopefully a better
06:40
database is what people end up taking
06:43
away from it we've also created a way to
06:48
think make blockchain technology just
06:50
more accessible to developers and some
06:53
of the challenges we find with at least
06:55
the current technologies is it is
06:58
brand-new technology it requires
07:00
developers to develop a new set of
07:02
expertise to use it it requires them to
07:05
change their technology stack which you
07:07
know creates a whole new set of sort of
07:10
management overhead that needs to happen
07:12
as far as you know what if the smart
07:14
contracts not working how do we
07:16
troubleshoot this how do we fix it how
07:17
do we get it back online and the idea
07:20
was that if we could actually take black
07:21
chain technology and put it at the core
07:24
of a database all application developers
07:26
know how to build and work with
07:28
databases so we don't really need them
07:31
to change the the stack and we don't
07:34
really need them to change the way they
07:37
think about building an application you
07:38
know every application starts with the
07:40
database so here are the choices okay I
07:43
can I can choose Oracle or MongoDB or I
07:45
can choose flurry DB and of course the
07:47
thing that comes with Fleury DB is all
07:49
of these better benefits but also some
07:51
of this black chain capability and then
07:54
we also saw some of the challenges and I
07:56
think it will hopefully change and
07:58
mature over time but with companies
08:00
trying to use blockchain technology like
08:03
aetherium aetherium was designed really
08:07
for you know smart contracts computing
08:09
but it really wasn't designed to handle
08:12
anything or not much anyway related to
08:14
data and of course as we address some
08:16
business problems like supply chain
08:18
management you know a typical supply
08:21
chain might generate gigs of Ida data in
08:24
no time and storing gigabytes of data on
08:26
the etherium blockchain is you know it
08:29
wasn't it's not fair because it wasn't
08:31
really designed to do that but it would
08:33
cost you you know I haven't done the
08:35
latest calculations based on the latest
08:36
price bump but I think at least 10
08:39
million dollars where of course that
08:41
would cost you just a few pennies to
08:43
store on Amazon s3 so there was a really
08:47
technology that enabled this foundation
08:50
layer to happen but still enable some of
08:52
these blockchain characteristics and
08:54
things like that to happen it looks like
08:56
we got a flip on now is that right I
08:58
think so
09:03
so Mike I don't know if you wanted to
09:07
take this in a certain direction but I'd
09:09
be great to let slip do a little trust
09:13
what why don't we let flip do a little
09:15
intro and tell me if they if that echo
09:19
comes back I'm just meeting myself
09:21
anytime I want to talk so we'll see if
09:24
this works but a flip hey thanks for
09:26
coming on board
09:27
thanks for being here at blotchy and
09:30
weakly and why don't you tell us a
09:31
little bit about about yourself and what
09:33
would my background in the database
09:35
space is pretty lengthy part of it was
09:39
honed in Motorola and IBM environments
09:43
where the creation of things like D bomp
09:47
bomp CFM s dl1 all of those preliminary
09:51
databases that were part of the past
09:56
cultivated and I worked on all of those
09:58
and I ended up ultimately working as the
10:01
chief operating officer for a company
10:02
called Cullinan
10:03
that was the IDMS codicils database
10:06
management system we had a great run
10:10
with that business cullen that became
10:12
the largest software company on the
10:14
planet during the 1980s ultimately I
10:19
ended up then leaving and starting a
10:22
firm called platinum technology which
10:25
created variety of tools for relational
10:29
database management systems db2 an
10:32
Oracle in particular those
10:35
environs just to clarify if you had to
10:38
build a relational database system 20-30
10:40
years ago maybe even longer you would
10:43
have built it the way Oracle is today if
10:46
he had to build Oracle Oracle today you
10:48
would never make it the way it looks and
10:50
you would never create it the way it is
10:53
and that goes from my sequel and lots of
10:55
other starting to be long in the tooth
10:59
database environments so after we grew
11:05
platinum to a billion in revenues sold
11:07
it for four billion dollars in 1999 the
11:10
next endeavor was in a lot of incubation
11:13
spaces
11:14
technologies that are to be created
11:17
silkroad technology where Brian and I
11:19
spent many many years was a SAS vendor
11:22
for human resource suites of a suite of
11:27
human resource products became a very
11:30
large substantial software Sassa vendor
11:33
and then about six or seven years ago I
11:37
in particular got very interested in
11:40
blockchain and thought of it as perhaps
11:43
the building blocks on which one would
11:45
create a whole new breed of database one
11:49
that if you looked at flurry DB and
11:52
compared it to Cassandra you compared it
11:54
to Mongo you compared it to Oracle or
11:57
any of the yellow there are alternatives
11:59
you would say hey 99 of the time I'm
12:02
gonna pick flurry DB and avoid making a
12:06
big mistake
12:07
so basically we formed this business
12:13
about three four years ago and started
12:16
putting together at a cost no object
12:19
funded database system that would in
12:22
fact appeal to everyone who wanted the
12:25
most comprehensive way of dealing with
12:27
data in the black frankly I would say
12:31
the objective was also that even if
12:33
blockchain was not part of the equation
12:35
you would still pick flurry DB over any
12:38
other alternative and if you had
12:40
inclinations of wanting the immutability
12:45
and other things Mauri
12:50
and blockchain you only pick that turn
12:55
in it that's kind of my background I
12:57
turn it over to Brian who I think is
13:00
going to cover the rest of this yeah and
13:05
and flip III definitely I can definitely
13:10
relate to the the databases and building
13:13
databases and how we did things 20 years
13:15
ago and and the differences we have
13:18
today there's there's a lot of legacy
13:21
types of things that really hold
13:23
technology back in a lot of ways I think
13:25
so I really appreciate your comments
13:27
there
13:28
and are you guys getting the the echo
13:33
again when I'm talking no it's good okay
13:36
good I'm not yeah yeah just when I talk
13:43
the thing that is very important to sort
13:48
of add to the equation is the fact that
13:50
all of the constraints whether they were
13:52
CPU speeds whether they were data
13:55
volumes whether they were performance
13:57
all of the things that were constraints
14:00
before Moore's law has greatly affected
14:03
since that twenty thirty years of the
14:05
passage of time and now things are very
14:07
viable very possible that couldn't be
14:10
even be comprehended yeah I I think I
14:16
think we were using mome moments moments
14:19
when we landed the the Apollo spacecraft
14:23
on the moon that basically there was a
14:25
the data was on a wire recorder and
14:28
we've come a long way since then and I
14:31
think we've kind of skipped a generation
14:33
with our databases in the software that
14:35
we're using and and how we write
14:36
programs and and I think we're having
14:39
some issues with with errors I think you
14:43
if you look for the bounty programs that
14:47
exist for various software's and things
14:48
of this nature I mean everyone's
14:50
everyone's grabbing bounties and and
14:52
it's just because we really haven't gone
14:54
through and rethought what we do as far
14:55
as software is concerned bringing us
14:57
into flurry so I kind of want to set a
15:02
tone here I want to give you guys
15:04
prepped it we're going to ask some
15:05
questions about hash graph we're going
15:07
to ask some questions about swarm and
15:10
you know compare and contrast with some
15:12
of the things with flurry but the flip
15:14
or Brian could you so I so here is a
15:18
person that's in the audience here
15:20
that's that's working on rationalizing a
15:24
workflow at a small business and they're
15:28
going to be using distributed ledger to
15:30
rationalize this workflow and now we're
15:34
ready to to do a smart contract and
15:37
start doing some different things
15:38
how is flurry going to help out where
15:41
does flurry
15:42
come into the process and how do we get
15:44
started does that make sense yes I think
15:49
it makes a lot of sense and Brian I
15:51
think will take you through that unless
15:56
he's disappeared
15:58
I think I think I scared Brian well he's
16:02
there now I yeah yes so I guess
16:09
rationalizing the workflow of process
16:13
management so it's pretty broad I would
16:17
say if you are focused on building an
16:20
application generally you need some sort
16:23
of state data for that and generally you
16:25
would turn towards a relational document
16:29
database graph database whatever the
16:31
case may be to actually store that
16:34
information so that is certainly one way
16:36
that we want people to be able to kind
16:40
of approach these problems in the same
16:42
way they've been approaching them before
16:43
what we want to be able to do is under
16:45
the covers give you blockchain
16:47
characteristics and in fact do so
16:49
completely transparently if you you know
16:52
don't really care about it if you do
16:54
care about it you can get into various
16:56
aspects like which part of data which
16:58
parts of the database data reside in
17:02
different consensus levels you know is
17:03
this like a private blockchain consensus
17:05
level is this something you're running
17:07
internally or is this a full public
17:09
watching consensus but the idea is that
17:11
you if it's core you don't even really
17:13
need to worry about that from the get-go
17:15
if you're just trying to get an
17:16
application up and running and the
17:18
benefit you get is that what we haven't
17:21
talked about some of the ways we feel
17:23
like we've kind of changed how you
17:24
interact with databases you get a very
17:26
modern database so let's just put it
17:28
that way you get something that
17:29
hopefully solves a lot of hard issues in
17:32
dealing with databases today but you
17:35
also get the at least the one core
17:38
characteristic of that black chain
17:40
brings to this which is really the
17:41
tamper resistance so the idea that all
17:44
this data that you're storing is all
17:46
there it's immutable it certainly brings
17:49
a level of comfort for any sort of
17:51
application you're developing you don't
17:53
have to worry about kind of a
17:54
traditional database
17:55
we call update and place databases but
17:57
essentially they lose the historical
17:59
context unless you're logging it out for
18:01
some period of time but lose the
18:03
historical context of what was there so
18:05
you you have the full history of
18:08
everything that was ever there and then
18:10
it is also assembled that history in two
18:13
blocks in those blocks are hash you know
18:15
much much like Bitcoin assembles blocks
18:18
which makes them highly tamper resistant
18:21
so we think that that will definitely
18:23
have an impact on things like auditing
18:25
you know where do you go to figure out
18:27
if data has been tampered well if you
18:28
have a very tamper resistant system a
18:32
record at the core you don't need to go
18:33
anywhere it's it's all right there you
18:35
don't need to you know if you're
18:37
PricewaterhouseCoopers you don't need to
18:39
ask for this documentation from this
18:41
department in this department and emails
18:43
and Excel spreadsheets to try and piece
18:45
together whether or not essentially
18:47
process controls within an organization
18:49
were followed you just look at the
18:51
database and you can have trust in in
18:52
the immutability characteristics so
18:56
that's how we would like people to think
18:57
and that way they don't really need to
18:59
think about learning you know a new
19:01
programming language called solidity
19:02
which they've never used before or you
19:05
know how am I going to connect this into
19:07
my you know JavaScript front-end web app
19:10
and you know what does it talk to and
19:12
there's a lot of things that kind of
19:14
come with that when you're changing how
19:16
you're building applications so our hope
19:17
is that we can bring some of these
19:18
benefits without changing how you would
19:21
approach that problem to begin with so
19:23
that's a that's a pretty high level
19:25
answer to the question and that's in a
19:29
business workflow I think we understand
19:31
that and once again anyone that's in the
19:35
audience at any point if you have a
19:37
question that you want to ask of someone
19:38
a couple different options you can raise
19:40
a question we have a question of flip
19:44
and I think Eric is asking if you're an
19:47
advisor to crypto trust do you know who
19:49
they are or is that something that
19:52
you're involved in I am NOT okay so this
19:59
is an example Eric you ask a question
20:01
and we'll give you an answer right away
20:03
so any of you guys that have
20:06
questions when we're talking about
20:08
flurry about the database about our
20:10
specific application even please feel
20:13
free to you know raise your hand and
20:15
we'll give you will ask that question
20:17
for you or alternatively we can actually
20:20
bring you up on the stage and you can
20:21
interface with us so I think we've had
20:24
tell me about the application and flurry
20:28
where you think it is most likely to be
20:32
used and and what are some of the what
20:35
are some of the things that we want to
20:36
see when we're when we're looking at
20:38
specs and we're looking at at
20:40
implementing a flurry database does that
20:42
make sense
20:43
yeah makes sense I think it's a little
20:46
bit easier for me to ask where it's not
20:48
a good fit because it is designed to be
20:50
a pretty general purpose database this
20:52
is a graph database
20:53
although the way you interact with it
20:55
you don't necessarily have to know all
20:57
this if anyone's used a graph database
20:59
they all seem to have this kind of very
21:01
different way of querying them then like
21:03
sequel which everyone's used to and we
21:06
very much adapt a very familiar sequel
21:09
syntax we don't require you to learn
21:11
about vertices and edges and all this
21:13
sort of graph theory stuff to be able to
21:16
utilize the technology but what was your
21:20
question again Mike Oh mute oh you're
21:27
muted but I recalled anyway as you were
21:29
talking so the the areas where would not
21:33
be a good fit is certainly incredibly
21:35
high volume transactional data so you
21:39
know what we're looking at and the order
21:41
in sort of the magnitude a transactional
21:43
speed here is somewhere around a
21:46
thousand transactions per second within
21:48
the database itself and at least for
21:51
most business applications or really
21:53
most applications in general probably 90
21:55
plus percent of them that fits within
21:57
the needs of how often data is updating
22:00
but if you have something like
22:01
incredibly high volume that you're
22:04
trying to push through it
22:05
not only is black chain as a concept
22:08
maybe not the right solution but
22:10
certainly our databases and optimized
22:13
towards that it's actually optimized
22:14
towards doing very rich even
22:16
programmatic
22:18
permission models inside and there was a
22:20
lot of extra work that we do over even
22:22
what a my sequel might do to figure out
22:25
if data can be updated where it's coming
22:28
from dealing with things like consensus
22:30
so that naturally sort of prohibits
22:33
super high-volume transactional data
22:35
there are concepts that are not black
22:38
Chaney which can potentially apply here
22:41
like iota stain goals for example that
22:44
is a way of doing high-volume
22:47
sort of distributed ledger technology
22:49
without a blockchain and that has some
22:52
implications here but it also has some
22:54
challenges as it relates to database so
22:56
really our core focus is blockchain and
22:58
therefore we kind of have this upper
23:00
threshold really any sort of web
23:03
application is perfect made for this
23:06
because of our graph query interface you
23:10
can just follow relational data and kind
23:12
of all the way through the graph and
23:13
actually get back in JSON so it's really
23:16
easy to work with
23:17
get back responses to your queries in
23:20
real time but in that graph form which
23:22
is usually exactly how applications need
23:24
it and we've done some other things for
23:26
kind of web based applications that we
23:29
think make it even more violet valuable
23:30
one thing we've done is we've actually
23:32
built a query engine in JavaScript that
23:35
synchronizes to the blockchain trans
23:38
actors but you can actually run it in
23:40
process like right inside your iPhone a
23:43
for your android app or your web app and
23:46
your app will issue queries to the local
23:49
database and that local database will
23:50
automatically know what data it already
23:52
has it'll go fetch in batch data it
23:55
doesn't you know actually automatically
23:57
handle real-time streaming updates so
23:59
it'll be able to create real-time
24:01
applications so that's an example of
24:05
where it's like a perfect fit and sort
24:08
of on the other side where it's not a
24:09
good fit is right things where you need
24:12
to do in a single database more than a
24:15
thousand transactions per second and
24:17
where we all are familiar and I'm sorry
24:21
if the the echo has come back again for
24:23
some reason we're having some technical
24:24
difficulties there but you know we have
24:29
a couple of things going on number one
24:30
we
24:30
question I want to get to but I want to
24:32
talk just a little bit about transaction
24:35
and velocity and link that into a
24:39
question we're going to have in the you
24:40
know after this question is hash craft
24:44
and how how that works but what is it
24:50
that the Bitcoin ledger is at about
24:56
seven seven and a half transactions a
24:58
second now and we're looking at the
25:01
etherium that's at three or four
25:02
transactions a second it's not very
25:04
scalable and is this something am I kind
25:11
of going down the right where we can
25:13
actually have transactions that are off
25:14
chain but relate back to a chain where
25:18
we can have a coin into a coin where
25:20
we're conducting transactions via a coin
25:24
and we are tracking those transactions
25:29
on ethereum so we have the data stream
25:33
for the distributed ledger we understand
25:36
where all the where all the coins are we
25:39
understand which transaction was first
25:41
but we need we have a need for data
25:44
outside of that as opposed to using
25:47
standard my sequel queries or setting up
25:50
a standard database flurry has some
25:55
definitive it advantages as far as the
25:58
database in the integration I'm probably
26:00
wrong but is that anywhere near correct
26:03
yeah you know well I guess you're
26:06
talking about aetherium as it is today
26:07
and there's all these technologies have
26:10
roadmaps and I would say all of them
26:12
probably acknowledge some of their
26:14
issues and have some degree of plans to
26:17
work to resolve them so resolving the
26:20
transaction speed of the theorem you
26:22
know they have two strategies that
26:24
they're looking to do that with one of
26:26
course is a migration off of proof of
26:27
work to proof of stake and they think
26:29
they can get a lot of efficiencies there
26:31
and probably can and then the other
26:33
strategy is that of sharding and so
26:37
these are kind of two aspects that we
26:39
address at the core now I'll get to kind
26:41
of you're off chain question in a minute
26:43
so what
26:44
we actually handle this and it it's not
26:47
that I mean we're lucky because it's a
26:49
little easier to do in our context is
26:51
that databases operates sort of in
26:53
isolation regardless and so they make a
26:57
natural sharding technique so our shards
27:01
we do have charting built-in which
27:03
enables this higher transaction velocity
27:06
as you call it in the shard is a
27:08
database and technically the shard is
27:10
actually a database partition so if you
27:13
have really high volume databases you
27:16
can actually partition in a single
27:18
database into many sort of smaller
27:20
partitions or shards but most people
27:23
will probably just use a single database
27:24
but every single databases is don't
27:27
shard and therefore really its own
27:28
blockchain so that of course solves you
27:31
know a lot of issues and you know
27:33
etherium will obviously become faster as
27:36
they implement charting as they're
27:37
proposing to do and you know not too
27:40
soon off but pretty far away but
27:42
regardless it's it's something they're
27:44
looking to accomplish and then us other
27:47
questions sort of this off chain method
27:49
in this off chain method is becoming a
27:51
lot more popular you also bring up hash
27:53
graph you know the same thing and sort
27:55
of these directed directed graph you
27:59
can't call them black chains because
28:00
they're not black chains but these you
28:02
know hash graph iota is an example
28:04
obviously a pretty popular one of this
28:07
they're using a different type of
28:09
technology to do high velocity
28:12
transactions and we actually see
28:16
potentially a merging of those two so
28:18
using a kind of a backbone consensus
28:21
model which might be proof of work in
28:24
the case of Bitcoin we actually are big
28:28
fans of proof of capacity and basically
28:32
your side chains your your side chains
28:34
become you know like iota tangles they
28:39
become you know like iota the whole
28:43
thing runs is the tangle but what if it
28:45
didn't run as a tangle what if sort of a
28:47
side chain ran as a tangle which could
28:49
support very high velocity but it always
28:52
ended up linking back into the core
28:54
black chain which is using something a
28:56
little bit more traditional like a
28:57
of work sort of change it's the
29:00
combination of these things that I think
29:02
will be at least in the near term some
29:04
of the where some of the velocity really
29:08
comes from but yeah in proof of work and
29:10
proof of capacity and maybe even to a
29:14
degree proof of proof these are not
29:17
super fast so achieving that velocity is
29:22
going to be challenging but it also goes
29:24
against what why are you using a black
29:26
chain to begin with I mean generally
29:27
you're using it because you want this
29:29
trustless consensus method and that is
29:32
for lots of applications a very valuable
29:35
trade-off to getting speed some
29:39
applications it's not but you know you
29:40
need to choose the right application for
29:42
the job and none of this stuff is going
29:44
to be one size fits all III agree I
29:48
agree I mean I've looked at literally
29:50
hundreds of different applications and
29:52
definitely there's a lot of people that
29:55
are trying to force the blockchain
29:58
application into you know their world
30:01
when it really doesn't belong there and
30:02
I look at you know is there because
30:05
their transfer of trust in other words
30:07
in the in the transaction that you're
30:09
looking at or in the workflow that
30:10
you're looking at or and what you're
30:11
trying to do with the blockchain is your
30:13
transfer trust are their sticky bits
30:14
sticky bits are people and personalities
30:16
where people try and negotiate
30:18
renegotiate change the you know grind
30:20
the price or make some sort of a comment
30:24
as far as the quality is concerned and
30:26
then is there money in the transaction
30:30
because if there's not money in the
30:31
transaction really doesn't make any any
30:33
any real sensitive to move forward and
30:36
then the last one of course and I've
30:38
added this recently is does it make it
30:40
simpler right does it simplify the
30:42
process you know growth hacking number a
30:45
rule number one is make a simpler or
30:47
someone else will so that's really what
30:48
we have to be looking at so that's
30:50
that's kind of the metric I look at it
30:51
and you know that my metric and fifty
30:54
cents will buy you half a cup of coffee
30:55
at Denny's but you know there's there's
30:57
got to be a transfer trust there has to
30:59
be some sort of a sneaky bit that's in
31:01
the process that we're looking to
31:03
overcome in the transfer of trust and we
31:05
we have to look at
31:07
you know is there money in the
31:10
transaction is there value that's enough
31:12
to move forward and does it make things
31:14
simpler or if if it doesn't hit every
31:17
one of those with spades I mean it you
31:18
just don't look at blockchain
31:20
traditionally to to go into it I want to
31:23
get some questions up and we've got a
31:24
couple of them that are that have been
31:26
out there for a while and is this
31:29
something like neo4j and I don't know
31:32
what neo jail are you do you yeah I do
31:36
so it is probably one of the most
31:38
popular kind of graph databases out
31:41
there today so it's used a lot by for
31:44
new applications say someone's building
31:45
a new SAS application in in the respect
31:48
that it's a graph database the answer is
31:50
absolutely it's a lot like it we bring
31:52
some other interesting characteristics
31:54
of course you know we've been talking a
31:55
lot about blockchain one of the things
31:57
we've been able to do is since we're
31:59
storing an immutable history of that
32:02
database in the form of a black chain
32:04
how do we actually leverage that
32:06
information that most databases don't
32:08
have because they sort of forget it or
32:10
it's in backup tapes that they need to
32:11
restore to get access to it up to a
32:13
certain period of time whatever how do
32:15
we take that rich data and solve real
32:18
problems with it so one of the things
32:20
that we have built in is the ability to
32:23
do point in time query so when you issue
32:26
a query like a sequel looking query into
32:29
Fleury DB it will respond as any other
32:32
database would with the information that
32:34
currently knows about that query it'll
32:36
answer your query absolutely so Fleury
32:39
has the opportunity to do time travel
32:42
yeah time travel on this fact that every
32:45
single query that you you ask you can
32:47
optionally say I want to know the answer
32:50
to this query but I want to know it
32:52
yesterday I want to know what a year ago
32:54
I want to know what two years ago in
32:56
every single you think about like micro
32:59
versioning every micro version of the
33:01
database is available at your fingertips
33:04
for real-time queries so you can go back
33:06
in time we actually allow some ways to
33:08
go forward in time too if you want to do
33:10
scenario planning or things like that
33:12
you can basically create transactions
33:14
that you don't physically store in the
33:16
database or commit but you pretend like
33:19
they're there to then run what
33:21
you want behind it too you know your app
33:23
to be able to run it in the future and
33:26
see what this report looks like six
33:27
months from now assuming this
33:29
transactional data transpires between
33:31
now and the next six months so yeah we
33:34
allow time traveling and it's immutable
33:36
so you know it eliminates if you're an
33:38
application developer you've all dealt
33:40
with probably the least fun thing to
33:42
deal with which is race conditions where
33:45
you know while your application is
33:47
processing something the databases might
33:50
be changing underneath it and some error
33:52
happens because you know function a ends
33:55
up calling function B a millisecond
33:58
later but the database changed
33:59
underneath it and now they have two
34:00
different results over the same data
34:02
that they thought they would get with
34:05
Fleury when you get a database that
34:07
database it never changes so we
34:09
completely eliminate race conditions and
34:11
applications and basically every time
34:14
you know maybe a new request comes into
34:16
your web server you just grab a new
34:18
database in the idea that you can
34:20
actually be running thousands of
34:22
versions of the databases in thousands
34:24
of application processes simultaneously
34:27
to us is trivial we use them so it
34:30
really changes how you think about a
34:31
database the database actually becomes
34:33
like a variable as opposed to like this
34:35
thing that you need to go send a request
34:37
to and in fact so much so you can
34:40
actually run our query engine in process
34:43
right next to your application and it
34:45
really even starts to change how you
34:47
code because normally when you're coding
34:49
you're thinking about oh I got to go ask
34:50
the database for this data well that's
34:52
really expensive it takes a long time so
34:54
I'm gonna be very very conservative with
34:57
what data I asked for and how often as
34:59
I'm trying to you know process a request
35:01
when you have your database essentially
35:03
right next to you you just start coding
35:05
differently because you can ask
35:07
questions instantly and get
35:08
instantaneous responses so we really
35:11
have changed kind of how you think of a
35:13
database by this idea that we separate
35:15
the query engine from the thing that's
35:18
actually processing transactions and
35:20
then the other benefit and why this
35:21
makes sense in the black chain space is
35:23
that only one node essentially is in
35:26
control of that database at a specific
35:28
point in time so it can ensure the
35:31
consistency in
35:32
miss city of a database so the idea is
35:36
that you know it's like a non unreality
35:39
but it's like a single-threaded process
35:41
is processing transactions serially so
35:45
your database can never be out of sync
35:46
you can do things like atomic
35:47
transactions with guarantees and all
35:50
this sort of thing and basically the
35:51
result of those transactions create a
35:54
database state change sort of some
35:56
additional logs and those logs then get
35:58
synced to all the query engines and you
36:00
can run thousands of query engines it
36:02
doesn't really matter but the key is is
36:03
your applications are talking to the
36:05
query engines and they're getting
36:06
responses in most of our queries are
36:09
like sub to millisecond response times
36:11
so they're getting they can scale
36:14
arbitrarily they're not concerned about
36:16
the scalability of the blockchain aspect
36:18
because we've actually split the
36:19
database into two different things
36:21
there's some ramifications for me there
36:23
that are quite significant and it's
36:27
going to take me a while to process that
36:29
I'm not the sharpest knife in the drawer
36:30
for sure but it's interesting that it's
36:34
a single thread and at that point you
36:36
you you're not having vulvar right
36:38
you're not having data that's being
36:40
written from one source on top of a
36:44
database on another and you don't have
36:46
that issue no in fact in fact locking
36:50
you know database locking is one of the
36:53
problems that plague and make things
36:55
like Oracle so complicated it needs to
36:58
quickly figure out what parts of the
37:00
data it needs to lock and freeze while
37:03
it's trying to handle all these requests
37:04
and do all this stuff and it's a normal
37:06
vertically complex it is but the trends
37:09
of elements of flurry DB right the
37:11
transactions takes so long that it that
37:13
it's relevant who's who's coding and
37:15
who's writing to the database but
37:17
whether you're is it's not so relevant
37:19
no that's interesting that's that's
37:23
going to be one that's going to spin
37:24
around my head for a little while and I
37:27
want to get to another question we have
37:29
one more question from the same guy in
37:32
cybersecurity resilience AI and machine
37:35
learning how are they related to your
37:38
database and any company using using
37:45
your database for icos okay well a
37:51
couple questions there yeah so I would
37:54
say as it relates to artificial
37:56
intelligence you know the the the food
38:00
of artificial intelligence is data of
38:03
course and in that regard we're a
38:07
tremendous food source for artificial
38:09
intelligence in mostly because we are
38:13
immutable we have the full history of
38:14
everything that happened in time is a
38:17
you know most most databases kind of
38:20
have two dimensions they got a table
38:21
with rows and columns we have three
38:23
dimensions we have time as well and lots
38:27
of AI oriented algorithms one of the
38:30
more important aspects of it isn't the
38:32
data itself but it's the time how you
38:34
know what's the pattern of when things
38:35
happen over time and we have all that so
38:38
a normal database does it typically
38:39
store that type of data you would have
38:41
to go through some extra effort to
38:43
retain that and one of the things that
38:45
we're finding is that people are trying
38:47
to come up with some algorithms to
38:49
answer questions and you know they got
38:52
some good idea and then the first thing
38:53
they need to do is is find the food
38:55
source right what data do we need to
38:57
power this algorithm so that we can find
39:00
that answer
39:00
and then the challenge usually is is oh
39:03
shit we don't have that data it's not
39:06
there we need to start tracking it and
39:08
then they start tracking in and maybe
39:09
three months later they have the data to
39:11
feed it if you have every piece of data
39:13
that you've ever had over time and you
39:16
know this is pretty cheap to do storage
39:17
is so cheap then hopefully is you're
39:21
coming up with new questions to ask and
39:23
new algorithms to run what you'll find
39:25
is you already have the data you need to
39:26
power them you don't have to you know
39:28
wait three months to collect a new piece
39:30
of data that you weren't already
39:31
collecting so you know what we what we
39:34
have isn't doesn't have anything
39:37
specifically to do with AI but like I
39:39
said I think we will be a better food
39:41
source for AI algorithms than a typical
39:44
database would as it relates to I cos
39:47
it's an interesting question you know we
39:50
have we support in the database itself
39:52
of a programming language so you know
39:56
aetherium has solidity we have ten
39:59
our own programming language it is
40:01
designed you know solidity is designed
40:03
to be a general-purpose programming
40:04
language our programming language is
40:07
really designed to work with a graph
40:09
database and execute custom predicate
40:12
functions but those functions are very
40:15
very powerful and they can actually
40:17
enable smart contract like behavior so
40:20
we see technologies like aetherium and
40:22
hyper lighter being a great compliment
40:24
to Fleury DB they're really focused more
40:26
on in a traditional application stack
40:28
you know the apps here the business
40:30
logic we're more focused on the database
40:32
itself there are some areas where
40:34
there's a little bit of overlap and
40:36
there are some smart contracts that you
40:39
might normally go to a cerium to write
40:41
that could be fully written right within
40:43
flurry DB but there's other things that
40:46
are going to be very custom you know
40:48
programming logic that are going to be
40:49
better suited for etherium all that is a
40:52
long answer to say that you could write
40:56
the logic to do something like an ER c20
40:59
offering within Fleury DB i don't know
41:01
if it would make at this point more
41:04
sense for you to choose that over doing
41:06
it in aetherium or something else you
41:08
know I'll probably be able to answer
41:09
that question a little bit better in the
41:11
future is things play out but that type
41:14
of custom logic programming capability
41:17
is actually capable of doing right
41:19
within the Fleury database not only that
41:21
but I think the other components of the
41:24
database is just a foundation layer
41:26
would provide for the Richard
41:29
description of applications not that you
41:32
can't use Java not that you can't use
41:34
Python not that you can use anything
41:36
else right now
41:38
fundamentally any language that you
41:42
choose can become the way that you
41:45
contribute to and from Fleury DB there's
41:50
no there's no real restriction they're
41:53
fundamentally itself just so you know
41:56
this doesn't affect any customer and a
41:59
user anybody who's looking at it but the
42:01
product was written in closure so it's a
42:03
functional programming strategy
42:06
underneath the covers where are certain
42:09
things that can do to a function
42:12
programming language are possible who
42:14
are using some that's interesting
42:16
closure I don't think I've is that I
42:18
think that's similar to Lisp if I
42:20
remember correctly actually yeah
42:24
based on this okay so and that's that
42:28
kind of make it gives me a clear path I
42:30
understand now so going back in you're
42:36
talking about I had some interesting
42:38
questions about is there a service that
42:41
we can use as a GUI to when we have the
42:44
database and we're looking at it you you
42:46
talk to a little bit about the data that
42:48
we have and I wanted to ask just a quick
42:50
question and we got five questions we
42:52
got to get to you so is there a really
42:53
quick answers are a company or a service
42:57
that you're using as a GUI for the
42:59
database yeah so we've actually built a
43:02
GUI for the database that allows you to
43:05
query or see what's going on or
43:07
visualize the schema or even paint a
43:09
graph of the schema of the database and
43:12
allow you to transact right from it
43:14
obviously an application would normally
43:15
be doing it and it's worth pointing out
43:17
we do have our own query syntax which is
43:19
very sequel Lite but it's defined in
43:21
JSON so it's really easy to compose and
43:24
do things with but we also actually
43:26
support graph QL as well face books
43:29
graph QL in graphic ul has a pretty rich
43:31
ecosystem of tools around it and all
43:34
those tools work with flurry BB natively
43:37
so you know if you want to pick up any
43:39
graph QL tool or you're writing a react
43:42
app and you want to use graph QL under
43:44
the hoods it can connect to a flurry BB
43:47
it'll do its full introspection
43:49
understand the schema and you know just
43:52
work it's a great tool set just don't
43:55
ever use it a quick question from dan
44:01
Meyers hottas Laysan late latency and
44:04
acid-base ORM DBS compared to blockchain
44:07
over yet of course that depends on
44:09
blockchain implementation but if
44:10
possible give a a broad answer yes so
44:15
this is kind of what I talked about a
44:17
little bit before is that you should
44:19
really target well for one we use
44:22
sharding so
44:23
that immediately scales the number of
44:26
transactions we can do and we shard at
44:28
the database plus partition level the
44:30
second part of that is that were really
44:32
targeting applications in the sort of
44:34
sub 1,000 transactions per second range
44:38
for some of these reasons we think that
44:41
fits most applications but there are
44:43
obviously applications that need more
44:45
than a thousand transactions per second
44:47
and we wouldn't be a good fit for those
44:50
so something like building a an exchange
44:54
that would have multiple transactions on
44:56
multiple multiple chains and keeping
45:00
some sort of a database on what's going
45:02
on big high volume that kind of stuff
45:05
this would work well for that if it's
45:07
very shard friendly data we can still
45:09
work very well from it but for example I
45:11
wouldn't try to replace the New York
45:12
Stock Exchange with flirty bebe I would
45:15
I would custom write technology to do
45:17
that that only solves that problem
45:19
because that's kind of what you need for
45:21
that use case so flurry sounds
45:24
acceptable to supply chain management
45:26
particularly for time sensitive storage
45:28
and delivery yeah so the in I cut out in
45:31
the middle of that question but let's
45:33
see supply chain particular time senses
45:36
storage and delivery please comment yes
45:38
my chain is just a phenomenal use case
45:41
for flurry DB the idea that a group of
45:43
companies can run a database where no
45:45
one controls it you set up the rules
45:47
ahead of time exactly which data and
45:49
under what conditions that data can be
45:52
transacted by whom so you kind of have
45:54
this level playing field you set up and
45:56
then you can incorporate notions like
45:59
even voting in there so if you know 50%
46:01
of the supply chain wants to change the
46:03
permissions or wants to alter some
46:05
business logic for the database itself
46:08
then those you know transactions go
46:10
through and if for example they don't
46:12
then they don't go through it keeps
46:14
running by the same rules that it's
46:16
currently running by but the supply
46:18
chains a great example there's you know
46:21
use cases probably for every industry
46:23
but that's a good one and I we do have a
46:28
couple more questions here what but give
46:31
me a good example of your best most
46:33
successful use case in this part is that
46:35
in the specific industry or is it
46:37
with a specific application that goes
46:39
across industries or nature oh I admit
46:44
want you baby to describe how time
46:47
travel into the future would affect the
46:49
cap table application because that's
46:52
kind of got sort of immediate
46:54
recognition by folks as to what is
46:56
happening and - one of the things to
46:59
remember is that you could write the
47:01
query against any number of databases
47:04
some of them private some of them
47:07
federated in the hands of n number of
47:09
authorized and permissioned users and
47:13
write that same query over the third
47:16
component which is a completely public
47:19
blockchain database and you as the
47:22
writer of the sequel don't have to know
47:25
anything about what they are that
47:27
they're private or they're federated or
47:29
they're public yeah which which is the
47:33
whole idea behind decentralisation more
47:35
or less so that's thanks for that I want
47:37
to get to a quick question here flip for
47:41
you I talked with Flip 20 plus years ago
47:42
when I left IBM research to launch
47:45
privacy Inc are there any specific
47:47
privacy autonomous capabilities built
47:49
into flurry and that comes from edy
47:52
Albarn I had Brian can add a lot more to
47:59
this but I think the immune ability of
48:01
it is a big part of that privacy you can
48:05
chime in sure and I guess there's a few
48:10
layers of it and and I won't belabor the
48:12
point because I know we're running out
48:13
of time but if you're talking about
48:16
privacy from the standpoint of
48:18
anonymizing transactions answer is no
48:20
that's not a sort of a primary use case
48:22
that we're trying to solve with this
48:24
because we don't anticipate that many
48:26
people needing that and some of the
48:28
algorithms around this I think are a
48:30
little early still - although it's
48:31
really interesting to look at things
48:33
like z cache and some of these others
48:35
and sort of see where that goes but no
48:37
that's not really a primary use case
48:38
we're looking to solve you can anonymize
48:41
data that you put in by using standard
48:44
encryption so you know you there's
48:46
there's a couple trade-offs that you
48:48
need to think about what
48:51
we highlight that if you are going to
48:52
fully encrypt certain types of data
48:57
you're going to store that's fine but
48:58
the database can do a little bit less
49:00
with that data than it otherwise could
49:02
specifically around performing database
49:04
functions around it so that would
49:08
certainly be a way to do that and then I
49:11
guess the other aspect of you know
49:13
anonymity
49:16
I guess I'll stop there
49:18
so hopefully that addresses the at least
49:22
depending on what they were asking about
49:23
the anonymous question but now my mic is
49:26
on you know and you know I think the
49:33
first the first thing that most people
49:35
do when confronted with a decentralized
49:37
database is to in the back of their mind
49:41
figure out how to centralize it yeah
49:44
yeah and that's fair right but I don't
49:49
think that's a good application I know
49:51
that a lot of a couple of the people are
49:54
going to be here are going to be
49:56
concerned with security cyber security
49:58
and breaches and things of this nature
50:01
and you know when you have an immutable
50:06
database that's public there's things
50:08
you can do you can hash the data you can
50:11
you can encrypt the data you there I've
50:16
seen some things where they're actually
50:17
taking a key and encrypting a key and
50:19
putting that on the blockchain but it's
50:22
a key that won't open until a future
50:23
time in the in the future so in order to
50:27
get to the data before the time that's
50:28
on the key you have to you have to break
50:32
the code that's on the hash for the key
50:34
and then break that you know so there's
50:36
there's a lot of things that that are
50:38
going on there but when we're talking
50:41
about the the public blockchain that's
50:43
one thing when we're talking about a
50:45
consensus where we have a community
50:47
blockchain that's another thing we want
50:49
to keep other players out we only want
50:51
to have that that blockchain available
50:55
to our community and that's it and we
50:57
provide some sort of a consensus
51:00
mechanism algorithm be you know
51:02
proof of capacity proof of work proof of
51:05
stake proof of leadership there's four
51:08
or five different ways of doing
51:11
consensus coming down the pike but it's
51:14
not always appropriate to to be looking
51:16
at our data from a security standpoint
51:18
on on who can touch our data when it's
51:22
public data right that's right and and I
51:27
would only add that you control who when
51:29
you set up a database you initially
51:32
whoever turned it on sets up the rules
51:35
that govern exactly who and under what
51:37
conditions data can be updated and again
51:39
you can get really rich with this you
51:41
can actually like custom programs that
51:43
are determining if someone can then
51:45
update this entity in this particular
51:47
attribute so that is initially set up
51:51
and then you can establish either you
51:54
can hold on to the keys and change them
51:56
whenever you want in which case it's
51:57
visible to everybody what's changed or
51:59
you can set it up in a way where you no
52:02
longer have permission to change the
52:04
rules but you set up essentially a
52:06
voting mechanism that elects people who
52:09
then determine whether or not they're
52:11
going to approve a rule change or not -
52:13
what can be updated how were schema
52:15
changes or whatever the case may be but
52:18
in that regard you know it is it is not
52:21
like this public database that anyone
52:23
can do things with it runs by a set of
52:26
rules and those rules even if they're
52:28
functional code actually happened to sit
52:30
is data itself and it's stored in the
52:32
database as data itself so they actually
52:34
create their own blocks so so member
52:37
proposed schema changes that are are
52:40
that have a member consensus in a
52:43
community chain yes I have no idea what
52:49
I said but hey your your honor marketing
52:52
team now interesting stuff really
52:59
interesting stuff we've got two more
53:02
questions here I don't want to get
53:04
sidetracked I could I think I could talk
53:07
about for another hour just on that one
53:09
fact right there but let's talk about oh
53:11
and it's another privacy issue how are
53:13
we approaching privacy in your
53:14
blockchain well applications be able to
53:16
leverage both
53:16
public and private databases I think
53:18
we've I think we mana let's answer that
53:20
did we or did we not yeah I guess the
53:23
only quick thing I would add is that
53:25
your applications don't talk directly to
53:28
the blockchain trans actors so that's an
53:30
important thing too from an architecture
53:32
standpoint they talked to a query engine
53:34
we have a lightweight JavaScript query
53:36
engine that can run right in your app
53:38
you may set up a Java based query engine
53:40
which we also have that will run as a
53:42
server and you can scale those as much
53:44
as you want but those query engines
53:47
because your app is actually talking to
53:49
them those query engines may be
53:51
aggregating data across multiple
53:53
databases together in displaying them to
53:57
your application as though they are a
53:59
single database so the idea here is that
54:02
you can really grab data from across
54:04
different consensus modes different
54:05
databases have them merged at this query
54:08
level and your applications can remain
54:11
incredibly simple they don't have to
54:12
connect to this database in that
54:14
database and that database for different
54:16
data they can connect to one database in
54:18
the query engine has abstracted all of
54:21
that from them good good good one more
54:27
question and then we're going to get on
54:29
with with closing this thing out I think
54:31
so the concept of privacy volume control
54:35
yeah I like that
54:37
sounds viable to control levels of
54:39
public access and this is again coming
54:42
from ads so flip you want to answer this
54:43
one so the concept of privacy volume
54:46
control sounds viable to control levels
54:49
of public access like I guess that's
54:52
more of a comment then yeah I don't know
54:56
how to actually answer that question for
55:00
that reason but III think that
55:02
permissioning is a very rich part of who
55:06
can and who can't
55:07
maybe maybe it's worthwhile to go
55:10
through a little bit of that it resides
55:12
inside as a data element of the database
55:16
and therefore if you have a flurry
55:19
database to somebody they really can't
55:21
decipher it
55:22
I like they can if you hand them an
55:24
entire Oracle database you can act
55:26
through that all you want
55:29
yeah and there's one version and that's
55:32
the version and unless you've got an
55:35
Oracle database with some really really
55:37
cool version controlling it's hard to
55:40
lens the data as it was ten years ago or
55:42
five years ago or what have you which is
55:45
a an interesting concept as far as
55:47
databases are concerned it is getting to
55:50
the top of the hour I wanted to thank
55:54
you guys for coming on board I want to
55:56
say one thing that we're going to give
55:59
you a free community version of flurry
56:02
for being here and if you'll go to
56:04
flurry comm and scroll down you get a
56:07
free 50 minute blockchain storage 100
56:10
megabits with query 250,000 transactions
56:13
or database function calls 100,000
56:17
requests of one kilobyte 100,000
56:19
function calls so there's a database
56:21
that you can go to flurry and flurry as
56:23
f lu r dot e e and scroll down and
56:29
there's a free community version that
56:31
you can get just by coming to blockchain
56:34
weekly and sticking with us for the hour
56:36
we're going to give that to you of
56:39
course if you just go to flurry comm you
56:41
get the same thing but we want we want
56:43
her from we want to promote blockchain
56:48
weekly we want to thank you guys for
56:49
coming out we we really appreciate you
56:52
it's been now kind of a top-heavy
56:55
conversation today I'm definitely going
56:59
to have to go away and and have lunch
57:01
now and just give this awesome thought
57:03
there's some interesting things on a
57:06
couple of projects that that I'm working
57:08
in on right now and Brian I'm I'm
57:10
definitely going to be reaching out to
57:11
you in the next couple of days and
57:13
pitching you in a couple of applications
57:16
that this might be interesting going to
57:19
get you together with my developer so
57:21
one of the say thanks to shindig this is
57:24
a really interesting environment I know
57:29
there was 24 25 people at the at the top
57:33
of it there's been a couple of them that
57:35
dropped off at the top of the hour
57:37
probably lunch hour type engaged
57:39
but you guys were able to raise your
57:42
hand and ask questions I hope we got all
57:45
of your questions answered you guys were
57:49
able as part of the audience to get
57:52
together and talk to one another you can
57:53
actually connect with one another inside
57:55
the audience which is an interest
57:57
interesting thing as far as shindig and
57:59
shindig is Shi and EIG comm if you're
58:04
interested in this type of environment
58:05
and doing these types of events please
58:07
give them a call and mike is my guy just
58:10
tell them you want to talk to Mike the
58:12
guy that's doing blockchain consultants
58:14
you'll be able to to to hook you up I'm
58:17
Mike Noel I'm the CEO for blockchain
58:19
consultants we're doing a lot of really
58:22
what we find that we're doing is we're
58:23
doing rationalizing workflows so we're
58:26
going in and looking at a business
58:28
process of business development that's
58:30
been going on since the dawn of mankind
58:32
and done a certain way and databases
58:35
that are built in in certain kinds of
58:38
ways and one of the things that we do
58:40
revolve around the way the databases are
58:43
written as opposed to the way that we
58:44
really want the workflows to function
58:46
and what we do is we go in we start
58:48
rationalizing workflows and implementing
58:52
a blockchain solution and it's a it's
58:55
it's an interesting business to be in
58:57
and it's a interesting time to be alive
59:00
and a lot of things going on in
59:02
blockchain we have one more questions
59:05
oh and that is anyone can continue a
59:11
conversation with us at inflow dot
59:14
flurry
59:15
da-te happy to chat further with any
59:18
further questions so we've we've got
59:20
someone from flurry that's uh that is
59:24
ready to to chat with you and enhancing
59:26
our other questions and again it's M
59:28
value REE what if I really appreciate
59:32
your time and your work here it's been
59:37
fun it's been engaging for me it's been
59:39
interesting for me I'm I'll be honest
59:41
I'm going to have a bit of a headache
59:42
trying to get my arms around some of the
59:44
things that you guys have said but I'll
59:47
try and get that done and we really
59:51
appreciate
59:52
everyone's interest and everyone's input
59:56
Brian we really appreciate you coming to
59:58
to the to the board here Kevin is in the
60:02
background Kevin we appreciate you
60:05
connecting with me on LinkedIn and
60:07
helping to put this thing together
60:09
appreciate everyone's time
60:12
go ahead if you have questions any
60:14
questions we're we're gonna we're going
60:16
to sign off now no questions thanks a
60:19
lot guys
60:20
welcome to blockchain wake away thanks
60:22
for coming and be sure to tune in again
60:24
next week
60:25
same bat-channel same bat-time thanks
60:27
guys
60:35
you