►
From YouTube: Pinning Services API with Marcin Rataj
Description
Marcin Rataj (@lidel) provides an overview of the vendor-agnostic API, ongoing integration work, and its role in the wider IPFS and Filecoin ecosystem.
Join us for Filecoin Liftoff Week, an action-packed series of talks, workshops, and panels curated by the web3 community to celebrate the Filecoin mainnet launch and chart the network’s future. https://liftoff.filecoin.io/
Events take place all week, October 19-23, 2020. #FilecoinLiftoff
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
My
name
is
marcin
ratay.
Everyone
knows
me
as
lidl,
I'm
working
on
ipfs
in
web
browsers
and
user
agents.
It
makes
more
sense
to
say
those
days,
ip
fashion,
user
agents,
I'm
leading
gui
and
web
working
group,
which
includes
our
browser
extension
desktop
web
interface,
but
also
we
are
tackling
the
behavior
on
how
ap
ipfs
is
exposed
on
http
gateways.
A
So
in
this
talk
I
will
it
will
be
like
non-native
speaker
using
two
fancy:
english
words.
I
will
go
quickly
over
what
pinning
service
api
is,
what
problems
it
solves
and
how
it
fits
into
a
wider
ecosystem
during
the
transition
between
web
2
and
web
3,
and
for
a
long
long
time
we'll
be
living
in
that
hybrid
reality
and
I
believe
pinning
services
will
serve
an
important
role
in
that
transition
periods.
So
I
said
there
would
be
two
english
words
which
will
I
use
to
illustrate
my
case
for
pinning
service
api.
A
A
It
works
on
top
of
a
concept
of
content
addressing
so
when
you
import
your
data
to
ipfs
that
data
is
chunked,
it's
cut
into
a
block
or
more
blocks.
That
set
of
blocks
is
represented
as
a
dag
with
which
is
a
tree,
and
the
tree
has
a
root
and
that
root
has
a
hash
and
the
hash
represents
the
data
in
entire
tree.
A
So
you
import
your
cut
picture
to
ipfs
and
you
get
a
specific
cid
and
every
time
you
import
the
same
file
with
the
same
set
of
import
parameters,
you
will
get
the
same
identifier
and
in
turn
you
will
get
the
same.
Address
data
will
be
addressed
by
its
own
hash,
and
that
gives
its
this
permanence
in
ipfs
network.
You
know
that
this
specific
cad
picture
has
this
specific
address
and
that's
permanent.
A
A
You
are
chunking
it
and
you
are
finally
getting
the
cid
and
the
persistence
in
ipfs
is
ensured
by
your
node,
providing
the
data
to
the
network
and
it
does
it
in
two
ways:
one
is
it
announces
it
on
the
hd
says:
hey
I
got
this
cid.
A
A
So
what
happens
when
I
close
my
laptop?
That's
the
question.
Everyone
asks
when
I
give
a
cat
picture
example,
because
you
got
that
file
in
your
local
store.
You
imported
it,
you
provided
it
to
the
network
and
then
you
shared
that
cid
or
maybe
a
link
to
a
public
gateway
to
someone.
But
you
quickly
close
your
laptop
and
what
happens
then
someone
asks
network
for
that
cid
and
it
may
find
your
provider
records
in
dht.
A
But
your
note
is
no
longer
available,
so
it's
just
sitting
there
and
waiting
and
that's
why
we
need
pinning
services
pinning
services.
It's
like
the
main
purpose
for
spinning
service
is
to
provide
data
to
the
network
when
your
node
is
not
around,
and
I
use
that
example
of
sharing
a
cat
picture
with
a
friend
and
closing
the
laptop
as
a
very
simplified
example.
But
this
applies
also
to
things
like
continuous
integration.
A
You
may
be
building
stuff,
you
may
want
to
persist
logs
or
artifacts,
but
you're
building
in
an
ephemeral,
docker
container
and
that
container
may
be
running
ipfs.
It
may
be
having
go
ipfs,
it
may
be
imported,
but
it
then
disappears
and
you
are
not
able
to
fetch
the
data
that
was
logged
in
the
ci
output,
so
pinning
service
api
is
a
vendor
agnostic.
A
Spec
for
doing
just
that
for
managing
remote
pins-
and
I
highlight
is
vendor
agnostic,
because
it's
protect,
like
the
one
of
main
requirements
for
creating
pinning
service,
was
to
protect
against
vendor
lock-in
and
protect
both
users
and
services.
It
protects
users
by
establishing
a
generic
api
that
both
tools
and
services
implement
and
you
are,
you
can
easily
switch
between
services
and,
at
the
same
time,
it
abstracts
away
details
of
actual
storage
away
and
that
way
the
pinning
services
themselves
are
free
to
switch
between
providers.
A
They
can
use
filecoin
as
a
back-end
or
they
can
use
something
else.
They
can
pick
the
most
cost-effective
way
of
storing
data.
They
can
have
introduce
a
hot
cache
for
the
most
interesting
data
that
users
are
interested
in
and
that
aspect
of
being
vendor
agnostic
is
very,
very
important
and
just
to
illustrate
how
important
it
is.
You
can
see
that
the
pinning
service
api
itself
in
the
context
is
a
very
narrow
and
minimal
api.
A
A
It
does
not
care
about
user
management
or
any
api
specific
to
the
backend
where
actual
data
is
stored.
All
those
apis
which
I
mentioned
can
be
exposed
by
the
pinning
service
as
on
additional
endpoints.
But
this
pinning
service
api
is
a
very
small
api.
It's
very
focused
on
taking
scid
and
ensuring
that
data
is
around.
A
A
There's
an
endpoint
for
adding
pins
where
you
simply
pass
a
name
and
the
cid.
You
may
pass
additional
metadata
and
in
response
you
get
pin
status
the
same
pin
status.
You
will
get
when
you
hit
the
get,
pin
object,
so
you
can
in
after
you
pin
a
thing
you
can
get
its
state
and
at
any
point
in
the
future
and
there's
this
replay
spin
object,
end
point
which
is
pretty
important
for
managing
big
data
sets,
which
mostly
don't
change,
but
they
will
have
updates
over
time.
A
For
example,
english
wikipedia
it
was
600
gigabytes
in
2017,
and
it's
close
to
one
terabyte
in
2022
and
most
of
like
pictures
and
videos
in
in
wikipedia
does
not
change.
Articles
may
change,
but
those
media
files
do
not
change.
A
So
if
you
want
to
persist
such
huge
data
set,
you
don't
want
to
like
pay
for
the
overlap
time
and
at
the
same
time,
you
don't
want
to
unpin
the
old
data
set
and
pin
the
new
data
set,
because
in
the
meantime
the
pinning
service
may
garbage
collect
stuff,
that's
not
pinned,
and
then
you
will
have
to
wait
for
it
to
fetch
the
data
that
that's
missing
for
that
div
between
old
and
new
version
and
stuff
that
was
garbage
collected.
A
So
that's
why
we
have
replace,
pin,
object,
endpoint
and
there's
a
remote
pin,
object.
Endpoint
for,
of
course,
like
unpinning
stuff
and
the
api,
as
I
said,
it's
super
simple:
there
are
only
two
objects:
one
is
pin
and
the
second
one
is
pin
status.
So
the
pin
object
request
instead
is
sent
to
a
pinning
service
the
way
it
works.
It
has
a
cid
of
a
data
that
you
want
to
pin
and
optional
attributes,
like
name
metadata,
dictionary
and
origins
and
pinning
service
takes
that
request,
and
it
immediately
responds
with
pin
status.
A
It
will
return
request
id,
which
is
the
unique
identifier
of
your
pin,
request
that
you
can
use
in
the
future
for
managing
this
specific
pin
that
you
just
created,
you
got
a
status,
so
the
status
will
tell
you
is
the
data.
Maybe
the
data
was
already
on
the
pinning
service
and
it
was
pin
immediately
or
maybe
you
are
pinning
a
bigger
data
set,
which
will
take
some
time
for
a
pinning
service
to
transfer
and
to
pin
into
the
secure
storage.
A
A
And
it
has
the
original
pin
id,
so
you
get
the
same,
pin
status,
object
there.
It's
a
very
simple
api.
Something
I
want
to
highlight
here
is
that
you
got
the
origins
here
and
you
got
delegates
here
and
those
two
fields.
It's
those
fields
are
arrays
of
multi-others,
which
are
addresses
of
ipfs
nodes
that
are
known
to
have
data
or
are
participating
in
the
data
transfer.
So
in
case
of
pin
object
when
you,
which
you
send
to
a
pinning
service.
A
That
array
is
a
hint
it's
an
optional
to
hint
pinning
service.
Saying
hey
this
cid,
which
I
want
to
pin,
is
provide
being
provided
or
is
available
at
those
addresses
at
those
nodes
and
spinning
service
may
act
on
that
hint
and
say:
oh,
that's,
cool
I'll,
try
to
connect
to
them,
and
that
way,
maybe
I
will
be
lucky
and
I
will
can
like
immediately
start
the
file
transfer
and
avoid
checking
dht
for
providers
for
that
data.
A
In
your
original
request,
however,
what
happens
when
you
are
behind
the
knot?
And
you
are
you
don't
have
like
a
your
note-
is
not
diable
from
the
outside
of
the
internet,
because
maybe
you
you
disabled
relays,
maybe
your
network
has
a
strange
network.
Topology
pinning
services
by
definition,
will
always
have
like
a
dialable
address
or
should
have
a
dialable,
ipv4
or
v6
address
on
the
internet.
So
that's
why?
A
Here
are
a
list
of
nodes
which
that
service
delegated
for
the
task
you
may
want
to
like
proactively
ensure
that
pro
the
nodes
with
the
data
are
connected
to
it.
So
then,
in
case
you
are
pinning
your
cut
picture,
you
are
proactively
connecting
to
the
delegate
nodes
and
then
the
bit
swap
can
start
and
that's
very
nice
optimization,
which
means,
if
we
don't
need
to
rely
on
dht,
we
we
won't
you.
We,
like
the
transfer,
can
start
immediately,
which
is
a
pretty
good
user
experience,
but
also
it's
pretty
good
for
private
setups.
A
A
If
you
are
not
available
from
the
public
internet,
then
you
take
delegates
and
make
your
notes
to
connect
back
to
the
pinning
service.
So
this
is
a
pretty
nice
optimization
that
solves
the
data
transfer
in
a
strange
network
topologies.
So
the
ipfs
pinic
api
spec
is
in
a
yaml
file,
which
is
in
open
api
format.
We
pick
that
on
purpose,
because
it's
sort
of
like
a
state-of-the-art
way
of
doing
api
specification
that
then
can
be
fed
into
code
generators
and
it's
super
easy
to
generate
client
and
server
for
any
language.
A
Another
cool
side
effect
of
having
open
api
spec
is
that
we
have
a
human,
readable
documentation
generated
from
the
yaml
spec,
which
means
the
spec
itself
always
is
in
sync,
with
the
docks,
and
vice
versa,
and
the
specs
include
much
more
than
just
this,
like
example,
how
each
endpoint
works
and
with
some
sample
responses
and
descriptions
all
the
fields.
It
also
has
a
long
running
theme
of
having
a
pin
lifecycle.
A
The
information
about
objects,
identifiers,
the
provider
hint
scheme,
which
I
spent
some
time
explaining
just
before
it's
there
as
well,
and
the
way
you
can
leverage
custom
metadata
for.
A
Managing
pins
from
your
app
all
that
is
on
the
pinning
services
api
spec
that
you
can
find
under
this
address
so
I'll
spend
the
remaining
part
of
this
talk
on
ongoing
integration.
Work
in
this
quarter,
probably
the
most
important
part
will
be
native
support
in
go
ipfs
that
will
be
landing
in
go
ipfs
0.78
in
this
quarter.
A
Historically,
we
had
local
pinning
that
was
a
command
ipfs
pin,
which
enabled
you
to
persist
any
cid
around
so
ipvs
note
will
garbage
collect
stuff
if
you
enable
garbage
collection
and
it
would
remove
stuff-
that's
not
pinned,
and
thanks
to
this
api,
you
are
able
to
persist.
It
saying
hey.
I
want
to
keep
this
ip
cid
around.
Unfortunately,
there
are
no
support
for
names,
so
you
had
to
manage,
pin
and
name
or
the
meaning
behind
pins
manually.
A
That's
why
now,
when
we
introduce
remote
pinning
you
will
be
able
to
pin,
you
will
be
able
to
pin
data
to
a
remote
service
you.
It
will
be,
of
course,
of
opt-in,
but
you
will
be
able
to
configure
pins
in
not
your
nodes,
config.
A
That
config
may
have
multiple
pinning
services
defined
and
by
using
ipfs
pin
remote
namespace
of
commands,
you
will
be
able
to
pin
a
specific
cid
to
a
remote
service
and
something
which
I
just
kind
of
started
mentioning
before
is
that
if
we
introduce
this
remote
pinning
api,
we
may
be
able
to
re
revamp
the
local
pinning.
A
So
we
plan
to
revamp
local
pins
to
also
support
things
like
named
pins
and
those
api
should
be
looking
fairly
similar,
so
should
be
very
intuitive
for
people
to
pin
locally
and
remotely
and
then
kind
of
like
manage
pins
across
different
different
pinning
services,
and
when
that
lands
we
will
have
built-in
support
for
pinning
in
ipfs
web
ui
and
ipfs
desktop.
A
Just
add
endpoint
at
the
api
key
and
you
are
set
to
go
and
then,
when
you
go
to
files,
you
will
see
the
pin
status,
is
it
pinned
remotely
for
every
like
each
file
and
directory?
And
then,
if
you
click
on
that,
you
will
be
able
to
switch
between
pinning
services
and
maybe
migrate
your
files
from
one
service
to
another.
You
will
be
able
also
to
have
multiple
access
tokens
for
each
pinning
service.
A
Let's
say
you
are
using
pinata
and
you
will
be
able
to
have
like
multiple
accounts
on
pinata
one
for
like
personal
stuff,
one
for
work
and
you
will
be
able
to
transfer
pins
between
those
accounts
and
that
should
be
pretty
nice
user
experience
for
things
like
managing
europeans,
but
also
the
migrating
between
different
providers,
which
is
a
part
of
the
our
no
vendor
lock-in
theme,
and
that
will
be
landing
soon.
A
So
we
want
people
to
keep
using
your
current
providers,
which
exist
or
people
should
be
able
to
opt
into
a
new
providers
that
will
appear
at
some
time
in
the
future.
So
you
should
be
able
to
easily
migrate
between
different
providers
using
built-in
tools
and
we
are
working
with
existing
pinning
services
to
add
support
for
this
api.
A
So
hopefully
ecosystem
will
be
able
to
leverage
that
pretty
soon
and,
of
course,
it's
a
small
api-
I
I
could
probably
describe
it
in
10
minutes,
but
I
believe
this
small
api
is
a
has
a
big
ecosystem
effect
and
it
will
improve
the
way
we
persist
available.
Data
sets
on
the
ipfs
network.
However,
the
valuable
part
here
is
available
for
humanity.
Yes,
of
course-
and
I
think
those
data
sets
will
leave,
will
be
fine.
The
problem
is
available
for
you
as
a
person
or
as
a
company
when
you're.
A
No
one
cares
about
your
cat
picture
really
or
maybe
you're.
No
one
cares
about
your
customer
data,
which
is
encrypted,
and
it's
just
like
a
on
a
bike
blob,
it's
valuable
to
you
and
how
do
you
persist?
Those
data
sets
on
the
ipfs
network.
I
think
this
will
unlock
possibilities
where
people
persist,
data
on
ipfs
network,
even
when
they
don't
care
about
decentralization
or
don't
have
time
on
bandwidth,
to
learn
about
ipfs
things
like
filecoin.
A
They
may
be
using
a
pinning
service
which
is
using
filecoin
on
the
backend
and
not
really
knowing
that
the
pinning
service
will
act
as
a
proxy.
That
is
black
boxing
on
all
the
complexity
related
to
the
data
storage
and
that's
kind
of
like
a
way
for
us
to
bridge
the
gap
between
web
2
and
web
3.
people
will
it
will
be
yeah.
It's
super
trivial.
It's
simple,
http
api
that
you
can
use
in
your
ci
cd,
setups,
there's
no
vendor
logged
in
I.
A
I
believe
it
will
be
pretty
interesting
way
to
make
ipfs
and
internal
falcon
to
the
masses
in
a
very
approachable
way.
So
I
believe
I'm
close
to
my
time
window.
So
that's
it
on
my
end.
Thank
you.
So
much
if
you
are
interested
in
more
details,
I
probably
glossed
over
over
a
bunch
of
important
stuff.
There's
a
github
repo.
When
we
not
only
have
a
spec,
we
got
links
to
documentation,
there's
a
section
on
already
existing
integrations
things
like
go:
pinning
service,
http
clients.
A
There
is
a
test
server
in
ruby
on
rails.
We
are
working
on
bringing
this
integration
to
go
ipfs
and
like
js
http
clients.
So
if
you
want
to
follow
all
that
discussion,
here's
the
repo
and
join
us
there
if
you're
interested
in
the
way
we
created
this
api,
there's
a
bunch
of
historical
discussions
on
the
issues
tab,
which
I
find
also
interesting
because
about
a
bunch
of
existing
pinning
services
participated
in
shaping
this
api.
So
it's
a
small
api,
but
it's
small
on
purpose
because
we
wanted
to
cover,
make
it
a
generic
enough.