►
From YouTube: Myel in 2022 - Alex Camuto
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
A
Am
Alexander
Dante,
Camuto
known
to
samba's,
Alex
or
Dante,
depending
on
the
context
and
I
am
the
former
CEO
of
the
entity,
formerly
known
as
Mile
and
I'm
now
part
of
the
retrieval
markets
lab
led
by
Patrick.
A
So
this
is
more
of
a
retrospective
talk
on
of
what
we
were
doing
over
the
past
year
prior
to
joining
protocol
Labs.
So
I
assume,
all
of
you
are
fairly
familiar
with
what
a
dcdn
and
what
a
retrieval
Market
is
at
this
point,
so
I'm
gonna,
Dive,
Right
In.
A
So
some
of
the
constraints
we
imposed
when
we
were
designing
mile,
maybe
somewhat
foolishly,
were
first
to
be
unopinionated
about
the
kind
of
peer
that
could
join
the
network,
which
means
we
would
make
no
claim
as
to
or
enforce
no
constraints
as
to
the
capabilities
of
peers
that
would
join
the
network.
The
second
constraint
was
that
we
needed
to
enable
peer-to-peer
to
peer
connections,
so
browsers
would
need
to
be
able
to
connect
directly
to
caches
without
relying
on
HTTP
gateways.
A
So
those
first
two
constraints,
you
know,
there's
a
whole
host
of
literature
on
how
to
deal
with
that.
You
know
coming
from
the
torrenting
world,
but
the
third
constraint
was
to
be
interoperable
with
some
of
the
foremost
storage
networks,
decentralized
storage
networks,
specifically
that
existed
a
and
that
imposes
a
whole
host
of
other
constraints,
particularly
in
terms
of
what
kinds
of
data
transfer
protocols
you
can
use
or
how
you
can
represent
your
data.
A
So
yeah,
a
core
piece
of
the
network
was
what
we
called
a
pop,
just
a
point
of
presence,
which
is
classic
content,
delivery,
Network
terminology
and
these
CDN
building
blocks
basically
were
capable
or
are
still
capable
of
four
things.
So
the
first
is
that
they
are
able
to
dispatch
content
to
other
caches.
So
let's
say
a
node
is
completely
overwhelmed
and
is
getting
lots
of
requests.
They
can
dispatch
content
to
neighboring
nodes
to
help
lessen
the
request
load
that
they're
getting.
A
The
second
is
that
a
node
should
be
capable
of
discovering
which
nodes
have
which
content.
This
is
the
Discovery
module
within
the
node.
The
third
is
that
they
should
be
able
to
deliver
content
to
requesting
peers,
and
the
fourth
is
that
they
are
able
to
both
accept
and
issue
payments
for
Content
that
they
receive.
A
So
when
we
started
the
year,
our
Network
architecture
was
as
follows.
So
somewhat
betraying
our
you
know:
decentralized
ethos.
We
had
content
indexing
and
routing
hosted
on
cloudflare,
so
we
had
a
key
Value
Store
sort
of
indexing
which
nodes
held,
which
piece
of
content
and
a
client
that
wanted
to
find
that
piece
of
content
would
then
query
that
cloudflare
key
value
stored
to
to
then
fetch
the
content
in
many
decentralized
or
peer-to-peer
networks.
A
You
need
bootstrap
nodes
which
enable
you
to
connect
to
other
nodes
in
the
network,
so
these
were
provided
by
pop
nodes
with
public
IPS
content
delivery
also
supplied
by
pop
nodes.
But
we
also
wanted
the
ability
for
browsers
to
be
able
to
fetch
content
directly.
You
know
from
nodes
on
the
network,
and
that
was
the
JS
implementation
of
our
pop
node
and
I'll
run
through
all
of
this.
In
a
bit
more
detail
and
the
M
browser
content,
as
I
said,
you
know
we're
trying
we're
aspiring
to
have
no
gateways.
A
Oh,
that
showed
up.
I
was
not
expecting
that
yeah,
so
there
were
four
there's
four
core
modules
to
a
go:
pop
node,
the
first
and
they're
all
kind
of
leveraging,
the
protocol
labs
and
filecoin
stack
and
various
capabilities.
So
at
the
networking
layer
you
know
we're
leveraging
libidoopy
and
a
DHT
for
PR
Discovery.
Our
data
is
represented
using
ipld
and
Unix
FS
for
storing
that
data.
We're
using
you
know
the
data
store
implementation
with
badger
in
the
back
end
and
for
data
exchange
we're
using
the
graphing
protocol.
A
The
reason
we
chose
this
is
that
we
wanted
to
be
able
to
Cache
Miss
eventually
to
storage
providers,
which
is
something
that
we
haven't
done
yet
and
then
for
payments,
which
is
also
tightly
coupled
with
the
data
exchange
protocol.
We
used
file
coin
payment
channels
and
what
I
mean
by
tightly
coupled
with
the
data
exchange
protocol
is
that
you
needed
to
be
able
to
incrementally
verify
data
that
you
were
receiving
and
then
in
turn
issue
my
group
payments
for
each
little
piece
of
data
that
you
had
verified.
A
So
the
person
that
had
provided
you
with
the
data
and
as
promised
the
in-browser
client,
is
just
a
stripped-down
version
of
the
previous
note.
We've
got
Lippy
DP
we've
got
an
ipld
data
representation
and
the
same
data
exchange
protocol,
but
it
can
run
in
a
service
worker
or
a
cloudflare
worker.
A
The
problem
when
we
were
designing
this
is
that
graphsync
did
not
exist
for
or
there
was
no
reference
implementation
for
graphsync
and
JavaScript.
So
we
had
to
go.
Do
that?
Please
go
check
it
out,
use
it.
If
you,
if
you
really
want
to,
we
only
got
six
stars.
We
should
be
getting
more
all
right.
Moving
on,
there's
a
whole
host
of
problems
with
this
setup,
so
we've
got
go
nodes
and
we've
got
clients
in
JS.
A
There's
some
issues
with
performance
when
using
JS
libdp,
one
of
which
is
that
because
browsers
need
to
use
TLS
to
connect
to
nodes
you're,
both
encrypting
with
TLS
Plus,
what's
called
noise
encryption,
which
is
another
encryption
protocol
used
in
the
P2P,
and
that
slows
everything
down
a
lot.
So
even
when
fetching
content
locally,
so
we
had
one
JS
node
and
one
go
node
and
one
fetching
content
and
that
setup
we
were
maxing
out
at
30
megabytes
per
second.
A
So,
even
if
you
wanted
to
fetch
content
from
a
really
really
really
good
peer
on
the
network,
you
couldn't
do
so
because
the
implementation
or
your
networking,
layer,
Plus
or
implementation
of
graph
sync,
would
just
not
enable
you
to
do
that.
The
other
problem
is
that
our
development
efforts
were
being
split
across
two
repos
and
two
languages,
which
is
not
so
great,
and
we
were
also
imposing
a
client
server
architecture.
So
the
browsers
couldn't
serve
data
to
other
peers
and
we
were
introducing
lots
of
asymmetry
into
the
network.
A
I
won't
go
into
race
conditions
and
go
so
what
are
potential
solutions
to
this
problem?
So,
like
lots
of
people
in
2022,
we
were
flirting
with
rust
and
it
turns
out.
We
really
really
liked
it.
So.
A
Facing
similar
issues
to
JS,
you
know
there
was
no
reference
implementation
for
graph
sync
and
rust,
and
you
know
we
really
really
love
graphing,
so
we
have
another
implementation
of
graph
sync
and
rest.
Please
also
try
this
one
out.
It
has
a
similar
number
of
stars
all
right,
so
the
performance
in
Rust
is
actually
already
improving
on
some
of
the
performance
we
had
previously.
So
the
rust
transfer
speeds.
A
You
know,
testing
locally,
we're
maxing
out
at
400
megabytes
per
second,
so
this
is
just
doing
transfers
between
two
rust
pop
nodes
and
in
wasm,
which
could
potentially
be
used
in
a
browser
we
had
doubled
on
the
performance
in
JavaScript,
which
is
pretty
cool.
It's
not
it's
not
amazing,
but
it's
already
better
than
what
we
had
previously
and
it's
all
done
with
a
single
repo
yeah.
A
Some
other
work
that
we
did
in
Rust
as
part
of
the
implementation
of
the
point
and
presence
in
Rust
is
I,
guess,
sort
of
inspired
by
the
falcoin
indexer
and
aiming
to
replace
that
cloudflare.
Our
key
value
store
that
I
introduced
at
the
beginning.
We
wanted
to
roll
out
sort
of
a
decentralized
indexing
system,
sort
of
inspired
by
how
falcoin
indexers
currently
work.
You
store
an
index
as,
what's
called
a
hampt
or
a
hashed
array
map.
A
The
problem,
okay,
so
we've
sort
of
addressed
some
of
the
local
performance
issues,
which
means
that
if
we
connect
to
a
good
peer
with
good
Uplink-
and
we
have
good
down
link,
maybe
we
can
get
a
file
fast.
But
that's
not
always
the
case
and
we
kind
of
need
to
accommodate
for
uneven
performance
of
peers
on
the
network.
And
this
is
you
know,
a
problem
that
torrenting
networks
faced
and
the
way
they
typically
solved,
It
Is
by
enabling
multi-pier
data
exchange
protocols.
A
A
If
you
have
questions
about
that,
we
can
talk
about
it
later
and
yeah.
Unfortunately,
you
know
Juan
and
his
opening
talk
said
not
to
do
compute
and
retrieval
at
the
same
time,
but
we've
done
both
and
we've
been
running
experiments
in
in
conjunction
with
the
electric
Coin
Company
responsible
for
zcash
and
some
friends
out
of
Penn
State
University,
who
are
professors
there
and
trustless
and
decentralized
compute.
So
what
have
we
built?
A
So
we've
built
this
command
line
tool
called
easy
KL,
which
enables
you
to
turn
any
kind
of
like
Pi,
torch
or
tensorflow
graphs
into
ZK
circuits.
You
can
then
run
proofs
on
those
graphs.
You
can
I'll
get
into
more
detail
about
that
in
a
bit,
but
you
can
submit
those
proofs
on
chain.
You
know
execute
some
logic
in
a
smart
contract
as
a
result
of
verifying
that
proof.
A
All
sorts
of
cool
stuff
so
in
the
back
end
we're
using
Halo
2,
which
is
actually
a
joint
venture
between
electric
Coin,
Company
and
protocol
Labs,
so
also
wrapping
the
protocol
lab
stack
here,
a
big
problem
with
ZK
circuits
and
a
big
challenge
when
you're
shoving
data
through
them
is
that
they
only
operate
on
fields
of
integers.
So
if
you
have
a
bunch
of
floating
Point
stuff,
you
have
to
quantize
it.
You
have
to
do
all
sorts
of
complicated
stuff
in
terms
of
customizing
circuit
Gates.
This
command
line
tool
handles
it
all
for
you.
A
A
We
support
that,
if
you
like
non-linearities,
like
value
and
sigmoid,
we
support
that
if
you
like
neural
network
layers
like
convolutional
networks
and
dense
layers,
we
also
support
that
and
you
can
turn
all
of
that
into
a
zero
knowledge
circuit,
and
you
can
basically,
if
you
save
this
as
in
what's
called
an
onyx
file
which
is
just
sort
of
like
Universal
representation
of
what
neural
networks
or
computational
graphs.
Look
like
it's
compatible
with
a
whole
host
of
languages.
A
Like
you
know,
there's
rust,
tensorflow
supports
loading,
these
sorts
of
things
python
whatever,
and
you
can
use
this
basically
to
to
prove
claims
like
let's
say
you
have
a
private
model
and
there's
a
bunch
of
public
data.
You
can
say:
I
ran
my
model
on
this
public
data
and
I
achieved
X
percent
accuracy.
Or
let's
say
you
have
private
data,
but
a
public
model.
You
can
say:
I
ran
this
public
model
on
my
private
data
and
I
produced
this
output,
or
you
can
just
prove
that
you
ran.
A
You
know
a
computation
correctly,
so
it's
kind
of
got
interesting
applications
for
trustless
and
distributed
compute
when
you're
dispatching
compute
jobs
to
lots
of
different
nodes,
and
this
is
just
how
simple
the
command
line
is.
A
Performance,
you
know
we
were
able
to
put
a
three
layer:
convolutional
Network,
that's
a
pretty
big
model,
actually
with
private
data
input
and
assuming
private
model
parameters
and
we're
able
to
generate
a
proof
in
400
seconds
flat
and
only
using
35
gigabytes
of
RAM.
A
So
that
seems
really
really
bad,
but
we
haven't
used
some
of
the
sort
of
like
proverbial
hammers
in
our
Arsenal
that
Halo
2
provides
like
recursion
and
look
up
table
Fusion,
so
hopefully,
next
time,
I'm
talking
these
numbers
are
much
much
better.
Thanks.
B
Thanks
a
lot
for
that
talk,
it's
really
entertaining
I.
Had
some
questions
about
the
performance
numbers
you
quoted
with
your
various
graph.
Sync
implements
oh
yeah,
so
does
that
depend
on
the
like
piece
size
when
you're
splitting
the
file
delivery
up,
yeah.
A
B
A
C
A
I
mean
that's
one
of
the
reasons
we
were
leveraging
cloudflare
to
begin
with,
just
because
that
reduced
the
time
to
First
Bite
significantly,
if
you're
going
for
like
a
completely
sort
of
decentralized,
pure
Discovery
you're
using
things
like
gossip
or
ADHD
for
querying,
which
peers
are
where
and
have
what
and
that
gets
yeah,
it's
just
not
scalable
so
I
mean
the
next
best
thing
is
basically
replacing
cloudflare
with
like
the
indexers
that
I
mentioned,
where
people
are
response,
replace
cloudflare,
are
running
nodes
and
are
responsible
for
determining
who
has
what
and
in
that
sort
of
system,
and
this
is
something
that
old
networks
like
Nutella
and
some
other
torrenting
networks.
A
Did
it's
a
it's
a
great
effect.
D
A
In
that
space,
yeah
yeah
I
mean
a
key
role
of
I
mean
a
key
function
of
certain
cdns
is
to
be
able
to
execute
certain
functions
and
transform
data
as
close
as
possible
to
the
end
user.
So
using
something
like
this,
where
you
know
you
don't
have
to
trust
that
the
operator
is
running,
your
computation
correctly
is
actually
kind
of
cool,
obviously
they're
scalability
issues
with
ZK
snarks,
so
operations
that
would
run
you
know
very
quickly
in
a
in
a
fully
trusted
setting
it
don't
anymore,
but
yeah.