►
From YouTube: Advanced Pinning Structures - Andrew Hill
Description
Textile’s latest releases of ThreadsDB and Buckets come with new pinning capabilities that support dynamic datasets and IPNS addresses. In this talk, Andrew Hill highlights how Threads, Buckets, and IPFS can enable new forms of pinning services.
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
So
textile
is
really
focused
on
a
handful
of
technologies
that
connect
and
extend
the
p2p
ipfs
file
coin
in
useful
ways
for
app
builder
since
and
services,
and
today,
I
really
want
to
talk
to
you
about
two
of
those
technologies,
threads
and
buckets,
and
then
tomorrow,
I'll
be
talking
about
our
work
to
link
in
file
coin
through
a
technology
called
the
power
gate.
So
hopefully
you
can
join
for
that
as
well,
but
so
to
jump
right
in
because
I
have
a
lot
of
a
lot
of
things.
I
want
to
share
with
you.
A
I
want
to
focus
on
the
first
technology,
which
is
called
threads
DB
or
sometimes
just
threads.
For
short,
threads
really
is
a
technology
that
rose
out
of
some.
What
we
called
our
field
studies
actually
trying
to
build
applications
on
on
the
ipfs
network
and
realizing,
where
some
areas
that
we
could
build
helpful
technologies
for
other
people
that
wanted
to
do
the
same
thing
and
so
threats.
A
Db
is
a
peer-to-peer
database
built
on
IP,
FSLIC,
p2p,
IP,
n
s,
IP
LD,
it's
really
helping
to
sandwich
and
stack
those
technologies
and
then
and
then
create
in
faced
four
developers.
That's
really
easy
to
use,
so
we're
really
focused
on
delivering
kind
of
a
MongoDB
like
developer
interface.
So
when
a
developer
wants
to
put
a
database
in
their
application,
they
don't
necessarily
want
to
think
about
how
they
can
stack
and
sandwich
all
those
protocols.
A
They
really
just
want
to
start
using
them
into
a
very
simple
starting
interface,
but
then
it
gives
some
modular
components
like
a
CL
identity,
CR
DTS
that
developers
can
plug-and-play
what
they
need
to
make
their
application
run
and
then,
finally,
it's
it
has
an
encryption
ssin
first
design
that
enables
private
sharing
with
third
party
services
being
added
as
well
and
I'll,
get
deeper
into
that.
Cuz
I
think
that's
where
this
gets
really
useful
for
this
audience.
So
just
really
quick
going
inward
to
thread
threads
I'll
talk
about
the
database
here
first
and
so.
A
Every
thread
which
is
kind
of
a
network
has
a
database
which
is
the
local
component,
and
these
fill
these
terms
might
sound.
Familiar
actually
I
hope
they
sound
familiar.
Is
that
when
a
developer
creates
a
database,
a
database
has
many
collections
collections
are
the
schemas
that
define
what's
going
to
be
in
that
database
inside
of
a
collection.
A
There
can
be
many
instances,
so
the
objects
are
the
documents
that
you're
storing
in
that
database
that
fulfill
those
schemas
and
then
those
instances
are
what
you
can
add,
delete
and
update
once
you
have
your
database
and
so
on.
The
Left
I
have
some
code
here,
that's
using
the
JavaScript
library
to
create
a
collection
of
astronauts
with
some
fields
and
then
update
and
query
those
fields
in
a
very
familiar-looking
way
and
trying
to
help
the
developer,
not
necessarily
have
to
be
thinking
about.
A
You
know,
content
addresses
that
are
constantly
changing
and
how
they
can
manage
this
mutable
data,
that's
actually
running
over
IP
FS,
but
then
we're
threads
is
probably
really
powerful.
Is
the
networking
and
so
there's
a
couple
things
I
wanted
to
just
point
out
about
the
networking
so
that
you
can
start
getting
your
heads
around
how
this
is
working
and
what's
different
and
new
here.
A
So
when
we
started
building
a
textile
we
we
started
trying
to
build
applications
that
would
run
in
the
browser
and
mobile
devices
and
in
just
real
network
condition,
and
when
you
build
a
peer-to-peer
application,
one
of
the
first
in
kind
of
the
default
ways
that
you're
gonna
architect
is
that
say
you
are
pure
a
and
you
have
some
data
or
update
that
you
want
to
send
to
Pier
B.
You
would
push
it,
and
this
is
where
Lib
p2p
is
fantastic.
They
can
connect
to
each
other
and
push
these
updates.
A
So
if
a
tries
to
make
a
change
to
the
data
and
B
comes
on
later,
it
can
attempt
to
pull
those
updates
from
a
and
that's
baked
into
the
networking.
So
the
developer
doesn't
have
to
think
too
much
about
it,
but
then
again,
really
really
interesting
to
this
audience.
I
think
is
the
third
component,
which
allows
a
push
and
pull
architecture.
So
if
a
tries
to
make
an
update
and
B
is
not
online,
a
can
actually
assume
that
they're
going
to
be
offline.
A
The
next
time
becomes
online
and
so
they're
not
actually
going
to
be
available
for
the
pull
request,
and
so
what
they
do
instead
is.
They
can
push
those
updates
to
a
third
party
service,
Z
and
then
some
time
can
pass
and
B
can
come
online
and
knowing
knowing
that
Z
is
available,
they
can
actually
pull
the
updates
that
they
missed,
and
so
what
we've
tried
to
do
here
is
take
some
of
the
things
that
that
sort
of
technologists
learned
by
making
web
to
run
really
well
and
actually
apply
them
to
the
web
three
space.
A
And
so
what
I
mean
by
that
is
actually
allowing
services
and
api's
to
be
stood
up
in
a
way
that
applications
can
be
built
on
them
and
scaled.
But
they
don't
have
to
abandon
the
idea
of
letting
users
own
their
data
or
creating
interoperable
data
sets
or
private
key
infrastructure,
and
so
what
this
does
and
I'll
show
you
how
this
actually
works
in
a
more
technical
level.
It
lets
end-users
own
their
data.
A
The
left
side
is,
is
sort
of
what
is
user
owned
and
controlled
and
private,
and
the
right
side
is
where
threads
enables
third
party
services
and,
if
you,
if
you're,
building
a
pinning
service,
if
you
want
to
build
api's
friend
users
that
service
key,
that's
mentioned
in
the
upper
right,
hopefully
is
making
your
ears
ring
that
this
might
be
an
interesting
opportunity
of
something
that
you
can
build
on.
So
just
a
quick
flow
here
on
the
bottom
left,
the
user
create
some
raw
data.
A
The
first
thing
that's
going
to
happen
is
the
the
the
applicator
sorry,
the
library
is
going
to
create
a
symmetric
private
key
for
that
data
or
sorry,
just
a
symmetric
key
for
that
data
that
will
encrypt
it.
One-Time
use
key,
and
you
don't
have
to
follow
this.
This
is
just
for,
if,
for
those
of
you
that
have
kind
of
your
head
around
this
already,
but
the
next
step,
that's
going
to
happen
is
there's
a
shared.
A
Read,
read
key,
so
all
participants
in
a
thread
who
are
collaborating
on
the
same
data
set,
can
share
this
read
key,
and
so
that
will
then
encrypt
the
body.
The
encrypted
body
from
the
previous
step
and
the
key,
and
then
you
want
to
share
that
out
to
the
participants,
so
they
can
open
it
up
and
see
what
you've
updated
in
the
data
set.
A
But
the
next
thing,
that's
going
to
happen
is
actually
you're
going
to
wrap
that
one
more
time
with
some
metadata
that
links
it
to
the
previous
updates
and
then
one
more
layer
of
encryption
with.
What's
called
this
service
key
and
so
with
the
service
key,
you
can't
see
anything
inside
the
data,
but
you
can
see
how
the
data
links
across
updates.
So
you
can
do
really
interesting
things
like
surface
api's
that
allow
paging
or
time-based
lookups.
A
That
I
think
that
they'll
give
me
a
service
that
I
want
so,
for
example,
archiving
or
making
it
available
on
the
ipfs
network,
so
left
side,
user,
owned
right
side
available
for
services
to
build
on
in
a
really
interesting,
an
open
way
with
these.
What
and
and
the
threads
DB
concept
allows
you
to
think
about
these,
like
interoperable
datasets,
so
once
it's
user
owned,
if
there
are
people
that
are
standing
up
services
or
their
different
applications
that
are
using
these
schemas,
the
user
can
pull
them
back
out
and
put
them
in
new
applications.
A
They
can
find
new
ways
to
make
sure
their
data
lives
forever
or
make
sure
their
data
lives
in
other
applications
and
they
get
the
most
out
of
it
and
so
I
think
really
interesting
in
the
pinning
service
or
the
pinning
summit
context
is
that
threads
are
actually
dynamic.
Pin
sets
so
I'll
get
into
our
some
of
our
hosted
services
that
were
making
available
to
developers,
but
really
you
can
think
about
updates
to
your
database.
A
You
want
to
persist
them
off
of
your
phone
or
you
want
to
persist
them
out
of
your
browser
on
some
ipfs
node.
That's
going
to
be
online
longer,
and
so
what
you
do
is
you
can
take
this
service
key.
You
can
push
your
your
thread
updates
to
these
third-party
services
that
are
running
ipfs
nodes
and
they
can
make
sure
that
data
is
pinned
a
zip
inset
across
the
entire
thread
and
I'll
share
these
slides,
but
some
important
links
about
threads.
A
You
can
actually
share
that
rekey
with
the
service
as
well,
so
they
can
go
all
the
way
down
into
the
thread
and
expand
and
recursively
move
through
this
dag
and
do
work
on
top
of
your
data,
and
in
this
case
right
now,
it's
just
the
work
is
pinning
and
exposing
that
data,
but
it
might
be
like
I,
said
resampling
or
formatting
or
other
other
operations
on
your
data,
so
buckets
are
built
on
threads
DB.
So
this
is
really
just
another.
A
Interoperable
format
thread
buckets
are
really
just
a
schema,
and
so,
if
you
recall
the
database
part
of
threads,
it's
the
it's
threads
that
have
a
database
inside
the
database
or
collections
inside
of
collections
or
instances
buckets
are
actually
each
bucket
you
create,
which
is
a
different
dynamic.
Folder
on
your
disk,
is
actually
just
a
different
instance
in
a
collection
that
collection
is
defined
by
a
schema
that
is
just
buckets.
Something
really
cool
I
think
that's
happening
here
is
the
interoperability
is,
is
is
really
powerful
and
instances
in
in
any
kind
of
database.
A
You
use,
you
probably
have
some
key
some
unique
ID
for
an
instance
in
this
collection
of
in
the
buckets
collection.
We've
actually
made
that
ID
be
an
IP
NS
address,
and
so
you
already
know
immediately.
That
instance
defines
a
bucket.
It
also
has
this
address,
which
is
interoperable
across
all
ipfs
notes
that
are
exposing
IP
NS
addresses,
since
this
bucket
is
public.
I
can
go
to
that
on
any
gateway
and
and
share
the
content
to
this.
A
So
that's
really
exciting
and
there's
a
lot
of
opportunity
to
do
more
with
that
and
different
kinds
of
schemas
that
we
can
build
that
are
beyond
buckets
that
use
the
same
property
to
add
interoperable
interoperability
and
expose
really
cool
features.
We
have
a.
We
have
a
client
which
I'll
talk
about
next,
that
lets
you
create
buckets
and
push
them
to
remote.
A
Ip
FS
peers
quickly,
here
I'm
pushing
a
folder
of
four
files
to
a
remote
IP
FS
peer
in
a
one-liner
and
then
I'm
gonna
go
to
a
gateway,
I'm
gonna,
first
I'm
gonna
ask
for
all
the
links
and
you'll
see.
One
of
them
is
an
IP
NS
link
and
I
can
grab
that
and
go
to
the
gateway
on
textile
and
look
at
that
IPS
at
I
am
s
Lincoln.
There's
my
web
page
and
I
can
go
to
that
on
other
gateways
as
well.
A
So
we
have
a
lot
of
work
to
do
still
on
just
making
buckets
bigger
and
better
and
more,
like
I
said
we're
working
on
private
buckets,
so
that
would
be
the
content
encrypted.
We're
working
with
a
few
different
people
to
also
support
buckets
and
have
interoperability
on
other
services
same
with
threats
and
obviously
we're
working
on
file
coin
and
I'll
talk
more
about
that
tomorrow.
A
But
the
idea
here
is
that
threads
and
buckets
would
also
be
supported
on
endpoints
that
can
do
storage
and
persistence
on
the
file
coin
network
and
that
gets
really
super
exciting
too,
because
then
we
just
add
another
protocol,
that's
all
in
our
interoperable
with
these
datasets
and
so
some
interesting
links
for
you.
We
have
documentation
about
buckets
on
the
dock,
on
the
textile
docks
and
we
have
a
bunch
of
different
blog
posts
about
about
buckets
and
and
how
to
put
them
to
use
and
we'll
be
doing
some
more.
A
We
just
actually
that
piece
I'll
talk
about
next
about
the
hub.
We
just
launched
that,
and
so
we're
still
adding
a
lot
of
content
there
and
and
but
I'll
share
with
you
some
of
the
early
bits
of
it
so
yeah
that
gets
me
to
the
third
piece
of
technology.
The
hub
and
the
hub
is,
is
where
what
we
were
trying
to
do
is
is
just
reduce
the
cost
for
developers
to
really
come
and
experiment
and
build
things.
A
What
we
want
to
do
is
make
it
easy
for
developers
to
come,
explore
test
and
fail
quickly
so
that
they
can
go
and
test
and
build
the
next
thing
and
really
test
their
ideas
on
this
thing,
because
it's
only
if
we
can
get
a
thousand
developers
or
tens
of
thousand
developers
to
coming
be
testing
and
building
that
we
can
have
the
sparks
that
really
take
off
through
society
and
really
make
this
up,
make
some
really
big
and
impactful
successes.
And
so,
let's
try
to
lower
that
cost
of
adoption
and
the
cost
of
of
failure.
A
And
so
the
hub
really
does
that
and
and
like
I
said,
the
hub
is,
is
really
just
a
set
of
open-source
technologies
that
include
threads
and
and
buckets
support
and
some
IP
FS
notes,
and
so
really,
if
there's
are
there,
if
there
are
pieces
in
here
that
you're
running
services-
and
you
want
to
run
these
on
your
own-
we're
happy
to
help
and
walk
you
through
and
share
with
you
what
we've
done
here.
But
so
when
you
go
and
grab
the
CLI
for
the
hub,
you
can
create
things
like
accounts.
A
You
can
create
things
like
organizations
so
that
you
can
share
administrative
tooling
with
other
collaborators,
and
you
can
invite
people
to
those
organizations,
and
so
here
I'll
create
my
conifers
and
I'll.
Invite
an
astronaut
to
my
conifers
organization,
and
that
means
I
can
create
buckets
and
teams
the
buckets
and
threads
that
are
collaboratively
edited
and
managed
by
this
team.
But
that's
for
developers
and
I
have
mentioned
early
on
that
we
have.
This
idea
of
developers
can
provision
space.
A
So
this
is
this:
is
a
developer
provisioning
space
on
the
hub
and
that
will
give
them
hosted
ipfs
resources
that
will
give
them
access
to
these
networks
and
protocols
through
some
persistent
nodes.
But
what
we
really
want
to
do
is
let
them
then
pass
that
on
to
their
users
in
a
way
that
their
users
still
on
their
data
and
so
I'll
get
into
that
in
a
second.
The
hub
has
OSI
ipfs
services
thread.
A
But
probably
the
most
interesting
thing
here
is
the
way
that
we
do
the
access
to
those
resources.
So
the
developer
in
the
in
the
preview
I
just
showed
you
is
setting
up
an
account
with
their
other
developer
team
when
they
want
to
use
the
api's,
they
can
actually
get
what's
called
an
account
key
and
that
account
key
will
grant
them
access
to
everything
that
they're
doing
in
the
CLI.
So
they
can
create
buckets.
A
But
it's
all
encrypted
and
private
to
both
the
developer
and
to
textile.
So
then,
these
users
have
an
easy
onboarding.
They
get
their
data
on
persistent
ipfs
nodes,
but
they
can
actually
just
use
IP
FS
in
there
and
their
private
key
to
get
it
back
out
and
or
replicate
it
on
their
own
nodes
or
in
the
future,
as
other
services
come
online,
get
it
into
other
services,
and
we
think
that's
really
cool
and
interesting.
A
So
it's
really
than
just
a
relationship
up
between
the
end
user
and
the
hosted
interface,
but
using
threads.
It's
interoperable
data
formats,
it's
PKI,
so
the
end
user
really
owns
it
and
they're
just
more
or
less
borrowing
some
space
provided
by
the
developer
on
the
hook.
And
if
you
want
to
use
these
things,
if
you
want
to
try
to
build
them
into
your
app,
let
us
know
we
have
a
slack
channel
slack.
A
Textile
IO
are
always
available
trying
to
help
people
a
lot
of
the
pieces
on
the
hover
early,
so
there's
we're
sort
of
filling
in
examples,
we're
filling
in
documentation,
but
if
you
have
specific
use
cases
and
want
help,
just
let
us
know
we're
working
as
fast
as
we
can,
and
we
also
hope
that
other
services
want
to
adopt
these
things
and
build
on
it.
So
let
us
know
if
you're
on
that
side
and
and
we're
down
to
help,
and
so
those
are
the
kind
of
those
are
kind
of
covered.
A
Really
three
technologies
here
and,
like
I,
said
tomorrow:
I'll
talk
about
the
power
gate,
but
kind
of
leave.
The
my
presentation
off
here
I
wanted
to
like
step
back
and
just
talk
about
the
bigger
picture,
because
I'm
really
excited
to
present
at
the
Pinney
and
opinion
summit.
But
one
thing
I
got
thinking
about
when
I
was
putting
these
slides
together
is
that
text
I
was
just
born
in
a
totally
different
time.
A
We
were,
you
know,
we're
obviously
focused
on
helping
people
work
with
decentralized
protocols,
we're
really
focused
on
making
data,
something
that
people
can
own
and
can
persist
on
the
online
for
long
periods
of
time.
But
really
things
are
changing
right
now
and
the
things
that
are
changing
may
never
go
back
to
the
way
they
normally
were,
and
we
want
to
find
people
that
are
trying
to
build
technologies,
for
that
new
world
importantly,
are
trying
to
build
technologies
that
will
bring
positive
impact
to
that
new
world.
B
Awesome,
thank
you
so
much
Andrew.
This
is
phenomenal.
Do
you
folks
have
any
questions
for
Freda,
stickman,
Q&A
or
in
the
chat?
Threads
and
buckets
are
awesome?
I
was
just
reading
rereading
the
threads
paper
last
night,
so
super
super
cool
work
there
and
thank
you
all
for
the
amazing,
tooling,
the
ur
building
on
ipfs.
It's
amazing
yeah.
A
B
A
So
buckets
are
really
our
first
version.
Well,
we'll
definitely
publish
some
documentation
on
what
that
looks
like
and
what
the
spec
is
for
a
bucket.
But
it's
pretty
simple
right
now.
It's
really
just
a
basic
document
that
has
the
CID
of
the
head
of
the
folder,
and
then
it
has
some
UNIX
FS
type
inning
behind
the
scenes
to
make
sure
that
that
folder
is
persistent,
but
it's
pretty
straight
forward,
and
so,
if
you're
building
things
like
a
pinning
service,
it
shouldn't
be
it
shouldn't
be
out
of
the
park.
A
Also,
the
way
services
run
is
they're
actually
baked
into
the
the
the
reference
implementation.
Argo
threads
implementation.
So
you
can
already.
You
can
all
use
that
library
to
stand
up
your
own
services
and
to
accept
things
like
other
threads
to
follow,
and
so
that's
all
there
and
actually
the
binary
has
it
as
well.
So
you
can
run
the
threads,
the
binary
and
and
build
services
on
that
it's
under
documented.
It
is
kind
of
like
the
next
thing.
We
need
a
document
after
getting
people
to
use
these
things,
but
it
will
come
and
it's
it's
there.
B
A
Yeah,
the
folders
are
UNIX
FS
and
right
now,
I
had
mentioned
that
buckets
are
only
open
and
because
they're
open
the
authors
of
the
bucket,
don't
really
care
about
the
rete
key,
so
they
actually
just
share
the
rekey.
When
we
have
open
threads,
you
wouldn't
need
to
do
that,
but
right
now,
threads
are
only
encrypted,
and
so
what
they
do
is
they
just
the
bucket
owner
will
just
share
that
read
key
with
a
with
the
hub
in
this.
A
In
this
case
it's
the
hub
is,
you
can
just
think
of
it
like
the
gateway
and
because
of
that
that
gateway
knows
how
to
go
and
look
in
the
thread
as
a
thread
service.
But
then
it
also
can
see
that
CID,
because
it
has
the
read
key
and
then
it
will
just.
It
will
just
pin
that
you
know
UNIX
FS,
folder
and
there's
a
lot
of
enhancements.
A
We
can
do
there
and
we're
working
on
a
lot
of
those
things
so,
but
it's
working
really
well
right
now,
so
did
I
understand
quickly
that
threads
are
per
user
encrypted
by
default
now
and
that
you
will
support
not
encrypt
yourself
later.
It's
not
encrypted.
Already
possible,
so
so
that
gets
into
some
pretty
deep
technical
things.
So
the
thing
that's
really
novel
and
interesting
around
threads
is
it's
actually
a
thread
is
a
collection
of
single
writer
logs
that
then
have
have
a
modular
crc
rdt
that
turned
that
into
a
database.