►
From YouTube: Firefly Architecture Series Episode 1: API & Resources
Description
This is the first video of a six-video series about FireFly, giving an overview of the four main pieces of a FireFly Node:
Core:
-Active engine which your apps use to interface with the system
-Maintains private data storage
-Manages the lifecycle of assets and data, and dispatch actions and processes events.
Connectors:
-Abstract away the complexity of reliable,
-coordinated flows across heterogeneous runtimes.
Registry:
- Maintains the identity and connectivity info of the network members.
Infrastructure Runtimes:
- Pluggable implementations of multi-party collaboration across transactions, data, and messages.
- Many compute types (blockchain, low code, TEE, zkp, etc.)
Learn how these pieces fit together and why this architecture is important.
What is FireFly?
FireFly is a Hyperledger Lab that provides a multi-party system for enterprise data flows, powered by blockchain. It solves the layers of complexity that sit between the low-level blockchain and high-level business processes and user interfaces. FireFly enables developers to build blockchain apps for enterprises radically faster by allowing them to focus on business logic instead of infrastructure.
Learn more about FireFly at Hyperledger Labs: https://wiki.hyperledger.org/display/labs/Firefly
----
Hyperledger – Open Source Blockchain Technologies
Hyperledger is an open source community focused on developing a suite of stable frameworks, tools and libraries for enterprise-grade blockchain deployments.
It serves as a neutral home for various distributed ledger frameworks including Hyperledger Besu, Fabric, Sawtooth, Indy, as well as tools like Hyperledger Avalon, Cactus and libraries like Hyperledger Aries, Ursa. Learn more about Hyperledger projects: https://www.hyperledger.org/use
Case Studies: https://www.hyperledger.org/learn/case-studies
Training & Certification: https://www.hyperledger.org/learn/training
Tutorials: https://www.hyperledger.org/use/tutorials
Webinars: https://www.hyperledger.org/learn/webinars
Events: https://www.hyperledger.org/events
Vendor Directory: https://www.hyperledger.org/use/vendor-directory
Subscribe to the Hyperledger Newsletter: https://www.hyperledger.org/newsletter
Follow-us on Twitter @Hyperledger
Learn about Hyperledger Membership: https://www.hyperledger.org/about/join
#Hyperledger #Blockchain
A
A
Welcome
everybody:
this
is
our
very
first
firefly
community
call
and
we're
really
glad
to
have
you
and
excited
to
kick
this
off.
For
these
first
few
community
calls
we're
going
to
have
a
subject
matter:
expert,
walk
through
a
technical
topic
on
firefly
kind
of
starting
with
architecture,
and
you
know
flows
through
the
system
to
help
people
get
familiar
with
how
firefly
works,
how
it's
put
together
and
all
that
good
stuff.
So
peter
broadhurst
is
going
to
be
leading
the
session
this
morning,
so
we'll
basically
take
the
first
30
minutes
of
the
call.
A
B
Thanks
nico
so
and
you're
gonna
you're
gonna,
keep
me
to
time.
We
want
to
make
sure
that
we
try
and
keep
the
second
half
of
this
just
for
open
topics
and
those
topics
don't
have
to
have
anything
to
do
with
the
the
first
half
of
the
the
meeting
either
we
were
thinking
about.
What's
the
very
first
topic
to
kick
it
off
and
I
think
we'll
be
trying
to
influence
the
schedule
for
what
other
topics
we
do
and
who
comes
along
and
talks
based
on
feedback
from
the
community.
B
B
What's
the
first
thing
I
want
to
do
inside
of
firefly,
I'm
particularly
thinking
about
the
ping
pong
example
we
use
during
the
kickoff,
where
there's
a
sort
of
mixture
of
coordination
of
some
stuff
happening
on
chains,
some
stuff
happening
off
chain
I
want
I
want
to
do
some
of
that.
I
want
to
do
some
things
which
I'm
sharing
with
everybody
in
the
network,
some
things
that
I'm
just
doing
with
individual
members
in
the
network
sort
of
privacy
first
approach,
which
is
so
common
in
enterprise
scenarios.
B
B
So
we're
going
to
start
here
with
sending
a
message.
A
message
is
probably,
if
you
sort
of
put
blockchain
transactions
aside
and
we'll
talk
a
little
bit
more
about
those
later
in
the
session,
we'll
talk
lots
about
them
in
future
future
sessions.
If
you
sort
of
put
the
simplifying
talking
to
really
sophisticated
blockchain
transactions
aside
and
you
what's
the
the
most
important
construct
inside
of
sort
of
firefly,
and
it's
probably
this
construct
of
a
message-
a
message
is
a
an
envelope
really
of
one
transmission
of
data
with
a
signature.
B
If,
if
you
choose
to
choose
to
have
that
from
one
member
of
the
network
to
one
or
more
members
of
the
network-
and
I
think
the
reason
to
think
of
it
like
the
envelope
rather
than
the
whole,
that
rather
than
the
letter
is
because
inside
of
that
that
message,
you
include
data
that
that
data.
When
you
actually
send
a
message,
you
can
just
put
it
there
and
json
right.
You
can
just
say
look.
B
I
only
want
one
piece
of
data
in
this
message
and
its
value
is
a
string,
a
test
I
could
put
in
a
sophisticated
json
object.
Inside
of
this
message.
I
could
put
five
pieces
of
data
inside
of
this
message,
but
you
could
also
have
data
that
you're
putting
in
the
envelope
and
you're
sending
to
somebody
by
doing
over
a
send
to
an
individual
private
message
to
somebody
or
broadcast
to
all
of
the
network.
B
You
could
do
that
based
on
data
that
you
already
have,
because
you
received
it
from
somebody
else
or
data
that
you
have,
because
you
uploaded
it
because
it
was
100
megabytes
file.
So
when
you're
sending
a
message,
you
can
either
reference
existing
data
that
already
exists
in
your
private
view
of
the
world
on
your
firefly,
or
you
can
add
data
in
line
in
that
in
that
payload.
B
B
Is
going
to
look
something
like
this
thing
on
the
right?
I'm
going
to
going
to
say,
look,
here's
my
data,
it's
just
in
line
it's
there
in
the
in
the
message
itself
and-
and
you
can
do
this-
using,
for
example,
the
the
the
the
sample
application
and
firefly
samples
that
andrew
showed
at
the
kickoff
and
we'll
make
sure
there's
good
things
to
that,
and
you
just
say:
look
here's
some
data.
I
want
to
send,
but
you,
but
in
the
future
you
might
find
your
referred
to
date.
B
It's
just
just
one
transmission
that
you
know
you
can
look
at
and
everybody
who's
involved
and
can
see
so
in
the
in
the
header.
I
say
things
like
do.
I
want
this
to
be
pinned
to
the
blockchain.
What
transaction
type
is
that
so
you
might
want
to
depend,
or
there
are
many
cases
where
in
this
multi-party
network,
you
want
it
to
be
audited
on
your
side
in
firefly
with
the
database.
B
You
want
it
to
be
all
still
on
the
other
side
in
in
their
their
firefly,
but
actually
don't
want
any
of
the
overhead
of
putting
on
the
blockchain
at
all.
There's
no
there's
no
reason
you
have
to
do
that,
just
because
you're
you're,
using
firefly
as
part
of
the
the
monopoly
network.
So
so
you
choose,
if
you
want
a
transaction
or
not
on
here,
and
you
tag
it
to
say
the
type
of
message
there.
B
So
this
is
a
request
like
my
particular
request
message,
or
you
know
a
category
of
the
message
and
then
topics
we're
going
to
talk
about
in
future
sessions.
It's
like
an
ordering
context.
Everything
on
the
same
topic
has
to
be
ordered
with
everything
else
on
that
same
on
that
same
topic
within
the
scope
of
the
group.
So
so
that's
an
important
construct
that
we'll
talk
about
in
future
sessions.
When
we
talk
about
message
ordering
and
then.
B
If
you
want
it
to
be
private,
you
have
to
specify
who
the
recipients
are,
and
if
you
specify
the
same
recipients
over
and
over
and
over
again,
it
will
all
be
resolved
to
the
same
group
and
and
if
you
want
to
really
detail
business
down
the
road,
you
might
want
lots
of
different
groups
with
the
same
participants
in
you
can
customize
it
with
a
name.
So
one
last
thing
is:
there
is
the
construct
which
more's
happening
as.
B
Work
on
fabric
channels
and
and
the
like,
the
construct
of
a
ledger
that
I
want
to
attach
this
to
so
think
about
many
networks.
Only
just
have
one
one
ledger
that
everybody
can
see,
but
there
are
other
networks
where
you
actually
want
to
have
different
ledgers
that
have
a
subset
of
people
who
can
see
and
attest
to
that
ledger.
B
I
guess
the
key
thing
to
know
is:
there's
a
big
difference
in
firefly,
just
because
you're,
all
using
the
same
ledger
doesn't
mean
you
all
need
to
see
the
same
data,
because
in
real
business
scenarios
it's
much
more
common
for
different
parties
to
be
able
to
see
different
parts
of
the
transaction,
even
if
they're
all
attesting
to
that
transaction,
but
it
is
that
every
party
can
see
every
piece
of
data.
So
anyway,
that's
that's
a
message.
B
It
looks
pretty
simple.
It's
very
simple
to
send
you
just
do
post
to
message
to
to
send
the
the
message,
and
that
goes
into
the
system.
What
happens,
then?
Is
it
sort
of
gets
split
down,
reconciled
with
everything
else?
That's
already
there.
So
maybe
you
reference
some
existing
data.
Maybe
you
put
some
inline
data.
Maybe
it's
the
first
time
a
group
has
been
used
that
got
resolved
down
or
maybe
that
groups
haven't
been
used
a
million
times
before
all
of
that
gets
resolved
and
a
bunch
of
things
get
stored
locally
inside
of
firefly.
B
So
these
things
you'll
see,
there's
lots
of
rest
interfaces
to
get
on
firefly
and
the
ui
shows,
and
it's
continuing
to
evolve,
to
show
all
of
these
bits
of
bits
of
data,
and
you
can
see
sort
of
like
one
piece
goes
in
and
it
gets
split
apart
and
there's
good
reasons
why
it's
being
completed
apart,
but
in
this
session
we're
going
to
talk
about
what
some
of
that
splitting
is
and
why
it
happens.
So
the
three
logical
things
that
you
might
have
put
in
the
same
message
they
get
split
apart
in
the
data
model.
B
B
In
that
particular
case
and
the
data
all
of
those
individual
pieces
of
data,
whether
they're,
new
or
the
ones
that
you've
already
had,
they
all
exist
as
unique
resources
and
with
rest
interfaces
in
in
the
model
just
a
couple
of
other
things
that
we're
not
going
to
talk
about
much
more
about
in
this
session.
But
I
wanted
to
make
sure
you're
aware
of
data
is
split
between
the
stuff.
That
is
a
value
it's
like
in
line
in
the
data
that
gets
stored
in
the
database.
B
Databases
are
obviously
not
redundantly
suited
to
storing,
like
100
megabytes
blob.
That's
not
really
the
right,
the
right
balance,
in
fact,
probably
you
get
above
a
megabyte.
Probably
you
should
be
thinking
of
different
storage
approach,
so
the
the
data
exchange
plug-in
that's
a
pluggable
capability
of
a
firefly
that
comes
with
a
built-in
one
that
uses
a
file
system.
B
You
that's
where
these
those
will
be
uploaded,
so
you
can
upload
them
on
the
firefly
api
and
you
can
download
them
and
your
nice
multi-part
upload
that
you'd
expect,
but
where
they
get
stored,
that's
a
that's
a
plugable
thing,
so
blogs
are
interesting
and
then
the
other
thing
just
to
mention
here
is
that
groups
reconcile
down
to
identities
and
the
inside
of
a
group.
Each
identity
is
a
combination
of
an
actual
identity.
The
moment
the
only
identities
that
exist
organizational
identities
and
those
need
to
have
been
registered
ahead
of
time.
B
But
there's
the
architecture
will
definitely
support
anonymous
scenarios
down
the
road
and
and
also
a
node
identities.
There
is
a
plugin
for
identity,
which
is
really
a
placeholder
at
the
moment.
It
just
maps
one
to
one
where
you
might
have
an
identity,
which
is
something
very,
very
flexible,
like
a
did,
and
then
a
resolution
plug-in
that
will
allow
you
to
resolve
that
down
to
signing
identities
and
other
other
identities
in
the
system.
B
So
my
message,
little
input
message
bit
of
data
reference
to
a
group,
whatever
went
in
got
split
past
into
a
messaging
group
and
data.
Now
this
is
happening
in
you
know,
get
reduction
scenario.
This
is
happening
in
volume.
Lots
of
these
are
happening
and
they
are
being
accepted
into
the
system,
but
there's
lots
of
chain
of
events
that
needs
to
happen
from
them
going
from
their
initial
state,
which
is
pending
to
actually
being
confirmed
in
the
system
and
we'll
talk
about
the
importance
of
ordering
in
future
sessions.
B
B
B
So
batching
is
an
automatic
built-in
construct
for
pinning
inside
a
firefly
that
will
work
across
ledges,
etc.
So
so
your
messages
get
assembled
with
any
other
messages
that
arrive
in
a
particular
time
window
up
to
a
certain
cap.
So
I
don't
know
300
messages
above
within
a
couple
of
seconds.
You
assemble
those
together
they
go
into
a
batch
and
and
then
that
batch
gets
us
gets
a
transaction
assigned
to
it
and
the
transaction
exists
in
firefly.
So
you
can
actually
see
that
transaction
sort
of
set
has
a.
B
It
exists
in
your
local
database
of
firefly,
as
well
as
propagating
to
the
to
the
blockchain
just
a
placeholder.
Here
it's
really
important
to
understand
that
firefly
is
trying
to
simplify
all
of
the
things
you
might
do
in
a
multi-party
system.
We're
talking
a
lot
about
a
case
where
the
transaction
is
very
simple,
because
we're
focused
on
the
on-chain
off
chain
coordination.
B
We're
not
talking
about
it,
not
because
it's
not
important,
but
we
will
be
talking,
but
because
really
a
lot
of
the
heavy
lifting
that
firefly
does
is
to
enable
all
of
the
things
that
exist
off-chain
to
coordinate
with
those
on-chain
things.
So
it's
not
that
it's
not
important.
It's
just
that.
The
focus
of
that
is
all
of
the
existing
communities
and
we're
using
all
of
the
the
investment
and
and
fantastic
innovation.
That's
happening
inside
of
the
individual
blockchain
communities
and
across
the
blockchain
communities.
B
That's
what
firefly's
there
to
do
it's
there
to
harness
that.
It's
not
there
to
be
the
next
fantastic
implementation
of
a
hash
time
lock
on
chain
transaction
right.
That's
not
the
firefly
community's
role.
The
fireflies
community's
role
is
to
take
that
fantastic
implementation.
That's
just
been
done
and
make
it
possible
for
mere
mortal
engineers
that
by
full
stack
web
applications
to
build
beautiful
experiences.
On
top
of
that,
so
watch
this
space
for
us
to
talk
lots
more
about
transactions
in
this
session.
B
The
example
transaction
is
super
simple,
and
it
comes
out
of
the
box
in
firefly,
because
it's
so
simple
super
simple.
So
the
journey
we've
been
on
so
far
is
we've
got
messages.
We
put
a
message
in
it
got
assembled
into
a
batch
of
messages
and
we
said
well,
a
transaction
gets
associated
with
it
and
stuff
needs
to
happen.
B
B
An
operation
is
an
actual
thing
that
actually
happened
in
a
plug-in,
so
you've
got
a
plug-in
for
the
blockchain
you've
got
to
plug
in
for
the
data
exchange,
that's
doing
things
like
transforming
transporting
messages
privately
between
two
participants
with
the
right
level
of
transport
security.
You've
got
an
operation
for
something
like
storing
the
data
in
public
storage
like
ipfs.
B
Those
operations
are
product
like
that
they're
infrastructure
specific
and
they
have
a
result
right
depending
on
the
way
the
plug-in
works
that
result
might
come
immediately.
That
result
may
come
in
a
few
seconds
time.
That
result
may
be
a
success.
It
may
even
be
a
failure,
so
we
have
an
operation.
A
little
resource
and
a
very,
very
small
resource
there
inside
of
inside
a
firefly
for
each
one
of
these
operations,
each
each
sort
of
bit
of
the
plumbing
that's
happening.
Underneath
this
this
bigger
piece.
B
We
do
that
so
that
you
can
understand
what
happened
and
you
can
see
what
how
to
correlate
the
the
orchestrator
with
the
low-level
pieces.
So
if
you
want
to
go
and
look
inside
of
ipfs,
you
need
to
know
the
ipfs
id.
Where
do
you
look?
Well
because
it's
ipfs
specific
it's
going
to
be
in
the
operation,
because
the
operation
is
the
mapping
from
a
general.
I
need
to
pin
this
data.
I
need
to
store
the
state
in
public
storage
to
to.
I
did
this
in
ipfs,
and
this
is
the
id.
B
So
so
things
like
that,
blockchain
plugins
are
able
to
do
things
like
anonymous
submission
of
the
transactions,
but
that's
protocol
specific.
So
that's
in
the
plug-in
bucket,
but
the
transaction
data
itself
involves
an
id
uniquely
generated
for
that
one
batch.
So
it
doesn't
leak
a
hash
of
the
batch
which
allows
you
to
match
the
thing
that
you
receive
off
chain
with
the
thing
that
happens
on
chain.
B
An
idea
of
the
transaction
goes
there
as
well,
so
same
characteristics
have
been
uniquely
created
and
then
these
pins
and
we're
going
to
talk
a
little
bit
about
those
more
in
future
sessions.
There's
not
time
today
to
to
go
through
them
in
detail,
but
we're
going
to
refer
to
them
and
there's
a
pin
for
each
message
in
the
batch
and
the
pin
is
represents
the
that
this
message
is
sort
of
placed
in
the
overall
sequence.
B
It
doesn't
get
sequenced
in
the
actual
order
until
the
blockchain
puts
the
transaction
in
an
order,
but
it's
the
thing
that
identifies
in
a
way
that
is
obfuscated
for
privacy.
So
you
don't
have
this
like.
If
you
do
five
transactions
on
the
same
topic
within
a
private
context,
not
a
broadcast
context,
you
don't
want
that
to
be
the
same
same
value
in
those
five
transactions.
That's
the
cleverness
under
the
covers
that
we'll
go
through
in
the
future
in
the
future.
One
of
these
sessions,
these
pins
are,
are
there.
B
So
what
you'll
find
when
you
look
at
the
blockchain
transaction
is
there's
this
sort
of
hash
pin
for
each
message.
Inside
of
the
batch,
I
mean
it's
a
very
efficient
way
to
use
the
blockchain,
so
you
can
get
a
lot
of
a
lot
of
performance
out
of
the
blockchain,
because
you're
writing
per
batch,
which
might
contain
hundreds
of
transactions.
You're
writing
one
transaction.
It's
just
got
this
list
of
hashes
inside
of
it,
okay,
so
so
we've
and
just
to
refer
back
to
blobs.
Here
the.
B
B
It
goes
first
into
your
own
local
storage
and
then,
when
you
send
a
transaction
that
needs
that
to
be
broadcast
to
everybody,
we'll
check
if
it's
already
been
put
into
published
storage,
if
it
hasn't
we'll
put
it
there
and
then
the
the
data
that
flows
with
your
message
just
has
a
reference
to
wherever
it's
stored
in
the
public
storage
and
again,
that's
extensible
to
any
public
storage
mechanism.
It
could
be
a
ul
to
some
central
location.
It
could
be
an
ipfs
id
which
is
the
current
plugin.
That's
that's.
B
There
provides
it
out
of
the
box,
I'm
going
to
just
talk
a
minute
and
we
might
come
back
to
this
in
a
future
session.
It
is
possible
to
do
completely
unrelated
to
blockchain
tran
messaging
as
well.
That's
that's
there
available
and
you
can
give
it
a
try.
So
if
you
need
some
things
that
involve
the
blockchains
and
some
things
for
latency
reasons
or
other
reasons,
don't
don't
need
to
go
on
the
blockchain
at
all.
B
You
can
do
that
and
they
just
get
wrapped
up
and
basically
all
the
data
that
needs
to
go
gets
grouped
together
into
an
individual
message
and
that
message
gets
sent.
Super
simple,
the
message
details
of
the
group,
because
you
need
to
know
who
else
is
in
it
detail
about
that
in
future
sessions,
and
then
the
data
gets
bundled
together,
but
not
with
hundreds
of
other
messages
like
just
just
those
get
bundled
together
and
they
get
and
they
get
sent.
B
So
that's
how
unpinned
transfer
works
and
then,
if
we
look
again
at
pinned-
and
we
look
at
how
blobs
work
in
the
case
of
just
sending
those
privately
very
simple,
there's
an
operation
for
them
and
they
get
sent
separately
to
the
batch
because
they're
large,
it
makes
sense
for
them
to
have
a
separate
transmission
cycle
and
also
a
good
data
exchange.
Implementation
is
going
to
do
things
like
chunking
and
streaming
and
checkpoint
restart.
All
the
things
you'd
expect
from
a
managed
transfer
protocol.
B
Thank
you
very
much
nico,
so
we've
got
as
far
as
all
of
the
stuff's
gone
right
and
we
broke
it
down
our
input
message.
Groups
data
went
into
a
batch,
fewer
questions
happens
when
the
transaction
happens
and
we're
going
to
talk
a
little
bit
more
about
then,
and
we're
going
to
talk
now
about
the
other
direction
right.
I
I
send.
B
What
about
when
I
actually
want
to
receive
information
from
firefly
and
we're
going
to
just
talk
briefly
about
this
today
and
then
we're
going
to
have
whole
sessions
where
we
talk
about
sequencing
and
complexity.
That's
involved
here,
and
the
important
thing
to
know
is
in
the
case
of
pinned
transactions.
So
this
is
the
most
interesting
case.
B
The
order
on
the
blockchain
is
the
truth.
The
order
on
the
blockchain
is
the
truth.
It's
the
blockchain
interfaces,
responsibility
whatever
that
plug-in
is
to
do
a
reliable
event
streaming
from
whatever
the
blockchain
has
so
ifconnect
for
ethereum,
that's,
reliable,
a
collection
of
of
information
from
their
blocks
and
transactions
that
are
happening
inside
of
inside
of
your
ethereum
network
and
all
of
those
topics
and
and
logs
corda
corder
connect.
B
Does
that
with
the
with
the
java
interfaces
that
allow
transaction
streaming
based
on
timestamp
recorder
transactions
and
the
fabric
under
development
and
plugin?
Does
that
with
the
native
eventing
system
of
fabric,
but
it's
responsible
for
delivering
them
to
firefly
in
the
same
order
reliably
as
they
happened
on
the
chain.
Firefly.
A
B
Says,
thank
you
very
much.
I've
put
that
in
order,
and
it
puts
it
into
an
ordered
sequence
of
these
pens,
and
it
does
that
because,
while
the
order
on
the
blockchain
is
the
truth,
whether
a
message
is
ready
or
not
is
not
just
did
the
blockchain
get
arrived,
the
blockchain
get
midaway.
First
then
the
private
data,
then
the
blob,
the
blog,
might
live.
B
So
probably
one
of
the
heaviest
lifting
pieces
of
engineering
inside
of
the
core
of
firefly
is
the
aggregator
and
the
aggregator's
responsibility
is
for
working
out
when
a
pin
becomes
ready.
It's
ready.
All
the
stuff
is
assembled.
The
off
off-chain
stuff's
been
aggregated
together,
the
pin
is
ready,
I
can
move
on
and
what
does
moving
on
mean
moving
on
means.
Turning
the
fact
that
that
pin
was
something
that
I'm
interested
in,
I
had
a
void
to
see.
I've
got
the
data,
it's
all
available.
B
That
fact
becomes
an
event,
so
messages
go
into
the
system
from
one
member
and
then
they
come
back
out
against
events
to
that
same
member
and
everybody
else,
and
that
means
that
everybody
can
process
them
in
the
same
order,
whether
that's
the
person
who's
center
or
everybody
else.
So
inside
of
firefly.
B
You
don't
know
at
the
time
that
the
ping
comes
in
whether
you're
interested
or
not,
because
the
other
things
need
to
come
in
before
you
can
tell,
and
then
the
ones
that
I
am
interested
in
and
they're
complete
go
into
a
list
of
events,
which
means
we
store
those
events
only
once,
but
that
doesn't
mean
just
one:
application
can
listen
to
those
events.
Just
like
anything.
That's
in
the
messaging
space
that
deals
with
these
kinds
of
scenarios.
We
have
a
construct
of
a
subscription
and
a
subscription
is
a
very
simple
thing.
B
It's
just
a
pointer
to
a
particular
point
in
this
list
of
events
and
a
filter
to
say
what
events
you're
interested
in
and
then
a
connection
to
a
particular
transport
of
which
we
have
two
web
sockets
and
we're
hooks
very
pluggable
there,
easy
to
plug
in
lots
of
other
things
down
the
road
where
you
can
say.
Basically,
every
time
an
event
happens
of
this
type,
deliver
it
to
my
applications
using
this
transport
and
then
that
pops
up
inside
of
your
application
as
an
event.
B
B
I
send
a
message
and
I
get
events
out
we're
going
to
talk
and
maybe
in
a
future
session
we're
going
to
talk
about
how
we
could
turn
that
into
an
api,
so
that
there's
a
request,
message
and
there's
a
response
message
and
they
need
to
be
aggregated
together.
I
need
to
wait
for
a
response
to
a
particular
request.
We're
going
to
talk
about
that
in
future
sessions,
but
the
fundamental
model
of
firefly
is
event
driven
either
messages
or
blockchain
transactions
or
blockchain
transactions
caused
by
messages
right.
B
Back-End
core
java
developers,
developers
using
esbs
and
other
integration
technologies
on
premise
very
important
in
the
ecosystem.
Firefly
can
be
that
connection
point
where
you
can
say.
I
have
a
core
system.
It
wants
some
write,
some
data
and
broadcast
it
to
people.
Something
happened
on
the
blockchain,
it
turns
into
an
event,
that's
the
model
and
then
inside
of
the
box,
the
sort
of
paddling
feet
of
the
swan
under
the
surface.
B
Here
you
then
have
access
to
all
of
these
things
that
need
to
happen
for
an
efficient
system
and
firefly
from
the
learning
of
lots
of
projects
and
sort
of
said
we're
actually
going
to
end
up
implementing
all
of
these.
We
can
make
them
a
pattern.
We
can
make
them
plug-able
and
we
can
give
you
insight
with
user
experience
and
rest
api
so
that
you
can
see
what
the
heck's
going
on
and
you
can
see
under
the
covers
of
what
what's
happening
inside
of
the
environment
and
that's
all
we
wanted
to
take
you
through
today.