►
From YouTube: This Month in IPFS - Jan 2023
Description
Join Daniel, Developer Advocate for IPFS and guests from the IPFS ecosystem for This Month in IPFS.
00:00:00 - Countdown
00:00:26 - Welcome
00:02:27 - Discordian joins and introduces Disco Chat
00:03:57 - Disco Chat (Demo)
00:05:32 - How Disco Chat works under the hood
00:07:20 - Challenges Discordian faced while building
00:11:27 - What's next for Disco Chat
00:14:47 - David Justice joins
00:15:29 - The Browsers & Platforms team mission
00:17:03 - Some of the ongoing projects David is working on like Durin
00:18:27 - Intro to Pin Tweet to IPFS - The why, and the how
00:20:06 - Pin Tweet to IPFS (Demo)
00:24:27 - WebRecorder and web archiving
00:26:47 - Future plans for David and Pin Tweet to IPFS
00:30:00 - J Chris from web3.storage joins
00:31:08 - What is web3.storage?
00:32:56 - What are UCANs and how they solve distributed authorization?
00:34:11 - Differences between UCANs and Bearer Tokens
00:35:23 - UCANs and DIDs (Decentralized Identifiers), capabilities and user owned data
00:40:00 - Uploading and working with the web3.storage CLI: w3 (Demo)
00:50:00 - What's next for Web3.storage: w3ui, improving storage on Filecoin, and integration with Saturn, Filecoin retrieval network
00:52:00 - Broader updates in the IPFS ecosystem with all guests
00:52:57 - IPFS Community Calendar and all the working groups
00:56:32 - Kubo 0.18 Release: Delegated Routing, DAG-CBOR support in Gateways, and Webtransport
01:02:33 - Bringing IPFS to space with Lockheed Martin
01:05:10 - IPFS Thing
In this community-oriented live stream, we’ll discuss everything happening in the IPFS ecosystem.
In this first episode of the year, we’ll have three special guests:
- Ryan Discordian, Developer Advocate for IPFS, will give a tour of an encrypted peer-to-peer chat app built with IPFS
- David Justice, Engineer on the Browsers & Platforms team, will demo a new Pin Tweet to IPFS and discuss his work making IPFS accessible to more users by applying it to real-world use cases.
- Chris Anderson, Engineer @ web3.storage(https://web3.storage) will give an update on some of the recent releases from Web3.storage and give a demo of w3cli, the web3.storage CLI.
The live stream covers a wide range of topics related to IPFS, including live coding sessions, guest interviews with IPFS contributors and developers, and updates on the latest developments in the IPFS community and working groups.
The live stream will feature Q&A sessions with the audience. It could also include demonstrations of how to use IPFS and how it can be applied in various contexts.
---
Links
- Disco Chat: https://github.com/TheDiscordian/disco-chat/releases
- Pin Tweet to IPFS: https://github.com/meandavejustice/pin-tweet-to-ipfs
- WebRecorder: https://webrecorder.net/
- UCAN Distributed Authorization: https://ucan.xyz/
A
B
If
you
are
new
to
the
ecosystem
or
if
you've
been
in
the
ecosystem
for
a
while,
you
may
have
noticed
how
much
has
been
happening
in
the
last
year
and
now
we're
starting
this
really
exciting,
New
Year
of
2023
and
there's
just
so
much
happening.
There's
so
many
different
working
groups,
there's
so
many
different
apps
that
are
being
built
now
with
ipfs,
and
you
know,
there's
a
broader
sort
of
d-web
movement,
decentralized,
IDs,
there's
just
so
much
to
cover,
and
so
the
idea
is
for
us
to
create
this
space.
B
B
C
Yeah
yeah,
so
I've
been
working
on
a
project
called
disco
chat.
It's
got
some
interesting
features.
It's
a
peer-to-peer
chat
application
that
it
supports,
sending
videos
images.
It
has
full
markdown
support,
emojis
end-un,
encrypted
messages,
mutable
profiles
using
ipfs,
cids
and
ipns
and
honestly
just
a
whole
bunch
of
other
cool
features.
B
C
Yes,
yes,
you
are
so
yeah.
This
is
the
Disco
chat
UI.
It's
currently
in
developments
at
version,
0.2.1
I'm,
actually
not
sure
if
that
version's
out
yet
but
yeah
we're
connected
here.
The
user
list
currently
disappears
once
in
a
while,
but
it's
otherwise
working
we
are
connected.
We
can
send
messages
which
are
the
important
things
yeah.
C
Yeah
and
we
can
send
images,
those
should
work
so
if
I
send
it
on
my
end,
you
should
see
it.
It
just
takes
a
second.
So
what's
happening,
is
it's
adding
the
data
into
a
Kubo
node
in
the
background
getting
the
CID
serializing
it
into
Json,
sending
it
over
and
then
your
clients
deserializing
it
and
sharing
it.
That's
assuming
the
demo
Gods
will
be
kind
and
allow
this
image
to
send,
but
it
doesn't
usually
take
this
long
and.
B
One
of
the
nice
features
in
in
Disco
chat
is
the
fact
that
it's
encrypted
so
you've
actually
implemented
end-to-end
encryption
there
and
you're
doing
like
a
diffie-hellman
key
exchange,
you're
doing
like
a
lot
of
really
cool
stuff
behind
the
scenes.
So
this
is
is
the
end-to-end
encryption.
Is
that
just
for
direct
chats,
because
now
we're
in
a
group
chat
right.
C
Yeah
so
the
way
it
works
is
end,
end
encryption
sort
of
so
you
have
this
drop
down
here.
So
I
can
select
Daniel
2
color,
we're
still
in
the
global
room.
But
if
I
send
a
message
to
you
like
hey
Daniel,
it
encrypts
the
message
and
sends
it
into
the
same
room.
But
it's
set
up
in
a
way
that
other
users
can
see
who
the
message
is
for,
and
they
know
not
to
attempt
to
decrypt
it
because
they
can't
but
effectively
you're
sending
secret
messages
in
a
public
group.
B
Gotcha
gotcha,
so
it's
it's
using
the
same
Pub
sub
channel.
So
this
is
relying
on
Gossip
sub
right.
In
order
to
do
the
sort
of
propagation
would
be
really
interesting
to
see
how
this
plays
when
there's
more
people
joining
very
cool
I'm
really
curious
to
hear
a
little
bit
more.
So
how
did
you
use
ipfs
and
what
are
some
of
like
the
building
blocks
off
this
app,
because
this
is
a
native
app?
Is
that
right,
yeah.
C
C
Yeah,
a
lot
of
people
will
be
familiar
with
those,
so
basically
JavaScript
if
you're
familiar
with
that.
This
will
be
relatively,
hopefully
relatively
easy
to
use
and
understand.
But
what's
Happening
Here
is
we
have
a
library
called
the
Kubo
art,
Kubo,
RPC,
client
I,
believe,
and
that
is
a
JavaScript
library
used
to
connect
to
a
local,
Kubo
node.
C
So
what
disco
chat's
doing?
Is
it
bundles
up?
The
local
Kubo
node
starts
it
up
for
you
in
the
background
and
uses
this
RPC
client
to
communicate
it
with
it.
This
is
also
done
a
little
bit
with
the
help
of
a
rust
Tori
is,
is
built
using
rust
and
I.
Put
some
work
into
exposing
some
of
the
harder
to
find
things
like.
It
sets
a
random
port
to
listen
on
and
then
the
ports
exposed
through
a
JavaScript
callback.
C
So
that
way
you
can
communicate
with
the
Kubo
node
and
if
the
user
already
has
a
Kubo
node
installed,
it
won't
conflict
with
it
yeah,
that's,
basically
how
it
works
like
it
originally
used
jsipfs
and
it
had
a
node
running
in
the
browser.
But
right
now
it's
it's
running
on
desktop,
demonstrating,
like
honestly,
I,
think
the
maxim
of
what
we
can
do
with
ipfs
right
now.
Kubo
is
pretty
full
featured.
B
C
Yeah
yeah
so
I
mentioned
before
that
it
was,
it
was
in
browser
most
of
the
challenges
began
there.
It's
it's
difficult
to
do,
peer-to-peer
things
in
in
a
browser,
because
you
can't
open
your
own
sockets
you're,
mostly
dealing
with
like
web
sockets
or
webrtc,
and
so,
if
you're
using
webrtc,
you
have
to
have
like
a
star
node
which
advertises
the
path
to
connect
to
you,
and
then
you
have
to
you
have
to
connect
to
that
star
node.
C
So
some
people
don't
like
that,
because
that's
automatically
like
a
little
bit
of
centralization
right
there.
But
that's
what
gives
you
direct
browser
to
browser
communication?
That's
a
little
finicky
to
work
with,
and
then
you
have.
You
had
a
relays
via
circuit
relay
V1
and
these
operated
like
turn
nodes.
So
it
would
forward
all
of
the
data.
So
this
this
you,
this
relay
node,
would
really
be
trusting
you
because
you
can
really
do
whatever
you
want
with
it.
C
So
then
I
had
to
move
everything
onto
the
desktop
and
I'd
figure
out
how
to
do
that.
Electrons.
A
popular
solution
right
now
to
have
like
a
web
thing
on
a
desktop,
but
there's
a
lot
of
there's
a
lot
of
negativity
surrounding
electron
from
different
camps,
so
either
it's
too
big
and
too
bloated.
It's
too
Bucky,
which
can
you
can
argue
that.
E
C
A
lot
of
configuration
too,
so
it's
usually
a
configuration
issue
yeah,
so
there
were
and
then
I
guess.
The
final
issue
that
I'd
like
to
bring
up
was
more
ipfs
specific
because
it's
to
do
with
Pub
sub
channels-
and
this
issue
is
not
actually
completely
solved
right
now,
due
to
a
limit
I
think
in
web
views.
B
And
it's
probably
worth
flagging,
so
this
is
actually
an
issue.
So,
when
you're
opening
up
when
you
join
a
pub
sub,
Channel
you're,
essentially
trying
to
find
around
I,
think
it
like
the
pub
sub,
the
gossip
sub
protocol
tries
to
manage
about
I
think
five
to
six
connections
open
for
that
specific
topic.
So
each
topic
basically
multiplies
the
number
of
these
six
connections
that
you
have
open.
Obviously,
if
there's
six
other
peers
connected
to
that
same
topic,
is
that
a
good
way
to
understand
it,
and
is
that
constraint
a
webview
specific
constraint?
C
So
it
is
so
jsipfs
initially
implemented
a
configurable
limit
for
the
six
socket
limit,
which
is
a
usual
thing
in
most
web
browsers.
That's
where
that
limit
comes
from
I'm,
not
entirely
sure
why
they
agreed
on
six
or
how.
But
so
it's
not
a
Tory
limit.
Actually,
if
you
have
a
good
point
where
Kubo
can
actually
handle
a
lot
more
connections
than
just
six
at
once,
and
we're
not
actually
constrained
on
that
end.
C
So
when
we
subscribe
to
a
topic,
you're
right
that
a
bunch
of
connections
open
but
specifically
the
socket
connection
that
we're
worried
about
and
what
hits
our
limit
is
because
we're
using
that
RPC
client
to
talk
with
the
Kubo
node,
we
have
to
actually
have
a
socket
open
at
all
times
when
we
subscribe
and
yeah
it
just
passes
data
as
it
as
it
pleases
through
that
connection.
So
if
we
want
to
be
connected
to
six
rooms,
we
have
to
have
six
topics.
C
Currently,
the
way
disco
chat
works
too,
is
there's
also
a
backlog
Channel,
which
is
a
separate
subscription.
So
when
you
join
a
channel
you're
actually
joining
at
least
two
and
then
any
other
operation,
it
does
like
be
it
like
an
ipns
lookup
or
something
like
that
is
another
socket,
that's
open
for
a
little
bit
so
effectively
the
more
channels
you
join,
the
buggy
or
disco
chat
gets
right
now.
B
C
Yeah,
that's
a
great
question,
so
I've
been
working
on
Disco
chat
for
a
long
time,
and
it's
generally
in
the
back
of
my
mind
in
its
current
iteration
I
would
like
to
see
it
more
cleaned
up,
maybe
tackle
some
of
the
bugs
to
make
the
user
experience
a
little
bit
better
because
in
terms
of
features,
I'm
pretty
happy
with
it.
A
feature
that
is
notably
missing
is
file.
Sharing,
it's
a
bit
strange
that
you
can
share
pretty
much
anything
except
files
and
then
the
killer.
C
C
This
was
kind
of
made
with
a
desktop
UI
in
mind,
but
I
think
would
be
really
cool
if
there
was
a
like,
as
you
mentioned,
a
completely
serverless
totally
distributed
chat
application
that,
even
if
you're
not
100,
guaranteed
to
get
a
message
when
it's
sent
that
eventually
you
will-
and
hopefully
that's
good
enough.
If
people
want
something
totally
serverless.
B
C
I,
just
thought
of
something
and
I
think
it's
because
Jay
Chris
is
here,
but
there
is
another
feature
that
I
was
excited
about
So
currently,
because
everything
is
serverless
and
unless
somebody
trusts
you
in
which
you'll
automatically
store
some
of
their
profile.
Information
stuff
like
that,
but
basically
more
or
less.
When
you
turn
off
your
node,
your
data
is
gone.
C
I
want
to
add
a
web3.
storage
feature
where
you
can
move
your
ipns
keys
onto
web3.
storage
if
you
want
but
also
store
some
of
your
data
backed
up
on
web3.
storage,
maybe
with
like
a
convenient
little
button
that
pops
up
yeah
those
will.
Those
will
be
a
couple
more
simple
features
that
I
think
will
be
coming
sooner.
B
Cool
very
cool
and
I
think
it's
also
worth
pointing
out
we're
going
to
get
to
this
later
in
this
show
some
of
the
new
features
in
the
latest
Kubo
release,
one
of
them
being
a
new
protocol
and
and
this
sort
of
touches
a
bit
of
the
work
that
you
were
doing
prior
to
this
trying
to
get
a
chat
app
without
any
sort
of
central
servers
in
the
browser
and
some
of
the
challenges
that
you
hit
there.
So
anyways
we'll
get
to
that
anything
else.
B
B
B
You
for
joining
us
today,
so
you're
working
on
the
browsers
and
platforms
team
along
with
Dietrich
and
a
few
others.
Can
you
tell
me
a
little
bit
about
the
work
that
you're
doing
as
a
team,
because
what
you're
going
to
show
us
today
is
is
one
part
but
there's
a
lot
of
like
other
pieces
that
are
part
of
your
team's
work
right,
yeah,
absolutely.
F
Some
of
these,
like
Integrations,
that
we're
trying
to
get
into
are
open
to
full
ipfs
nodes
like
Brave
browser.
Well,
some
of
them
are
see
it
as
like
a
harder
cell
or
a
larger,
like
technological
feat,
to
just
to
integrate
it
in
some
of
those
cases.
We
try
and
get
some
of
the
cork
principles
of
ipfs
into
them
as
like
a
way
to
get.
You
know
open
up
these
doors,
some
of
that's
like
content
addressing
cryptographically
verified
data.
F
Sometimes
we
can
start
with
some
of
these
smaller,
like
building
blocks
and
Edge
our
way
in
to
getting
decentralized
technology,
and
some
of
this
can
look
like
bringing
these
tools
to
the
web
platform
itself
and
in
web
specs.
So
developers
can
deploy
to
their
users
using
mainstream
web
browsers
and
then
we'll
be
creating
interoperable
specifications
to
make
those
easier
to
implement
across
all
platforms
and
applications.
As
much
as
we
can.
F
Yeah
so
I've
been
working
on
a
couple
different
things:
I
I
made
like
a
little
list,
so
I
can
kind
of
drop
a
couple
different
projects
and
then
I'll
kind
of
end
with,
like
the
pin
Tweet
stuff,
just
to
give
like
an
overview
of
some.
Some
of
the
other
projects
we're
working
on
too
so
one
of
the
main
ones
I
work
on
is
called
Duran.
F
It's
an
application
that
makes
viewing
and
uploading
content
on
the
ipfs
network
a
lot
easier
on
mobile
devices,
we're
also
using
it
as
like
a
testing
ground
where
we'll
be
able
to
try
out
ideas
around
file,
sharing
verifiable
content
over
peer-to-peer
transports.
Exploring
connectivity
of
our
users,
social
graphs,
which
is
probably
gonna,
be
like
contacts
API
we've
been
working
with
a
company
called
trigram
with
that
one
too
and
they've
been
really
helpful.
F
Another
thing
that
we're
probably
going
to
be
starting
up
soon
is
I'm
working
on
a
new
blogging
framework,
so
we're
basically
building
a
team
blog
for
the
browsers
platforms
team
what's
interesting
about
it,
though,
is
it
uses
all
ipfs
technology
and
protocol
Labs
types
of
things,
and
then
we're
also
hopefully
going
to
be
running
a
smart
contract
on
fvm
to
connect
all
these
pieces
together.
So
it's
going
to
be
a
decentralized
Blog.
Think
what's
interesting
about!
F
Obviously,
we'll
do
some
more
like
announcements
and
things
around
that
in
a
couple
months,
once
we
get
like
some
MVPs
going
there
and
then
finally
pin
tweets
ipfs
what
this
is
about.
It's
a
browser
extension
and
the
goal
is
to
help
users
pin
web
Archives
of
Twitter
content
ipfs.
So
they
can
maintain
a
copy
if
it
gets
censored
by
the
platform
deleted
by
itself
or
anything
like
that.
F
F
Was
this
screenshot
modified
things
like
that,
so
people
want
to
be
able
to
verify
that
themselves.
So
we
think
that
maybe
we
could
expand
these
this.
These
types
of
use
cases
to
have
this
verifiable
embedded
web
archives
and
get
them
more
into
like
end
users,
hands
and
also
publishing
platforms,
and
so
people
can
have
this
longevity
and
just
more
credibility
across.
B
F
B
D
F
F
As
you
can
see,
we
embed
a
button
here
so
that
it's
we
get
really
quick
access
for
a
user
to
go
ahead
and
click
this
and
pin
it
directly
to
ibfs.
Since
we're
on
a
Twitter
permalink
page,
we
can
actually
just
clicked
our
badge.
That's
added
to
the
browser
for
us
and
we'll
go
ahead
and
get
redirected.
This
is
a
tool
from
the
web
recorder
team
that
they
made
special
for
this
project,
called
save
Tweet,
now
utilizes
their
Express
tool,
where
they
archive
web
pages
in
the
browser
specifically
for
tweets
here.
F
So
what
they
do
what's
actually
happening
here
is
they're,
going
to
pull
that
tweet
down,
put
it
in
its
embedded
form
and
then
turned
it
into
a
web
archive
zip
file
and
then
upload
that
to
web3.
storage
link.
So
now
that
we
have
our
link,
we
have
a
little
info
about
the
archive.
We
can
click
that
and
it'll
navigate
us
to
our
embedded
copy
of
the
archive.
F
F
You
have
the
public
key,
some
other
validation
information
and
another
link
to
download
the
whole
archive
there
after
this
has
been
uploaded
to
web3.
storage
link.
We
can
actually
see
that
we
have
a
panel
that
pops
down
here
as
long
as
you're,
not
on
a
permalink
page,
where
we
have
some
info
about
the
tweet
and
links
to
it
and
we
can
copy
the
link
the
link
straight
out
of
there.
All
of
this
data
is
shared
locally,
so
you
don't
need
internet
connection
for
it
and
you
still
have
access
to
your
archive
tweets.
F
B
Oh,
that
was
great
David
I,
think
that
was
a
pretty
good
run
of
the
code.
Is
there
anything
else
you
want
to
share
by
the
way?
I
just
dropped
a
link
in
the
chat
if
you're
watching
now,
if
you
want
to
check
it
out,
there's
a
link
to
the
open
source,
repo
and
there's
also
links
to
the
different
app
stores
for
Chrome
and
for
Microsoft
Edge
I
believe
it
is
right
and.
F
Right
yeah,
there's
been
I'm
sure,
like
anybody,
that's
familiar
with
web
extension.
Stuff
is
familiar
with
manifest
V3
and
how
there's
been
like
a
lot
of
confusing
things
going
back
and
forth
between
the
browsers
with
that,
so
can't
fault
Firefox
for
yeah,
it's
being
difficult
to
implement
there
right
now,
but
because
it's
definitely
not
their
fault,
but
we
are
getting
really
close
to
being
able
to
add
it
to
Firefox.
F
F
They
collaborated
with
us
heavy
on
this
one
and
on
other
projects,
also
just
to
tell
a
little
bit
about
them.
They
build
these
like
web
archiving
tools
that
are
user
driven
that
are
mostly
in
browser
and
like
all
around,
like
the
user
being
able
to
actually
archive
their
own
content
on
their
own
terms,
and
they
they
really
share.
F
Like
our
mission
with
that,
which
is
just
like
user
agency,
should
be
one
of
the
top
focuses
right,
so
they
made
this
special
version
of
save
Tweet
now
for
us-
and
it's
just
been
like
super
helpful
and
basically
made
my
job
on
this.
Writing
the
rest
of
the
extension
a
whole
lot
easier.
So
they're
definitely
like
a
really
incredible
team.
To
take
a
look
at
I.
Can
I
don't
have
a
link
accessible
right
off
the
bat
I
think
it's
webrecorder.io,
but
I'll
drop
it
in
the
chat
like
right
after.
B
And
I
wanted
to
ask
you.
So
as
far
as
my
understanding
goes
of
web
recorder,
web
recorder
is
a
general
purpose
tool
that
anyone
can
use
it's
open
source
too,
and
it
can
be
used
just
to
Archive
pages
on
the
web
and
sort
of
to
get
a
downloadable
version
of
them.
That
is
viewable
without
internet
connection
and
that
can
be
sort
of
persisted
on
any
sort
of
external
hard
drive,
Nas
or
even
in
the
cloud.
Is
that
a
good
model
for
that.
F
F
This
is
insane
and
I
opened
up
the
network
Tab
and
everything's
replaying
like
really
Blown
Away
by
just
how,
like
all
encapsulating,
it
is,
and
it
totally
works
like
that.
Another
interesting
thing
about
them.
While
it
is
totally
available
for
end
users,
they've
been
working
more
and
more
with
libraries,
And
archiving
and
other
archivists,
which
is
just
like
a
super
important
thing
for
our
world
right
now.
So
I
really
appreciate
that
and
want
to
give
them
props
for
like
working
with
all
these
archivists.
So.
F
Sure
I
mean
excited
to
start
this
blogging
stuff.
We
have
some
things
coming
up
with:
pin
tweet,
mostly
just
like
some
little
UI
things
we
just
want
to
make
it
as
smooth
as
possible.
Easier
I
do
want
to
add
a
little
bit
more
support
for
using
different,
pinning
Services,
bringing
your
own
web3.
storage
account
to
the
pinning
service,
because
people
want
to
organize
their
stuff
in
every
way
that
they
want
to,
and
they
should
have
the
total
right
for
that
right.
F
Like
we're
talking
about
user
agency,
I
also
would
love
to
explore
a
little
bit
more
for
like
connecting
to
local
nodes.
There's
a
lot
there
there's
a
whole
lot
that
we
can
get
going
here,
and
maybe
eventually
connectivity
with
Duran
we'll
see
I
mean
we're
just
going
to
kind
of
keep
pushing
all
these
things
at
once
and
seeing
where
we
can
connect
and
meet.
You
know
so.
B
Yeah,
so
right
now,
it's
basically
using
one
account
right
of
web3
storage
and
one
you
mentioned,
of
bringing
your
own
account
and
using
multiple
pinning
Services.
The
idea
there
is
that
you
can
actually
sort
of
pin
it
to
your
own
account,
rather
than
a
shared
account
that
is
sort
of
controlled
by
by
the
plugin
right
or.
B
Yeah,
even
though
you
get
this
interoperability
with
ipfs
that
even
right
now,
once
it's
sort
of
uploaded,
you
can
go
and
use.
You
know
the
pinning
API
spec
or
you
can
just
go
to
your
painting
service
and
you
can
or
run
on
your
node.
You
can
go
and
you
can
actually
pin
that
said
and
you'll
be
able
to
replicate
it
from
the
network.
Exactly.
F
B
B
F
F
Probably
in
the
I'm
not
like
super
super
online.
These
days
like
as
far
as
my
accessibility,
but
my
GitHub
mean
Dave
Justice
I'm
on
the
file
coin,
slack
day
of
Justice,
usually
in
the
browser
and
platforms,
Channel
browser's
standards,
email
is
work
at
justice.engineering,
so
those
are
probably
like
the
three
easiest
ways
to
get
in
touch
with
me.
B
B
D
B
D
E
E
Yeah
so
ucan.xyz
and
I'll
show
this
site
here
in
a
second
is
a
distributed
authorization
protocol.
You
can
think
about
it
as
solving
the
problems
with
Bearer
tokens,
so
the
problems
with
fairer
tokens
all
come
from
the
fact
that,
while
they're
cryptographically
side
by
the
server,
so
the
server
knows
they're
not
tampered
with,
they
can
easily
be
you
know,
copied
or
stolen
and
replay
attacks
and
all
those
problems
you
know
come
from
that.
E
So
what
ucans
are
is
taking
that
idea
of
cryptographic
signing
but
extending
it
also
to
the
client,
which
depends
on
the
client
having
a
robust
cryptographic,
key
situation
which
all
of
a
sudden
you
know
in
the
last
few
years
that
got
easy.
So
you
cans
are
kind
of
the
right
thing
for
the
times
to
distribute
capabilities
and
invocations
across
the
distributed.
Network,
where
you
know
like
a
bearer
token
getting
stolen,
is
a
problem
you
can
is
designed
to
be
safe
to
store
them
forward.
E
It's
broader
than
that,
so
it
kind
of
doesn't
matter
these
days,
how
you
authenticate
into
one
of
these
microservices
applications.
Then,
when
your
API
call
goes
out-
and
it
starts,
you
know
going
through
the
tree
of
microservices-
that
it
takes
to
compose
the
result.
It's
going
to
send
you
know
different
kind
of
you
know:
verification
validation,
tokens
through
with
it
and
these
days,
because
those
like
are
meant
to
be
the
use
for
the
length
of
the
session.
B
And
I'm
curious.
So
how
does
this
relate
to
a
decentralized
ID?
Because
you
you
mentioned
that
all
of
this
relies
on?
Basically
the
client,
like
the
user
having
some
cryptographic
sort
of
identity,
which
he
controls
right,
rather
than
some
kind
of
like
externally
owned
one.
So
how
does
this
relate
to
decentralized,
IDs
and
dids,
which
is
an
actual
spec
that
specifies
these
decentralized
identifiers.
E
So
did
is
mapped
to
a
whole
bunch
of
the
objects
in
our
domain
model.
They
map
to
agents
and
spaces,
and
so
both
of
those
correspond
to
a
public-private
key
pair
and
the
important
thing
about
using
dids
to
address
that
stuff
is.
It
allows
us
to
rotate
the
key
pair
over
time
for
security,
so
the
actual
cryptographic
identity,
that's
required
to
get
into
this
world
is
very
slim
right.
You
just
need
to
have
some
kind
of
safe
key
custody
which
it
turns
out
that
indexeddb.
You
know.
E
Local
storage
has
a
non-extractable
key
pair
data
type,
so
we
can
actually
just
manage
a
bunch
of
keys
in
the
local
index
DB
in
the
browser,
and
what
this
means
is
that,
like,
if
you're
in
a
traditional
web,
2
Style
app-
and
you
already
have
authenticated
users-
and
you
just
want
to
use
web3.
storage-
you
know
either
via
the
client
which
I'll
show
in
a
in
it
or
via
the
you
know-
components
the
UI
libraries.
E
You
can
link
that
you
know
our
library
in
the
client
which
has
that
private
key
to
your
existing
session
and
start
doing
uploads
right
away
and
the
user
doesn't
see
anything
it's
completely
headless.
They
don't
have
to
log
in
they
don't
have
to
know.
Web3
storage
is
there,
so
it
totally
fits
into
your
existing
identity
system
on
a
web
2
app,
if
you
want
it
to,
but
because
it's
based
on
these
public
private
key
pairs,
you
can
do
it
in
a
more
decentralized
user-owned
Manner
and
that's
the
default
when
you
use
our
UI
component.
E
You
know
they're
creating
a
fresh
app,
then
the
space,
the
uploads
are
like
owned
by
the
user
and
the
big
end
result.
I.
Think
of
that
is
that
you
can
have
apps
that
go
viral
get
super
popular
and
the
developer
is
not
on
the
hook.
For
a
huge
bill
it
can
be,
the
cost
is
distributed
across
all
the
users,
so
we
think
that'll
change.
What
apps
look
like
in
the
long
term,
so.
B
If
I
understood
you
correctly,
one
of
the
big
benefits
that
you
can
do
with
these
Yukons
is
that
you
end
with
web
3
storage
that
supports
them
now
is
you
can
build
an
app
where,
instead
of
you,
the
app
developer,
having
this
like
AWS
account
or
a
Google
Cloud
account
or
whatnot?
And
then
you
know,
you
basically
have
your
token
and
you
have
your
back
end
then
right,
you
know
classical
kind
of
like
three-tier,
app
or
whatever
a
serverless
function.
B
That
has
a
secret
with
the
token
right
and
then
that
token
is
used
to
then
upload
to
your
S3
account
or
whatnot.
Then,
instead
of
this
whole
model,
the
user
actually
is
bringing
his
own
kind
of
like
storage
credentials
and
those
might
be
an
account
on
web3
storage
or
they
might
be
it's
again.
It's
all
Open
Standards,
so
you
know
tomorrow
anyone
could
go
and
start
a
competing
service
with
web
3
storage
that
as
long
as
they
support
you
can't
and
they
support
these
standard
apis.
B
E
Exactly
and
there
will
be
in
the
ecosystem
of
ucan
services,
other
providers
of
the
same
capability
right
now
we're
a
storage
capability
provider,
but
you
could
have
compute
capability
for
running
a
wasm
or
you
know
a
JavaScript
block.
You
could
have
like
a
video
transcode
capability
and
as
long
as
folks
are
using
the
same
signatures
for
those
you
can
invocations,
then
you'll
be
able
to
swap
out
service
providers
as
an
end
user.
B
E
B
E
E
So
if
I
worked
to
upload
this
directory
of
files,
it'll
go
into
Myspace
and
then
like
90
of
the
time
users
don't
need
to
know
what
any
of
this
is
as
a
developer,
you
might
want
to
you
know
know
the
difference
between
this
basically
corresponds
to
your
app
and
all
the
you
know
spaces
that
the
users
are
bringing
to
the
app.
But
you
don't
even
need
to
know
that,
so
there
is
a
ton
of
flexibility
in
here
with
delegations.
E
E
B
E
And
so
yeah
those
are
uploading
and
back
to
some
of
the
verifiability
that
we
heard
about
in
the
earlier
conversations,
the
CID
that
you
see
here
is
generated
locally
based
on
the
data
in
that
directory.
This
is
for
the
car
file,
which
is
a
bag
of
blocks.
It's
a
transport
mechanism
for
ipfs
blocks
and
what's
cool
about
the
way
we
manage
this?
Is
you
get
this
CID
before
the
upload
starts,
and
that
allows
you
to
do
things
like
enqueue,
an
Integrity
check
elsewhere
in
your
system,
while
the
upload's
still
processing
Etc?
B
Maybe
you
can
verify
this
my
understanding
of
a
car
file
that
it's
like
a
tar
file
or
like
a
zip
file
but
for
Content
addressed
data,
so
it's
kind
of
like
you
package
up
all
of
these
files,
and
you
already
know
this
it
and
you
can
do
this
on
the
client
side,
irrespective
of
the
network,
so
even
if
you're
in
Cuba,
somewhere
with
sitting
with
your
laptop,
you
can
actually
create
all
of
these
content
addressed
car
files.
You
can
know
the
sets
for
them
and
you
can
share
them
using
USB
sticks
or
whatnot.
E
A
car
file
is
a
bag
of
blocks
where,
like
what
you're
used
to
in
an
ipfs
address,
is
a
block.
So
one
cool
way
to
think
about
what
you
could
use
it,
for
is
like
say
you
did
a
build
on
your
front
end
app,
and
now
you
have
an
HTML
directory.
That's
your
app
deploy!
You
could
put
that
into
a
car
file,
and
then
you
know
that
any
ipfs
node
that
you
ship
that
car
file
to
will
have
everything
that
it
needs
in
order
to
render
that
application.
E
So
it's
it's
all
the
blocks
you
need
for
something
all
together
and
that
leads
to
car
transactions,
which
are
the
way
that
you
work
with
like
raw
ipld
graphs
and
applications
like
you
saw
in
that
chat
app
earlier.
What
you
can
do,
if
say,
you're,
extending
a
b
tree
to
add
a
new
entry
to
you
know
a
chat,
log
or
a
photo
gallery
or
something,
and
then
you're
also.
You
know
at
the
same
time,
maybe
adding
a
comment
to
go
along
with
that
entry
and
updating
a
counter
somewhere
else
on
the
page.
E
You
know
service
they
can
make
those
car
files
available
over
the
protocol.
Like
web3
storage,
does
and
you'll
have
your
you
know:
transactions
available
for
the
other
application
users
I
see.
If,
if
your
database
geek,
you
notice
I
skipped
over
the
part
where
we
decide
which
transaction
wins,
and
so
that's
more
of
an
ipnsw3
name,
question
which
you
know
maybe
we
punt
on
for
now,
and
let
the
let
the
experts
like.
E
We
got
these
uploads
in
there
if
I
copy
this
URL.
It
should
be
fetchable
over
here
on
the
Gateway
and
while
we're
in
the
browser
I'll
show
you
know
the
other
side
of
this
I'll
just
get
this
load
started
up,
but
if
I
go
to
the
ucan
website,
you
can
see
that
it's
going
to
be
familiar.
It
has
a
JWT
encoding.
It
also
has
an
ipld
encoding,
so
you
can
use
it
in
your
existing
tooling,
but
it
has.
E
E
D
E
So
back
over
to
the
UI
components
and
the
reason
I
started
with
ucan
and
then
brought
these
up
is
because
they
make
it
so
that
you
can
use
this.
You
can
stuff
without
even
knowing
it
they're
designed
for
you
just
want
to
get
the
job
done.
You
want
to
win
the
hackathon,
so
you're,
going
to
put
an
uploader
into
your
app
by
you,
know,
copy
and
pasting
this
code
essentially,
and
those
use
you
can
by
default
and
get
you
logged
in.
E
E
A
E
B
I
see
so,
if
you
are
now
sort
of
starting
a
nap
that
needs
storage,
and
you
want
to
sort
of
explore
this
whole
idea
of
like
building
it
in
a
way
where
the
users
own
their
data.
They
might
be
interested
both
in
the
UI
components
and
then
the
CLI.
What
is
the
CLI
sort
of
useful?
Is
it
mostly
for,
like
the
development
phases
it
just
kind
of
like
the
S3
CLI,
where
you're
just
kind
of
like
doing
things
quickly
from
your
terminal
as
you're
developing.
E
It's
meant
for
that
and
then
I
think
it's
gonna
be.
You
know,
naturally
a
little
bit
easier
to
work
with
doing
like
a
10K,
nft
drop
or
other
kind
of
large
uploads.
Both
of
these
are
going
to
intelligently
restart
your
upload.
If
something
happens
in
the
middle
and
you've,
gotta
pick
it
up
where
it
left
off,
but
people
just
like
working
with
big
files
on
the
command
line.
B
E
E
I
hope
that
people
go
out
and
write
a
bunch
of
apps
and
you
know
upload
a
ton
of
data
I
think
that
you
know
there's
so
much
low
hanging
fruit,
especially
in
verifiable
data
like
doing
things
like
a
verified
chat,
GPT
uploader.
If
you
look
on
the
web3
storage
blog,
you
can
see
that
we
did
an
uploader
for
stable
diffusion
that
includes
the
random
seed
and
all
the
prompt
metadata
to
make
it
easy
to
regenerate
and
archive
all
that
stuff.
E
B
Let's
see
look
at,
can
we
bring
discordian
back
on
yeah,
let's
see
how
long
we
can
get
you
for
okay,
so
I
just
want
to
share
some
stuff.
Thank
you
all.
By
the
way
for
joining
back,
we
have
a
new
community
calendar.
Have
you
guys
seen
it
you
can
find
it
at
AP
ipfs.fyi
calendar
I'm,
going
to
drop
a
link
to
that?
That's
not
the
one.
B
B
B
B
C
That
is
right,
yeah
I
everybody's
welcome,
really
what
we
do
is
we
just
hang
out.
Sometimes
people
have
new
projects,
they
want
to
talk
about.
We
listen
to
their
projects
or
they'll
talk
about
what
grants
they're
going
for
and
they
want
some
advice
or
it's.
It's
really
just
an
hour
of
hanging
out
with
people
interested
in
web
3
distributed
computing
in
general.
It's
a
lot
of
fun.
B
B
C
B
Cool
I'll
drop
a
link
to
that
in
the
chat
be
sure
to
check
it
out
anything
else.
Yeah
we
have
the
probe
lab
office
hours.
Problab
is
the
org
that
is
doing
a
lot
of
the
research
and
the
network
measurements
so
they're
like
really
analyzing
the
ipfs,
DHD
and
they're.
Also
publishing
all
of
this
data
onto
GitHub,
actually
I,
maybe
I
can
find
the
GitHub
program.
I
can't
remember
where
it
was
anyways
I'll
try
to
find
the
oh
there
we
go.
B
Really
really
interesting
stats
there
that
you
can
look
at
I'll,
also
drop
that
in
the
chat
and
there's
a
new
release
of
Kubo,
so
I
spoke
about.
Where
do
we
have
Kubo
0.18
just
went
out,
I
had
a
chance
to
take
it
for
a
spin.
Yesterday,
specifically
I
was
so
there's
a
couple
of
major
highlights
here.
There's
the
new
interplanetary
Network
index
on.
B
So
this
is
one
of
sort
of
the
layers
that
is
creating
interoperability
between
ipfs
and
filecoin,
and
the
idea
there
is
that
you
have
this:
basically
a
delegated
routing
protocol.
So
one
of
the
major
things
that
ipfs
does
is
it
sort
of
like
helps.
You
find
the
location
of
your
content,
and
you
know
we.
We
talk
a
lot
about
content
addressing
in
the
ipfs
world,
but
even
if
you're
doing
content
addressing
when
you're
fetching
something
you
still
have
to
fetch
it
from
a
location
in
ipfs.
B
All
of
the
data
that
is
being
stored
on
the
filecoin
network,
and
so
now
we're
like
starting
to
see
a
lot
of
this
interoperability
between
filecoin
and
in
ipfs,
and
this
sort
of
like
is
a
bit
of
a
callback
to
to
what
Jay
Chris
was
mentioning
with
some
of
the
work
they're
doing
to
kind
of
like
streamline
the
deal
making
process
when
you
upload
to
web3
storage
in
filecoin
is.
Is
that
a
good
way
to
like
think
about
it?
Jay
Chris.
E
B
B
Now
the
main
feature
that
I
wanted
to
mention
is
support
for
web
transport.
Web
transport
is
new
protocol
that
is
supported
by
browser.
So
it's
an
actual
specification,
it's
already
implemented
by
I'm
trying
to
find
yeah.
So
it's
sort
of
specified
by
the
w3c
and
I
believe
that
Chrome
already
has
initial
support
for
this,
based
on
like
a
a
draft
of
the
spec,
and
the
cool
part
here
is
that
it's
built
on
top
of
quick.
B
Is
that
it?
It
means
that
the
network,
the
ipfs
network,
is
no
longer
going
to
be
as
segmented
or
fragmented
as
it
used
to
be,
because
right
now,
if
you're
working
in
a
browser,
right
and
I
can
see
discordians
already
happy
about
this.
If
you're
in
a
browser-
and
you
want
to
connect
to
a
a
an
ipfs
node
like
a
Kubo
node,
then
essentially
you're
constrained
by
the
protocols
that
the
browser
gives
you
websockets
I
mean
HTTP
requests.
B
B
That
is
happening
here,
and
this
is
done
in
cooperation
with
Lockheed
Martin
and
they're,
actually
planning
to
bring
this
work
on
ipfs
onto
their
self-funded
lm400,
which
is
like
a
software
device,
a
defined
satellite
about
the
size
of
a
fridge
and
that's
going
to
be
running
a
some
implementation
of
ipfs,
which
is
open
source
and
it's
written
mostly
in
Rust.
So
I'll
drop
a
link
to
that
and
I
see
that
discordian
quick
is
so
awesome
exceeded
my
expectations.
B
C
Oh
no
I'm
I'm
just
still
happy
about
quick.
Since
the
moment
it
came
out,
I
thought
TCP
was
like
great,
but
UDP
was
much
faster
and
I
thought
there
must
be
something
better.
The
quick
came
out
and
I'm
still
just
just
reel
in
by
how
awesome
it
is
yeah,
I
didn't
have
anything
too
specific
I
was
mostly
just
listening
to
everything.
You
said
it's
really
easy
to
listen
to
you
talk,
especially
what
it's
about
things.
I'm,
really
excited
about.
C
B
B
Okay,
I
probably
misspelled
that
anyways
we'll
drop
a
link
if
someone
finds
it
final
thing,
I
wanted
to
mention
was
ipfs
things.
So
ipfs
thing
is
an
event
that
is
mostly
focused
on
the
implementer
community
of
ipfs,
and
so
that's
going
to
be
taking
place
in
Brussels
and
we've
already
opened
up
the
pre-registration.
The
dates
for
this
are
15th
till
the
19th
of
April.
B
Right
so
there's
your
chance:
if
you're
working
on
an
ipfs
implementation,
there's
your
chance
to
meet
David
in
person
anyways,
you
can
find
the
link
to
that
in
the
community
calendar
and
with
that
I
think
it's
about
time
for
us
to
wrap
up
so
if
you've
joined
us.
Thank
you
for
joining
today
on
this
first
episode,
we'll
be
back
next
month
and
anything
else.
You
want
to
share
J,
Chris,
David
and
discordian.
Thank
you
by
the
way
for
joining
once
again.