►
Description
A virtual meetup hosted by the Hyperledger India Chapter on July 29, 2021 featuring Jim Zhang, Co-Founder and Head of Protocol at Kaleido and Nicko Guyer, a Software Engineer at Kaleido. They are speaking about an exciting new Hyperledger Labs project - FireFly, a multiparty system for enterprise data flows, powered by blockchain. They discuss how FireFly came about through real world blockchain consortia and the value it brings to enterprises building blockchain apps. They also talk about how FireFly works, give an overview of the architecture, and a short demo of some of some of the types of business transactions that FireFly allows you to perform.
More about Firefly is at: https://wiki.hyperledger.org/display/labs/FireFly
More about this meetup is at: https://www.meetup.com/Hyperledger-Bangalore/events/279613137/
----
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 #HyperledgerGlobalForum2021 #Blockchain
A
B
Thank
you
very
much
appreciate
it
arun.
Thank
you
all
for
coming
here
this
evening
or
this
morning
or
wherever
you
may
be
located,
we're
very
excited
to
get
a
chance
to
talk
with
you
about
firefly.
It's
a
pretty
exciting
project.
I've
been
working
on
it
for
a
couple
of
months
now
and
I'm
super
excited
to
tell
other
people
about
it
and
hopefully
get
them
excited
about
it
as
well.
We
would
love
to
get
more
contributors
from
all
around
the
world
involved
in
the
project
and
and
also
maintainers
as
well.
B
But
you
know
the
kind
of
the
first
step
of
that
is
just
helping
people
understand
what
what
is
the
project.
How
does
it
work?
What
does
it
do?
What
problems
does
it
solve?
So
that's
kind
of
the
goal
of
today's
meet
it
up
is
just
an
introduction
to
firefly,
if
you
maybe
you've
heard
of
it,
but
maybe
you
haven't
had
a
chance
to
see
it
in
action
or
try
it
out
yet
so
we're
gonna
do
both
of
those
things
today,
but
so
first
so
so
my
name
is
nico.
B
Guyer,
I'm
a
software
engineer
at
collido,
I'm
also
the
community
lead
for
the
firefly
project,
so
I
put
on
meetups
run
our
weekly
community
calls
and
that
sort
of
thing
I'm
going
to
hand
it
over
here
to
jim
zhang,
our
head
of
protocol
and
also
co-founder
of
collido
and
he's
going
to
talk
you
through
kind
of
what
you
know
the
high
level.
What
is
firefly,
what
problems?
Does
it
solve
and
kind
of
the
the
story
of
you
know
how?
C
A
C
C
A
A
C
Okay,
awesome
so
firefly
what
it
is.
It's
it's
not
a
new
dlt
technology,
but
it
builds
on
dlt
to
be
a
system
for
multi-party
systems,
solutions
when
we
say
multi-party
system.
What
does
it
mean?
So
I
don't
think
I
don't
necessarily
coined
this
term.
I've
seen
this
term
used
in
in
other
channels
in
other
situations,
but
I
think
in
general
it's
it's
a
new
term
that
is
describing
a
system
where
typically
it's
rooted
on
blockchain.
C
So
that's
where
things
are
really
critical
to
have
a
blockchain
as
sort
of
the
foundation
of
such
a
system,
but
on
top
of
the
blockchain
layer,
a
multi-party
system
has
many
other
components
that
are
needed
to
make
things
flow,
all
the
things
that
you've
seen
in
the
typical
centralized
enterprise
it
systems.
You
know:
reliable,
messaging,
api
servers,
file,
system,
storage,
distributed
file
system,
databases,
all
that
are
still
involved
to
make
this
such
a
system
work.
C
C
You
have
the
blockchain
on
the
bottom,
but
that's
just
sort
of
five
to
ten
percent
of
the
whole
thing
you
have
to
build.
On
top
of
that,
you've
got
to
build
all
these
other
things
to
make
all
the
all
the
data
exchange
work
reliably.
So
that's
what
we
mean
by
a
multi-party
system,
which
is
it's
rooted
in
blockchain,
but
it's
much
more
than
blockchain.
So
that's
that's
sort
of
the
space
firefly
is
targeting
and
it's
trying
to
solve
all
the
problems
to
accelerate
the
adoption
of.
C
Blockchain,
okay,
just
need
to
click
all
right,
so
let's
spend
a
few
seconds
on
the
sort
of
the
the
problem
statement.
What
are
we
trying
to
solve?
Blockchain
is
definitely
a
groundbreaking
technology,
but
it's
so
new
that
it's
still
in
its
early
days
in
the
adoption
curve
we've
seen
in
the
past
six
years
since
we
started
on
this
journey
with
blockchain,
there
are
interest
in
this
technology
from
every
single
industry,
regardless
of
what
industry
industry
you
are.
You
have
at
least
one
or
two
problems
that
can
be
solved.
C
C
Most
of
the
enterprises
came
into
the
space
with
a
fairly
naive
view
that
okay,
I've
got
a
blockchain,
that's
it.
You
know,
I'm
going
to
write
a
bunch
of
smart
contracts
deployed
to
the
chain
and
we'll
be
fine,
but
very
soon
they
found
out
that.
Well,
if
you
put
the
business
logic
on
chain,
then
the
data
that
needs
to
be
processed
by
those
logic.
C
A
C
C
So
it's
it's
very
unfortunate
that
a
fantastic
technology
like
blockchain,
it's
sort
of
seeing
difficulties
in
adoption,
because
things
that
are
needed
off
the
chain
that
needs
to
be
there
to
make
the
chain
itself
work.
So
that's
kind
of
the
problem
where
we're
seeing
enough
of
that.
We
decided.
We've
got
to
do
something
about
this
because,
as
a
company
we
we
know
this
technology
is
groundbreaking.
It's
going
to
be
very
disruptive.
It's
going
to
be
strategic
for
the
whole
industry
going
forward,
but
un
until
these
robot
blocks
are
taken
care
of
are
solved.
C
So
at
each
party
at
the
table,
they're
running
their
own,
a
bunch
of
components
or
you
can
say
their
their
own
stack
of
components
that
are
attached
to
the
blockchain.
The
blockchain
is
definitely
the
the
universal
source
of
truth,
but
then,
on
top
of
it
they're
building
their
own
components
so
that
they
can
do
their
processing
business,
logics
data
exchanges,
save
their
critical
data
share
files.
All
that,
so
you
know,
there's
definitely
information
that
needs
to
be
shared
across
to
the
whole
network.
C
But
at
the
same
time,
you
also
have
just
peer-to-peer
data
sharing
just
between
two
parties
or
multiple
parties,
but
it's
a
subset
of
the
network.
So
there
are
parties
that
are
involved
and
they
can
see
the
data
and
the
rest
of
the
parties
on
the
network
are
kept
in
dark,
so
private
data
exchange.
You
know
you
want
to
do
it
through
reliable
messaging
and
you.
C
There
is
a
global
view
to
the
ordering
of
who
submitted
first
and
whose
second
and
all
that
so
all
that
is,
is
very
difficult
because
it
involves
off-chain
components,
databases,
queues,
messaging
systems
and
the
blockchain
itself.
So
blockchain
is
hard
enough
to
figure
out
and
now
you've
got
to
make
it
work
with
all
these
other
enterprise
components.
So
that's
sort
of
the
the
high-level
view
of
the
kind
of
things
you
have
to
make
work
to
build
a
solution
all
right.
C
So
now,
if,
if
we
look
at
the
the
open
source
landscape
right
as
a
enterprise
developer,
I
like
to
first
look
at
what's
available
in
open
source
space.
For
anything,
I'm
I'm
starting
to
build
because
open
source
is
great.
It's
usually
give
you
the
best
quality
stuff
and
also
prevents
a
vendor
lock-in.
So
that's
usually
the
first
choice
for
any
enterprise
solutions
to
start
looking
for
solutions.
C
So
you
have
to
build
them
for
the
solution
specifically
and
there's
a
big
missing
part
in
the
middle
that
takes
care
of
all
the
things
we
just
described
things
you
have
to
build
on
top
of
blockchain
and
we
haven't
seen
a
open
source
project
that
addresses
that
space
and,
as
as
we
said
out
of
a
whole
solution.
Blockchain
is
about
five
to
ten
percent
and,
let's
say
the
top
layer,
the
the
special
ip
is
another
5
or
10
in
the
middle
we
have
60
to
80
percent
of
stuff.
C
C
C
Remember
I
think
around
circa
2014
when
docker
came
about
it
was
great.
It's
it's
super
super
slick.
You
can
deploy
things
repeatedly
and
you
don't
have
to
think
about
deploy
things
configure
things
when
things
run
together.
How
do
you
config
config
all
the
ports,
so
they
don't
run
into
each
other.
Docker
is
a
great
isolation,
deployment
platform.
C
It
was
great.
It
was
so
exciting
and
we're
trying
to
use
it,
but
we
found
that
doc
while
docker
is
sort
of
the
beating
heart
of
new
architecture.
There's
so
many
things
missing
right.
How
do
you
configure
networking?
How
how
do
you
connect
the
instances
of
dockers,
how
you?
How
do
you
name
them,
so
they
don't
just
run
on
ips.
C
So
that's
where
kubernetes
came
in
until
kubernetes,
it
was
quite
difficult
to
figure
out
how
to
properly
and
efficiently
use
docker,
so
kubernetes
helped
a
docker
to
to
realize
the
the
promise
of
docker
and
we
think
firefly.
You
know
we're
still
in
the
early
days
of
firefly
we'll
you
know
we'll
still
be
trying
to
grow
it
to
become
a
real
thing,
but
we'd
like
to
think
that
firefly
will
will
help
the
adoption
of
blockchain
just
like
humanities,
to
dockers.
C
Right
so
now,
let's
look
at
look
at
what
exactly
makes
up
firefly.
So,
as
you
can
see
from
this
diagram,
firefly
is
a
typical
way
to
run.
Firefly
is
every
party
in
the
network
has
their
own
copy,
so
the
thing
that
they
run
for
their
own
organization
is
one.
We
call
one
firefly
node
a
firefly
node.
Has
these
multiple
components?
C
It's
got
a
a
api
that
you
can
send
messages
to
send
a
file
exchange
to
and
ask
firefly.
Please
share
this
with
this
party
and,
at
the
same
time
please
add
a
painting
transaction
to
the
blockchain
or
at
the
same
time,
in
a
token,
to
represent
this
information,
because
this
is
going
to
be
represented
as
a
unique
asset.
C
So
all
those
things
is
very
easy
to
do
with
firefly
by
just
making
a
simple
api
call
and
then
to
talk
to
different
kinds
of
blockchain
technologies.
Unique
connectors,
firefly
is
designed
to
be
super
plugable.
Pretty
much
everything
it
does
is
through
a
plugable
interface,
so
that
you
can,
you
can
replace
what's
there
with
a
alternative
implementation
as
an
example,
a
business
logic
when
some
events,
so
firefly
is
completely
event-driven
programming
model
beyond
the
apis.
So
when
some
events
is
published
and
it's
received,
how
do
I
process
it?
C
You
plugging
what
fits
your
scenario
the
best.
What
comes
out
of
the
box
is
sort
of
the
the
common
components
are
really
useful
for
you
know
most
of
the
scenarios,
but
if
you
have
a
special
need
for
a
special
kind
of
plugin
you
can
you
can
swap
in
or
if
there's
not
an
existing
plugin
implementation.
Yet
you
can
write
your
own
implementation
and
we're
going
to
provide,
as
you
will
see,
with
nico's
demo
part
very
good
material
to
write
them
yourself
and
we'd
love
to
engage
with
you
to
help.
C
So
I
mentioned
that
it's
very
plugable,
so
all
the
major
blockchain
technologies,
with
the
big
three
fabric,
enterprise,
ethereum
and
corda.
It's
all
supported
out
of
the
box.
We
have
a
hundred
percent
support
for
enterprise
ethereum,
already
we're
working
on
very
actively
working
on
hyperledger
fabric
and
order
support.
So
we
love
to
hear
feedback
from
you
guys,
and
so
we
can
accelerate
these
components.
C
C
C
A
B
B
A
Hi
all,
could
you
hear
me
yes
yeah,
so
you
told
like
it
can
be
plugged
with
hyperledger
fabric
as
well
right.
So
my
question
here
is:
if
we
plug
in
as
usual
like
in
hyperledger
fabric,
we
will
be
using
a
database
like
couchdb
or
level
db
right.
So
if
we
connect
this
firefly,
where
will
the
data
go
and
store
in
hyperledger
fabric?
C
Is
yes
great
question,
so
you
still
set
up
a
hyperledger
fabric.
The
way
you
want,
if
you
want
to
use
couchdb
or
the
the
embedded
leveldb
you
can
do
that,
but
understand
that
it
only
has
your
own
chain
data
in
that
database
and
it's
the
database
schema
is
designed
such
that
it's
easier
for
the
for
the
protocol
to
process
state.
It's
not
necessarily
the
ideal
way
to
save
the
data
from
your
business
queries
point
of
view
so
hype
fabric.
C
Sorry
firefly,
gives
you
a
off-chain
database
that
is
a
replication
of
the
data
on
unchained,
but
also
your
private
business
data.
That
is
not
prolong
chain,
but
is
also
critical
to
your
solution
itself.
So
you
also
have
this
database
in
firefly
off
chain
that
you
can
choose
to
replicate
the
information
from
on-chain
storage,
but
also
has
your
private
data
and
you
can
design
your
schema
to
make
that
be
more
efficient
in
terms
of
queries
from
your
solution.
So
that's
that's
the
difference
between
the
on-chain
state
database,
where
you
get
with
fabric
and
the
option
database.
A
Okay,
so
okay,
nice,
that's
great
actually
so
querying-
is
also
a
like
present
problem
in
hyperledger
fabric.
So
if
we
go
on
data
increase,
the
data
like
business
will
usually
has
many
transactions
per
day,
so
increasing
data
might
also
make
complex
for
querying.
So
that's
great
actually
and
another
question
is
you
were
telling
like
there
will
be
multiple
nodes
of
firefly
right,
so
each
node
will
have
the
same
data
or
what
is
the
architecture
there?
Yeah.
B
Yeah,
so
so
the
answer
is
the
short
answer
is
it
depends,
and
it
will
probably
make
more
sense.
Actually,
as
I
get
into
my
slides
and
show
a
demo
each
and
the
reason
it
depends
is
because
not
every
party
in
the
network
may
be
privy
to
all
of
the
data
in
a
certain
transaction.
So
for
for
things
that
are
public,
like
the
ledger
itself,
everybody
will
have
the
same.
Everybody
will
be
working
off
the
same
ledger.
A
B
Yeah,
so
the
firefly
is,
is
most
definitely
about
combining
the
power
of
on-chain
logic,
with
off-chain
business
logic
and
also
having
data
on
chain
and
off
chain
and
orchestrating
between
both
of
those
things.
So
from
from
that
standpoint,
it
it
does.
It
does
both
and
it
leverages
blockchain
in
a
lot
of
different
ways
to
be
able
to
do
that.
A
A
B
B
Yeah
good
question,
so
there
is
a
firefly
has
a
network
registry
api,
and
so
when,
when
a
new
node
comes
up
it
can
you
can
use
an
api
to
register
the
node
to
the
network
and
provide
the
identity
of
the
member?
That's
running
that
one
in
terms
of
exchanging
certificates
that
is
going
to
be
dependent
on
the
actual
the
the
technology
you're
using
to
implement
the
private
data
exchange.
B
C
And
to
add
to
that,
in
terms
of
the
identity,
how
how
do
you
represent
identity
on
the
firefly
network?
You
will
see
in
the
demo
that
identity
is
represented
as
ethereum
address.
Of
course
that's
when
you
build
your
firefly
on
top
of
ethereum
dlt,
but
if
you
are
building
on
top
of
fabric,
for
example,
or
even
corda,
where
identities
are
represented
as
certificates,
then
identity
in
that
case
in
the
registry
will
be
certificates
because
identity
itself
is
pluggable
component
in
firefly.
A
C
That's
a
great
question,
so
at
the
moment
we
have
implementations
that
uses
software
based
key
representations,
so
the
key
itself
is
in
memory,
it's
manipulated
by
the
by
the
software,
but
we
have
the
the
part
that
we
built
in
the
current
generation
has
support
for
hsm
modules.
We
just
need
to
port
that
over
to
the
new
generation,
so
there
is
an
interface
for
signing
things
and
we
don't
assume
the
private
key
is
always
always
available
to
us.
B
All
right
and
just
real
quick
apologies
for
the
I
realize
the
video
or
my
my
computer.
I
think
right
now
is
struggling
under
the
cpu
load
of
processing.
The
video
we've
we've
run
this
setup
before,
and
it
worked
a
lot
more
smoothly.
I'm
not
sure
why
it's
struggling
today,
but
I'm
just
going
to
turn
video
off
for
now.
Apologies
for
that
I
will
go
ahead
and
share
my
screen,
though,
and
so
you
don't
have
to
look
at
a
black
screen
and
we'll
talk
through.
B
So
I'll
go
quickly
through
this
part,
because
jim
did
a
fantastic
job
already
of
describing
the
use
case
for
firefly
when
you
would
want
to
use
it.
So
you
know,
but
to
summarize
you
know,
alice
and
bob
could
stand
up,
blockchain
nodes
on
a
shared
chain
and
then
and
then
what
well
there's
a
whole
bunch
of
other
stuff
that
they
need
to
add
in
order
to
actually
do
business
transactions
on
top
of
that
chain.
B
So
alice
can
stand
up.
A
firefly
node
bob
can
stand
up.
A
firefly
node
charlie
can
stand
up
a
firefly
node.
They
all
register
to
one
another
and
they're
in
a
firefly
network.
This
gives
them
a
ton
of
different
capabilities.
They
can
send
data
publicly
or
privately.
They
have
the
choice
of
making
that
on-chain
or
off-chain.
B
There
are
different
models
in
your
event,
driven
or
request
response.
They
can
send
just
you
know,
json
objects
they
can
send
blobs
or
binary
files
in
the
very
near
future.
There
will
be
support
for
fungible
and
non-fungible
tokens
as
well
as
custom,
on-chain
logic.
Those
are
things
that
are
either
in
development
or
will
be
shortly
and
there's
also
a
very
easy
to
use
rest
interface
along
with
web
sockets
and
web
hooks
for
receiving
events
out
of
the
event
driven
model
that
firefly
has
and
like
jim's
talked
about
it's
all
very
pluggable.
B
So
a
lot
of
these
things
can
be
replaced
with
you
know
if
you
need
a
specific
technology,
a
specific
type
of
messaging
system,
for
instance,
that
firefly
doesn't
support.
Today,
it's
extensible
you
can,
you
can
build
a
plug-in
to
extend
it.
So,
let's
talk
about,
how
do
I
actually
get
data?
You
know
say:
alice
has
a
piece
of
data
that
she
wants
to
send,
so
the
first
way
is
a
broadcast.
This
is
a
public
way
to
send
data
to
every
party
in
the
network.
B
B
This,
however,
say
she
has
a
piece
of
data
that
is
a
transaction
only
between
alice
and
bob
and
charlie
should
not
be
able
to
see
this
transaction
there's
also
a
way
to
send
messages
and
data
privately
in
firefly
as
well,
in
either
of
these
cases.
It's
it's
worth,
noting
that
the
the
data
payload
itself
will
not
be
on
the
blockchain
and
we'll
talk
a
little
bit
more
about
that
on
this
slide.
B
So
alice
has
the
option
when,
when
she's
sending
messages
to
other
members
of
the
network,
whether
that
message
should
be
pinned
to
the
blockchain
or
if
it
should
be
unpinned
and
even
if
the
blockchain
is
used,
it's
a
pin,
that's
stuck
on
the
blockchain,
not
the
actual
data
payload
itself,
so
bob
can
verify
that
when
he
receives
the
data
payload
that
yes,
okay,
that
is
actually
what
alice
sent
me.
It's
really
from
her,
and
that
was
really
what
she
sent.
B
Like
I
mentioned
earlier,
the
the
actual
things
that
you
send
inside
the
message
could
be
just
json
objects
or
it
could
be
a
blob.
It
could
be
a
binary
file.
The
data
can
be
either
inline
in
the
message
or
it
can
be
linked
and
like
we
talked
about
before
it
could
either
be
public
or
private,
and
you
can
sort
of
mix
and
match
all
these
different
types
of
things.
B
Okay:
let's
talk
real
quick
about
the
the
event-driven
model,
so
jim
said
that
you
know,
firefly
is
designed
in
to
be
an
event-driven
programming
model.
Firefly
itself
is
very
event-driven
and
the
best
way,
probably
the
most
recommended
way
to
write
an
app
that
uses
firefly
or
to
interact
with
firefly,
is
in
an
event-driven
manner
as
well.
B
So
alice
has
a
piece
of
data
that
she
wants
to
send
to
charlie
charlie,
previously
has
set
up
a
subscription
we'll
talk
about
what
subscriptions
are
I'll,
actually
show
you
one
in
a
little
bit,
but
it's
basically
just
a
way
of
saying
hey
for
these
types
of
events,
send
them
to
this
place
and
that
could
be
a
websocket
connection
or
it
could
be
a
web
hook.
Just
you
know
a
post
to
an
http
endpoint
somewhere,
so
charlie
has
set
up
that
in
the
past.
B
Alice
has
a
piece
of
data
she
wants
to
send
to
charlie,
so
she
makes
an
http
post
to
the
firefly
api.
I've
sort
of,
for
the
sake
of
this
drawing
simplify
the
communication
between
the
firefly
nodes
here,
but
when
she
makes
this
post
she'll
immediately
get
back
a
202
accepted.
That
means
firefly
has
received
the
message
and
it
has
it
it's
safe.
B
Alice
will
receive
either
again
over
a
websocket
or
web
hook.
A
an
event
saying
that
hey
this
message
has
been
confirmed:
charlie
got
it,
so
the
transaction
is
done
at
some
point
in
the
future.
You
know:
charlie's
application
may
also
generate
some
data
as
a
result
of
receiving
this
message
from
alice,
and
so
then
you
could
flip
the
whole
diagram
and
charlie
could
send
some
data
back
to
alice
the
other
way.
B
Again.
This
could
this
message
could
be
pinned
or
unpinned.
The
data
that
she's
sending
could
be
a
json
or
blob
this.
This
could
be
a
a
broadcast
message
to
everybody,
or
it
could
be
in
this
case
we're
only
showing
it
going
to
one
member
of
the
network,
but
remember
you
can
kind
of
mix
and
match
all
of
these
concepts
of
ways
to
send
data
within
firefly
to
meet
the
needs
of
your
specific
application.
B
B
So
the
key
difference
here
is
that
when
alice
makes
this
post,
so
this
is
a
post
to
a
slightly
different
http
endpoint
that
behaves
differently
than
our
other
broadcast
or
private.
Send
message
endpoints
this
endpoint,
which
I'll
show
you
in
a
little
bit
we'll
actually
look
at
all
the
the
rest,
swagger
and
I'll
show
you
all
the
different
endpoints
that
are
there
when
alice
makes
a
post
to
the
request.
B
Endpoint,
though,
that
request
will
stay
open
and
will
firefly
will
not
respond
to
the
request
until
it
has
sent
the
message
all
the
way
to
charlie
charlie's
application
has
responded
to
it
and
that
response
from
charlie
will
be
wrapped
up
in
another
firefly
message
and
returned
to
alice
back
as
the
response
to
her
original
request.
So,
as
you
can
imagine,
the
latency
is
definitely
higher
in
this
model,
because
this
original
http
request
will
be
blocked
until
charlie's.
Application
has
a
chance
to
respond.
B
B
Okay,
so
firefly
is,
is
very
modular,
as
jim
talked
about
I'll
just
quickly
highlight
all
the
different
things
that
can
be
plugged
into
firefly.
We've
talked
a
little
bit
about
it,
so
I
won't
talk
you
to
death
about
how
you
can
use
plug-ins,
but
yeah
we
talked
about
you
know.
Ethereum
support
is
there
100.
Today,
fabric
support
is
in
very
active
development
and
corda
is
is
shortly
to
follow,
so
you
can
actually
swap
out.
B
You
know
the
entire
blockchain
layer,
it's
worth,
noting
that
all
of
the
members
of
the
network
need
to
be
using
the
same
type
of
blockchain
right
now
today
in
firefly,
but
if
all
of
the
members
of
the
network
can
agree
hey
for
our
network
use
case,
maybe
fabric
is
a
better
fit
than
ethereum,
and
so
we're
all
going
to
deploy
firefly
and
we're
all
going
to
use
fabric
on
the
database
side.
There's
also
a
question
about
this:
we
there
are
plugins
today
for
postgresql
and
sql
lite.
B
Not
all
of
the
members
in
the
network
have
to
use
the
same
type
of
database,
though
the
database
is
their
own
private
database,
and
so
your
different
members
could
use
different
databases
if
they
wanted
to
if
they
had
a
specific
need
for
that.
The
blockchain
and
the
blockchain,
the
data
exchange
and
and
the
public
storage
are,
and
probably
the
registry
are
the
ones
that
need
to
be
the
same
across
the
network.
B
B
Okay,
cool.
I
then
I
had
the
thought
well
they've
been
able
to
see
my
slides
the
whole
time
right.
I
hope
all
right
cool,
so
yeah
the
event
transport.
All
of
these
things
are
pluggable,
so
if
you
want
to
use
something
other
than
websockets
or
or
web
hooks,
you
could
do
that.
Here's
just
a
quick
look
at.
We
talked
about
this
diagram
in
our
community
call
yesterday.
B
So
there's
there's
sort
of
multiple.
You
have
the
the
firefly
core
process,
but
a
firefly
node
is
really
a
micro
services
architecture,
and
so
you
can
have
a
firefly
is,
is
really
an
orchestration
engine
and
it
talks
to
many
different
systems
to
actually
implement
the
specific
functionality
that
it
needs.
B
So
firefly
has
many
different
interfaces
of
sort
of
types
of
behavior
that
it
defines
in
the
code,
and
you
know
say
you
wanted
to
swap
out.
You
want
to
use
something
other
than
ipfs.
Well.
Ipfs
makes
a
lot
of
sense
in
a
distributed
system
like
this,
but
say
you
want
had
a
reason
to
use
something
else.
You
could
write
some
different
client
code
here,
just
just
a
little
bit
of
code
and
go
that
implements
the
public
storage
interface
and
talks
with
some
other
system.
B
Besides
ipfs
and
boom
you've
got
a
plugin
and
you
can
extend
firefly
and
work
with
multiple
different
public
storage.
Public
storage
systems
so
won't
go
into
too
much
detail
here,
but
this
is
just
sort
of
a
picture
of
the
different
layers
of
when
we
look
at
the
the
firefly
application.
How
a
firefly
node
is
put
together
all
right,
just
a
couple
of
quick
concepts
before
we
get
into
some
hands-on
demos,
so
namespaces
as
well.
When
we
start
looking
at
the
api
you'll
see,
everything
is
prefixed
by
a
namespace.
B
A
namespace
is
a
way
to
basically
group
related
messages
and
data
together.
So
your
reasons
you
might
want
to
use.
So
there
is
a
default
namespace.
That's
there
out
of
the
box
that
you
can
use,
but
you
may
want
to
use
a
different
namespace,
for
instance,
if
you
want
to
just
run
some
test
transactions
because
blockchain
is
used
here,
the
data
is
immutable.
B
B
Okay,
so
messages
we're
gonna.
Look
at
some
messages
here
in
just
a
second.
A
message
is
really
just.
Unfortunately,
it's
you
know,
everybody
has
a
message.
Kafka
has
a
message.
Sqs
has
a
message:
firefly
has
a
message.
A
message
is
the
way
that
you
send
data
to
other
members
of
a
firefly
network.
A
message
can
have
multiple
data
elements
in
it.
B
It
can
have
a
header
section
that
describes
how
the
data
should
be
sent
and-
and
it
can
have
a
group
section
in
it
that
says
who
it
should
be
sent
to.
So
we'll
look
at
some
specifics
here
now.
Actually,
I
think
yep
all
right,
so
I'm
gonna
I'm
gonna
slide
over
here.
You
should
be
able
to
see,
let's
see
so
my
screen
sharing
is
paused.
A
A
B
You
know,
questions
and
answers
and
and
have
some
discussion
here
at
the
end,
because
that's
I
think
the
discussion
part
of
meetups
is
one
of
the
most
valuable
parts.
So
if
you
want
to
get
started
with
firefly,
the
easiest
way
to
do
that
is
with
the
firefly
cli.
So
the
cli
is
a
tool
it
is
written
in
go
so
you
can
right
now
you
can
install
it
with
go
install
if
you
have
go
installed
on
your
computer,
and
this
is
a
way
to
set
up
a
like
a
local
development
environment.
B
So
say
you
want
to
write
an
app
that
runs
on
with
on
firefly,
and
you
can
use
the
cli
to
deploy
a
you
know
like,
like
I'm
sure
you
realize
by
now,
hey
there's
a
whole
bunch
of
moving
parts
in
a
firefly
network.
Well,
the
cli
takes
care
of
the
logistics
of
all
that,
for
you,
it's
not
designed
as
a
tool
to
deploy
to
production.
This
is
a
development
tool,
so
I'm
going
to
show
that
in
action
now
I
have
it
installed
and
the
binary
name
is
ff.
B
So
you
can
run
that
and
it
will
tell
you
all
the
different
commands
you
can
run.
So
I'm
going
to
ff
init
demo
it'll
initialize,
a
new
firefly
stack
it'll.
Ask
me
how
many
members
I
want
we'll
say
three
and
then
I'm
gonna
start
it
up
and
then,
while
it's
starting
up,
I
will
kind
of
describe
what
it's
doing
so.
B
B
So
I
think
my
computer
is
under
a
lot
of
stress
because
usually
this
goes
faster,
but
we'll
just
give
this
a
minute
here,
while
that's
going,
I
just
want
to
point
you
to
the
the
doc
site.
So
if
you're
curious
to
to
read
up
more
on
firefly
or
what
the
different
api
endpoints
are,
you
can
go
to
labs.hyperledger.org,
firefly
and
there's
some
different
getting
started
guides
here
on.
You
know
how
to
how
to
set
things
up.
Some
examples
of
you
know
how
to
broadcast
data,
and
then
the
api
spec
is
also
here.
B
All
of
the
api
endpoints
this
is
generated
by
so
the
our
the
swagger
for
firefly
is
generated
by
firefly
itself
at
build
time,
so
it
should
always
be
up
to
date
with
the
latest
version,
so
you
can
come
here
and
see
all
of
the
different
endpoints
and
my
goodness
this
is
going
really
slowly.
I
apologize
I'm
not
sure.
B
So
right
now
what
the
cli
is
deploying
on
my
machine
is
using
ethereum.
So
it's
it's
actually
that
the
current
version
of
the
cli,
if
you
go
grab
it
today,
will
use
it'll,
actually
use
ganache
as
a
just
a
very
lightweight
blockchain
implementation.
There's
a
an
open
pr
right
now
to
switch
that
to
an
actual
go
ethereum
node,
but
as
more
types
of
as
other
dlts
are
implemented
in
firefly,
there
will
be
additional
command
line
flags
added
to
the
cli
to
set
those
up
as
well.
A
B
B
C
A
A
C
C
Firefly
messages
are
things
that
you
send
across
parties,
you
know
can
be
json,
payloads
can
be,
can
be
referenced
to
a
file
or
it
can
be
filed
itself
and
and
the
secret
sauce
of
messages
exchanged
between
firefly
parties
is.
It
has
a
very
prescribed
side
effects
in
terms
of
what
what
it
does
to
the
blockchain.
C
Mainly
two
things
can
happen
when
you
exchange
messages,
one
is
it's
gonna
be
protected
by
blockchain.
So
after
the
fact,
neither
parties
can
deny
exactly
what
kind
of
data
was
exchanged
in
that
transaction,
because
it's
pinned
to
the
blockchain,
so
the
hazards
and
commitment
is,
is
immutable.
Now
the
other
is
a
global
ordering
if
multiple
parties
are
sending
their
their
messages
in,
let's
say
for
bidding
for
a
an
asset,
it's
critical
for
everybody
to
to
agree
who
went
in
first
or
who's.
A
B
B
B
Sure,
okay,
so
the
demo
is
up
so
my
my
firefly
cli
has
finished
starting
the
stack
and
it
says:
here's
your
web
ui
for
each
of
the
members
of
the
network.
So
I
have
three
members
in
my
network
and
firefly
core
is
listening
on
different
ports
for
each
of
them.
So
five
thousand
five
thousand
one
thousand
two,
so
you
know
kind
of
using
our
characters
from
the
slides
earlier.
We'll
pretend
that
this
is
alice.
B
This
is
bob,
and
this
is
charlie
and
I'll-
try
to
use
those
same
names
as
we're
going
through
the
demo
and
so
that
folks
can
kind
of
follow
along.
So
here
we
have
each
of
their
uis
right
now
they
all
look
the
same.
There
are
there
have
been
no
messages
sent
through
the
system,
so
there's
three
members
in
the
network
and
no
messages,
no
transactions,
because
nobody
has
sent
anything.
B
So
I'm
going
to
go
over
to
postman
here,
I'm
going
to
I'm
going
to
send
a
message.
This
is
from
alice,
so
I'm
using
port
5000
here
to
hit
the
first
firefly
node
in
the
network,
and
this
will
be
a
we're
sending
this
to
the
the
broadcast
message
endpoint
here.
So
this
will
be
a
public
message
that
will
be
sent
to
both
of
the
other
members
on
the
network.
B
B
Firefly
has
also
hashed
both
the
message
itself
and
the
pieces
of
data
in
it,
and
it's
it's
told
me
that.
Okay,
I
got
the
message
we
can
see.
This
is
a
202
accepted
and
it's
still
pending
right
now,
so
we
can
go
back
and
look
at
the
firefly
dashboard
here
and
just
refresh
this,
and
we
can
see
that
the
message
has
come
here
and,
let's
just
refresh
these
guys
too,
the
demo
is
not
working.
B
Oh
man,
this
is
this
is
wonderful.
This
did
work
last
time,
so
the
other
two
nodes
have
not
seen
the
message,
and
so
this
one
is
from
that
standpoint.
Firefly
is
working
correctly
in
that
the
message
is
still
pending,
because
the
message
hasn't
hit
the
other
nodes,
I'm
going
to
try
stopping
it
here
and
starting
it
back
up
again
and
see
if
that
clears
it.
If
not,
then
I'll
just
have
to
talk
through
the
rest
of
the
demo,
and
I
do
apologize
for
that.
B
The
first
time
you
start
up
a
firefly
stack
on
your
machine.
It
takes
a
bit
of
time
because
it
is
doing
a
lot
of
deployment
and
configuration
setup
that
the
next
time
you
start
it.
It
should
start
up
pretty
quickly,
though
it
just
has
to
basically
go
turn
on
all
of
the
processes
in
the
docker
containers.
B
And
it
did
not.
Oh
there,
it
goes
okay,
cool
refresh
this
one,
all
right
so
now
now
everybody
has
the
same
view.
So
each
this
is
alice.
Bob
and
charlie
all
see
the
same
message
that
has
gone
back
gone
through
the
system.
They
can
go
here
to
the
messages
tab
to
see
the
actual
message.
They
can
see
the
hash
of
the
data.
If
you
go
to
the
data
tab,
you
can
actually
click
on
this
and
see
the
actual
data
payload
as
well
and
there's
there's
the
message
that
was
sent.
B
Yes,
yes,
we
will
that's
a
good
spin
on
it.
Thanks
jim
I'm
just
going
to
try
that
one
more
time
just
to
make
sure
I'm
going
to
broadcast
one
more
message
here,
just
to
make
sure
that
goes
through
as
well
before
we
keep
going
okay,
yep.
I
think
I
think
we're
in
business
now,
I'm
not
sure
why
it
didn't
go
through
the
first
time,
but
now
now
each
member
sees
two
messages
have
been
sent
through
the
system.
So
that's
a
broadcast.
B
Let's
look
at
a
private
message
now
and
there
was
a
question
about
you
can.
Can
I
broadcast
a
message
to
multiple
people,
but
not
everybody,
and
this
is
this-
is
how
you
would
do
that,
so
we
called
so.
The
previous
request
was
to
the
broadcast
message.
Endpoint
now
we're
going
to
go
to
the
send
message:
endpoint
and
the
we've
added
a
new
thing
to
the
message.
B
Json
here
called
a
group
with
an
array
of
members.
We
could
have
many
different.
You
know,
however,
many
members
you
have
in
your
network.
You
could
list
out
all
the
identities
of
the
members
that
you
want
to
send
this
message
to.
In
this
case,
we're
just
sending
it
to
one,
but
if
you,
if
we
had
more
than
three
and
you
wanted
to
send
it
to
two-
you
could
just
continue
appending
identities
to
this
array.
B
So
here
we're
going
to
send
we'll
say
this
is
a
secret
message.
We've
also
added
a
header
now
this
is
not
required
to
send
a
private
message,
but
I
wanted
to
talk
about
the
header
as
well,
so
the
header
is
where
you
can
define
some
other
fields
that
tell
you
know
how
the
message
should
be
processed.
So
this
one
we're
adding
a
tag
on
and
a
tag
is
used
to
indicate
to
the
other
members
of
the
network,
how
they
should
process
the
data.
B
So,
for
instance,
you
may
have
you
may
send
some
some
data
and
the
message
may
be
sent
because
it
was
a
new
customer
order
or
something
like
that,
and
so
the
tag
can
be
used
to
tell
the
other
members
hey.
This
is
a
new
customer
order,
as
opposed
to
maybe
an
order,
that's
being
cancelled
or
revised,
or
something
like
that,
and
that
can
inform
the
other
members
how
they
should
process
the
data.
B
You
know
independently
from
the
data
itself,
okay,
so
so
this
is
going
to
be
a
message
again,
I'm
sending
it
from
alice's
endpoint
to
org
one
is
we
look
over
here?
You
know
number
one
is
this:
is
bob
so
he's
the
they
count
up
from
zero,
so
zero?
One
two
is
how
the
orgs
are
labeled
here,
so
we'll
send
this
one.
So
what
we
should
see
here
is
alice
and
bob
should
both
see
this
message,
but
charlie
should
be
totally
oblivious
to
the
fact
that
it
happened.
B
So
if
we
go
back
over
here,
we
look
at
alice's,
firefly
interface.
We
can
see
there
are
four
messages
sent
and
bob
sees
four
messages.
Charlie
sees
two
and
if,
if
you're
counting,
you
maybe
wonder
why
we
jumped
from
two
to
four
when,
when
we
sent
that
group
message
there
was
an
additional
firefly
behind
the
scenes,
sent
another
message:
initializing
the
group
between
alice
and
bob's
nodes,
and
so
that
was
what
this
group
message
was
and
that's
why
we
have
four
messages
here.
B
B
B
So
this
will
create
a
subscription
and
I'm
going
to
define
that
subscription
here.
So
basically,
I'm
telling
it
I
want
it
to
use
web
hooks,
I
give
it
a
name.
This
could
be
whatever
you
want.
Subscriptions
need
to
be
unique
between
the
namespace
that
you're,
creating
them
in
and
name
so
you
kind
of
have
the
the
two
combinations.
The
combination
of
the
two
needs
to
be
unique
there,
and
then
I
can
set
some
options
on
it.
B
So
the
most
important
option
here
is
the
url
of
where
I
want
it
to
go
to
so
I
I
fictitiously
called
this
the
banana
handler.
So
if
somebody
sends
me
stuff
related
to
bananas,
it's
going
to
send
a
post
to
this
endpoint
banana,
I'm
going
to
filter
on
things
coming
in
to
firefly
based
on.
If
they
have
the
tag
banana,
then
I'm
going
to
send
them
to
my
banana
handler.
B
This
will
also
it
will
so
these
options
here
so
remember
how
we
talked
about
the
request
response
model.
So
this
is
this
is
how
I
set
up
the
far
side
of
the
of
the
response.
So
basically
anytime,
a
message
comes
into
this
endpoint
firefly
will
wait
for
a
response.
It
will
get
that
response.
It
will
wrap
it
in
another
message
as
a
reply
to
the
original
message
sent
to
it,
and
then
it
will
tag
that
with
banana
response,
and
it
will
send
that
back
to
whoever
created
the
original
banana
message.
B
B
B
B
So
here
we're
going
to
the
the
tag
is
banana
because
that's
that's
what
we
have
set
up
on
the
far
side
for
the
subscription
to
receive
that
this,
the
tx
type
I've
set
here
to
none.
That
means
this
is
actually
not
going
to
be
pinned
to
the
blockchain
and
for
the
data.
I
I
just
decided
to
make
it
a
little
bit
more
interesting.
So
I
created
you
know.
Whole
json
object
here.
Rather
than
just
a
string
called
hello
world,
or
something
like
that-
and
then
here
down,
we've
seen
this
group
already.
B
This
was
not
pinned
to
the
blockchain,
so
it
was
actually
pretty
quick,
but
basically
that
went
round
trip
from
alice's
firefly
to
charlie's
firefly,
sorry
bob
to
this
request
bin-
and
we
can
see
that
the
banana
endpoint
was
hit
here
and
we
can
look
at
here.
We
see
the
json
payload
that
alice
sent
to
bob,
and
if
we
go
back
to
postman,
we
can
see
what
bob
responded
with
in
the
response.
So
the
response
is
itself
is
a
firefly
message
and
it
has
data
in
it
as
well.
So
we
can
go
down
here.
B
We
can
see
so
this.
This
is
the
basically
what
bob
responded
with.
So
he
responded
with
a
status
200.
Here's
all
the
headers
that
were
on
that
http
response
from
request
bin.
You
can
see
it's
you
know
powered
by
express
and
then
basically,
this
request
bin
just
responds
with
success.
True
and
that's
what's
in
the
response
body
there,
so
then,
if
we
go
look
at
alice's
dashboard
now
we
can
see.
B
B
I
can
go
to
the
data
tab
and
I
should
be
able
to
see
here's
here's,
the
actual
payload,
the
response
that
bob
sent,
so
that
is
it
for
the
demo.
Thank
you
for
for
bearing
with
the
the
technical
challenges
of
doing
a
live
demo.
I
appreciate
your
patience
there.
Hopefully,
the
demo
and
the
hands-on
was
helpful
just
to
see
some
of
the
types
of
things
that
you
could
do
with
firefly.
B
We
have
about
15
minutes
left
and
just
wanted
to
open
it
up
for
for
more
questions
and
answers.
I
think
some
some
conversations
been
going
on
in
chat
but
yeah.
I
want
to
open
up
for
for
a
q
a
and
discussion
now
and
actually
before
that
sorry,
I
had
one
more
slide
and
that's
kind
of
you
know.
What's
what's
next.
B
So
those
are
those
are
areas
that
we're
working
on
right
now,
fungible
and
non-fungible.
Tokens
actually
is
is
being
worked
on
right
now
as
well.
So
that's
that's
coming
up
next
shortly:
custom
on-chain
logic,
we
we
know
we
definitely
need
to
have,
however,
we're
holding
off
on
implementing
that
until
we
actually
have
multiple
different
types
of
chains
that
we
can
work
with,
so
that
we
make
sure
we
get
that
right.
B
We
don't
want
to
design
custom,
on-chain
logic
for
just
ethereum
and
then
realize
that
we
needed
to
design
it
differently
when
we
have
other
chains
available,
so
we're
waiting
on
that
one
until
we
get
all
three
ethereum
fabric
and
corda
100
supported,
and
then
we
will
layer
on
custom
on
chain
logic.
On
top
of
that
and
lastly,
what
you
know
what's
coming
up
next
on
firefly,
hopefully
contributions
from
you
all.
B
We
would
love
to
get
people
involved
in
this
project
and
contribute
to
it
or
you
know
if
you're
really
passionate
about
it
and
want
to
get
involved
long
term,
we
would
love
to
bring
on
more
maintainers
for
the
projects
as
well.
There's
a
lot
of
different
repos,
a
lot
of
different
parts
of
the
project
that
people
could
have
ownership
over
and
I
definitely
want
to
grow
this
community
and
that's
why
we're
so
excited
to
be
able
to
share
with
you
all
what
it's
all
about
today.
So
that's
that's
it
for
my
slides.
C
C
A
C
A
B
Yes,
so
what
I
think
happened
there
is
we
probably
got.
There
was
probably
some
component
of
the
network
that
wasn't
talking
to
one
of
the
other
components
and
just
a
restart
got
that
to
work.
It
was
probably
just
a
timing
issue
and
everything
starting
up
on
my
machine.
It's
not
typical,
but
so
so
what's
the
yeah.
So
I
I
just
talked
briefly
about
the
kind
of
the
deployment
strategy.
So
so
firefly
itself
is.
B
It
is
a
the
process.
Itself
is
stateless,
so
you
can.
You
can
run
multiple
firefly
core
processes,
you
as
long
as
so
so.
The
state
really
ends
up
going
to
the
database,
primarily
so
each
type
of
database
that
you
use
will
have
its
own
and
redundancy
sort
of
model
and
that's
that's
going
to
be
dependent
on
which
type
of
database
you're
using
as
long
as
you
know.
B
So
you
so
we
talked
about
how
a
firefly
node
is
really
like
a
whole
bunch
of
different
processes
and
a
node
could
have
actually
within
that
multiple
firefly
core
processes
for
redundancy
or
for
scale,
but
they
they
do
need
to
talk
to
the
same
source
of
truth
in
terms
of
where
the
data
is
coming
from,
though
so
yeah.
So
you
could
have
a
firefly
node
crash
in
the
middle
of
stuff,
and
you
know
all
of
the
important
state
and
status
of
messages
in
flight.
B
C
A
A
B
B
It's
basically
going
to
be.
You
know,
however
fast
your
application
can
go,
you're
only
going
to
be
limiting
yourself
in
terms
of
bottlenecks,
though
that's
a
great
question
there.
There
is
more
performance,
testing
and
tuning
and
scale
testing
that
needs
to
happen
on
firefly
in
general,
but
the
so
there's,
there's,
there's
batching
that
happens
within
firefly.
B
C
Yeah,
as
nico
mentioned,
you
know,
we've
we've
seen
bottlenecks
happening
from
past
experience
with
live
deployments
and
they
tend
to
be
all
the
distributed
components
in
the
mix
and
that
being
the
blockchain
itself
and
ipfs.
Both
are
you
know,
peer-to-peer
decentralized
technologies
and
compared
to
centralized
technologies.
You
know
stateless
server
or
even
the
database,
those
tend
to
be
slower
than
the
others
and
for
both
components.
A
B
B
If
you
just
run
ff
or
ff
help,
it
will
tell
you
all
the
different
things
you
can
do
with
it.
So,
first
of
all
I
can
see
all
I
do
a
lot
of
development
with
fireflies,
so
I
have
a
lot
of
different
stacks.
You
can
run.
You
can
have
many
stacks
on
your
machine,
so
this
is.
I
have
like
all
kinds
of
different
things
in
different
configurations.
B
You
can
only
run
one
of
them
at
a
time,
though
it's
just
worth
noting
because
of
port
collisions
right
now.
We've
had
thoughts
about
running
multiple
it'll,
be
a
lot
to
run
on
your
machine,
but
right
now
you
can
run
one
at
a
time
and
if
you
want
to
see
what's
running
on
one
of
them,
so
we
were
running
the
dev
stack
earlier,
so
I
can
run
ff
info
on
the
dev
stack.
So
go
read
the
stack
info
and
then
it
will
tell
me
all
about
the
stack.
B
So
this
first
thing
this
first
table
that
gets
printed
out
here
is
all
of
the
containers
and
you
can
see
the
image,
the
docker
image
name
that
it's
using
and
the
the
tag
and
the
image
id.
So
if
you
need
to
go
check,
okay,
which
version
of
this
thing
am
I
actually
running,
especially
as
we're
doing
development
on
it?
B
A
One
more
question:
for
you
know
the
purpose
of
like
governance:
do
we
need
some
governance
for
this
for
five?
You
know
if
you
use
fireflies,
there's
some
additional
need
for
governance.
Like
you
know,
consortium
we
need
to,
you
know,
have
a
governance
that
okay,
you
know.
How
do
we
allow
what
what
is
needed
to
be
allowed?
You
know
how
to
onboard
a
new.
You
know
organization,
so
it
doesn't
mean
anything
else.
You
know
firefly
ads
on
top.
B
C
C
In
fact,
the
the
previous
generation
had
a
decentralized
implementation
of
that
registry,
which
is
based
on
blockchain
itself,
so
based
on
the
community
needs
we
can
bring
it
back
into
the
into
new
generation
and
fabric,
for
example,
has
great
support
for
decentralized
governance
for
membership
management
us
as
does
quorum
and
besu
so
yeah.
I
guess
the
short
answer
is
it's.
It's
it's
pluggable
and
it's
can
both
be
centralized,
simple
or
decentralized,
democratic.
B
So
if
you're
interested
in
firefly-
and
you
want
to
get
involved
kind
of
you
know
next
steps
that
I
would
encourage
you
to
take
are
we're
on
rocketchat
and
you
can
join
our
rocketchat
through
the
through
the
hyperledger
rocketchat.
I
will
drop
the
link
to
that
here
in
chat,
so
you
can
join
that
channel
if
you're
interested
and
then
also
we
have
a
weekly
community
call
as
well,
and
the
weekly
community
call
is
it's
a
little
smaller
audience
than
some
of
these
meetups?
Usually
it's
a
chance
to
talk
about
firefly
discuss.
B
You
know
upcoming
either
existing
architectural
things
or
you
know,
upcoming
changes
that
folks
may
be
interested
in
adding
or
changing
in
firefly,
and
also
just
to
to
discuss
things
about
it.
So
you
can
I'll
post
here.
A
link
to
this
is
where
our
that's,
our
wiki
page
there
and
you
can
see
all
of
our
community
calls
on
there
as
well,
and
let
me
get
the
link
to
the
chat
channel
here
as
well.
C
B
B
Definitely
join
our
our
chat
there,
we're
I'm
very
active
on
there
and
a
lot
of
the
other
maintainers
are
as
well
that's
a
great
place
to
ask
questions
or
you
know
if
you're
trying
it
and
something
isn't
working
right,
it's
a
great
place
to
get
help
or
or
even
report
bugs
as
well,
and
we
would
love
to
continue
seeing
folks
and
we
would
love
for
folks
to
get
involved.
So,
thank
you
very
much
and
I
hope
you
all
have
a
great
rest
of
your
day.