►
Description
Every other week, the Retrieval Market Builders get together to share progress in their projects in a demo format. We want to sincerely thank all of our collaborators for demoing their developments and helping to improve the FIL Retrieval Markets one demo at a time.
February 2, 2022, Demo Day: In this video, you can find quick demos from -
• Magmo
• KEN Labs
__________________________________________________________________________________________
If you would like more information about the Demo Days please follow the link below to the Demo Days planning document.
https://docs.google.com/document/d/1IrNbBm2_P79Xi2fXFj9YUfQ0PjWjreGdPYFjFntD1QM/edit#heading=h.akao8aspby4
A
A
B
Okay,
so
yeah,
I'm
colin
kennedy,
I'm
at
colin
kennedy
in
the
file
coin
slack
so
feel
free
to
reach
out.
If
you
have
anything
to
say
or
ask,
I'm
part
of
the
magmo
team
over
at
megmo.com,
we
have
a
dev
grant
from
the
filecoin
foundation
to
do
an
upgrade
on
or
to
spec
out
some
upgrade
work
on
file
coins,
payment
channels
and
the
work
that
we're
doing
can
be
found
at
github.com
state
channels.
Slash,
go
nitro,
so
for
the
next
little
bit,
I'm
gonna
talk
about
how
payment
channels
currently
work
in
filecoin.
B
Introduce
virtual
channels
then
go
into
a
little
more
detail
about
opening
running
and
closing
the
virtual
channel
talk
a
little
bit
about
virtual
channel
networks
and
then
wrap
it
all
up,
try
and
say
what
it
what
it
might
mean
for
the
filecoin
retrieval
market
and
for
for
users
and
for
developers
and
then
just
share
a
few
links
andrew
another
member
of
the
magma
team
is
in
the
chat.
So
if
you
have
any
questions
feel
free
to
throw
them
in
there,
and
he
knows
all
of
this
stuff
better
than
me.
B
B
So
to
solve
this,
the
sort
of
original
payment
channels
notion
is
that
you
lock
a
bunch
of
funds
on
chain
and
exchange
a
streaming
service
for
cryptographic,
guarantees
of
incrementally
redeemable
funds.
The
service
provider
gets
guarantees
that
they
can
apply
to
the
chain
that
they
can
recoup
funds
for
services
rendered,
and
this
works
pretty
well.
B
So
an
improvement
on
direct
payment
channels
is
virtual
channels,
and
the
basic
premise
here
is
to
move
up
a
level
of
abstraction
in
a
payment
channel.
The
channels
are
funded
by
on-chain
lock-ups
of
capital,
but
in
a
virtual
channel
the
the
funding
comes
from
lockups
inside
of
other
state
channels,
and
the
promise
of
a
virtual
channel
payment
channel
is
lower
latency
because
your
your
funding
agreements
are
handled
by
in-channel
operations
which
are
which
operate
at
network
speed,
as
opposed
to
a
blockchain
transaction
and
lower
costs.
B
So
in
the
file
coin,
payment
channels,
what
you
have
is
basically
sort
of
the
naive
payment
channel
where
vouchers
are
exchanged
for
well
vouchers,
are
signed
by
one
party
and
sent
to
the
other
party
and
there's
not
a
lot
of
room
for
sort
of
a
state
channel
is
is
different
in
software
and
state.
It
allows
for
arbitrary
application
state
which
allows
for
us
to
program
something
called
a
ledger
channel,
which
is
a
specialized
kind
of
channel
meant
for
providing
funding
toward
other
channels.
B
So
I'll
talk
yeah,
let's
talk
through
the
sort
of
life
cycle
of
a
virtual
channel
how
to
make
one
from
from
another
channel,
so
any
channel
before
being
useful
to
its
participants
has
to
be
funded.
So
in
this
diagram
the
outer
circle
is
represents
the
underlying
blockchain
and
the
little
dots
represent
channels,
and
here
we
have
a
channel
between
alice
and
adam
reed
and
a
channel
between
bob
and
irene.
B
B
B
They're
then
able
to
virtually
fund
this
channel
by
by
applying
specific
updates
to
each
of
their
respective
ledger
channels.
So
the
alice
irene
ledger
channel
is
updated.
With
a
specific
data
structure,
we
call
a
guarantee
which
points
to
this
new
channel
and
likewise
for
the
irene
bob
channel
and
now
this
channel,
which
still
only
exists
kind
of
in
the
client
machines
of
irene,
alice
again.
C
B
But
I
think
that
includes
like
the
lightning
network,
those
payments
involved,
the
intermediaries
on
on
every
payment.
So
after
this
virtual
channel
is
created,
alice
and
bob
can
update
that
channel
with
with
alice's
payments
to
bob's,
as
often
as
they
want,
and
it
doesn't
involve
by
read.
This
doesn't
make
a
huge
difference
for
alice
and
bob,
but
for
irene,
who
wants
to
act
as
a
hub
in
a
in
a
network.
B
B
B
When
alice
and
bob
are
done
in
in
the
file
coin
case,
you
know,
alice
has
received
her
file
to
completion.
Bob
has
received
all
of
his
payment.
Then
they
defund
the
channel
by
taking
their
signed
final
state
of
the
channel
back
to
their
electric
channels
with
irene
and
irene.
They
collaborate
with
irene
to
update
that
channel
and
everything
is
sort
of
rebalanced.
B
So
here
we
have
alice,
has
sent
a
coin
to
bob
and
in
the
interaction
of
of
this
channel
and
as
that
settles
the
alice
irene
channel
irene
gains.
One
alice
loses
one,
so
that
represents
alice's
payment
of
one
to
bob.
Her
her
later
channel
balance
is,
is
deducted
by
one
bob's
lighter
challenge,
channel
balance
increases
by
one.
In
practice.
B
B
B
Hubs
are
here
in
the
middle,
and
this
here,
big
circle
represents
the
chain,
so
what's
happening
here,
is
that
these
lines
from
left
to
right
are
different,
virtual
channels
being
spun
up.
It's
probably
not
easy
to
see
on
on
the
shared
video,
but
all
of
these
the
faint
lines
here
between
each
client
and
a
hub
represents
a
ledger
channel.
B
B
So
any
given
client
is
connected
to
a
certain
hub,
but
that
hub
might
not
be
connected
to
the
provider
who's
whose
file
you
want.
These
hubs,
though,
all
have
larger
channels
with
each
other
and
they
are
able
to
through.
Through
this
connection
of
ledger
channels,
you
can
open
up
a
virtual
channel
with
a
very
similar
kind
of
network
overhead
and
the
same
sort
of
desirable
properties
of
like
low
latency
to
open
a
virtual
channel
and
low
cost,
because
again
it's
just
updates
to
channels
which
are
done
over
the
network
using
client-side
cryptography.
B
So
this
is
a
rundown
of
our
approach
to
improving
the
the
payment
channels
that
exist
in
file
coin.
Talks
about
typical
user
flow,
so
making
an
initial
an
initial
deposit
to
open
a
ledger
channel
with
some
hub,
but
then,
after
that,
you
create
virtual
channels
in
collaboration
with
your
hub,
your
provider
and
potentially
your
provider's
hub.
It's
a
multi-hop
virtual
channel.
B
B
C
B
B
The
virtual
channels,
in
terms
of
this,
like
the
straight
retrieval,
would
very
much
mimic
the
existing
voucher
channels,
a
client
signs
vouchers
of
increasing
value
in
exchange
for
receiving
data,
but
because
these
are
generalized
state
channels,
you
can
make
a
stateful
application
with
whatever,
whatever
rules
you
might
like,
which
is
potentially
useful
to
anyone
building
on
the
secondary
retrieval
markets
and
yeah.
These
should
theoretically-
and
it's
a
little
out
of
turn
for
me
to
say
this,
because
it
it
depends
longer
term
on
kind
of
the
implementation
of
the
fbm.
B
So,
as
I
said,
there's
the
notion
doc
and
the
link
is
in
slack.
Our
blog
has
a
lot
of
pretty
in-depth
articles
on
state
channels
and
feel
free
to
reach
out
to
us
at
the
team,
either
in
the
retrieval
market
channel
or
via
email
or
website,
and
that's
it.
If
there
are
any
questions,
we
can
take
them
async
in
the
chat
or
or
afterwards,
but
otherwise
that's.
That
is
my
presentation.
B
Yeah,
so
I
think
this
is
I'm
going
to
cop
out,
to
my
my
earlier
caveat
of
not
being
an
expert
of
the
file
point
system
or
ecosystem,
but
for
any
like
filecoin
user
anybody
who's
like
storing
a
file
and
retrieving
it.
They
won't
notice
like
they
don't
care
about
the
existence
of
the
bespoke
virtual
payment
channels.
E
Yeah,
I
mean,
I
think
I
think
one
of
the
natural
questions
for
somebody
is
there's.
You
know
a
payment
system,
that's
in
fall
coin
and
what'll
be
the
delta
in
using
that
you
know
version
to
this
version,
and
it
is
interesting
that
the
intermediaries,
I
think
your
diagram
was
very
helpful
to
kind
of
show.
There's
this
collection
of
intermediaries
in
the
middle
between
you
know
the
retrieval
clients
and
the
retrieval
secondary
market
servers,
and
so
there'll,
be
a
larger
sort
of
you
know
who's.
E
Actually,
you
know
running
those
hub,
those
kind
of
hub
intermediary
functions
and
kind
of
discovery
process
of
having
well-known
ability
to
to
find
people
to
facilitate
the
payments
that
are
that
are
right
for
you.
If
you're
you
know,
sitting
in
australia,
you're
not
gonna
want
your.
You
know
intermediary
potentially
to
be
located.
You
know,
physically,
you
know
in
in
the
uk,
because
that's
just
too
big
of
a
time
difference.
You'd
rather
have
somebody
closer
us
hardware
running
closer
to
you.
D
I
can
maybe
make
one
comment
about.
You
know
why
the
notion
of
a
generalized
state
channel
can
be
very
useful,
that's
relevant
to
the
filecoin
retrieval
market
there's.
I
know
that.
There's
ongoing
research
about,
for
instance,
how
do
you
incentive
a
retrieval
provider
to
provide
the
right
data
at
the
right
time?
We
can
imagine
a
world
where
some
retrieval
providers
have
a
good
reputation
and
they
are
going
to
offer
a
good
sla
to
uphold
that
reputation.
D
That's
something
that
the
current
file
of
coin
payment
channels
can
do.
If
you
had
a
direct
channel,
they
can
do
it
pretty.
Well,
if
you
didn't
have
a
channel
already
with
that
provider,
you
either
need
to
create
one
that
uses
those
on-chain
transactions
or
you
can
use
this
notion
of
the
hashtag
construct
contract
and
that
creates
a
lot
of
network
overhead
involved
in
sending
a
stream
of
payments.
We
consider
that
to
be
not
viable
at
a
production
scale.
D
Nevertheless,
the
current
file,
one
payment
channels,
can
work.
If
you
did
have
this
direct
channel
open
with
your
your
provider.
What
the
current
filecoin
payment
channels
cannot
do
is,
as
an
example,
set
up
a
payment
scheme
where
my
payment
to
this
new
provider
is
conditional
and
the
provider
actually
sending
the
correct
bytes
that
I
can
verify,
for
instance,
by
checking
against
some
encoding
of
the
file
in
some
merkle
tree.
D
Moving
forwards
right
now,
we're
focused
on
getting
very
simple
payments:
working
multiple
hops,
using
those
intermediaries,
but
removing
the
intermediary
from
the
stream
of
payments.
That's
what
we're
focused
on
today,
but
in
the
future.
We
also
want
to
explore
these
other
ways
of
incentivizing
new
providers
to
behave
nicely
until
they
develop
the
type
of
reputation
that
allows
us
to
drop
those
requirements.
E
There
are
even
farther
out
models
that
I
know
patrick
you
mentioned,
sometimes
so
I'll
just.
I
think
it's
useful
just
to
put
on
the
recording
if
somebody's
gone
through
and
listen
to
virtual
channels
to
hear
that
they're
flexible
in
other
ways
too,
since
it's
off
channel,
what's
being
recorded
and
passed
around
in
the
tokens,
can
have
different
meanings
like
it's
also
possible
that
you
could
have
a
network
where
someone
is
paying
for
the
transfers.
Maybe
a
user
has
a
monthly
subscription
to
a
cdn
network,
or
maybe
users
come
in
publicly
and
someone
pays.
E
The
network
could
potentially
look
at
your
tokens
and
you
could
have
a
balance
that
if
you've
exceeded
it,
the
secondary
network
providers
say
oh
you've
hit
your
cap
for
the
month
or
what
have
you
so
there's
there's
a
whole
bunch
of
really
interesting
economic
models
and
they're,
just,
I
would
say,
maximal
flexibility
with
state
channels.
That's
the
really
valuable
part
while
you're
getting
this
full
scaling
benefit.
A
Yeah,
definitely,
I
think
it's
super
exciting.
The
work
there's
that's
going
on.
It
keeps
coming
up
in
more
and
more
conversations
around
the
retrieval
marcus
ecosystem
about
where
it
could
be
applied
in
its
kind
of
most
obvious
context
and
then,
as
you
say,
in
sort
of
more
yeah,
innovative
or
thoughtful
ways,
and
we
just
got
to
lay
out
how
it's
going
to
integrate
with
the
existing
farcoin
stuff
and
just
yeah
make
that
happen
over
the
next
next
few
months.
C
C
So
we
name
it
as
ipf's
computing
quickly
go
through
the
agenda,
so
actually
two
topics
introduction
and
the
demo
a
quick
introduction
to
this.
What
we
call
the
mesh
ipfs
computing
mesh.
There
are
several
components
in
the
network.
The
idea
is
that
we
want
to
have
the
code
deployed
to
a
network
so
that
can
be
executed
on
the
in
a
decentralized
manner.
C
C
C
So,
as
I
click
the
execute
button
here,
so
the
the
code
is
uploaded
and
it
will
be
compiled
by
the
by
our
component
and
uploaded
to
the
ipfs
network.
So
the
code
were
eventually
identified
or
addressed
by
a
cid
and
the
parameter
is
also
passed
to
the
server
side.
We
call
the
scheduler,
we
will
look
for
the
executor,
get
it
executed
and
the
result
will
also
be
put
on
the
network
so
that
we,
the
client,
is
able
to
subscribe
to
you
to
the
result.
C
As
you
can
see
here,
this
is
the
the
the
logic
or
the
data
flow.
Eventually
we
receive
the
result.
So
as
a
fibonacci
numbers,
the
series,
the
third
one-
is
one
one
two,
so
that's
a
two.
We
can
also
slightly
change
the
code.
Maybe
that's
yeah.
This
is
just
for
demonstration
purpose.
So
I
I
make
some
some
really
simple
change
to
to
the
code.
C
C
C
C
So
it's
somehow
like
that,
it's
cached,
so
you
can
quickly
find
this
result,
so
you
can
avoid
the
further
execution,
but
in
terms
of
the
state
we
may
need
to
find
some
way
to
to
manage
state
on
the
network,
but
it's
just
something
we
can.
We
can
do
to
make
it
more
powerful,
so
this
is
to
the
idea
is
to
bring
the
computation
power
to
the
ipv6
network.
C
B
C
A
C
A
Nice,
yes,
well,
it
seems
to
be
some
questions
generated
about
yeah
the
decentralized
model
of
this,
but
it's
really
interesting
to
dive
into
the
ipfs
fan
stuff,
because
I'd
only
seen
it
in
its
paper
form
so
great
to
see
some
some
stuff
around
that
and
also
a
happy
chinese
new
year.
Thank
you
very
much
anything
else.
Anyone
wants
to
add
before
we
finish
this
presentation.