►
From YouTube: This Month in IPFS - March 2023
Description
Join Daniel, Developer Advocate and guests from the IPFS ecosystem for This Month in IPFS, which will be streamed to YouTube and IPFS Twitter
For March, we will have the following guests:
Robin Berjon: Robin heads Governance & Standards at Protocol Labs. He's been making web things and trying to build a web worth wanting for a couple of decades. He's done a lot of work on open standards and privacy, and is passionate about turning the web into a space that is operated collectively and cooperatively.
Ryan Plauche: Ryan is a Texas-based engineer working with Little Bear Labs currently working on the IPFS in space project. This project aims to apply content-addressable data & tooling to satellite communications. His background includes shipping code for inventory scanners, in-car GPS units, and open source flight software, and an ever-growing love for pushing bytes with Rust.
Brendan O'Brien: Brendan is working on Iroh, a new implementation of IPFS and hosting the Move the Bytes Working Group.
The live stream will cover a wide range of topics related to IPFS, including live coding sessions, demos, guest interviews with IPFS contributors and developers, and updates on the latest developments in the IPFS community and working groups.
There will also be a Q&A session, so come with all your IPFS questions!
A
B
Welcome
good
evening
or
morning,
depending
on
where
you're
joining
us
and
welcome
to
this
month
in
ipfs
I'm,
your
host
Daniel
I'm,
a
developer
advocate
for
ipfs,
and
this
is
a
community
oriented,
live
stream
to
cover
all
of
the
progress
that
is
happening
in
the
ipfs
ecosystem.
It's
also
because
it's
a
live
stream.
It's
meant
to
be
interactive,
so
we
want
to
hear
from
you
if
you're
watching
this
on
YouTube,
we
can
see
the
comments
coming
in.
B
Let
us
know
where
you're
joining
us
from
what
you're
doing
with
ipfs.
We're
always
curious
to
hear
that
and
if
you're
watching
this
post
event
feel
free
to
drop
the
questions
in
the
comments
we
check
those
out
and
we
like
to
always
hear
from
you.
So
let's
get
to
today's
guest
because
that's
what
really
this
live
stream
is
all
about.
Today
we
have
really
special
guests
and
we
have
three
of
them.
B
We
have
Robin
Bergeron
who's,
heading
governance
and
standards
at
protocol
labs
and
he's
focused
on
ipfs
too,
and
finally,
we
have
Ryan
plausier
who's
working
on
the
idfs
in
space
project.
This
ipfs
spacing
project
we're
gonna
get
into
this
a
little
bit
later
once
Ryan
joins.
But
we
mentioned
this
in
a
previous
live
stream.
I
believe
it
was
the
January
of
the
February
one.
B
So
today
we're
going
to
get
a
chance
to
look
at
some
of
the
technical
nitty-gritty
details
and
talk
about
some
of
the
challenges
that
Ryan
is
facing
when
working
on
this
project.
So
with
that
I
want
to
get
into
our
first
case
guest
of
today,
that
is
Brandon
O'brien
and
I'll
give
Brendan
a
short
introduction.
So
Brendan,
as
I
mentioned,
he's,
been
building
and
contributing
to
ipfs
for
a
number
of
years
and
now
he's
working
at
number
zero
on
iro.
B
So
with
that,
let's
bring
Brendan,
hey
Brendan
good
to
have
you
here,
I,
don't
know
how
you
doing
nice
to
see
you
pretty
well
pretty!
Well,
I'm,
really
I've
been
yeah.
So
yesterday,
let
me
start
by
saying:
yesterday:
I
was
watching
the
video
you
I
put
up
on
Blake
three
Blake
3's.
This
some
people
may
be
familiar.
B
C
Good,
thank
you
Daniel!
It's
nice
to
be
here.
You
know
it's!
It's
a
YouTube
game,
recognized
YouTube
game.
It's
nice
to
see
you
putting
together
these
incredible
high
quality
productions
for
the
ipms
community
and
so
yeah
delighted
to
be
here
and
happy
to
chat
about
iro
and
everything
we're
doing
at
number.
Zero.
C
C
And
so
for
the
first
six
months
of
working
on
iro.
We
made
it
a
completely
stock
compatible
with
Kubo
compliant
implementation
and,
as
time
went
on,
we
sort
of
like
learned
a
lot
in
that
process
and
really
came
to
understand
where
we
did
and
didn't
think
that
our
goal
of
building
a
highly
high
performance,
ibfest
stack
in
a
highly
interoperable
ipf
stack,
maybe
I'm
coming
to
tension,
and
so
for
that
we
decided.
C
You
know
what
we're
members
of
the
ipfs
community
and
the
ipfs
standards
and
specifications
are
delivered
kind
of
Allah
card,
and
so
what
if
we
evolved,
iro
into
something
that
is
sort
of
maybe
an
ipfs
system
at
the
highest
order,
but
is
a
kind
of
reimagination
of
the
stack
from
certain
other
perspectives.
So
we
made
a
number
of
changes
to
try
and
take
iro
closer
to
this
sort
of
performance
and
we're
delighted
to
say.
After
a
couple
of
months,
we
have
we've
had
one
new
release
under
this
new
paradigm.
C
We're
doing
the
second
release
this
week
of
the
new
Arrow
and
we're
now
seeing
performance
numbers
that
we're
really
excited
about
we're.
Seeing
we've
built
something
called
an
experimental
Loop
so
that
we
can
actually
see
on
a
per
commit
basis
how
our
technology
is
performing
in
network
simulations
and
we're
just
really
excited
to
deliver
sort
of
a
new
cut
of
ipfs
and
expand
sort
of
the
big
tent
of
implementations
that
are
out
there.
B
And
it's
hard
to
not
mention
the
move,
the
bytes
working
group,
which
you
started
I
believe
at
ipfs
or
it
was
dig
your
colleague.
You
started
this
at
ipfs
camp
in
Lisbon.
It
was
part
of
a
talk
about
actually
how
bitswap
Works,
and
can
you
tell
us
a
little
bit
about
move
the
binds
working
group?
What
were
some
of
the
insights
that
came
out
of
that
and
how
that
influenced
your
work
on
iro
totally.
C
Yeah,
so
when
you
think
about
what
ipvs
does
at
its
core,
it's
really
it's
got
three
major
tricks
content
addressing
right,
so
it's
going
to
take
all
of
your
data
and
always
refer
to
it
by
hash.
It's
gonna
do
something
called
content,
routing
it's
going
to
figure
out
who
has
which
hashes
and
what
data,
and
then
it's
going
to
do.
Data
transfer
right
get
me
the
stuff
from
the
people
who
have
it
and
so
move.
The
bytes
working
group
is
really
focused
on
that
third
category.
C
The
data
transfer
side
of
things-
and
we
really
wanted
to
a
lot
of
that-
grew
out
of
writing
an
implementation
of
bit
Swap
and
we
needed
one
in
rest
because
there
wasn't
one
in
Rust
that
we
knew
over.
That
was
interoperable.
There
had
been
bit
swap
implementations
that
followed
the
spec,
but
didn't
sort
of
in
practice
communicate
meaningfully
with
Kubo,
which
kind
of
was
the
whole
Jam
and
So.
C
Based
on
that,
we
found
a
number
of
things
again
with
this
sort
of
like
heavy
lens
around
performance
that
got
us
sort
of
like
we're.
We
think
we
can
do
better
here
and
so
at
ipfest
camp
in
2022
we
convened
a
group,
as
you
mentioned,
dig
my
co-founder
came
hot
off
of
writing.
That
implementation
said
Hey.
What
if
we
took
a
cut
at
writing
a
new
data
transfer
protocol?
Let's
try
something
new.
We
just
realized
that,
like
again,
it's
a
community
effort.
C
It
would
it's
better
if
you
do
it
together,
and
so
we
try
to
sort
of
bring
more
folks
into
that,
and
so
we
formed
the
move,
the
bike's
working
group
as
a
sort
of
exploratory
hey,
who
wants
to
put
their
hand
up
and
work
on
this
side
of
things
and
what
was
really
fun
about
the
way
that
that
evolved
is
over
time.
We
just
started
meeting
every
two
weeks
and
a
lot
of
really
exciting
ideas
started
coming
out
of
the
woodwork
we
just
being
totally
blunt.
C
In
terms
of
moving
bytes
around
and
so
we're
pretty
proud
of
the
way
that
that
group
has
evolved
in
terms
of
disseminating
research
and
that's
really
what
its
focus
has
evolved
to
be
about
inside
of
iro,
we
have
a
new
data
transfer
protocol
and
we
present
our
work
pretty
routinely
to
the
group
as
well
as
others,
we've
heard
from
a
number
of
sort
of
data
transfer,
oriented
projects
and
ideas
that
I
think
the
now
now
we're
at
the
phases.
Community
is
like.
B
And
this
brings
us
to
this
new
direction
of
Ira.
What
are
some
of
the
it's?
It
looks
to
me
also
from
the
approach
that
you've
been
taking,
is
that
it's
not
only
or
purely
a
a
research-oriented
one
really
you're
trying
to
bring
this
into
like
real
world
applications?
What
are
some
of
the
use
cases
that
you
think
that
Ira
will
excel
at
and
what
are
some
of
the
new
opportunities
that
you
think
haven't
been
sort
of
seized
with
ipfs
as
a
protocol.
C
Yeah
I
think
sort
of
where,
where
our
will
excel
is,
if
you
need
web
2
perf
for
an
ipfs
like
system
where
it
won't
Excel
is,
if
you
need
interoperability
with
existing
ipfs
systems.
Those
two
things
are:
that's
not
where
it's
going
to
deliver
for
you,
but
there
are
a
number
of
groups
and
there
are
a
number
of
just
brand
new
spaces
that
we
haven't
taken.
Ipfs
to
that
we're
thinking
about
here.
I
iro
is
really
a
grow.
The
ibfs
pie
project,
it's
not
a
sort
of
like
change.
C
The
existing
ipfs
user
base
project
and
the
thing
that
we're
really
targeting
is
mobile
phones,
and
so
we
really
want
to
see.
We
think
there's
a
really
great
opportunity
in
developing
in
the
native
mobile
space
and
in
Native
mobile
application
developers
being
able
to
leverage
peer-to-peer
Technologies.
We
think
this
area
is
specifically
exciting
because
you
have
a
really
nice
set
of
apis
that
give
you
access
to
low-level
networking
protocols
that
you're,
often
locked
out
of
in
the
browser
context.
C
You
still
want
to
support
browsers
in
the
long
run,
but
like
that's,
not
really
our
core
Focus.
But
if
you
need
a
thing
that
is
ipfs
like
and
really
really
fast
and
works
inside
of
work
like
fast
by
web
2
standards
fast,
then
iro
is
going
to
be
a
great
fit
for
you.
If,
if
you
yeah
it'll
be
an
even
better
fit
for
you,
if
you
have
total
control
over
the
stack,
but
if
you
need
to
interoperate
with
Kubo
we
long
term,
there
will
be
an
answer
there
and
we've
had
some
really
exciting
conversations.
C
C
B
B
You've,
as
I
mentioned
you've
probably
you've
published
rudiger,
did
a
great
Deep
dive
into
some
of
the
details
of
of
Blake
three,
and
maybe
you
can
tell
us
a
little
bit
more
of
I,
have
sort
of
my
own
intuitions
based
on
watching
that
video.
But
why
do
you
think
that
Blake
3
is
such
a
natural
fit
for
ipfs.
C
Yeah
I
think
it's
it's
interesting.
It's
been
fun
to
watch
the
like
three
hashing
algorithms
sort
of
make
its
way
into
the
content
address
Zeitgeist.
Can
we
call
it
a
Zeitgeist,
Adam
sure,
because
it
what
Blake
3
does
internally
to
to
build
a
faster
hashing
algorithm?
Is
it
actually
builds
a
Merkle
tree
as
part
of
its
hashing,
Construction
And?
So
there's
just
this
natural
symmetry
between
chunking,
as
we
understand
it
in
ipfs
and
chunking,
as
it
happens,
inside
of
Blake
3
hashing
and
as
rudiger
goes
into
detail.
C
He
sort
of
explains
this
all
in
a
deep
dive,
but
basically
by
just
using
Blake
3,
you
get
a
lot
of
the
same
benefits
that
we
have
to
do
as
additional
layers
on
top
of
a
hashing
algorithm
in
the
current
ipfs
Paradigm
right
and
so
with
Play3.
We're
able
to
push
a
lot
of
that
just
down
into
the
hashing
function,
which
has
a
certain
degree
of
Elegance
to
it.
It
you
sacrifice
some
flexibility
right,
and
so,
if
you
think
about
like
a
in
Unix
FS
right
now,
we
have
different
chunking
strategies.
C
C
If
you
can
calculate
the
Blake
tree
hash
of
anything,
it
will
be
the
same
output
that
we
use
for
verified
streaming
for
chunking
strategies.
It
will
just
match,
and
so
now
we
get
this
wonderful
alignment
where
we
have
an
ipfs
system
that
can
use
whole
file
checksums,
and
so
we
see
this,
you
know
in
the
world
you
see
like
hey.
Here's
a
shot
to
256
check
some
of
a
file.
If
we
use
Blake
3
in
iro,
that
value
would
be
the
exact
same
as
the
incrementally
verified
chunk
thing
that
we
use
to
actually
do.
C
C
B
I
guess
is,
is
the
use
case
for
this,
like,
if
you
say,
doing,
video
streaming
and
you
want
to
do
obviously
verified,
because
that's
the
sort
of
the
key
idea
behind
ibfs
and
you
want
to
seek
to
sort
of
the
middle
point
of
the
video,
then
you
don't
have
to
actually
stream
all
of
this
extra
data.
You
can
just
stream
the
data
that
is
necessary
for
that
and
still
be
able
to
verify
it
without
sort
of
a
bigger
added
attacks.
B
A
C
A
way
to
frame
it
sort
of
so
what
you're
referring
to
is
being
able
to
select
or
transfer
byte
ranges
inside
of
a
total,
which
is
a
cool
benefit
that
comes
out
of
incremental
verification,
and
so
incremental
verification
means
that
you
don't
have
to
download
the
entire
file
to
know
that
you've
got
what
you
asked
for
right.
So,
if
you
imagine
just
a
whole
file,
checksum
I
have
to
download
every
single
byte
of
that
file.
C
C
I
made
you
download
a
gig
of
data
and
it's
wrong
right
and
that's
that's
where
we
use
the
phrase
incremental
verification
is,
can
I
know,
hey
I've
only
downloaded
a
kilobyte
of
data
and
I
know
that
you've
sent
me
a
byte.
That's
incorrect
right,
and
the
upside
of
that
is.
This
is
a
really
necessary
precursor
for
peer-to-peer
systems,
because
you
want
to
deal
with
the
sort
of
adversarial
side
of
things
from
that
you
get
this
really
nice.
You
usually
get
this
nice
property.
C
Where
you
can
say,
hey
just
give
me
a
subsection
of
that,
and
we
can
verify
that
subsection,
because
if
you
can
verify
just
a
piece
of
the
file
well,
then,
if
we'd
make
that
piece
that
you're
asking
for
some
middle
section
of
the
file,
then
you
get
this
thing
called
bite
offset,
seeking
and
so
they're
kind
of
closely
related.
But
the
Primitive
that
you
really
need
is
the
capacity
to
only
get
a
chunk
of
something
and
know
that
the
chunk
you
got
is
what
you
asked
for.
B
And
this
is
also
the
same
reason
why
in
ipfs
as
it
is
now
in
sort
of
Kubo
and
and
JS
ipfs,
and
so
on,
we
chunked
these.
Whenever
you
take
a
file,
you
represent
it.
As
you
know,
a
dag,
essentially,
then
you're
chunking
it
into
small
chunks
that
you
can
sort
of
move
around
and
verify
them
as
self
sort
of
certifying
units.
C
Yeah
we
call
those
chunks
blocks
in
in
regular
ipfs
parlance.
We
call
them
chunks
inside
of
Blake
3
because
they
actually
aren't
blocks
right.
These
are
just
literally
chunks
of
of
a
of
a
larger
hole
that
actually
don't
make
sense
out
of
that
context,
and
that's
one
of
the
bigger
things
right
with
blake3.
We
dropped
the
number
of
cids
that
we
talk
about
by
an
order
of
magnitude,
because
we
don't
actually
represent
a
file
that
might
in
in
regular
ipfs
problems.
We
might
use
a
fixed
size
chunker.
C
It
takes
a
100
megabyte
file
and
cuts
it
up
into
256
kilobyte
blocks.
Here
we're
saying
no,
that
100
megabyte
file
gets
a
single
CID,
and
then
we
have
incremental
verification
metadata
that
we've
transmit
separately,
where
those
hashes
made
theoretically
could
be
cids,
but
they
are
never
treated
that
way.
Inside
of
our.
C
Six
percent
yeah
okay
by
default,
six
percent
and
and
the
setting
we
use
is
far
lower-
is
chunk.
Groups
you
can
get
down
into
the
like
one
percent
range
I.
Think
it's
important
to
like
point
that
out
and
kind
of
dispel
that
myth
you
can
get
that
trick
with
regular
ipfs.
We
call
that
the
file
store
pattern
in
in
Kubo
lab,
so
you
can
actually
do
this,
where
you
just
store
the
block
constructions
and
the
block
setups
as
metadata.
C
The
challenge,
though,
is
that
the
metadata
overhead
is
quite
High,
and
the
construction
of
that
overhead
can
be
quite
expensive
by
using
just
a
hashing
algorithm
and
in
particular
blake3,
which
is
a
highly
paralyzable
hashing
algorithm.
We
can
do
our
recent
tests
had
ingests
of
llama
the
Facebook
new
machine
learning
model.
B
Gotcha
and
in
the
design
dock
I
read,
iro
is
in
alignment
with
many
common
wholesome
whole
file.
Checksum
systems-
maybe
you
could
sort
of
it,
seemed
like
it
was
hinting
at
something:
potential
interoperability
with
existing
system.
What
are
some
of
those
systems
that
you
had
in
mind
that
we're
talking
about
package
managers,
Docker
registries,
yeah,
yeah,.
C
That's
a
great.
We
could
have
phrased
this
a
little
clearer.
The
idea
there
is
with
iro.
It
should
not
be
this
All
or
Nothing
system.
We
don't
want
to
end
up
in
a
world
where
you
have
to
ingest
stuff
and
keep
around
this
like
really
thick
textbook
of
metadata
anywhere
and
so
the
interoperability
story
for
iro
is
you
can
just
content
address
stuff
at
rest
because
you
don't
need
to
change
the
bytes
and
the
metadata
overhead?
It's
really
small
entire
S3
buckets
entire
package
manager
systems,
like
literally
you
know,
existing
blockchains.
C
C
We
can
give
you
like
outboard
metadata
and
say:
hey,
go
fetch
this
file
from
S3
here
is
the
CID
and
the
and
the
incremental
verification
data
and
that'll
be
passed
as
a
side
Channel
and
now
all
your
data
transfer
protocol
is
just
an
HTTP
Fetch.
With
this
like
really
clean
and
transparent
interoperability
story,.
B
C
Yeah
and
so
as
soon
as
you're
as
soon
as
your
client,
you
know
we
really
like
back
from
move
the
bike's
working
group,
I.
Think
geropo
had
a
really
sort
of
like
bombshell.
Talk
that
drove
home.
A
point
that
a
lot
of
us
have
been
excited
about,
which
is
smarter
clients
is
the
way
to
go
as
long
as
you
can
do,
parallelized
fetch
right.
So,
let's
use
that
scenario
of
hey
I
need
to
get
a
video
file
and
I
happen
to
know
the
three
people
provide
it.
C
If
the
client
knows
gets
into
a
position
where
it
knows
enough
soon
enough,
it
can
efficiently
construct
and
paralyze
that
query
across
the
three
peers
that
are
providing
that
data,
and
so
the
the
example
I
just
just
explained
to
you
was
like
Hey.
You
know:
here's
an
S3
URL
and
here's
this
CID
and
metadata.
That's
the
idea.
Metadata
is
the
sort
of
manifest
that
you
need
to
understand
how
that
file
looks,
and
if
you
knew
about
multiple
providers,
you
could
do
half
your
fetch,
be
an
HTTP
call
half
via
a
peer-to-peer
connection.
C
You
can
sort
of
efficiently
construct
that.
However,
you
want
not.
However,
you
want
as
as
fast
as
we
can
possibly
ship
you,
a
plan.
They'll,
do
it,
but
that's
yeah,
that's
the
sort
of
Hope.
Is
we
really
want
to
get
into
that
position
where
we
have
really
smart
clients
that
can
do
the
best
make
the
best
possible
choices
based
on
the
knowledge
that
they
have
locally
and
that's
really
kind
of
the
heart
of
doing
peer-to-peer
stuff
right.
B
C
Totally
you
heard
the
nail
on
the
head,
I
think
I.
Think
if
you
had
to
prioritize
the
problems
and
our
research
is
pointing
us
really
at
that
churn
problem
as
number
one
closely
followed
by
a
pretty
small
Uplink
as
being
number
two.
So
we
can
think
about
modern
Wi-Fi
as
being
capped
at
basically
200
megabytes.
A
second
right,
that's
not
the
same
speed
as
your,
and
so
your
phone
sitting
on
your
wife
even
sitting
on
your
Wi-Fi
network,
which
is
better
than
5G,
which
we're
just
not
even
going
to
touch
it
is
yeah.
C
Can
that?
Can
we
actually
make
an
efficient
peer-to-peer
citizen
out
of
that
device?
And
so
you
can
imagine
a
graph
where
the
longer
the
device
is
online
and
the
better
the
connection,
the
more
useful
it
can
be,
and
so
the
real
challenge
with
iro
is
to
construct
a
system
that
can
move
as
far
down
that
curve
as
possible
where
the
session
time
is
as
short
as
possible
and
as
short
as
reasonable
and
the
number.
C
But
through
that
shorter
session
time
you
get
a
better
you're,
they're,
theoretically,
more
nodes
available
right,
and
so
there
isn't
any
major
magic
here
that
is
different
from
how
ipfs
works.
Today
we
still
imagine
using
a
DHT,
we
still
imagine
using
path
and
address
systems,
and
we
still
have
to
do
a
whole
bunch
of
natural
magic
to
get
a
really
reliable
connection
infrastructure.
C
With
that
said,
the
thing
that
I
think
we've
learned
the
most
over
the
last
five
years
is
really
just
how
important
it
is
to
solve
for
this
churn
problem
and
to
start
thinking
about
session
lengths
that
are
on
the
order
of
seconds
and
that's
really,
where
we've
been
spending
a
lot
of
our
time
researching
and
we're
also
kind
of
tuning
in
the
use
cases.
We're
not
just
saying
hey,
we're
going
to
do
we're
going
to
serve
web
pages
from
mobile
phones
like
that's,
not
it's
not
a
reasonable
thing,
but
mobile
gains
and
mobile
game
assets.
C
Yeah.
We
can
do
that
right
because
now
we
have
really
big
asset
sizes
really
long
session
length,
because
a
user
is
spending
a
lot
of
time.
Online
social
media
right
you've
got
a
whole
bunch
of
people
browsing
a
lot
of
rich
media
content,
often,
unfortunately
glued
to
our
phones
for
long
periods
of
time,
and
so
we
there
are
very
real,
very
actionable
use
cases
where
you
can
align
the
scale
of
these
networks.
C
We've
got
hundreds
of
thousands
millions
of
devices
playing
these
games
on
these
social
networks,
so
we
can
drive
even
like
a
five
percent
utility
out
of
those.
These
are
major
league
scaling,
wins
right,
and
so
that's
really
what
we're
aimed
at
that
means
doing
a
whole
bunch
of
gack
under
the
hood.
B
C
So
I
was
interactive
development.
We
have
a
release
out
today
that
you
can
play
with
the.
There
are
three
major
pillars
that
we
have
to
solve
for
data
transfer
check.
We've
got
that
reliable
connections.
That's
the
thing
that
we're
shipping
next,
which
is
hey.
Can
we
connect
to
you
even
if
you're,
behind
Network
address
translation,
even
if
you're
lined
with
corporate
firewall
that
shipping?
Next?
C
B
Got
it
Brendan?
Thank
you.
So
much
I
dropped
the
link
into
the
chat.
That's
iro
dot,
computer
and
everything
you're
doing
is
open
source
too
so
I
folks
are
interested.
They
can
dive
into
the
rust
code
base.
Anything
else
you
want
to
share
before
you
wrap
yeah
thanks
so
much
for
hosting
this
Daniel.
It's
really
it's
been
great
chatting.
Thank
you
for
coming
on
hope
to
have
you
here
soon
and
maybe
with
some
more
progress
updates
on
iro
thanks
all
the
best
okay.
Next
we
have
our
next
guest
and
that
is
Robin
Bergeron.
B
So
welcome
Robin
you're,
heading
governance
and
standards
at
protocol
labs
and
you've
been
working
on
making
the
web
better
for
a
couple
of
decades
and
you've
done
a
lot
of
work
on
standards
and
privacy
and
you're
really
passionate
about
turning
the
web
into
a
space
that
is
operated
collectively
and
cooperatively.
Is
that
a
good
way
to
put
things
Robin.
D
Yeah
yeah
I
think
I
think
that's
that
that
is
indeed
a
a
better
way
to
put
it
than
I
would
have
put
it
myself.
So
so
thank
you,
yeah
I
mean
basically,
you
know,
sort
of
like
in
the
late
90s
I
just
covered
this.
This
web
thing
and
I
thought
it
was
wonderful,
but
it
had
a
few
problems
and
I
figured
I'd,
spend
you
know
six
months
or
a
year
working
on
fixing
those
problems
and
then
I'd
be
done
with
it
and
figure
out
what
I
wanted
to
do
in
life.
B
And
tell
me
something
Robin,
so
tell
me,
you
told
us
a
little
bit
about
your
background
in
the
90s.
That
was
a
really
exciting
time
for
the
internet
right.
It
was
this
like
new
publishing
Revolution.
It
was
almost
like
a
Gutenberg
V2,
and
how
did
you
come
to
work
on
ipfs
because
you
were
working
on
the
you
were
working
for,
like
w3c
I,
believe
you
had
some
Association
in
the
New
York
Times,
what
sort
of
attracted
you
to
ipfs
and
how
did
you
come
to
work
on
it.
D
D
D
So,
basically
it
it's
one
way
to
think
about.
It
is
in
terms
of
authority
and
and
I.
Think
we
don't.
We
don't
spend
a
lot
of
time
thinking
about
these
issues
because
stuff,
like
names
and
and
like
who
decides
how
to
name
things
tend
to
be
like
so
basic
and
so
automatic
that
that
we
don't
we
don't,
you
know,
think
about
them
much.
But
if
you
read
the
you
know
a
lot
of
the
early
architectural
documents
of
of
HTTP
and
of
the
web.
D
There
was
this
very,
very
strong
idea
that
DNS
delegates
authority
to
a
server
and
on
that
server
you
know
whoever
operates.
It
absolutely
owns
that
space
and
they
own
that
space.
In
terms
of
like
naming
things
in
terms
of
like
what
resources
resp,
you
know
can
be
used
to
reply
to
what
names
and
it
we
don't
I,
don't
I,
don't
think
we.
We
completely
understand
how
strong
that
belief
in
Federation
and
like
in,
like
my
server,
is
my
land,
and
this
is
my
property
and
and
I'm
the
king
of
that
property.
D
It's
like
you
are
basically
visiting
when
you
visit
the
website,
you're
visiting
someone
else's
property
and
as
a
user,
you
have
no
authority
over
what
happens
there.
What
we
mean
by
self-certifying
is
things
that
carry
their
own
authority
with
themselves
so
with
ipfs,
because
it's
company
addressed,
you,
don't
need
someone
else
to
tell
you.
You
know
what
content
this
is
and
and
how
it's
retrieved,
the
the
the
name
is
the
is
derived
directly
from
the
content.
D
Therefore,
you
can
interact
with
content
in
a
way-
that's
not
mediated
by
this
idea
that
it
is
necessarily
someone
else's
property
or
that
you
have
to
abide
by
someone
else's
rules
to
to
to
interact
with
it
and
that
you
know.
That
means
a
lot
of
power
gets
pushed
back
to
to
people,
and
it
goes
very
well
with
you
know,
having
having
a
self-sovereign
identity
and
a
whole
number
of
other
properties
that
that
basically
again
push
power
back
to
people.
B
I
see
so
in
your
understanding,
would
you
consider
say
because
DNS
while
it
is
an
open
system-
and
you
can
use
it-
you
know
to
your
liking,
you
can
run
your
own
DNS
server
and
then
you
know
allocate
names
as
you
like.
You
know,
in
the
sort
of
the
modern
kind
of
like
application
of
it.
It's
really
I
mean
you
have
the
TLD
and
you
have
the
ican
and
you
have
like
this
authorities
and
these
organizations
that
are
trying
to
manage
what
is
I
think
a
scarce
resource
right.
B
You
have
only
so
many
names
that
you
can
fit
under
the.com
TLD.
How
do
you
think
about
you,
because
you
mentioned
identity
and
I-
was
very
curious
to
hear
your
thoughts
about?
How
do
you
see
sort
of
human
friendly,
self-certified
self-certifying
naming?
Do
you
think
that's
even
a
realistic
Vision,
or
do
you
imagine
that
in
any
system
you
would
require
some
level
of
of
like
essentially
organizations
to
manage
these
Collective
resources
at
a
scarce?
That's.
D
A
very
good
question,
I
mean
naming
naming
is,
is
is
very
hard.
I
forget
who
said
that
that
the
two
hardest
problems
in
computer
science
are
are
naming
and
validation
and
and
I
honestly
think
cash
and
validation
is
a
bad
compared
to
naming
so
I
I,
don't
think
that's
been
solved
yet,
at
least,
if
you
want
the
names
to
be
readable
and,
as
you
said,
human
friendly,
if
you
want
something
better
than
you
know,
an
ipns
hash
of
a
key
or
something
that
delegates
to
DNS,
it
hasn't
been
solved
completely.
D
Yet
that
being
said
that
people
working
on
a
variety
of
systems
that
I
I
do
think
you
know
give
me
hope
that
the
the
the
the
this
problem
will
be
solved,
or
at
least
improved
soon.
So,
for
instance,
at
the
next
ipfs
thing,
there's
going
to
be
a
presentation
about
Blaine,
Cook's,
name
name
system
which
tries
to
address
some
of
these
issues.
There's
also
been
work
around
various
pet
naming
or
local
naming
conventions.
So
I
know
I,
know
the
the
the
subconscious.
D
People
have
a
system
where
you
can.
You
can
have
your
local
pet
name,
that
map
everything
maps
to
cids,
and
then
you
can
do
like
your
local
name,
dot.
Someone
else's
name
got
someone
else's
name,
and
so
you
can
eventually
create
a
path
across
the
network
that
goes
that
goes
somewhere
else,
so
these
problems
are
being
being
worked
on
and
I
I
do
think
we
can
find
a
collectively
governed
way
of
of
addressing
them.
D
So
you
know
working
with
others
to
to
to
put
together
some
specs
websites,
and
you
know,
have
a
nice
system
for
publishing
specs.
Really.
The
idea
is
to
go
a
bit
beyond
the
kind
of
like
markdown
system.
You
know
just
marked
down
on
GitHub
that
we
have
today
still
keeping
that
on
the
authoring
side.
We
want
to
keep
it
easy
for
people
writing
specs,
but,
like
you
know,
improve
the
the
general
stature
and
also
a
number
of
like
distributed
web
policy
things.
B
D
Yeah
I
mean
that's,
that's
a
great
question.
We
can.
We
can
learn
from
experience,
you
know
from
from
you
already
Webb.
Initially
it
was
sort
of
like
vague
standards.
If
you
look
at
like
HTTP,
09
I
think
it's
described
in
like
maybe
seven
or
eight
paragraphs
like
the
whole
thing
and
and
HTML
itself
was
just
like.
D
D
Whichever
browser
was
on
top
at
that
at
the
point,
but
people
copy
with
bugs
and
so
and
so
then
you
had
bugs
and
copies
of
bugs
and
couple
of
copies
of
bugs,
and
you
ended
up
with
this
sort
of
like
big
organic
thing.
That
I
mean
it
worked.
It
was
successful,
but
at
the
same
time
it
was
really
hard
to
use
and
build
content
for
and
build
build
experiences
in
and
at
that
point,
focusing
on
on
interop
became
really
really
important
and
I
think.
D
That's
interoperable
and
won't
create
those
kind
of
like
bugs
and
copies
of
bugs
issues.
But
it
also
sort
of
dispels
this
idea
that
everything
has
to
copy
Kubo.
Kubo
is
wonderful,
but
it's
one
way
of
thinking
about
ipfs
and
if
we
want
ipfs
and
we
do
want
ipfs
to
go
into
all
kinds
of
different
environments
and
to
address
all
kinds
of
different
use
cases.
B
And
what
is
the
process
for
writing
these
specs
and
and
maintaining
them?
Look
like
I.
Imagine
that
this
also
touches
I
mean
the
very
governance
of
an
open
source
project.
So
maybe
we
can
start
with
like
how
that
would
looks
like
for
the
ipfs
specs
and
what
are
some
of
the
lessons
of
like
effective
governance
that
could
be
maybe
extrapolated
from
it.
D
D
Basically,
you
know
it
depends
on
on
the
kind
of
change,
but
if,
if
you're
talking
about
a
major
change,
you
you'll
you'll
you'll,
you
know
submit
an
improvement
proposal
along
along
with
it
with
a
spec.
It
doesn't
have
to
be
super
formal.
Currently,
the
standards
aren't
very
formal,
we're
probably
going
to
make
them.
You
know
incrementally
a
little
bit
more
formalized,
so
that's
so
so
as
to
avoid
some
some
ambiguities.
D
But
really
you
know
if,
if
you
look
at
the
few
ipps
that
are
out
there
and
you
read
the
process
which
is
I,
think
two
pages
long
you'll
have
a
pretty
good
act
of
of
of
what
needs
to
be
done
now.
I
think
the
question
that
certainly
I
wouldn't
say
it
keeps
me
up
at
night,
but
but
that
that
I
I
feel
that
we
need
to
really
get
to
inside
of
say
the
coming
year
is
at
what
point
do
we
need
to
scale
up
this
process
a
little
bit?
D
What
I
mean
by
that
is
in
terms
of
success?
You
know
successful
governance.
The
the
difficulty
is
not
finding
a
model
that
works
at
the
scale
at
which
you
are
I
think
the
current
ipfs
system.
You
know
it
works
well.
The
problem
is:
how
do
you
scale
when
something
becomes
successful,
because
there's
a
level
at
which
you
know
basically
having
some
common
rough
Norms
is
sufficient.
D
You
know
you
I,
don't
want
the
other
people
in
there
to
think
that
I'm,
a
jerk
so
I'm
going
to
behave
well
and-
and
that's
enough,
you
know
that's
basically
enough
enforcement
and
enough
power,
but
as
soon
as
you
start
getting
like
large
companies
involved,
maybe
a
lot
of
money,
money
riding
on
something,
maybe
conflicting
interest.
You
know
increasingly
large
large
companies
and
again
we've
seen
that
in
HTTP.
D
Quite
quite
quite
strongly,
then
you
know
a
a
process
that
only
relies
on
on
Norms
and
on
on
people
not
wanting
to
be
perceived
as
as
a
bad
person
by
us
eventually
breaks
down,
because
you
know
on
one
side
you
have
a
job
and
you
have
like
a
whole
bunch
of
other
people
that
you're
working
with
and
they
think
you're
doing.
The
right
thing.
Unity
thinks
you're
doing
the
wrong
thing.
But
that's
not
that's
not
enough.
D
You
could
go
like
well,
I
think
my
people
are
are
more
correct,
and
so
you
start
to
need
to
build
stronger
governance
and
stronger
enforcement
mechanisms
and
stronger
requirements
for
consensus
and
ramping
that
up,
and
so
that
that
you
know,
there's
not
one
one
solution
and
just
one
way
of
doing
it.
But
it's
it's
it's
basically
the
we
don't
want
to
do
it
too
early,
because
then
you
start
creating
process,
that's
administrative
and
bureaucratic,
and
everyone
hates
that.
D
B
B
Maybe
you
can
give
I
mean
you
mentioned
the
ipps,
which
is
the
lightweight
sort
of
proposal,
process
that
we
have
but
yeah
in
general,
how
how
can
folks
get
involved
and
when
would
they
get
involved,
because
in
many
situations,
I
think
there's
also
no
need
for
folks
to
get
involved
in
the
spec
process.
You
know
sometimes
you're
just
trying
to
get
something
done,
and
that
doesn't
mean
you
need
to
start
diving
into
specs,
and
maybe
you
can
also
clarify.
When
is
the
moment
to
actually
get
involved
in
specs
yeah.
D
That
that's
a
very
good
question,
I
mean
first,
you
could
get
involved
because
you
like
specs.
Some
people
are
like
that
they're
kind
of
weird
I'm,
one
of
them,
but
you
know
it.
The
specs-
can
can
provide
interesting
challenges
in
themselves
as
artifacts.
So
that's
one
reason
to
do
it,
but
I
would
say
more
generally.
There
I
would
say
that
two
primary
reasons
why
you
would
want
to
get
involved
in
the
process.
D
One
is
you
there's
a
significant
new
feature,
new
new
piece
of
functionality
that
you
want
not
just
your
own
personal
implementation
support,
but
others
as
well,
and
so
in
that
case
you
know,
say
you
know,
I
I,
don't
know
any
any
new.
Any
new
feature
I
mean
Brendan
was
talking
about
like
like
Blake
3,
for
instance,
I
think
you
know
something
like
that
would
would
require
some
degree
of
specification.
That
would
be
something
that
that
could
get
us
want
to
do
something
like
that,
bringing
us
back
forward.
D
One
is
yes
improving
the
spec,
because
normally,
if
things
disagree,
it
will
mean
that
the
spec
either
isn't
written
or
is
ambiguous
or
has
a
problem
of
some
kind.
So
focusing
on
that
helping
fix
that.
That
is
something
that
can
be
a
small
intervention.
You
know
you
don't
have
to
become
like
a
standards,
wonk
and
and
know
everything
about
writing
things
well,
even
just
like
filing
the
issue
in
the
first
place.
D
Is
already
super
helpful
on
that
on
that
front,
but
the
other
part
of
it
is
is
contributing
to
a
test
Suite,
that's
often
something
that
developers
can
be
more
familiar
with
and
find
more
more
rewarding,
so
that
there's,
you
know,
there's
work
ramping
up
on
a
shared
test
suite
for
for
ipfs.
It
is
starting
now,
but
it's
starting
to
look
really
nice
already,
and
you
know
a
spec
is
only
ever
as
good
as
the
test
Suite
that
tests
it,
because
that's
that's
what
makes
things
real
right.
D
You
can
have
all
the
words
you
want,
but
if
there
aren't
tests
to
match
them,
it's
just
words,
and
so
so
you
know,
whenever
you
find
an
interop
problem
coming
to
the
test
system
and
saying
like
well,
this
isn't
tested.
Maybe
we
should
test
that
because
then
people
will
do
the
same
thing
is
also
a
great
way
to
contribute
to
you
know
things
that
are
overall
standards
and
specification.
Artifacts.
B
D
Absolutely,
and
so
you
know,
I've
been
talking
a
lot
about,
you
know
what
I
think
the
governance
should
be
and
and
what
what
things
people
could
do,
but
I
I
think
that
track
is,
is
really
a
good
place
for
people
to
bring
governance
problems
to
the
community.
It's
like,
if
you
think
that
this
or
that
part
of
ipfs
should
be
better
governed.
D
D
B
D
Know
we're
hearing
a
lot
from
operators
about
how
do
I
handle
all
this
gdpr
thing
or
all
that
DMC
anything
or
you
know
this.
This
other
kind
of
problem-
and
you
know
get
it
is-
is
just
like
YOLO
I,
don't
care,
I'm
gonna,
ignore
it,
but
I
think
I.
Think
a
lot
of
operators
are
now
really
wanting
to
have
shared
solutions
to
to
these
issues,
and
so
that's
also
something
that
we
want
to
govern
together
and
and
standardize
across.
D
B
Great
and
yeah,
this
is
also
a
good
moment
to
just
plug
ipfs
thing
in
general,
so
ipfs
thing
in
case
you
haven't
heard,
is
taking
place
in
Brussels
Belgium.
This
is
also
a
chance
to
meet
Robin,
Ryan
I
believe
is
going
to
be
there
and
also
Brendan
who
was
here
earlier.
So
is
this
really
like
an
event
for
the
ipfs
implementers
community
and
everything
from
talks,
workshops,
discussion,
circles
and
and
hacking
time
really
all
focused
on
on
advancing
ipfs?
B
So
this
is
your
opportunity
and
I'll
drop
a
link
to
the
website
where
you
can
learn
more
about
this.
If
you
haven't
thing
dot,
IO
yeah,
so
I
just
dropped
the
link
there
Robin
anything
else
you
want
to
share
it.
Can
we
do
do
we
have
something
that
we
can
share
with
regards
to
the
new
specs
website
that
you've
been
working
on
or
is
that
premature?
B
D
Like
it's
proven
to
me
by
a
couple
days,
I
was
hoping
to
have
it
for
today,
but
it
hasn't
completely
shipped,
but
it
you
know,
people
can
can
already
open
it
in
a
tab
and
it'll
refresh
at
some
point.
Specs
dot.
Ipfs.Tech
is
where
it's
going
to
be
at
there's
already
a
draft
there.
But
it's
it's
it's
it's
it's
it's
very
early
days,
but
we're
going
to
start
seeing
actual
specs
dropping
there
within
within
days.
B
E
B
You
are
a
texas-based
engineer,
working
with
little
bear
Labs,
currently
working
on
the
ipfs
in
space
project,
and
this
is
a
project
that
is
focusing
on
applying
content,
addressable
data
and
tooling
to
satellite
communication,
and
your
background
includes
shipping
code
for
inventory
scanners,
in-car
GPS
units
and
open
source
flight
software.
So
you
really
have
this
ever
growing
love
for
pushing
bytes
and
doing
low-level
things
with
rust,
and
this
is
I
believe
what
brought
you
to
work
on
this
ipfs
in
Space
Project.
E
There
I
actually
got
to
meet
with
Marshall
in
person
because
we
live
in
the
same
city
and
really
talk
shop
about
what
had
been
done
and
where
this
project
was
going.
So
that
made
it
just
a
really
nice
transition
and
with
the
similar
backgrounds,
I
was
excited
to
once
again
get
to
work
on
sending
rust
up
into
space.
B
E
Yeah
yeah,
so
when
I
think
about
the
project
that
we're
currently
working
on,
there's
almost
like
two
different
projects
here,
so
one
of
them
is
supporting
this
demonstration
of
ipffs
in
space
that
you
guys
are
working
with
Lockheed
on,
and
that
obviously
is
super
cool.
And
we
want
that
to
go
really
well
and
we
want
to
make
sure
that
we
we're
demonstrating
ipfs
in
a
way.
That's
like
really
meaningful
and
working.
E
So
the
other
is
like
more
of
a
long-term
view
of
like
how
do
we
create
a
foundation
like
a
base
for
people
to
build
on
top
of
for
using
ipfs
in
space
so
that
they
don't
have
to
start
over
from
scratch?
You
know
we
have
some
tools
or
even
a
system
that
they
can
build
on
top
of
when
they
start
to
address
more
complex
parts
of
this
particular
problem.
E
So
this
initial
demo
is
going
to
be
a
relatively
simple,
like
point-to-point
demonstration
of
using
ipfs
to
transfer
content,
addressable
data
back
and
forth
between
a
ground
station
and
a
satellite,
and
that's
one
satellite
and
one
ground
station,
which
is
why
I
say
simple.
You
know
we're
able
to
eliminate
a
lot
of
the
complexity
of
like
peer-to-peer
things
and
focus
just
on
the
basics
of
shipping
content,
addressable
data.
E
So
as
of
today,
almost
all
the
functionality
required
for
that
mission
is
actually
complete
and
we're
working
on
like
edge
cases
and
hardening
things
up,
so
that
when
we
go
to
actually
test
this
on
Hardware,
there's
no
big
surprises.
So
we
have
a
new
ipfs
node
kind
of
up
here
to
Cubo
and
that's
named
Miceli,
similar
to
the
fungus
that
spreads
and
communicates
really
well
over
long
distances.
E
Now
that
the
demo
obviously
is
the
first
priority,
but
that's
kind
of
shaped
the
way
that
we
think
about
this
long-term
foundation
and
how
we
build
it
and
the
process
we're
going
through
is
essentially
starting
with.
How
do
we
ship
something
that
just
works
and
then
we'll
layer
on
pieces
of
functionality
addressing
more
complex
concerns?
E
E
But
the
reality
is
that,
right
now,
as
I
work
on
this
I'm,
not
the
best
person
to
answer
those
questions
and
those
questions
aren't
actually
relevant
to
the
demo.
That's
being
worked
on
this
year,
so
we're
kind
of
punting
those
questions
down
into
the
future
and
for
now
building
a
foundation
that
will
work
for
the
demo
and
give
people
a
great
place
to
start
when
it's
the
time
to
address
those
questions.
So
we
can
get
this
year
like
the
priorities
for
the
project
are
one
making
sure
the
demo
is.
Success?
B
B
How
has
that
been
with
rust
and
sort
of
approaching
these,
because
I
imagine
that
it's
quite
challenging
you're
trying
to
build
here
a
solid
foundation
and
a
big
part
of
that
is
that
you're
having
to
think
about
multiple
layers
of
the
iso
The
OSI
or
the
tcpip
model
right?
You
know
we
have
this
model
to
provide
encapsulation
so
that
most
developers
can
really
focus
on
their
layer
of
the
stack
like,
for
example,
most
developers.
Today
you
know
they're
working
on
HTTP
servers.
B
They
don't
really
need
to
think
too
much
about
TCP
and
and
and
how
things
are
Ethernet
or
how
you
know.
Packets
are
rooted
around
the
the
web.
That's
just
a
different
layer
of
abstraction,
but
when
you
approach
this,
you
know,
ipfs,
arguably,
is
sitting
on
top
of
Transport
protocols.
It's
an
application
layer
technology
and
it's
relying
on
you
know
a
full
stack,
a
full
Network
stack
below
it.
B
You're
in
you
know
if
you're
speaking
about
you
mentioned,
for
example,
doing
a
radio
communication
where
you're
actually
doing
this
transmission
over.
Like
radio
communication,
you
know
in
your
testing
environment
you
mentioned,
you
also
have
all
of
these
like
I,
believe
like
SDR
software,
controlled,
radio
and
and
so
I
guess.
My
question
is
like
what
is
it
like
to
be
thinking
about
so
many
layers
of
the
stack?
At
the
same
time.
E
E
So
when
it's
come
to
like
actually
building
this
and
thinking
about
the
different
networking
players,
I
find
it
to
be
very
satisfying
and
interesting.
You
know
we
all
know
about
HTTP
and
TCP
and
IP
to
a
certain
extent,
because
we
just
use
them,
but
usually
we
don't
have
the
opportunity
to
peel
back
those
layers
and
see
what's
going
on
underneath.
E
So
it's
a
privilege
to
get
to
work
in
a
problem
where
I
have
to
peel
back
those
layers
to
even
see
what's
happening
and
maybe
try
to
try
to
switch
them
out
and
in
a
lot
of
ways,
it's
like
surprising
and
humbling
to
see
all
the
work
that's
been
done
and
all
the
different
ways
people
try
to
solve
different
networking
problems.
So
this
is
a
this
is
a
different
sort
of
problem,
maybe
than
we've
had
to
address
before.
E
So
we
have
to
think
about
what
is
the
new
idea
here
that
we
we
that
we
need
so
in
this
for
this
project
in
particular,
like
we're
talking
over
radio,
this
radio
link
could
have
been
empty.
You
anywhere
from
like
60
bytes
to
normal
1500
bytes.
We
don't
know
how
reliable
it
will
be.
It
could
be
one
way
it
could
be
two-way,
so
TCP
is
like
obviously
off
the
table.
It
would
just
be
so
upset
with
us.
E
We
tried
to
use
TCP
over
a
radio
link
like
this
in
the
worst
case,
so
we
can't
do
that.
So
what
we
did
is
in
the
Assumption
we
we
were
able
to
assume
that
we
get
a
network
stack
on
the
spacecraft
and
on
the
ground
station.
Maybe
those
Network
Stacks
can't
talk
directly
to
each
other,
but
at
least
we
can
use
that
within
the
system
itself
to
talk
to
the
different
components.
So
we
made
the
assumption
that
everyone
will
be
able
to
speak
UDP,
so
my
cellular
will
speak.
E
E
B
E
E
Yeah
yeah,
so
we've
been
using
this
this
phrase
into
use.
This
is
I,
think
maximum
transmission
unit
and
just
to
give
some
context
so
I
have
a
little
lab
set
up
on
my
desk
where
I've
been
testing
this
and
that's
a
Raspberry
Pi
with
the
radio
hooked
up
to
it,
and
then
a
pure
radio
on
my
computer
and
the
MTU
for
those
radios
is
60
bytes,
which
means
that
at
the
most
I
can
send
60
bytes
at
a
time.
E
E
So
if
like
every
packet
on
my
radio,
was
a
ipfs
block,
that
would
give
me
about
20
bytes
of
data
per
40
bytes
of
CID,
which
is
an
absurd
amount
of
overhead,
so
that
you
know,
we've
had
to
do
some
chunking
way
below
that
to
decrease
the
amount
of
overhead
and
actually
get
a
little
bit
of
efficiency.
Out
of
the
slit.
Now,
back
to
your
question:
Daniel:
yes,
there
are
a
ton
of
like
variables
that
affect
a
radio
and
how
we
communicate
over
it.
There's
the
MTU
size,
there's
the
reliability.
Are
they
one
way?
E
Are
they
two-way?
Those
are
like
the
main
things
that
I
think
about,
and
some
of
these
elements
we
can
work
them
into
configuration
like
the
MTU
size
is
something
we
can
configure
or
if
we
know
there's
going
to
be
latency
in
the
back
and
forth,
we
can
figure
that,
but
some
things
we
can't
just
like
configure
and
tune
on
a
dial
like
how
reliable
the
radio
is
going
to
be.
It
would
be
really
hard
to
have,
like
you
know,
low
medium
high
reliability
settings
so
many
things
change
based
on
the
reliability.
E
So
what
we've
done
is
started
with
the
assumption
that
we're
just
working
with
the
really
bad
radio,
it's
pretty
unreliable.
Maybe
it's
one
way.
Another
element
of
this
is
that
the
radio
on
the
satellite
and
the
ground
station
side
are
not
always
in
communication.
Usually
you
communicate
over
something
called
a
pass
and,
let's
assume
we
get
like
five
minutes
every
few
hours.
So
we're
not
communicating
very
often
so
everything
is
pitted
against
us.
E
How
do
we
build
a
protocol
that
can
make
the
most
of
that
time
make
the
most
of
that
link
and
work
somewhat
well
over
that
so
I
started
with
these
kind
of
bare
bare
minimum
assumptions
like
it's
going
to
be
real
bad.
If
it's
really
good,
that's
great,
but
if
it's
really
bad,
it
still
needs
to
work,
and
what
this
has
meant
is
that
for
the
data
protocol
itself,
it
is
needed
to
start
out
as
something
that's
really
simple.
It
has
very
few
expectations
about
maybe
receiving
responses.
E
This
idea
of
our
request
response
assumes
that
I
will
take
action.
If
you
acknowledge
my
action
and
maybe
tell
me
what
to
do
and
I've
had
to
like
eliminate
a
lot
of
those
those
assumptions
and
think
like
okay,
maybe
I'm
not
going
to
hear
very
much
back.
How
do
I
give
the
other
side
the
best
shot
at
getting
all
the
data
that
I
have
or
getting
the
right
data,
even
if
I
don't
hear
very
much
backwards,
so
in
general,
as
I've
been
thinking
about
how
we
form
the
messages,
how
we
form
the
responses?
B
B
That
can
be
done
and
you
know
maybe
the
work
that
iro,
the
iro
team
is
doing
is
is
gonna
like
yield,
some
of
those
like
more
efficient
representations
and
you
know
eliminate
the
need
for
you
know
you
know
representing
the
data
as
a
completely
discrete
you
know,
content
addressed
representation
of
it,
but
I
really
look
forward
to
see
how
this
pans
out.
You
know
with
satellite
communication,
because
I
mean
at
some
point.
You
know
you
just
can't
rely
on
there
being
a
single
point
that
you
can
always
reach
right.
B
E
Yeah
absolutely
and
I
think
this
first,
you
know
demonstration
Mission
gives
us
the
opportunity
to
show
like
hey.
We
can
do
simple
content
address
things,
but
the
real
power
will
come
out
whenever
you're
dealing
with
a
constellation
of
satellites
or
a
network
of
ground
stations.
That's
really
where
you
get
to
pull
these
big
levers
of
content,
addressable
data
and
Stitch
things
back
together
across
multiple
tiers.
B
E
Yeah,
it's
a
wonderful
question
so,
like
I
said
earlier,
there's
the
two
projects
at
play
here:
right,
there's
the
demo
Mission
and
then
there's
the
longer
term.
Building
this
foundation
and
I'm
sure
everyone
is
much
more
interested
in
the.
When
will
this
actually
get
into
space
side
of
things
so
I'm
going
to
give
you
basically
a
non-answer
here,
one
of
the
big
realities
that
I
personally
observed
in
the
space
industry
is
that
schedules
tend
to
slip.
E
That
just
happens
all
the
time
to
everyone,
so
I
believe
the
original
launch
date
for
this
demo
was
this
summer
and
I
can't
say
this
for
sure.
But
I
would
be
surprised
personally
if
that
summer
day,
folds
just
knowing
what
I
know
about
space
in
general
and
what
tends
to
happen
and
I
would
more
realistically
expect
a
fall
watch
but
I'm,
not
the
official
official
schedule
maker
here.
E
The
software
is
in
the
state
right
now
where
anyone
could
clone
this
code
and
get
a
Raspberry
Pi
and
some
radios
and
actually
start
using
it
to
send
data
over
their
radio
using
Miceli.
It's
at
a
good
enough
state
that
it
is
usable,
there's,
obviously
a
lot
more
to
build
on,
like
the
whole
peer-to-peer
concept.
But
the
foundation
is
there
and
usable.
E
The
way
it's
structured
is
the
Micelli
nodes
are
Standalone
binary,
similar
to
Cubo,
so
they
could
just
be
built
and
run
and
there's
also,
this
command
line
utility
for
forming
commands
that
you
use
to
control
the
nodes,
and
that
also
is
a
standalone
binary.
So
if
you
can
figure
out
enough
rust
to
build
these
projects
and
run
them,
that's
all
you
need
to
know
to
actually
start
using
it.
B
E
So
that
is
like
squarely
in
the
area
of
what
this
project
falls
into,
which
is
pushing
ipfs
or
forms
of
ipfs
into
different
embedded
spaces.
So
I
would
love
to
hear
from
all
you
Hardware
hackers
that
are
using
ipfs
about
your
different
ideas
and
what
you
want
to
do,
and
you
know
maybe
we
could
have
like
a
hack
day
on
one
of
the
uncomp
days,
where
we
all
bring
our
different
weird.
E
B
B
I'll
share
there
we
go
so
as
I
mentioned
ipfs
thing
you
can
check
out
the
website
here.
These
are
all
the
different
tracks
that
we
have
and
the
schedules
will
be
going
up
in
the
coming
days.
Also,
you
can
submit
a
talk
if
you're
interested
in
speaking
next,
we
have
the
Kubo
release,
so
oh
I
just
realized
that
I'm
not
even
sharing
my
screen.
Excuse
me,
okay,
that
should
work
a
bit
better.
B
B
Kubo
was
just
released
three
days
ago
and
with
it
there's
some
improvements
to
the
resource
manager,
P2P
resource
manager.
Some
of
the
commands
have
been
merged
into
a
single
ipfs
swarm
resources.
It
used
to
be
sort
of
grouped
under
two
different
sub
commands,
so
that's
a
bit
of
a
DX
Improvement
and
we
have
documentation.
Another
thing
which
I'm
particularly
excited
about
is
ipns,
signed,
ipns
record
response
format
from
the
Gateway.
B
So
when
you
run
a
Gateway
now
and
you
upgrade
to
Kubo
0.19,
then
you
can
actually
get
the
raw
ipns
record
from
using
HTTP,
which
means
that
you
can
verify
do
like
verified
resolution
of
ibns
Records,
as
you
may
be
familiar.
If
you
have
an
ipns
name
and
you
put
it
into
like
a
Gateway
URL,
then
you
basically
rely
on
the
ipfs
Node
to
do
the
ipns
resolution
and
then
to
just
serve
you
whatever
said
it's
pointing
at
with
this
you're
just
doing
the
ipns
resolution
stage,
so
it
also
potentially
shortens
the
time.
B
Obviously
it
doesn't
give
you
back
the
Sid,
but
this
can
help.
You
know
if
you're
just
debugging,
if
you're
just
trying
to
debug
ipns
resolution
I
mean
it's
quite
common
for
folks
to
look
up
an
ipns
record
and
they're
getting
an
older
version
of
it
or
whatnot.
So
this
really
makes
it
very
easy,
just
even
from
the
browser
to
do
this
verification
of
the
ipns
record
and
we're
also
deprecating
one
of
the
ipfs
pub
sub
commands.
B
If
you
are
relying
on
this
API
that
ipfs
that
Kubo
provided
I
highly
recommend.
You
look
at
this
release.
Note
in
in
some
of
the
rationale
for
it.
The
tldr
is
Kubo
will
continue
to
use
Pub
sub
for
ipns
propagation
and
it
still
uses
lipid
to
be
under
the
hood,
and
lip
P2P
continues
to
support
gossip
sub
and
Pub
sub.
B
The
main
thing
is
that
it's
very
hard
to
map
a
whole
decentralized
Pub
sub
protocol
onto
an
HTTP
API,
and
there
were
many
issues
that
arose
with
that,
and
this
is
why
we
think
it's
it's
best
for
us
to
sort
of
deprecate
this
API
and
instead
recommend
users
to
use
the
lip
P2P
gossip
sub
API
directly
we're
going
to
have
some
exciting
demos
coming
up
soon
on
that,
if
you're
interested
in
getting
sort
of
a
sneak
peek
at
what
we
have
in
store.
Just
look
for
the
universal
connectivity
repo
in
the
lipitorg.
B
B
It
is
you
know,
keeping
I
believe
the
polka
dot
network,
it's
being
used
for
the
consensus
of
polka
dot
and
also
by
the
consensus
clients
of
ethereum,
so
ethereum
two
post
merge
is
relying
on
Gossip
sub
to
propagate
its
messages
across
the
network,
and
this
is
fully
reliantly
P2P
and
and
it's
there's
interoperability,
there's
rust
nodes,
ethereum
consensus
nodes
and
there's
also
js1,
so
they're
all
relying
on
this
another
interesting
and
exciting
releases.
So
in
the
previous
episode
we
had
Alex
AKA
aching
brain
joined.
B
To
talk
about
Helia
Helia
is
the
new
implementation
of
ipfs
in
JavaScript,
typescript
I
mean
it's
typescript
first,
so
it's
really
nice.
You
get
all
the
typings
and
today
it
reached
1.0.
So
that
means
that
the
API
is
stable,
I'm
going
to
give
it
a
heart,
the
API
is
stable
and
pinning
API
has
been
added.
You
can
use
this
in
the
browser.
B
You
can
use
this
in
node.js
a
lot
of
exciting
things,
especially
with
regards
to
transports
that
it
supports,
but
the
whole
API
just
is
is
a
much
cleaner
API
if
you've
used
JS
ipfs
before
and
speaking
of
releases
ipfs
cluster
just
had
a
new
release
two
weeks
ago.
So
ipfs
cluster
is
how
you
scale
multiple
Kubo
nodes
and
manage
them,
and
the
main
thing
is
that
it's
using
a
new
data
store
so
I
think
it
you
had
the
option
of
running
Badger
and
level
DB.
B
These
are
essentially
like
key
value
stores
that
are
used
by
each
one
of
the
nodes
in
the
ipfs
cluster
and
I
believe
that
this
new
one
is
using
this
one
that
is
called
Pebble,
which
was
developed
by
the
Cockroach
DB
team.
So
yeah
check
that
out.
It
seems
that
upon
testing
that
this
delivers
much
a
lot
of
performance
improvements,
so
yeah
check
it
out
and
I
think
that
that
it's
pretty
much
it
I
mentioned
iro.
B
B
Let's
see,
if
there's
anything
else
here:
Blue
Sky,
social,
yes,
I
mentioned
Blue
Sky,
blue
sky
is
a
new
protocol
and
it's
building
on
top
of
well.
The
protocol
is
called
at
protocol
and
they're
using
it's
a
new
decentralized
protocol,
decentralized
social
media
protocol
and
I
have
two
invitations.
If
you're
interested
hit
me
up
on
Twitter
and
I'd
be
happy
to
share
two
invitations
to
Bluesky,
but
under
the
hood
it
is
using
ipld,
which
is
the
data
sort
of
model
that
ipfs
uses.
B
So
if
you're
interested
I
highly
recommend
checking
it
out
very
interesting
protocol,
they're
using
ipld
they're
using
dids
doing
some
interesting
stuff
human
friendly,
naming
and
sort
of
being
able
to
link
your
handle
to
your
own
domain.
So
it's
all
about
you
know
self-certifying
protocols
and
and
user
sovereignty,
so
I
highly
recommend
checking
that
out
and
with
that
I
think
we're
about
done
here.
If
you've
stayed
with
us
this
long.
Thank
you
for
staying
and
we
hope
to
see
you
here
soon.