►
From YouTube: IPFS Pinning API - Juan Benet
Description
In this presentation, IPFS creator Juan Benet discusses current and potential pinning use cases and how a standardized IPFS Pinning API could meet these envisioned needs.
Learn more about Pinning Services API at https://github.com/ipfs/pinning-services-api-spec
Read more about the inaugural IPFS Pinning Summit on the website: https://ipfspinningsummit.com/
For more information on IPFS
- visit the project website: https://ipfs.io
- or follow IPFS on Twitter: https://twitter.com/IPFS
Sign up to get IPFS news, including releases, ecosystem updates, and community announcements in your inbox, each Tuesday: http://eepurl.com/gL2Pi5
For more information on Filecoin
- visit the project website: https://filecoin.io/
- or follow Filecoin on Twitter: https://twitter.com/Filecoin
Get Filecoin community news and announcements in your inbox, monthly: http://eepurl.com/gbfn1n
A
This
is
a
preview
of
a
painting
API
that
that
I've
been
working
on
that
it's
kind
of
picking
up
a
lot
of
work
that
that
was
done
by
by
a
number
of
folks
in
the
last
few
last
few
months
and
kind
of
it's
a
goal
to
kind
of
land
really
settle
on
it
on
the
API.
That's
working
well
enough
for
most
of
our
use
cases
and
just
ship.
A
It
already
now
there's
a
lot
of
opportunities
for
four
different
products
in
the
ffs
landscape
to
to
leverage
this
kind
of
a
pinning
API,
so
I
want
to
kind
of
use.
This
talk
to
give
a
bit
of
the
motivation
for
what
the
spinning
API
came
from
walkthrough
a
bit
of
the
work
that
was
done
before
on
kind
of
fleshing.
This
out
talk
a
bit
about
the
scope
of
the
problem.
It
turns
out
to
be
a
very,
very
tricky
and
thorny
problem.
A
Maybe
talk
a
little
bit
about
some
interface
wishes
that
that
I've
been
collecting
from
from
a
number
of
folks
across
the
iphone's
ecosystem
and
then
talk
about
kind
of
the
roadmap
going
forward
in
in
in
terms
of
the
kind
of
proposed
API
changes
for
the
pinning
API.
So
this
this
can
be
something
pretty
significant
and
impactful
long
term,
but
this
change
is
gonna.
Take
a
bit
of
a
while.
It's
going
to
be
staged
and
faced
so
you
know
at
the
very
beginning,
nothing
is
gonna.
A
Alright,
let's
talk
about
motivation,
so
the
this
is
kind
of
a
long-standing
issue.
A
lot.
A
lot
of
the
spinning
services
are
familiar
with
this,
where,
where
there's
kind
of
a
goal
of
being
able
to
to
use
the
same
the
same
API
because
part
users
and
applications
having
to
be
built
against
one
API,
then
find
it
hard
to
differentially
switch
to
a
better
service
in
another
way.
So
there's
kind
of
like
an
API
lock
in
there.
A
That's
that
some
potentially
may
be
benefiting
one
party,
but
it
definitely
hurts
everybody
else
in
ecosystem
and
there's
also
other
benefits.
Where
there's
a
lot
of
tools
that
end
up
having
to
be
written
for
one
pending
service
and
another
pinning
service
would
like
to
use
them,
but
now
the
because
the
IP
is
not
the
same,
then
then
things
don't
quite
work.
So
this
is
clearly
a
case
where
having
a
standardised
common
API
would
be
ideal,
especially
for
any
kind
of
tooling.
A
Around
pin
sets
that
that
is
just
fully
open
source,
so
anything
that
I'm
that
it
that
is
not
related
to
a
service
dealing
with
pin
sets
would
love
to
be
able
to
use
kind
of
some
standard
standard
tooling.
It's
also
the
case
that
ipfs
cluster
needed
something
like
this
and
that's.
The
cluster
team
came
up
with
with
a
version
of
this,
of
this
pinning
API
that
will
describe.
In
fact,
they
did
most
of
the
work
that
met
here.
A
So
this
is
mostly
trying
to
kind
of
close
some
of
those
conversations
and
then
get
to
the
next
next
step,
I
like
to
flag
that
applications
like
desktop
and
companion
need
this
kind
of
thing,
you'll
hear
more
from
Molly
later
on
about
how
this
kind
of
API
can
be
used
in
in
products
to
make
the
experience
of
users
much
much
better
better
and
gave
create
a
bunch
of
opportunities
for
pinning
services
that
weren't
there
before
so.
There's
a
there's
a
lot,
an
issue
on
github.
A
You
can
go
and
check
out
and
read
where
most
of
the
work
around
this
API
was
done
and
there's
a
really
good
conversation.
Looking
through
a
whole,
you
know
different
different
set
of
different
set
of
like
constraints
front
around
the
API,
and
this
just
picks
up
from
for
most
of
the
work
there.
So
big
shout
out
to
to
Adrienne
who
did
most
of
this
and
a
number
of
other
folks?
A
So
there's
a
link
in
that
issue
too,
to
this
Steiger,
API
and-
and
this
has
most
of
the
of
the
feel
for
for
one
of
the
proposals
that
I
want
to
move
forward
today
and
you
can
go
check
it
out.
It's
kind
of
like
a
rest,
oriented
way
of
just
address
being
able
to
change
pins
in
some
service,
and
the
idea
is
that
it's
kind
of
like
a
standalone
thing
is
very
thin.
A
Unfortunately,
given
given
all
of
the
different
ways
in
which
people
people
use
these
tents
of
api's,
it's
unlikely
that
we're
gonna
find
exactly
one
so
I
think
going
with
with
a
few
flavors
is,
is
the
right.
The
right
thing,
as
I
mentioned
earlier,
you'll
hear
more
formally
later
about
how
how
this
can
be
used
on
a
number
of
number
of
products
and
so
on.
A
So
therefore,
all
of
them
I
want
to
look
a
little
bit
about
the
cluster
use
case,
which
is
that
the
way
that
cluster
manages
pin
sets
is
that
it
sort
of
keeps
say
a
penalty
log
and
uses
distributed,
consensus
to
agree
on
what
has
been
pin
or
what
has
not
been
penned.
And
so
there's
a
cluster
run
second
sentence
process.
It
needs
to
be
wrapped.
A
So
now
it
uses
a
I
think
all
Merkel's
here
duty
to
agree
on
on
the
pins
that
are
added
and
removed
to
the
pencil,
and
so
you
can
think
of
each
one
of
these
entries
as
extending
the
log
and
either
having
an
add
or
remove
of
a
pin
and
that
pin
them
being.
You
know
a
CID
to,
like
a
whole
whole
large
graph.
A
All
of
these
updates,
and
then
reason
about
them
later,
so
the
API
isn't
does
not
so
an
API
that
thought
of
that
would
potentially
use
a
structure,
would
would
offer
the
capabilities
of
looking
at
the
entire
history
of
events,
which,
which
is
a
something
that
a
lot
of
parties
care
about
in
terms
of
pin,
sets
some
parties
care
about.
Just
knowing
that
the
thing
is
pinned
other
parties
care
about,
knowing
exactly
who
pins
something
at
what
point
in
time
and
whether
or
not
it
has
and
when
it
was
on
pin.
A
So
let's
scope
of
the
problem
depending
APR
today,
is
both
kind
of
local
and
remote
there's
a
local
pinning
command
and
then
there's,
of
course,
remote
pinning
services
pinning
and
how
we
do.
It
has
a
bunch
of
implications
and
applications,
because
applications
have
to
tell
ipfs
to
keep
stuff
around
or
applications
have
to.
You
know
hope
that
the
data
that
they
need
is
there.
A
So
at
the
end
of
the
day,
pinning
is
a
very
key
architectural
component
and-
and
today
local
pinning
has
a
few
problems
so,
for
example,
the
way
the
pinning
is
set
up
now,
if
you,
if
you
call
if
two
different
applications,
pin
the
same
the
same
CID,
what
will
happen
is
that
the
first
of
all
succeed,
the
second
one
succeed,
because
it's
already
been
pinned,
but
then,
if
one
of
them
removes
that
remove
the
pin,
it'll
remove
it
for
both.
So
so
this
is
the.
A
But
that
doesn't
mean
you
want
to
serve
it
to
somebody
else
or
you
want
to
pin
something,
but
you
only
want
to
serve
it
to
a
subset
of
users,
and
so
access
control
is
kind
of
tied
to
the
nature
of
the
data
that
that
people
are
asking
to
pin
and
so
there's.
Some
ranges
of
policies
related
to
content
that
are
not
directly
related
to
pinning
but
they're
kind
of
adjacent,
depending
and
so
whatever
solution
ends
up
happening
for
pinning
will
great
form
the
access
control
for
for
content.
A
Similarly,
you
have
the
same
kind
of
effect
on
content,
routing
announcements.
So
today,
ITF
estes
is
a
just
announces,
the
content
that
that
you
add
for
the
most
part.
Unless
you
you
turn
this
off,
but
content
writing
announcements
are
sort
of
like
an
all-or-nothing
thing:
you
either
announcer,
you
don't
announce
and
it
go
nouns.
Then
you
announce
everything
from
the
get-go.
You
know
it
was.
A
It
was
a
goal
to
to
have
policies
eventually,
where
you
you're
able
to
describe
what
you
want
to
announce
and
how
more
carefully
now
the
tooling
to
do
that
and
the
kind
of
edges
of
that
problem
are
pretty
complicated
as
well,
and
so
it's
not
even
now.
It's
not
super
clear
exactly
how
you
would
want
to
do
this.
A
There's
a
few
ideas
floating
around
the
community,
but
but
nothing
concrete
has
emerged
where
we're
clearly,
you
know
we
have
a
great
API
for
for
how
to
how
to
think
about
announcements,
but
again
it's
related
to
pinning
and
it's
adjacent
depending
and
whatever
we
do
with
pinning
is
going
to
end
up
affecting
this.
So
so
it's
useful
to
kind
of
think
about
it
as
part
of
it.
A
So
the
the
key
thing
to
recognize
here
is
is
to
really
break
it
apart
into
different
problems
and
to
phase
it
in
such
in
a
way,
but
also
remember,
these
things
are
very
related,
meaning
that
whatever
we
end
up
doing
for
pinning
is
gonna,
have
implications
for
applications,
services
and
so
on,
all
right.
So
with
that,
although
that
kind
of
caveat
I'll
go
through
some.
A
A
few
wishes
that
for
for
this
API-
and
this
is
these
are
not
just
a
I
just
minded-
this
is
kind
of
collected
from
from
a
number
of
notes
across
the
community.
So
first
off,
pins
should
be
able.
Pins
should
be
a
first-class
object,
so
today,
pins
are
kind
of
as
this
large
pin
set,
but
you
can't
really
refer
to
a
pin
the
same
way.
A
The
same
way
that
you
can
refer
to
say
a
branch
in
or
a
tag
and
get
so
so
it's
clear
that
a
lot
of
interfaces
would
like
pin
to
be
a
first-class
object
and
and
I
love
that
pinning
services
do
this.
So
penny
services
today
treat
pins
as
a
first-class
object,
have
a
bunch
of
metadata
associated
with
pins
and
and
have
sort
of
that.
A
It
should
also
be
the
case
that
pins
should
have
a
unique
handle
to
solve
that
problem
that
we
described
before
around
to
applications
spinning
the
same
thing
and
then
only
one
of
them
removing
it
and
deleting
it
for
the
other
party,
it
pains
had
a
unique
handle
then-
and
you
know,
two
objects
will
be
created
and
each
application
would
be
able
to
remove
that.
Then.
Accordingly,.
A
We
should
also
be
able
to
keep
the
history
of
how
the
pins
have
changes.
So
today,
ipfs
doesn't
do
this
cluster.
Does
it
but
it'd
be
really
really
useful
in
ideas
proper
to
be
able
to
to
understand
how
the
pin
size
changes,
of
course,
that
history
might
need
to
be
garbage
collected
over
time,
so
this
might
be
in
kind
of
a
ref
log
style
thing
or
directly
in
the
data
structure
of
the
pin
set.
A
A
So
that
could
just
be
one
pin
it's
a
pin
that
changes
a
lot
but
but
I,
perhaps
it
could
be,
could
be
one
pin
or
maybe
a
few
likewise
there's
other
applications
that
might
want
to
maybe
keep
track
of
a
data
set
together,
but
wouldn't
want
to
keep
you
know
hundreds
of
pins
separately.
We
just
want
to
have
one
pin
so
it'd
be
ideal.
A
If
these
kinds
of
interfaces
supporter
that
kind
of
thing
now,
the
one
of
the
other
things
is
that
it
would
be
very
useful
for
the
spin
object
to
track
some
metadata
on
pins
when
they
were
created.
Who
created
this,
which
user
or
application
created
a
spin
and
kind
of,
and
so
for
cluster
or
other
use
cases.
What
kind
of
replication
factors
this
would
imply
and
replication
factors
might
mean
you
know,
create
independent
replicas.
It
might
mean
the
Razr
coding
there's
a
whole
host
of
potential
things
there.
So,
ideally
we
should.
A
If
we
gain
the
ability
to
just
assign
some
metadata
on
ten,
then
then
that
should
be.
That
should
be
good
enough
now
for
remote
up
api's
again,
we
also
want
that
pin,
pin
should
be
a
first-class
object.
We
should
be
able
to
individually
paint
on
pit
objects.
We
should
be
able
to
pin
it
on,
pin
groups
of
pins
and
in,
like
the
cluster
use
case,
we
should
be
able
to
follow
a
pin
set
now
it's
worth
noting
that
different
services
will
want
to
do
things
differently.
A
Some
services
are
built
today
in
kind
of
the
individual
pin
on
pin
operation
and
we'll
want
to
continue
doing
that,
and
other
services
will
want
to
kind
of
follow
the
pin
set
type
of
type
of
approach.
So
this
really
suggests
that
the
there
really
are
should
be
to
two
different
porcelains
over
the
same
kind
of
underlying
api.
A
It
should
also
be
noted
that
the
different
services
have
constraints
over
their
authentication,
so
while
many
groups
would
love
to
be
able
to
kind
of
arrive
at
a
single
authentication
system,
that's
actually
basically
impossible
and
different
services
will
require
different
kind
of
authentication
systems.
So
whatever
this
API
does,
it
should
either
have
off
around
it
or
should
just
pass
opaque,
authentication
tokens.
A
This
also
is
relevant
in
terms
of
payments,
so
you
think
of
passing
payments
through
these
authentication
systems,
not
just
not
just
say
token
identifying
a
party
you,
you
might
want
to
pass
an
opaque
payment,
because
this
could
be
a
stripe
thing.
This
could
be
a
cryptocurrency.
This
could
be
all
hosts
of
all
kinds
of
things,
and
so
the
whatever
the
we
do
in
the
API,
it
should
be
compatible
with
all
the
different
altitudes
that
people
use
all
the
different
kind
of
payment
systems
with,
and
you
should
just
have
a
way
of
doing
that.
A
We
should
also
be
able
to
distinguish
pinning
explicitly
from
pushing
or
pulling
so
pushing
or
pulling.
Is
the
the
process
of
pushing
a
you
know
a
whole
graph
to
another
party
or
pulling
a
whole
graph
for
another
party?
That
operation
might
be
expensive
and
it's
altogether
different
from
the
intent
of
hey
I
would
like
you
to
keep
the
stuff
around
and
so
having
an
API
that
actually
distinguishes
those.
Those
three
is
a
useful
and
important
thing
this.
This
is
a
thing
that
came
up
in
the
in
the
threaded
conversation
and
in
github
separately.
A
So,
ideally,
applications
and
tools
can
be
built
against
one
API,
which
might
have
many
flavors,
but
it's
the
semantically
the
same
thing
and
the
data
structure
is
the
same
thing,
but
then
kind
of
gets,
consumed
and
used
by
them
by
a
lot
of
different
services,
so
another
another
piece
of
this
is
to
to
kind
of
distinguish
the
economic
transactions
that
we're
talking
about.
So
when
we
talk
about
pinning,
we
were
explicitly
saying:
hey,
please
store
this
data,
but
we're
implicitly
also
saying
hey.
A
Please
get
the
data
from
somewhere
potentially
for
me,
hey
also,
please
serve
the
data
back
to
me
at
some
point
and
potentially
please
also
serve
the
data
to
others.
There's
a
lot
of
economic
arrangements
that
have
very
different
costs,
all
embedded
into
one,
and
so
this
makes
it
very
difficult
for
pinning
service
providers
to
distinguish
the
costs
for
these
different
different
features.
A
So
one
of
the
goals
here
is
to
be
able
to
distinguish
these
so
that
pinning
service
operators
could
assign
different
costs
to
all
of
these
operations
or
not,
but
at
least
have
the
flexibility
to
be
able
to
do
it.
So
whatever
we're
doing
in
in
these
api
is,
we
should
be
able
to
make
these
things
distinct.
A
We
want
to
explicitly
Express
the
intent
to
store
and
back
up
some
data
that
may
or
may
not
be
a
free
operation,
and
we
want
to
express
the
we
want
to
be
able
to
pull
and
download
a
graph
from
a
particular
remote
that
may
or
may
not
be
a
free
operation,
and
that
may
be
my
graph
or
it
might
be
somebody
else's
graph,
and
so
this
pull
needs
to
carry
some
kind
of
authentication
potentially
because
the
the
that
transaction.
So
it's
not
just
a
pin
operation
that
needs
to
carry
authentication.
A
It's
the
pull
transaction
as
well.
That
needs
to
carry
authentication
and
it
should
also
be
possible
for
the
pin
object
to
express
some
some
intent
to
publish,
and
so
what
this
means
is
that
I
should
be
able
to
to
agree
with
with
a
pinning
service
that
please
store
this
stuff
and
serve
it
out
to
other
people
for
free
and
charge
me
so
so
that
kind
of
intent
should
be
able
to
be
kind
of
expressed
either
in
the
metadata
of
the
pin
or
in
some
other
facility
in
the
NE.
Okay,
all
right!
A
So
there's
a
lot
of
wishes.
There
there's
a
lot
of
different
things
that
the
people
would
want
out
of
this
API
and
so
what
what
ends
up
making
sense
here
is
to
kind
of
decompose
a
problem
into
these
different
different
pieces,
you're
starting
to
see
kind
of
the
shape
of
it
emerge
and
then
see
what
we
can
do
in
terms
of
kind
of
a
roadmap
to
to
kind
of
satisfy.
A
The
most
important
needs
sooner
and
kind
of
learn
more
about
the
designs
that
am,
I
reliable
and
then
kind
of
pushing
some
directions
later
so
I
kind
of
narrowed
it
down
to
six
proposed
changes,
and
so-
and
these
are
this-
will
get
written
up
and
put
on
when
I
get
hub
right.
Now,
it's
it's
it's
a
mostly
in
notes
and
so
on.
A
So
this
has
to
get
well
structured
into
kind
of
an
RFC
style
proposal,
but
but
I'll
kind
of
give
the
brief
summary
here,
because
I'm
really
interested
in
people's
feedback
later
today
on
in
the
worship
time
so
so
change
one
is
to
eventually
kind
of
enter
in
a
local
tuning.
Api
introduce
a
pending
object
to
attract
metadata,
so
we
already
mentioned
that
earlier.
So
what
won't
go
into
it
again
and
the
pin
set
should
evolve
to
be
tracked.
These
objects,
as
opposed
to
just
the
C
IDs
directly.
A
They
should
also
solve
the
kind
of
that
problem
that
we
highlighted
earlier.
Then
it
should
be
possible
to
create
a
pin
API
for
services
or
tools
to
handle
most
simple
cases.
So
most
services
today
just
have
kind
of
like
a
crud
style,
API
around
being
able
to
create,
read,
update
and
delete
pins,
so
that
kind
of
basic,
simple
thing
should
just
work
with
a
simple
API
and
that
could
be
around
an
IP
first
node
or
it
could
so
it
could
be
able
to
miss
no
traffic.
A
A
We
also
need
a
pin
thread
API,
and
so
that
means
it
would
be
extremely
useful
for
kind
of
these
forward-looking
cases.
Things
like
cluster
and
and
a
number
of
applications
to
be
able
to
have
an
API
that
gives
us
the
entire
data
structure
over
the
history
of
what
happened
to
the
pin
set
as
things
get
added
and
removed,
and
so
on,
and
for
parties
to
be
able
to
follow
that
real
time
and
ideally
kind
of
replicate
the
whole
thing.
A
It's
worth
noting
that
these
are
not
sequential.
So
these
different
proposed
changes
could
happen
in
any
order.
They're
gonna
end
up
using
the
same
pin
data
structure,
but
we
could
go
about
building
this
out
in
different
order
order
and
so
I
propose.
We
go
through
the
know.
P0
of
creating
the
simple
API
for
services
need
and
then
kind
of
move
from
there
there's
three
other
changes
and-
and
these
are
not
exactly
pinning
related
but
they're
adjacent,
and
so
one
of
them
is
to
add
a
push-pull
API.
A
So
thankfully,
this
is
already
kind
of
partly
in
flight
because
of
the
graphs
and
integrations
there's
a
whole
kind
of
data
transfer
component
that
that
a
number
of
us
have
been
working
on.
That
makes
it
easy
to
reason
about
pushing
and
pulling
entire
IP
LD
graphs
and
associating
authentication
or
payments
through
that.
So
this
is
a
component
that
was
needed
in
in,
in
fact,
going
to
be
able
to
move
around
I,
feel
D
graphs
and
be
able
to
do
payment
channels
with
them.
A
A
A
So
an
IP
FS
node
cannot
cause
a
remote
call
in
another
IP,
fest
node,
of
course,
because
of
trust
reasons,
but
you
might
be
able
to
do
it
in
an
authenticated
way.
So
having
an
authenticated
remote
operation,
API
could
solve
a
lot
of
these
kinds
of
concerns.
That,
however,
is
a
it's
a
huge
undertaking
and
it
requires
kind
of
thinking
very
carefully
about
which
API
is.
You
might
want
to
do
this
with,
but
this
might
be
external
useful
cleaning
services
because
it
might
not
be
just
hand.
A
It
might
be
a
whole
bunch
of
other
operations
that
suddenly
become
available
as
an
easy
service
without
having
to
write
a
lot
of
code
all
right.
So
the
last
part
is
when
I
have
mentioned
the,
but
what
the
APS
are
looking
like,
I'm
running
early,
so
I'll
I'll
I'll
show
you
the
slice
now,
instead
of
kind
of
going
in
that
through
it,
I'll
just
describe
the
the
for
the
workshop
today,
the
pinning
service
API.
A
This
is
kind
of
what
we
will
be
discussing
really
landing
on
on
kind
of
the
crowd
operations
and
then
I'll
mention
the
that
for
the
thread.
So
there's
a
whole
bunch
of
requirements
here,
I
won't
go
into
jail
for
them
if
you're
familiar
with
the
cluster
use
case.
You'll
know
it,
but
we,
after
thinking
about
this
very
carefully
and
thinking
about
the
the
whole
shape
of
the
problem
and
the
importance
of
ACLs
and
so
on,
I
landed
on
the
fact
that
textile
threads
are
exactly
the
right
data
structure.
A
It
covers
almost
all
of
the
use
cases,
if
not
all,
of
the
use
cases.
These
cases
that
we'd
been
worried
about
it's
an
IP
LD
graph.
It
allows
creating
a
lot
an
event,
log
of
updates
of
as
and
deletes
and
so
on,
and
it
has
built
in
all
of
the
kind
of
encryption.
Tooling,
to
reason
about
being
able
to
read
or
write
to
different
parts
of
it,
and/or
be
able
to
replicate
all
of
it
without
being
able
to
read
it,
which
is
a
whole
bunch
of
the
heavy-lift
around
access
controls
for
replicating
clusters.
A
So
so
that
kind
of
thing,
so
it's
likely
it's
very
likely
that
the
whole
pinning
thread
API
is
going
to
turn
into
into
the
textile
thread
and
we
still
have
to
run
a
bunch
of
experiments
tried
for
a
type
that
try
to
use
it
and
so
on
and
do
the
heavy
lift,
but
first
of
all
like
a
huge
thanks
to
to
that
style
for
creating
all
this
and
and
basically
implementing
it.
You
know
all
of
the
complicated
logic
around
this
there's
likely.
A
A
Alright,
so
for
road
for
brief
roadmap,
we'll
have
the
worship
later
today
we'll
talk
about
this,
some
more
we'll,
then
I'll
be
formalizing
this
these
changes
and
proposals
and
submitting
them
and
then
hopefully
do
the
the
simple
pin
service
API
soon,
because
that's
what
people
need
the
most
and
then
later
on
in
in
the
later
part
of
2020,
we
can
go
towards
towards
making
decisions
on
on
the
pin
thread,
API
and
all
that
kind
of
stuff
we
could.
We
could
move
faster
on
this
depending
on
on
people's
desire
to
go
unimplemented.