►
Description
In This Lecture John will talk to us about what's been happening with Nix and IPFS, in his own words. Picking up where we left off integrating IPFS and Nix, we at Obsidian Systems have created a bridge between the Software Heritage archive and IPFS. We'd like to demonstrate those two integrations working together, and discuss the future possibilities of Nix taking a place within a larger family of content-addressing systems.
Special thanks to the NLnet Foundation, the European Commission, the NixOS Foundation, and Tweag for making this event a reality!
The continued discussion for the lecture series is happening over here:
https://matrix.to/#/#son2022-lectures:matrix.org
More information about the Summer of Nix can be found on the website:
https://summer.nixos.org
A
Hello,
everyone,
I
hope
everybody
can
hear
me
loud
and
clear,
so
you
all
know
the
drill
by
now,
so
I'm
not
going
to
spend
any
more
time
than
is
needed
on
this.
Today
we
have
john
it's
going
to
have
a
very
interesting
lecture,
but
I'm
going
to
leave
the
introduction
over
to
him
and
so
yeah.
You
know
what
I'm
here
for
I'm
here
to
thank,
of
course,
the
people
that
made
this
happen.
Thank
you
to
all
the
participants
of
the
summer
of
knicks
this
year.
A
This
very
special
thanks
to
the
analyst
foundation,
the
european
commission,
the
nexus
foundation
and
tweak
for
supporting
this
lecture
series
and
setting
them
up
without
much
further
ado.
I
am
going
to
pull
jean
in
here,
hello,
john,
hey,
hi,
brian,
and
I
will
put
your
slides
in
here
as
well.
There
you
go
good
luck,
john
great.
B
Well,
hi
everyone
else
too,
thanks
so
much
brian
for
walking
me
through
the
always
exciting
steps
getting
ready
and
thanks
to
all
those
organizations
too,
for
making
this
lecture
series
happen.
I'm
really
happy
to
be
here
and
talk
to
you
all
about
what
we've
done
on
this
sort
of
line
of
work,
since
next
ipfs
two
years
ago,
discussed
at
nixcom.
B
B
B
B
A
A
A
A
B
A
B
B
B
The
ips
store
implementation
was
actually
very
easy
and
natural
to
write,
and
so
that
is
for
me
that
was
sort
of
a
hallmark
of
hoping.
We
had
a
good
design
where
we
weren't
just
pulling
nicks
in
random
directions
to
work
with
ipfs,
but
we
did
a
few
sort
of
natural
want
them,
anyways
improvements
and
then
ipfs,
just
slides,
right
in
round
peg
and
round
hole,
and
also
we
added
some
outside
the
store
layer
and
the
fetchers
layer,
support
for
git
hashing
and
fetch
tree
and
fetch
git.
B
B
B
This
is
sort
of
the
the
first
motivation
that
everyone
thinks
of,
because
we
have
a
very
large
cache.nexos
today
and
everyone's
always
wondering
about
new
ways.
We
can
move
those
artifacts
around,
but
there's
a
second
motivation
that
I've
increasingly
become
fond
of,
which
is
the
source
distribution,
archival
motivation
with
this
one
we're
not
dealing
with
anything
nick's
made
we're
just
dealing
with
the
ultimate
inputs
to
mix.
B
If
any
of
you
all
have
tried
to
build
old
versions
of
nyx
packages
for
various
reasons,
you'll
see,
there's
often
a
case
where
old
sources
or
source
code
that
we
download
goes
stale
links
rot
and
for
both
individuals
and
institutions.
Looking
to
make
sure
that
not
only
could
we
continue
to
build
our
old
software
in
principle,
but
it
actually
works
in
practice
because
we
didn't
lose
the
data.
B
So
I
think,
in
addition,
having
good
allies,
it's
good
to
try
to
rather
than
make
us
like
the
rest
of
the
world,
which
is
great
but
can
sometimes
dilute
the
value
proposition.
Try
to
make
the
rest
of
the
world
by
us
like
us,
and
this
is
sort
of
an
underrated
way
to
instead
of
hitting
down
the
top
of
the
learning
curve.
Ramp
lifts
at
the
bottom.
B
So
software
heritage
fits
in
in
the
second
of
the
direct
motivations
and
the
indirect
motivation
software
heritage
has
helped
soon
explain
is,
has
a
huge
archive
of
as
much
open
source
software
as
they
get
their
hands
on.
So
they
are
the
source
code
archive
and
with
ipvest
involved,
as
opposed
to
directly
querying
the
software
heritage
archive,
there's
a
chance
to
sort
of
make
your
own
cdn
mix
together
an
archive
of
let's
say
your
own
private
software
and
the
public
comments
software.
B
So
this
is
sort
of
we
we're
both
giving
people
access
to
the
archive
the
central
one
and
allowing
them
to
sort
of
roll
their
own
with
whatever
extra
stuff
they
may
so
add,
and
then
finally,
we're
sort
of
continuing
the
coalition
building
and
ally
finding-
or
at
least
I
hope
so,
with
software
heritage,
again
being
a
very
natural
sort
of
in
their
in
their
goals
and
their
approaches
and
methodology.
A
very
natural
partner
for
us,
and
indeed
unlike
protocol,
a
software
heritage.
B
Excuse
me,
unlike
ipfs,
and
for
local
labs.
The
company
behind
ipfess
we've
actually
been
dealing
with
software
heritage
and
these
folks
area
and
stuff
for
years.
So
I
can't
give
myself
credit
in
making
a
new
bridge
from
the
next
ecosystem
to
them
when
we
already
have
one,
but
I
can
at
least
lay
down
a
few
more
lanes
on
that
existing
structure.
B
So
yeah
more
about
software
heritage,
as
I
said,
they
are
trying
to
collect
as
much
software
as
they
can
license.
Permittings
and
they're
doing
a
spectacular
job
with
one
petabyte
so
far,
which
may
not
sound
large
from
a
video
or
audio
perspective,
but
it's
quite
impressive
for
text
files
and
source
code,
where
the
the
call
is
always
to
be
terse.
B
Also
they
are
already
content
addressing
all
their
stuff
for
deduplication
purposes
and
the
software
heritage
ids
they
use
are
essentially
get.
I
get
hashes
with
a
little
extra
metadata
in
the
identifier
and
also
an
additional
object.
Format
represent
whole
repos,
which
are
not
content
dressed
in
git,
so
they're,
very
they're,
very
nice
small
incremental
step
over
vanilla,
get
hashing
and
the
files
and
directories
we
care
about
our
work.
I
do
identically
in
both
systems.
B
B
B
There's
tweet
did
some
very
nice
work
with
them
also
two
years
ago
trying
to,
as
I
understand
it,
make
sure
that
anything
that
nick's
packages
was
referencing
was
at
least
trying
to
be
adjusted
in
the
archive,
so
essentially
using
nyx
packages
as
a
new
source
of
things
to
go
fetch
not
unlike
how
a
car
crates
the
io
might
be
used
that
way.
But
there
are
some
difficulties
in
that.
B
So
that
was
the
the
on
the
next
side,
the
all
the
work
for
that
was
done
two
years
ago
with
the
ipfs
work.
But
we
continue
to
leverage
it
with
this
leg
of
the
project,
as
we
already
had
ipfess
and
nick's
now,
using
git
hashing
and
software
heritage
using
gashing.
So
we
are
building
out
the
amount
of
compatible
things
that
can
all
talk
to
each
other
and
all
content
addressed
in
the
same
way
in
a
real,
constant
address,
without
any
other
metadata
that
we
don't
want
mixed
in
polluting
it.
B
B
Also,
I
have
to
thank
and
elena
again
in
addition
to
for
the
helping
sponsor
the
summer
of
nix,
and
this
talk
today.
They
also
sponsored
this
project
and
that's
the
link
to
the
project
page
on
their
website.
So,
as
always,
thanks
so
much
nlnet
for
doing
so
much
to
keep
the
nyx
ecosystem
and
broader
ecosystem
of
open
source
stuff,
while
running
yes,
so
back
to
the
technical
details
with
this
two
layers
of
sliding
things
other,
we
have
a
very
co-linear,
clear
source
of
requests.
B
Things
can
come
from
nyx,
they
can
go
from
ipfs
and
from
there
they
can
be
relayed
to
software
heritage,
and
then
the
responses
likewise
will
fall
back
in
the
other
direction.
Software
heritage
to
ipfs
back
to
nyx
and
the
nice
thing
about
this
is
nyx,
doesn't
need
to
know
about
software
heritage
at
all.
B
In
fact,
I
did
not
even
test
the
nyx
ipfs
integration
and
software
heritage
and
iphone's
bridge.
Until
I
was
preparing
this
talk,
I
just
got
very
lucky
there
that
the
design
that
says
things
were
orthogonal
agreed
with
reality,
which
also
said
things
were
authorical
and
the
puzzle
pieces
just
snapped
right
together.
B
B
So
we
first
did
that
it's
a
currently
unstable
api.
So
you
need
a
access
token
to
try
it
out
today.
That
has
some
extra
perms,
but
it's
there,
and
if
you
click
that
url
you
can
get
the
docs,
it's
a
very
straightforward.
You
give
it
a
software
heritage
id.
It
gives
you
a
bunch
of
bytes.
If
you
hash
those
bytes,
you
get
the
same
hash
as
this.
The
hash
part
of
the
software
heritage
id
you
query
with
the
second
part,
is
the
codec.
B
So
these
git
itself
does
not
constant
address
whole
repository,
just
constant
address
commits
tags
if
they're
signed
directories
and
files,
and
so
the
repo
is
just
a
collection
of
stuff
that
has
its
known
hash,
so
they
wanted
to
also
be
able
to
say
well
if
we're
gonna
archive
an
entire
reboot,
we
want
a
hash
for
that
entire
repo
at
the
point
of
archival,
and
so
they
made
this
snapshots
format.
This
is
actually
not
at
all
necessary
for
nyx,
which
doesn't
care
anything
about
repos
or
history.
B
There's
we
I
didn't
want
to
skip
talking
about
that
and
then
finally,
the
important
part,
which
is
the
datastore
plugin
for
ipfs,
so
this
uses
will
will
intercept
a
request
that
thinks
it's
going
to
storage.
That
could
originate
with
a
cli
on
the
local
node
or
over
the
network
and
instead
of
doing
a
regular
look
it
up
in
the
local
database,
we'll
instead
translate
it
to
the
software
heritage
web
api
and
likewise,
if
it
gets
a
response
relay
that.
B
B
Okay,
thanks
brian,
so
the
first
thing
we
need
to
do
is
think
of
a
project
that
is
on
github
or
otherwise,
well
known
that
software
heritage
probably
has
archived.
So
I
will
just
think
of
something
on
github,
but
if
anyone
else
has
any
ideas
do
drop
in
the
chat,
I'm
happy
to
live
dangerously
and
use
a
crown
submitted
repo
to
fetch
from
instead.
B
A
B
B
B
B
B
B
So
we
hear
this
is
the
basic
commit
metadata
here.
It
says
aria,
which
is
a
good
sign
because
they
do
oh
camel
thing.
So
it
looks
like
we
have
the
right
repo
and
we
also
have
a
tree
hash
which
I'll
look
at
the
moment,
which
would
be
the
actual
files
we
care
about
and
not
the
history
stuff
which
nix
doesn't
so
again.
Nothing
here
says:
github.
Nothing
here
actually
says
software
heritage.
B
This
is
just
a
self-describing
content
address
known
ipfs
land
as
a
cid
content
identifier,
and
just
because
of
the
way
I
happen
to
have
things
set
up,
it
can
figure
out.
Ask
a
bunch
of
things,
find
one
that
claims
it
can
respond,
see
how
it
responds
verify.
The
data
display
the
data,
all
that
is
not
unlike
imp,
unlike
with
a
location
based
addressing
not
part
of
my
request,
but
just
incidental
in
the
way
the
network
is
set
up.
B
This
does
more
requests
again.
We
sell
actions
over
here
because
it
had
to
well.
This
node
talked
to
this
node,
which
talked
to
software
heritage,
which
had
the
request
lock.
But
if
I
do
the
same
thing
again
now
it's
cached
on
my
main
node
and
it
doesn't
need
to
talk
to
the
bridge
node
and
it's
a
little
faster,
so
easier,
a
bunch
of
stuff,
don't
need
to
look
at
all
those,
but
what
we
can
this
this
would
be.
B
B
B
So
let
me
explain
what's
going
on
here,
so
this
next,
that
I'm
running
is
the
is
our
is
our
modified
version
nyx
from
two
years
ago,
that
is
the
statically
linked
one
that
you
can
download
in
the
next
guide,
and
indeed
I
didn't
rebuild
it
or
anything.
I
just
download
that
old
binary
and
thanks
to
linux
for
not
changing
the
cisco
interface,
it
still
works.
B
I
could
have
used
the
fixed
output
derivation,
but
instead
I'm
using
the
live
fetchers
fetch
tree
to
demonstrate
this.
So
it's
a
fetch
tree,
that's
type
get.
The
url,
however,
is
totally
bogus.
It's
https
colon
slash,
slash
nope,
which
clearly
we're
not
going
to
be
able
to
get
any
data
from,
and
then
there's
this
new
triage
field,
unique
to
the
fork
that
has
the
now
the
magic
bytes
stripped
hash
that
I
just
pasted
in
and
then
the
substituters
is
a
trustless
ipfs
store.
B
B
B
A
B
B
B
B
A
B
B
B
B
When
we
did
the
fetch
28cf
so
this,
this
is
a
single
hatch
fetch,
but
this
is
not
an
mpr
fetch,
since
this
version
of
next
knows
about
the
git
hashing
again
old
stuff.
We
previously
did
it
this
this.
We
only
need
one
hash.
We
don't
need
two
hashes
like
today,
where
you
need
a
nar
hash
in
addition
to
some
sort
of
how
to
fetch
a
hash.
This
is
all
pure
eval
compatible.
B
It
just
uses
a
single
hash
and
even
and
because
the
url
is
busted,
it
falls
back
as
a
substituter
which
knows
how
to
get
it.
So
it's
all.
I
think
I
would
like
to
think
a
very
simple,
a
very
a
very
simple
user
experience
where
we
can
just
like
today,
with
a
fetch
tree
or
fixed
output.
Derivation
fetching
just
write
down
one
hash,
not
two.
B
B
B
B
B
Yeah,
so
it
really
is
gone
and
then,
if
I
try
to
download
it
again
now
it's
much
faster.
So
I
I
wasn't
the
trick.
I
really
did
delete
it,
but
instead
of
having
to
go
back
to
the
bridge
node,
which
is
so
slow,
it
can
there's
a
cache
copy
just
until
a
next
garbage
collection,
with
my
name
main
ipfs
node.
B
So
they
can
be
the
archive
of
last
restore
and
not
just
a
go-to
thing
where
people
get
their
stuff,
because
they're
too
lazy
to
find
it
anywhere
else,
and
since
they
are
a
non-profit
focusing
on
archiving,
not
dissemination,
that's
a
big
benefit
to
them.
Just
as
you
know,
you
shouldn't
go
to
your
national,
like
archival
library,
like
in
the
us
library
of
congress,
to
just
pick
up
a
bestseller,
that's
going
to
be
anywhere.
B
You
also
shouldn't
try
to
hit
that
software
heritage
cache
for
something
that's
well
known
and
going
to
have
a
bunch
of
other
copies
out
in
the
ether
and
just
as
libraries
have
the
sort
of
interlibrary
loan
human
level
protocol.
That's
that's!
Basically
what
ipfs
is
doing
that
on
the
internet,
and
that
is
the
end
of
the
demo
portion.
B
Okay,
so
yeah,
just
to
recap
there
things
I
was
saying
during
the
demo,
all
layers
are
using
the
same
hashes
and
on
the
next
side,
that
is
only
the
one
hash
they
get
hash.
Nyx
doesn't
know
about
software
heritage
at
all.
This
is
unmodified
from
two
years
ago.
Fork
of
nix
didn't
do
anything
to
bring
it
up
to
the
future.
Work
just
did
the
substituters
ipfs
and
let
my
regular
node
talk
to
the
bridge
node.
B
B
So
then,
finally
future
work.
We
want
to
deploy
a
public
bridge
so
that
you
don't
have
to
get
a
super
special
auth
token
and
software
heritage
doesn't
have
a
gazillion
people,
spamming
them
with
requests,
but
just
of
one
central
choke
point
they
can
monitor
the
research
usage
of
and
we
want
to
make
it
faster.
This
is
obviously
extremely
slow.
90S
error
speeds
right
now.
B
B
The
good
news
is
that
both
on
ipfs
and
software
heritage,
this
problem
is
well
known.
I
view
this
thing
as
a
graph
sync
protocol,
where
instead
of
saying
give
me
this
one
object
by
this
hash,
you
just
say
give
me
the
closure
and
it
will
sort
of
do
a
quick
traverse
on
the
remote
side.
Get
you
as
many
different
hashes
as
possible
of
that
closure,
and
then
you
can
start
broadcasting
all
those
hashes
concurrently
to
fetch
as
many
things
in
parallel
as
possible
and
on
the
software
heritage
side.
B
They
have
this
vault
api,
which
I
may
have
these
details
wrong,
but
it
seems
to
be
again
used
to
say:
hey.
I
want
to
have
some
sort
of
tarball
or
other
archive
of
the
closure
of
an
object.
It
will
go
a
symbol
of
that
for
you
async,
let
you
know
when
it's
done
and
then
you
can
download
that
big
tarball
or
whatever
in
one
fell
swoop,
so
two
different
approaches,
but
in
both
cases
the
concept
is
the
same.
B
How
can
we
best
transfer
back
and
forth
without
constantly
renegotiating
what
exactly
is
wanted?
So
I
think
I
I
think
you
know,
as
we
figure
out
future
plans,
hopefully
they'll
be
a
fairly
straightforward
way
to
find
a
find
way
for
both
sides
to
speak.
One
of
these
sort
of
recursive
fetching
closure
fetching
protocols
and
make
things
a
lot
more
efficient
and
then
finally
large
object.
B
Support
ipfs
has
a
very
sort
of
elegant
chunky
model
today,
where
objects
are
never
more
than
a
certain
maximum
transmission
unit
long
and
if
you
have
bigger
data
than
that
you're
supposed
to
split
up
into
more
objects,
that's
a
very
good
design.
I
think
the
right
design.
The
problem
is:
git
objects,
our
current
lingua
franca
that
I'm
using
to
get
everyone
to
communicate
with
each
other.
B
Don't
have
this
sort
of
chunking
bill
in
and
objects
are
arbitrary,
large,
so
we'll
have
to
be
a
little
clever.
Trying
to
retrofit
large
arbitrary
large
object
support
onto
ipfs
if
we
want
to
fetch
those
occasional,
very
large
source
files,
the
so
I'll
just
go
for
this
talk,
but
the
on
the
buy
on
the
binary,
the
the
the
builds
distribution,
the
binary
distribution,
suppose
the
source
distribution.
B
That
is
the
other
use
case
for
ipfs
and
nyx.
We
we
are
not
as
wedded
to
the
get
way
of
constant
addressing
things,
and
then
we
can
avoid
that
problem
in
other
ways,
but
for
source
code
that
is
already
get
hashed
everywhere.
We
really
are
kind
of
stuck
with
those
get
hashes
and
therefore
want
to
make
it
work.
B
B
If
we
are
to
like
upstream
this
functionality
in
nyx
and
start
thinking
more
broadly,
about
different
ways
of
scheduling,
builds
fashion
data
content,
addressing
data,
what
not
the
store
layer
is
going
to
get
a
lot
more
complex,
so
I
think
giving
it
a
bit
of
its
own
identity
will
help
manage
that
complexity
by
enforcing
the
separation
of
concerns
and
and
therefore
sort
of
allow
us
to
keep
a
grapple
on
things.
So
I
hope
to
write
rfc
about
this
soon,
but
basically
yeah.
B
Like
I'm
fully
aware
the
things
I
want
to
do
add
complexity,
and
therefore
we
need
to
have
some
sort
of
mitigations,
and
the
second
bullet
point
is
basically
my
hopeful
strategy
of
dealing
with
that
and
then
finally
broader
ecosystem.
Because
again,
the
indirect
motivation
with
all
the
stuff
is
to
try
to
find
new,
like-minded
partners
for
nics,
so
we're
not
trying
to
revolutionize
software
by
ourselves.
B
First
thing
here
would
be
to
continue
trying
to
get
people
to
constantly
address
software
in
the
uniform
way.
So
there's
this
sort
of
caching
thing
we've
done
with
ipfs
and
software
heritage
so
far,
but
many
language,
specific
package
managers
might
still
be
hashing,
tar,
balls
and
other
things
that
nyx
can
kind
of
support.
But
it
isn't
really
it's
not
good
for
software
heritage,
it's
not
great
for
us
because
it
closes
off
some
easy
de-dupe
strategies
and
and
and
generally
make
makes
things
less
efficient
as
they
could
be
in
theory.
B
So
I
I
hope
to
try
to
find
one
of
those
language,
specific
package
managers
and
sort
of
pitch
them
on
content.
Address
content
address
your
source
files
in
a
way
that's
compatible
with
next
compatible
software
heritage,
sort
of
here's
a
new
way
to
be
kind
of
a
team
player
which
historically
these
language
specific
pack,
managers
have
not
been
very
good
at,
but
maybe
also
not
knowing
how
to
do
as
part
of
once
you
do.
Those
data
model
changes.
Ipf
support
is
very
easy.
B
So
if
anyone
wants
like
a
cargo
or
package,
creates
the
I
o
package
and
pm
mirror
it's
a
very
easy
once
everything's
constant
dressing,
the
same
way
yeah
overall,
just
for
the
indirect
motivation,
rather
than
contort
ourselves
to
work
with
the
outside
world,
try
to
entice
the
outside
world
and
doing
things
which
are
good
for
them
on
their
own,
but
also
make
it
really
easy
to
integrate
with
us
and
yeah
thanks.
So
much
that's
my
last
slide.
I
see
we
have
a
bunch
of
questions
now,
I'm
happy
to
answer
some.
A
B
That
is
not
something
I
fully
control
go
chime
in
in
the
rfc.
If
that's
something
you
care
about,
I
mean
the
prs
are
open.
I
have
to
fix
the
conflicts
and
stuff,
but
I'm
I'm
ready
to
start
merging
things
whenever
people
approve-
and
you
know,
do
the
code
review,
but
you
know
I
I
I
can't
just
like
unilaterally
like
merge
a
bunch
of
stuff,
of
course,
that.
A
B
Well,
I
there
is
that,
but
I
mean
this:
there
is
like
I:
I've
tried
to
keep
the
architectural
changes
minimal
and
surgical
such
that
you
know,
ipfs
could
even
be
a
nyx
plug-in,
but
the
the
generalizations
you
need
prior
to
ipfs,
especially
on
the
source
side.
Those
are
still
a
serious
amount
of
stuff.
I
mean
it's
only
in
recent
years
that
people
have
sort
of
started
contributing
the
knicks
beyond
elko
in
a
broader
capacity
at
all.
B
So
I
mean
you
know,
I'm
not
going
to
just
pester
him
random
meetings
and
try
to
random
down
this
throat.
Didn't
want
to
do
that
in
2020.
Didn't
want
to
do
that
today,
but
I
I
think
the
rfc
process
is
the
right
way
to
sort
of
build
community
consensus
and
then
and
then
we'll
see
what
he
says.
What
other
people
say.
A
B
Those
are
good
questions,
so
I
I
haven't
checked,
who
has
upgraded
to
the
so
the
band-aid
hardened
shaw
one,
but
I
think
everyone
can
and
should
do
that.
I
know
I
know
git
has
itself.
I
would
sort
of
assume
software
heritage
is
definitely
aware
of
the
issue
and
probably
doing
something
about
it.
Ipfs
also.
B
I
would
think
they
would
have
that
upgrade
too
nyx.
We
we
currently
don't
really
use
shaw,
one
that
much
in
nyx,
so
we
might
have
the
bad
old,
vanilla
version,
but
we
can
do
that
upgrade
also,
I'm
obviously
not
wild
about
shaw,
one
which
is
definitely
end
of
life,
but
I
also
don't
want
to
do
the
classic
xkcd
mistake
of
trying
to
push
my
own
standard,
I'm
very
much
of
the
opinion
meet
people
where
they're
at
which
today
is
get
in
sha
1
and
then
try
to
push
things
forward.
B
So
there
is
for
a
few
years
now
shop,
256,
support
in
git,
but
github
doesn't
support
it
and
nothing
uses
it,
but
we
could
still
our
both
both
us.
This
bridge
ipfess
should
all
be
able
to
support
that
ahead
of
anyone
actually
using
it,
because
it's
a
very
sort
of
parametric
thing
that
all
those
things
already
don't
assume
specific
hashing
strategy,
unlike
old
git,
and
so
it
should
be
easy
to
swap
it
out
and
then
from
there.
B
B
You
can
just
fix
the
the
sort
of
new
school
view
of
the
repo.
It's
only
when
you're
pushing
it
to
repos
that
you
have
to
update
both
versions.
If
you're
trying
to
do
some
sort
of
migration
scheme
and
that's
the
thing
that
hasn't
yet
been
implemented.
As
far
as
I
know,
so,
I
think
we're
kind
of
off
the
hook
there
and
we
can,
you
know,
get
our
house
our
side
of
things
in
order
and
not
worry
so
much
so
yeah.
I
I
mean
I
I
wouldn't.
B
One
hash,
anyways,
there's
already
these
sort
of
man
in
the
middle
style
collision
attack
potential
because,
like
when
you're
doing
the
next
prefetch
get
or
some
other
next
fetch
you're
not
actually
like
checking
at
that
point,
and
did
I
get
the
data
I
want
the
only
source
of
truth.
You
have
is
the
sha
one
and
then
you
write
down
in
our
hash
and
commit
that,
and
so
you
could
have
already
got
those
there's
nothing.
You
can
really
do
about
that.
B
B
Yeah,
that's
that's
why
it's
slow
today,
because
you
have
a
bunch
of
tiny
files
and
it's
not
only
doing
the
round
trip,
but
it's
renegotiating
the
connections.
So
it's
yeah,
the
bridge
is,
is
just
doing
things
in
a
naive
way
to
show
that
the
things
are
interoperable
and
you
have
the
perfect
storm
of
all
those
issues,
but
ipfs
already
totally
solves
that
problem.
There's
both
way.
It
uses
quick
if
possible,
and
so
you
have
great
connection,
reuse
between
sort
of
logically
distinct
requests
and
b.
B
A
B
B
I
don't
remember-
and
I
think
the
the
content
addressing
stuff's
really
good
for
that,
because
the
actual
thing
I
want
to
nail
down
in
these
early
steps
is
not
any
of
these
implementation
details
as
important
that
they
are,
but
the
interface
I'm
presenting
to
the
user
that
I'm
presenting
between
the
systems-
and
that
is
the
high
level
there's
a
content
address,
do
something
with
that
address
everything's
self-verifying
and
that's.
I
think
it's
both
a
nice
interface
and
an
extremely
flexible
one.
B
So
you
can
set
this
up
today,
where
there's
a
clear
weakness
link
and
then
you
can
fix
all
that
stuff
behind
the
scenes
and
anyone
that's
using
the
thing
they
don't
need
to
know
what
sort
of
fancy
fancy
negotiation
is
to
avoid
the
pipelines.
They
don't
need
to
know
what
sort
of
compressing
is
being
done
on
the
fly.
B
All
that
is
implementation,
details
that
aren't
like
shoved
under
the
rug
but
actually
transparent,
and
so
that
that
difference
between,
like
ignoring
complexity,
that
like
does
matter-
and
it
actually
is
a
wholly
separate
knob,
I
think
is-
is
something
I
value
a
lot
and
something,
I
think
will
allow
us
to
very
seamlessly
go
from
an
existing
proof
of
concept
to
like
a
you
know,
slam
dunk
production
system
that,
without
any
like
you
know,
interruptions
or
oh,
we
have
to
like
do
a
bunch
of
breaking
changes.
There.
B
A
Okay,
I
do
not
see
any
questions
really
coming
in
anymore,
unless,
of
course,
my
internet
has
decided
to
drop
all
the
connections
which
I
doubt
so
I
think
I
will
be
wrapping
this
up,
then
so
yeah.
Thank
you
very
much
sean
for
giving
this
amazing
lecture
and
giving
us
an
update
on
nixon
ipvs
and
the
software
heritage,
and
also
the
great
demo
and
yeah
we'll
see
you
soon
and
again.
Thank
you.
B
A
So
that's
yet
another
lecture
that
is
wrapped
up.
There
is
not
yet
a
lecture
scheduled
for
next
week
that
might
change.
We
don't
know
yet,
of
course,
I'll
try
to
keep
you
updated
on
the
relevant
challenge
channels,
not
challenges.
Jesus
now,
of
course
again,
thank
you.
Everyone
for
watching
thanks
to
the
united
foundation,
european
commission,
nexus
foundation
and
tweak
for
making
this
all
happen.
If
you
want
to
ask
john
more
questions
you
can
head
over
to
the
matrix,
which
you
can
see
in
the
banner
right
now
where
to
head
to
and
yeah.