►
Description
Decentralized app-development is still in its infancy, and has been notoriously difficult to get started with. That's where this workshop comes into play. Using real-world examples built on Textile's suite of developer tools, this workshop will explore the anatomy of a working DApp (IPFS Tag!) in a single, engaging session.
https://github.com/ipfs/camp/tree/master/CORE_AND_ELECTIVE_COURSES/ELECTIVE_COURSE_D
A
D
Okay,
so
some
housekeeping
stuff
and
we'll
go
over
like
getting
the
slides
and
stuff
like
does
anything?
Does
anyone
you
want
to
have
the
slides
locally
handy
or
are
we
cool
with
the
first
part?
I
was
kind
of
gonna.
Do
some
slides
and
it's
more
a
little
less
hands-on
and
then
the
second
half
will
be
completely
hands-on.
If
you
want
to
start
grabbing
the
slides
and
code
examples
of
things
locally
right
away,
first
I
am
told
you
should
connect
to
the
internet.
D
That
should
make
it
a
lot
easier
to
actually
download
code,
snippets
and
slides
and
all
that
stuff,
so
I'll
leave
this
up
for
a
second
well
I
also
say
welcome
to
our
session.
Thank
you
for
coming
yeah,
so
I'll
just
leave
that
for
a
sec
get
logged
in
and
then,
while
you
do
that,
I'm
just
gonna
kind
of
go
over
what
we're
gonna
talk
about
today,
so
that
you
could
discreetly
leave.
If
you
decide
that,
that's
not
something
you
want
to
do
so.
D
So
we're
going
to
kind
of
do
it
from
the
perspective
of
like
real-world
app
development
and
we're
going
to
do
it
from
the
perspective
of
a
simple
game
of
tag
that
we
developed
for
the
IFS
camp.
So
it's
a
little
game
of
tag
that
operates
over
like
lib,
p2p
and
ipfs
in
order
to
kind
of
get
people
interacting
in
a
nerdy
but
fun
kind
of
way.
D
So
we'll
do
a
quick
demo
kind
of
at
the
beginning
of
the
tag
game
and
then
we'll
do
a
kind
of
command
line
version
of
it
to
keep
things
kind
of
simple
in
the
context
of
the
workshop
yeah.
So
we're
gonna
use
some
textile
developer
to
develop
or
developer
tools
that
we've
developed
we're
gonna
go
over
a
bunch
of
kind
of
core
concepts
that
we
use
in
the
sort
of
textile
ecosystem.
D
So
we'll
do
things
like
you
know:
data,
schemas,
decentralized,
database,
kind
of
structure,
a
little
bit
about
identity
and
contacts
and
linking
users,
and
they
only
some
more
social
interactions
like
messaging
likes
comments,
things
like
that
and
how
you'd
integrate
that
into
a
real
real
down.
So
if
you
want
to
do
that
great,
if
you
don't
I'm
gonna
turn
over
this
way
for
a
second,
you
could
just
sneak
out
the
door.
I
won't
feel
bad.
A
D
So
I've
already
mentioned
textile
bunch
of
times.
You've
probably
seen
our
sneaky
stickers
all
over
the
place,
so
learn
about.
Textile
textile
is
a
like
an
ecosystem
of
developer
tools
and
a
network
that
operates
within
or
a
part
of
our
on
top
of
the
night.the
ipfs
network.
So
we
provide
encrypted
recoverable
schema
based
cross
application
data
storage
built
on
top
of
IP
FS
and
live
PGP,
and
someone
recently
described
it
as
sort
of
like
a
layer
2
framework
on
top
of
IP
FS
network.
So
that
might
be
a
good
way
to
kind
of
conceptualize
it.
D
So
it
works
on
the
normal
ipfs
network.
Any
data
that
you
use
add
interact
with
in
a
textile
context,
is
available
by
a
normal
IVFs
gateways
and
all
that
stuff,
except
that
as
we
encrypted
if
you've
encrypted
it.
So
it
would
might
look
weird
if
you
tried
to
access
it
over
a
gateway,
but
in
general,
that's
all
doable.
D
So
then,
on
top
of
this
sort
of
sub
Network,
we've
got
a
bunch
of
develop
developer
tools
that
are
designed
to
take
advantage
of
the
schemas
and
things
like
that.
That
textile
applies
to
data
and
we'll
talk
quite
a
bit
about
that
idea
of
basically
like
enforcing
data
schemas
on
ipfs,
as
as
a
sort
of
thing
example
or
a
big
piece
of
the
textile
framework.
So
that's
what
we're
gonna
do.
That's
kind
of
what
we're
doing.
Here's
a
fancy
network
diagram
that
things
are
made
for
us.
So
half
the
textile
team
is
here
right
now.
E
D
And
then
sander,
Aaron
and
Thomas
or
back
home,
so
there
we
go
okay.
So
this
is
what
we're
gonna.
Do
we're
gonna
kind
of
go
through
concepts,
mostly
in
the
first
half
we'll
take
a
break,
and
during
that
break
I'll
get
you
to
install
some
things
and
well.
You
can
also
take
a
break,
but
then
we
get
back
and
we'll
kind
of
get
hands-on
and
start
playing
around
on
the
terminal
a
little
bit.
So
that's
pretty
much
it
I'm
gonna
assume.
D
You
know
all
the
same
things
that
all
the
other
sessions
have
assumed
that
you
know
what
ipfs
is
and
like
various
things
like
that,
I
think
that's
pretty
safe
assumption
at
this
stage,
not
going
to
assume
that
you
know
like
how
to
do
any
mobile
development
or
JavaScript,
or
anything
like
that.
Just
that
you're
able
to
copy
and
paste
things
it's
pretty
much
all
you
need
to
be
able
to
do
so.
I
think!
That's
it!
Here's
the
structure,
but
you
know
whatever
that's
fine,
so
we'll
do
kind
of
a
bit
of
a
demo.
H
D
Andrews,
just
gonna
run
the
mobile
app
in
a
simulator
on
his
laptop,
so
you
can
kind
of
see
what
things
how
things
are
going
and
then
for
the
session.
We
will
interact
with
the
same
data
and
the
same
sort
of
distributed
database
tables,
but
we'll
do
it
from
the
command
line.
So
the
idea
being
that
you
can
actually
have
different
apps
interacting
with
the
same
data
but
in
different
contexts.
D
H
Cool,
so
we
we're
trying
to
think
about
a
fun
demo
to
bring
so
that
we
could
build
with
all
of
you
and
we
came
up
with
this
game
of
tag.
We
thought
it
had
a
lot
of
really
nice
properties
to
talk
about
decentralized
data,
shared
databases,
verification
event,
and
so
we
started
thinking
that
actually
getting
everybody
spun
up
on
building
a
mobile
app
is
a
really
big
challenge
if
you're
not
already
familiar
with
Xcode
or
react
native
or
swift
or
something.
H
So
what
we
did
is
we
built
the
demo
app
to
show
you
how
it
works
in
a
mobile
phone,
but
today
we're
gonna
focus
on
just
doing
doing
it
over
command
line,
so
you'll
learn
how
the
actual
pieces
are
put
together.
But
this
is
the
game
of
tag
in
the
mobile
phone.
Some
of
you
already
joined
a
game
that
was
running
since
yesterday,
but
I'll
just
show
you
really
quick.
Think
off.
H
They'll
leave
that
game
on
my
phone
I
built
this
to
be
really
lightweight,
so
there's
no
like
there's
no
searching
for
other
people
on
it
or
anything
like
that.
It
all
happens
over
QR
code,
which
was
a
decision
because
speaking
between
Android
and
iOS
devices,
without
some
prior
knowledge
of
each
other,
it's
still
it's
stupid,
but
a
QR
code
works
most
of
the
time
if
it
works
on
your
phone.
So
what's
gonna
happen
is
just
to
like
foreshadow
on
things
that
we're
gonna
talk
about
in
the
workshop
part.
H
So
you
joined
the
game,
and
here
this
users
already
joined
and
they've
called
themselves
the
camp
King,
and
so
they
have
this
identity
in
textile.
That
is
essentially,
you
can
think
of
it,
like
your
PR
ID,
plus
a
little
bit
more
information
like
display,
name
and
some
other
ways
to
find
you,
and
so
now
they
have
this
identity
in
the
mobile
app
and
what
they
want
to
do
is
they
want
to
create
a
new
tag,
game,
and
so
they're
gonna
create
this
game
here.
H
H
Okay,
so
yeah
this,
this
user
wants
to
create
a
game,
and
so
what
we
do
behind
the
scenes,
as
we
just
treat
every
game
like
a
new
database
of
information,
you
want
to
share
and
we
call
those
threads.
So
it
behind-the-scenes
textile
that
the
mobile
sdk
is
gonna,
create
a
thread,
and
here
the
first
thing
that
this
user
needs
to
do
is
create
a
name
so
we'll
just
call
it
the
demo
game.
Okay.
So
now
the
thread
is
created.
The
rest
of
this
is
just
information
that
we
add
to
the
actual
database.
H
H
What
you
need
to
do
is
is
exchange
some
information
about
how
to
find
that
database
and
how
to
unlock
it,
and
so
we
do
that
all
in
this
game,
just
through
this
QR
code
and
what
happens
is
on
my
phone
I
can
just
scan
it,
and
this
QR
code
is
using
some
tricks
in
mobile.
You
can
do
it's
called
deep
linking
so
it's
a
it's
a
link
that
my
app
knows
how
to
open
directly
on
my
phone.
So
when
ice,
if
this
scans
off
the
projector
come
on,
you
are
good,
give
it
a
tap.
H
H
Yeah,
so
here
this
one
now
gets
an
information
that
has
two
players,
so
what
happened
is
I
got
the
information
for
where
this
database
was
and
I
went
and
added
a
record
to
it,
which
we
call
a
join
block,
which
gives
all
the
information
about
Who
I
am
on
this
phone.
So
now
we
have
two
players
in
the
game
and
okay.
So
then
there's
rules
in
the
game
for
how
it
should
be
played.
It's
really
funny
like
if
you
want
to
tag
somebody
with
your
phone.
H
Let's
this
is
a
game,
a
tag
like
on
the
playground.
Go
around
you
tag,
somebody
there
it
that's
a
really
there's
a
weird
thing
to
do
on
the
phone,
so
the
way
that
we
encoded
the
rules
here
is
that
when
the
person
is
it
their
phone,
it's
gonna
be
red,
and
anybody
who
sees
the
red
card
has
to
just
be
it.
What
does
it
mean
to
have
to
be
it?
They're
gonna
scan
that
red
card
and
it's
gonna
be
transferred.
So
what
we
do
is
we
have
this
verified
entry
in
the
database?
H
That's
a
tag
and
the
way
it's
verified
is
the
person
that's
becoming
it
signs
it
with
their
with
their
key.
So
everybody
else
playing
the
game
can
see
that
and
you
know,
and
can
trust
it
like
nobody
wants
to
be
it.
So
they
just
say:
yeah,
I
trust
that
that
person
is
now
it.
So
this
is
an
eternity
to
play.
Unfortunately,
there's
a
there's
a
little
block
out
here.
H
This
person
it
and
so
they're
in
like
the
timeout
for
the
first
five
minutes
of
being
it
and
then
what's
gonna
happen
is
this
is
going
to
turn
into
that
QR
code,
and
maybe
we
can
show
you
this
right
before
that
workshop
I
scan
that
QR
code
that
it
is
going
to
be
detected
on
in
the
database
on
my
phone
I'm
gonna,
verify
I'm
gonna,
believe
it
and
then
the
phone
has
a
record
of
everybody.
That's
been,
it
knows
who's.
Currently
it
and
it
will
be,
it
will
turn
red
and
play
on.
D
Yep,
we
don't
write
any
any
mistakes
in
our
code,
okay,
so
so
that
was
pretty
cool
I
think
got
this
little
game.
So
what
we're
gonna
do
over
the
next
couple
of
slides
is
kind
of
break
down
the
anatomy
of
that
game.
Talk
about
like
what
exactly
tag
is
and
how
we
implement
the
various
components
of
tag
in,
say,
a
textile
style
down.
Okay,
so,
first
of
all,
and
what
does
it
take
to
build
a
game
of
tag
on
ipfs?
We're
gonna
use,
decentralized
concepts.
D
D
Ultimately,
it's
a
bunch
of
people
who've
all
presumably
agreed
on
a
set
of
rules
for
how
that
game
of
tag
should
be
played,
and
some
shared
sort
of
record
or
state
or
understanding
of
the
current
gameplay
right
so
or
you
know
in
another
context,
would
be
a
board
game
of
some
kind
and
then
a
way
to
communicate
and
verify
that
the
rules
of
the
game
are
being
satisfied
and
play
I
mean,
ultimately
that's
what
most
games
are.
So
that's
what
we
need
in
in
this
sort
of
textile
framework.
D
We
have
a
couple
of
core
concepts
that
we'll
use
to
satisfy
some
of
those
conditions
so
identification
or
at
least
identifying
each
other.
We
do
via
something
we
call
data
wallets
and
accounts
within
those
data
walls
and
when
you
do
download
the
slides.
These
links
are
links
to
documentation
on
our
Doc's
website.
So
you
can
kind
of
reference
that
stuff
later
and
but
we'll
also
talk
about
these
concepts
in
detail
in
a
second,
so
identifying
individuals,
we've
got
wallets
and
we've
got
accounts
and
yeah
counts
are
like
kind
of
web
to
a
style
accounts.
D
You've
got
an
avatar
and
a
display
name
and
all
the
good
stuff
that
you
would
expect.
Rules
are
defined
via
schemas.
Basically,
rules
are
defined
by
rules
that
that
control,
how
data
gets
added
to
the
database,
so
schema,
is
very
similarly
in
the
you
would
think
about
database
schemas
more
traditionally
and
then
a
shared
record
or
state
and
communication
are
done
via
what
we
call
threads
threads
are
essentially
just
distributed
database
tables
so
you're,
you
know
ipfs
wallet
or
sorry.
Your
textile
wallet
would
be
like
a
single
database.
D
You
know
in
that
sort
of
conceptual
framework
and
then
each
thread
would
be
a
table
within
that
database
and
you
can
have
a
bunch
of
different
threads
one
per
app.
You
could
have
multiple
threads
per
app
they're,
very
lightweight
and
we'll
talk
about
the
actual
structure
of
a
thread
in
a
little
bit
and
then
obviously
you
need
to
interface
with
the
game
in
some
way.
D
In
the
textile
world,
we
have
a
bunch
of
clients
today
we're
just
gonna
play
around
with
the
command-line
client,
which
is
just
like
a
really
thin
wrapper
around
an
API
that
is
exposed
on
the
desktop.
But
we
have
like
SDKs
for
iOS
Android
JavaScript
whatever
so
each
client
is,
you
know,
sort
of
tuned
for
the
environment
in
which
it
gets
used
and
that's
pretty
much
all
you
need
so
there
that's
how
you
make
a
game
easy
right.
You
just
need
to
know
how
to
do
it
and
then
do
it
correctly.
D
Then
that's
a
game
so
games.
You
know
like
this
or
usually
about
people,
and
so
the
way
that
we
do
that
in
the
textile
world
is
we
use,
wallets
and
accounts
okay.
So
if
you're
familiar
with
sort
of
Bitcoin
concepts,
then
you
might
be
familiar
with
the
idea
of
like
your
coin
wallet,
where
you
would
have
some
sort
of
recovery
phrase.
Sometimes
it's
a
monic
recovery
phrase
bit
thirty.
Nine
might
be
a
term
you've
heard
or
bit
thirty-two
for
a
hierarchical
data
wallet.
D
So
we
use
a
hierarchical
data
wallet
to
basically
allow
you
to
have
a
like
main
key
that
can
be
used
to
derive
sub
accounts,
and
we
kind
of
you
can
conceptualize
accounts
and
I'll
go
into
more
details.
As
we
move
along,
you
can
think
of
accounts
like
different
personas,
potentially
right
so
I
might
have.
You
know,
I
care
about
storing
my
personal
tag,
history,
some
reason
long
term,
but
I
want
to
like
separate
my
workplace
tag
games
from
my
home
tag
game.
D
Obviously,
so
then
I
might
want
to
create
different
accounts
with
different
personas
different
avatars
different
names,
everything
that
are
essentially
sandboxed
from
each
other
but
can
be
derived
and
recreated
from
a
master
key
so
that
if
I
drop
my
phone
in
a
mud,
puddles
example
at
Sandra
uses
all
the
time
he's
very
worried
about
mud
puddles.
If
I
did,
that,
I
would
still
be
able
to
recover
all
of
my
data
from
the
network
afterwards.
D
So
we
use
these
hierarchical,
deterministic
wallets
to
derive
account
keys
and
accounts
are
really
just
private.
Public
keys,
just
like,
or
a
key
pair,
just
like
ipfs
appear
kind
of
set
up.
So
every
account
inside
of
the
wallet
can
be
derived
from
your
Manik
phrase.
So
you
really
all
of
all
is
is
like
twelve
words
or
16
words.
There's
something
like.
However
many
words
you
want
to
have
that's
it,
and
then
from
that
you
can
derive
these
different
attacks.
D
D
Right
so
there's
a
couple
of
fun
things
that
we
did
like
you
know
up.
Your
account
address
is
your
public
key.
It
always
starts
with
the
P.
Your
account
seed
or
key
is
a
practice.
Your
private
key,
it
always
starts
with
P.
These
good
I
mean
s.
Sorry,
because
it's
secret,
that's
your
secret
and
you
can
from
those
accounts
you
can
provision
new
IP
FS
peers
right,
so
each
account
would
have
a
separate
peer
that
it
interacts
with,
and
in
fact
you
could.
D
You
could
even
create
sort
of
ephemeral
peers
so
that
you
use
a
different
peer
for
like
every
app
or
potentially
even
every
session,
of
every
app
that
you
wanted.
If
you
want,
but
in
practice
it's
a
lot
easier
to
just
sort
of
associate
a
single
peer
with
a
given
account
on
a
being
and
give
it
out.
But
what
this
still
allows
you
to
do
is
if
I've
got
you
know
my
iOS
phone
I've
got
an
Android
phone
and
I
want
to
play
tag.
You
know
on
different
phones.
D
I
could
use
the
same
account,
but
each
phone
will
have
a
separate
peer
which
allows
me
to
sort
of
distinguish
between
which
device
is
making
different
updates,
but
those
updates
will
still
get
synced
across
those
devices
and
we'll
talk
a
little
bit
about
how
sync
works
as
well
as
we
go.
So
you
can
think
of
like
this
is
almost
like.
D
Namespacing,
like
we've
got
like
one
global
namespace,
which
is
your
Manik
and
then
below
that
we've
got
these
accounts
and
within
those
accounts
we
can
actually
have
multiple
peers
that
control
that
account
right
with
me
so
far.
Now,
of
course,
you
don't
really
need
to
know
any
of
this
as
a
user
of
a
sort
of
textile
based
app.
D
All
of
these
things
just
get
allocated
automatically
and
generally
any
app
that
just
can
use
a
default
account
and
they
can
assign
a
peer
ID
and
all
that
stuff
very
nicely,
and
so
will
will
kind
of
go
through
that
today.
You'll
see
that,
while
it's
useful
to
know
this
stuff,
you
don't
really
need
to
interact
with
it
very
much.
D
Okay.
So
that's
pretty
much
all
we
need
to
know
for
now.
For
that
ok,
so
then
the
next
thing
is
oK.
We've
got
me
I've
allocated
myself
an
account
based
on
a
identity
and
I
want
to
interact
with
the
other
players
of
the
game,
who
have
presumably
also
got
some
sort
of
wallet
back
account.
So
we
use
what
are
called
textile
threads
and
really
that's
sort
of
like
basis
for
what
everything
else
kind
of
builds
on
top
of
so
by
default.
Threads
are
all
encrypted.
They're
recoverable,
via
your
account
seed.
D
In
general,
it's
useful
to
think
of
a
thread
like
a
decentralized
database
of
encrypted
files
and
messages
shared
between
the
peers
that
are
interacting
right.
So
a
lot
of
this
is
like
designed
for
interacting
with
in
a
game
sense
or
like
textile
photos
is
another
example,
so
these
are
all
peers
that
are
sharing
information
between
them,
so
they
help
each
other
back
up
that
decentralized
database
and
then
as
an
additional
layer
on
top
of
the
like,
so
that
you.
D
Phone
or
appears
right
here
and
I'm
backing
up
my
friends
photos
that
are
there
sharing
with
me
on
my
phone,
but
then
there's
also
an
additional
layer
which
are
the
textile
cafes,
which
we'll
talk
a
little
bit
more
about
later,
which
provide
additional
services
on
top
of
just
regular
peers.
Interacting
we'll
talk
about
that
in
a
second.
So
essentially
these
are
decentralized
databases,
so
they
do
provide
a
bunch
of
nice
services
for
one
another
right,
so
they
provide
things
like
replication.
D
So
all
the
different
peers
are
replicating
the
current
game
state
in
this
in
the
sense
of
a
tag
game.
So
who
is
it
right
now?
All
the
peers
should
eventually
settle
on
the
same
outcome.
They
provide
p2p
updates
via
Lib
PGP.
So,
like
the
actual
interaction
of
tagging,
someone
is
transferring
a
tag
event
as
data
that's
done
by
a
DGP.
They
provide
conflict
resolution.
D
Obviously,
no
one
else
can
yes,
we'll
talk
a
little
bit
about
encryption
a
bit
later,
because
there's
a
bunch
of
layers
of
it,
so
you've
got
your
account
seed,
which
allows
you
to
do
things
like
sign
and
verify
updates
made
by
other
people
or
other
peers.
We've
also
got
these.
The
thread.
Id
is
actually
a
it's
public
key,
and
that
thread
also
has
a
private
key
and
in
order
to
be
allowed
to
update
the
thread,
you
need
to
have
both
of
those
things,
and
that
is
a.
D
Edie
two
five,
five
one,
nine
remember
the
actual
sequence
of
numbers,
one
of
those
key
pairs
and
then,
when
you
add
files
to
a
thread,
each
individual
file
is
also
individually
encrypted
and
the
key
for
those
files
are
added
to
the
threads.
So
really
like.
Files
in
a
database
are
really
just
like
their
IP
FS
reference
and
the
key
to
unlock
them,
and
each
of
those
are
individually
one-time
encrypted.
What's
a
unique
one-time.
D
Yeah
all
yeah,
it's
all
encrypted,
client-side
everything
just
done
client-side
option,
yeah,
there's
no
sort
of
centralized
framework
for
doing
it
yeah,
and
we
could
we'll
talk
more
about
that.
If
you
have
questions
becomes
for
sure
to
answer
them,
yeah
all
the
things
that
databases
do
whenever
queries
access
control
right,
so
you
should
be
fine.
Not
it
I
should
not
be
allowed
to
tag
someone
who
is
it?
D
Similarly,
if
I
don't
have
access
to
the
thread
because
I
haven't
had
the
key
shared
with
me,
then
well,
hey
I,
probably
don't
even
know
about
the
thread
and
therefore
couldn't
do
anything
anyway
but
say
I
had
figured
it
out.
I
wouldn't
be
able
to
do
anything
because
I
don't
have
the
private
key
and
then
there
are
some
additional
controls
in
there.
So
like
a
whitelist
too,
so
that
you
can
ban
particular
peers
and
things
like
that,
if
your.
D
So
this
is
a
sort
of
like
representation
of
threats,
because
threads
are
kind
of
the
most
important
thing
in
this
framework,
which
is
how
we
interact
with
all
the
data,
so
threads
provide
essentially
a
framework
for
doing
you,
know:
storage,
okay,
so
first
the
threads
are
backed
by
a
local
SQLite
in
this
current
implementation,
but
the
actual
database
back-end
is
sort
of
back-end
agnostic,
but
by
default
in
SQLite
database
to
provide
local
replication
and
that's
stored
on
the
local
device.
And
then
all
the
ipfs
data
is
stored
in
the
local
ipfs
peer.
D
But
then
it
also
remote
storage
by
a
sink
with
other
peers.
It
provides
recovery
by
a
sink
with
other
peers.
As
long
as
you
have
your
feet
and
we'll
talk
a
little
bit
about
the
UX
around
that
as
well,
it
provides
a
framework
for
retrieving
data
so
that,
if
I'm
on
my
phone
peer
and
I
add
a
new
file
or
a
new
tag,
event.
D
I
can
retrieve
that
tag
event
off
of
ipfs
on
a
different
peer
somewhere
else,
and
then
it
provides
a
means
to
actually
update
my
my
peers,
within
my
thread,
by
sending
p2p
messages,
getting
p2p
messages
and
leaving
messages
in
an
inbox
framework.
So
one
of
our
key
targets
with
building
textile
stuff
is
running
on
mobile
devices
and,
if
you're
playing
a
game
on
a
mobile
device,
you're,
probably
gonna
kind
of
open
it
up
and
add
a
photo
and
then
you're
gonna.
D
We've
spent
a
lot
of
time,
essentially
tweaking
how
the
network
requests
on
mobile
optimizes
the
sort
of
time
it
has
available
and
then
tries
to
get
out
of
the
way
so
that
it's
not
killing
your
battery
and
network
traffic
and
all
that
stuff,
and
we
run
a
little
bit
in
the
background
as
long
as
the
OS
will
allow
on
an
Apple
device.
That's
like
a
very
little
actual
time.
D
So,
basically,
our
job
is
that
we
fight
against
the
operating
system,
so
you
don't
have
to,
but
that's
this
kind
of
thing
that
you're
dealing
with
when
you're
dealing
it
so
chances
are,
if
I'm
playing
a
game
of
tag
with
Andrew.
My
phone
is
never
on,
or
at
least
never
on
ipfs
at
the
same
time
as
Andrews
phone.
D
It's
probably
you
know
quite
possibly
never
so
there
needs
to
be
some
way
that
I
can
leave
messages
for
Andrew
and
he
can
then
retrieve
them
when
he's
online
and
that's
what
we
provide
or
that's
what
cafes
are
for
and
anyone
can
run
a
cafe.
A
cafe
is
essentially
just
a
normal
textile,
pier
that
provides
a
few
additional
services
to
the
general
network.
So
it's
basically
like
just
running
a
vanilla,
ipfs
node,
except
it's
doing
a
couple
of
nice
things
for
the
textile
network
in
general
and
one
of
those
nice
things
is
offline
in
boxing.
D
So
essentially
my
I
can
register
with
a
cafe
on
my
mobile
device
and
as
a
developer.
I
could
maybe
spin
out
my
own
set
of
cafes
and
have
my
users
register
with
my
cafes
and
then
they
could
do
like
offline
in
boxing
and
things
like
that.
But
any
pier
couldn't
do
it
I
mean
the
incentive
layer.
There
is
sometimes
more
complicated,
but
if
you're
an
app
developer
that
you're
incentive
is
my
users
want
to
keep
their
data.
Yes,.
K
D
Yeah,
basically,
so
the
really
important
thing
for
us
is
that
you,
the
users,
should
never
really
be
locked
into
a
particular
cafe,
and
so
the
cafes
all
have
to
provide
like
a
specific
API,
so
that
they're,
you
know,
transferable.
If
they
don't,
then
they're
not
a
cafe,
but
so
we
just
added
to
textile
photos,
an
interface
where
you
can
actually
like,
add
and
remove
different
cafes.
If
you
want
so
in
theory,
you
could
say
like
okay,
well,
I'll
download
textile
photos
and
I'll
use
textiles
cafes
until
I
decided
like
now.
D
I
want
to
share
like
really
private
data,
that
I
just
don't
trust
textile
to
to
take
care
of
anymore
well,
I'll
run
my
own
cafe
and
I'll
transfer
to
that
cafe
and
all
my
offline
messaging
and
all
my
backup
and
stuff
will
happen
over
there
instead
yeah.
So
in
theory
you're
you
like,
if
you're
a
developer,
you
can
haidle
that
from
your
user.
D
If
you
don't
think
that
they
want
that,
but
you
can
also
expose
it
to
them,
and
you
know
the
I
think
our
idea
of
sort
of
like
the
right
way
to
do
it
is
for
your
power
users.
You
should
expose
the
ability
to
take
and
move
data
with
you,
but
you
know
a
nice
onboarding
experience
is
also
important.
Yes,.
L
D
So
right
now
we're
still
kind
of
like
settling
on
it,
but
it
actually
can
most
of
the
AP
I
mean.
Possibly
all
of
it
now
can
be
implemented
as
leap
Lib,
PDP
services.
So
in
that
sense
it
can
be
like
we
can
have
a
nice
spec
and
you
can
implement
like
as
long
as
you
can
implement
a
live
p2p
service,
you
should
be
able
to
provide
the
café's
services
that
you
mean.
K
D
Yeah
so
I
mean
as
a
bit
of
an
aside.
You
know.
Part
of
the
work
that
we
want
to
do
is
provide
just
a
generic,
like
textile
wallet
style,
app
that
a
user
could
use.
So
they
could
use
that,
like
very
generic
app
to
change
cafes
and
things
like
that
kind
of
under
the
hood
of
any
other
apps
that
are
using
the
framework
yeah.
E
D
Like
I,
like
it
like,
a
power
user,
might
have
the
textile
wallet
app
to
make
those
sort
of
changes
yeah.
Now,
in
some
context,
you
know
like
if
you're,
if
you've
got
some
propriety,
I
know
if
you're,
you
know,
you're
developing
you've
got
some
proprietary
services
that
you
want
to
provide
to
your
users
and
if
they
switch
cafes
now,
suddenly
they
don't
get
those
like
that's
a
possibility,
but
at
least
they
can
take
their
data
with
them
wherever
they
want.
That's
a
big
kind
of
important
thing.
D
D
You
could
use
a
like
hardware
wallet
like
reference
that
stuff,
but
because,
but
it's
all
like
all
the
data
is
off
off
chain
right
so,
like
you
still
have
to
kind
of
assume
that
it's
being
replicated
somewhere
on
IP
FS,
so
like
cold
wallet,
really
would
just
store
like
but
yeah,
but
you
could
yes
I
mean.
So
the
answer
is
yes,
you
could
derive
your
accounts
from
like
a
hardware
wallet,
but
there's
a
lot
of
important
like
external
things
that
you
have
to
keep
in
mind.
M
D
Haven't
added
that
but
like
as
long
as
you
can
like
it,
you
can
use
an
existing
zip,
39
I'm
on
it
I.
You
know
I
probably
got
like
30
different.
You
know,
like
300
different
textile
accounts
here,
because
I
just
keep
accidentally
deleting
things
and
whatever
for
testing,
so
you
can
always
derive
them.
However,
you
want.
We
also
have
a
JavaScript
client
to
like
derive
new
mom
onyx
and
account
something
like
that
too,
which
is
kind
of
nice
standalone
thing
anyway.
So
now
you're
all
experts
in
textile,
that's
how
it
works
very
simple.
Okay,
so.
D
D
So
in,
like
a
textile
photos
context
if
you're
sharing
photos
with
your
friends,
when
you
add
a
photo
eventually
that
photo
will
get
replicated
across
all
the
people
that
are
involved
in
that
thread,
which
obviously
makes
sense
because
they
want
to
be
able
to
see
the
photos
and
we'll
talk
a
little
bit
about
some
kind
of
fun.
Optimizations
that
you
can
do
to
make.
That
sharing
experience
a
little
bit
more
sort
of
like
snappy,
that
our
UX,
oh,
but
then
they
also
do
provide
access
control.
D
So
a
thread
is
essentially
just
like
a
public
key
pin,
public/private
key
pair,
that's
backed
by
so
a
thread.
Id
is
just
its
public
key
and
a
thread
like
access
control
is
controlled
by
its
private
key,
and
the
thread
itself
is
really
just
an
array
or
perhaps
chain
of
blocks
block
updates.
But
of
course,
this
chain
requires
no
sort
of
external
consensus
algorithm
because
it's
just
between
previously
decided
trusted
peers.
So
we
don't
have
to
worry
about
any
sort
of
crazy
consensus.
It's
just
a
block
chain
of
block
updates.
E
D
So
I
won't
go
into
too
much
detail
about
this,
but
there
are
different
types
of
threads
in
general
uses
like
a
CR
DT
to
handle
eventual
consistency.
So
that's
the
like
easy
answer,
but
there
are
other
frameworks
where
we
use
like
deterministic,
merges
and
like
a
time-based
hashes
to
order
things
as
well.
But
yeah
this
sort
of
long
term
or
short
answer
is
magical,
CR,
DT,
so
yeah.
So
there's
a
bunch
of
these
blocks.
There
are
time
ordered
blocks
effectively.
D
It's
a
hash
treat
right
like
it's.
Each
new
block
references,
its
parent
block.
So
the
really
cool
thing
there
is
just
like
on
get
as
long
as
you
have
the
head,
you
can
retrieve
the
entire
rest
of
the
chain
of
updates
and
that's
what
makes
recovery
possible
and
kind
of
magical,
because
all
you
really
need
to
do
is
tell
your
peers.
D
What
the
head
of
the
current
setup
is
and
they
can
recover
the
whole
thing
in
theory,
assuming
that,
like
all
of
the
files
along
there
are
accessible
off
of
my
PFS
one
of
the
cool
things
that
we
just
added
is
that
you
can
actually
traverse
the
entire
tree
now
via
links,
IP
LD,
dag
links
for
those
are
well.
We
all
did
two
sessions,
so
I
can
I
know
that
you're
all
experts,
so
you
can
traverse
the
entire
tree
even
and
never
get
blocked
by
missing
data,
or
something
like
that.
D
D
Block
and
then
obviously
the
block
the
content
so
that
you
can
download
whole
files-
and
there
are
a
bunch
of
different
block
types-
join
blocks,
leave
blocks.
Data
blocks
message
blocks
all
sorts
of
different
blocks.
You
want
a
different
block,
we'll
add
it
I
think.
Recently
we
discussed
adding
like
Reaver
seats,
which
I
hate.
What
yeah
I
know
it's
crazy?
Why
would
you
want
to
improve
it
receive.
E
D
D
So
all
these
different
block
types
will
allow
your
appear
to
react
in
certain
ways,
but
the
main
ones
are
joins
and
data,
probably
data
blocks,
are
sort
of
like
actual
files
added
to
the
database
and
then
yes,
it's
locally
indexed,
and
that
local
index
is
exposed
via
api's
and
a
very,
very
SDK,
so
that
you
can
do
quick
query
things
in
there.
Yes,.
C
D
Exactly
so
we're
running
short
on
time
for
like
going
through
all
the
threads
stuff,
cuz
I
want
to
make
sure
we
have
time
to
actually
get
our
hands
dirty
and
play
around
with
stuff,
but
this
is
sort
of
like
schematic
of
how
that
works
and
essentially
threads,
are
are
driven
by
the
schema
that
defines
their
structure
and
basically,
a
schema
is
just
a
declarative
like
JSON
declarative
document,
or
even
it's
just
a
like
dag.
Even
that
describes
what
the
eventual
day
added
to
ipfs
should
look
like.
D
So
in
this
case,
this
is
what
we
use
for
textile
photos.
So
in
this
case
you
added
two
photos
at
the
same
time,
both
0
and
one,
and
the
schema
which
I'm
going
to
show
to
you
in
a
second
defined
how
the
data
added
to
ipfs
should
be
processed
and
then
added
to
ipfs
and
then
indexed
in
the
database.
So
in
this
case,
what
the
schema
defines
is
you
take
the
photo
you
resample
it
to
a
fairly
large
size.
D
D
D
D
So
the
reason
it
has
the
reason
we
kind
of
use
this
dag
structure
is
because
you
can't
like
make
it
so
that
you
want
to
derive
for
thumbnail
from
the
large
file
which
needed
to
be
derived
from
the
thumbnail
or
something
crazy
like
that
right.
So
it
has
to
be
directed
graph
of
operations,
and
then
we
use
a
kind
of
cool
sorting
algorithm
to
make
sure
that
you
do
things
in
the
right
order
in
order
to
produce
the
output
that
you
want.
D
D
D
But
then,
within
that
data
structure,
you've
got
a
set
of
links,
a
large
one
which
is
going
to
use
this
special
thing
says
you
can
use
the
raw
file,
the
raw
input
file,
you're,
going
to
resize
it
to
a
width
of
800,
pixels
and
80%
JPEG
quality
and
so
on
and
so
forth
for
the
small
ones.
So
the
small
one
you're
also
going
to
refer
to
the
original
file.
You're
gonna
resize
it
to
a
different
thing,
but
to
calculate
the
thumbnail
you're
going
to
refer
to
the
large.
D
Element
so
now,
this
is
like
a
pretty
simple
sort
of
reasonably
flat
structure,
but
you
can
actually
do
pretty
cool
like
deeply
nested
dependencies
and
things
like
that
and
right
now,
and
so
that
that's
getting
more
and
more
complicated
as
we
kind
of
flush
out
schema
implementations.
But
it's
it's
pretty
neat
so
that
you
can
derive
like
meta
from
a
resized
file
that
was
resized
from
the
original.
You
could
all
do
all
sorts
of
fun
things
like
that,
including
working
with
JSON
JSON
data.
D
So
you
can
process
JSON
data
to
keep
only
certain
keys
and
things
like
that
and
mils.
The
last
thing
I'll
talk
about
before
we
kind
of
take
a
break
bills,
essentially
provide
like
decentralized,
client-side
or
a
remote
side,
compute
framework,
so
they
kind
of
are
designed
for
three
things:
to
validate
input.
So
in
the
context
of
like
textile
photos,
they
validate
that
it's
in
fact
a
photo
coming
in
and
that
they're
able
to
resize
it
and
then
able
to
produce
a
photo
output
from
it.
D
D
I'll
refer
you
to
the
docs
and
then
you
can
ask
us
all
sorts
of
questions
about
this
as
well,
but
yeah
we
better
take
a
break
so
I
take
five
minutes
in
the
meantime,
I'm
going
to
put
up
the
install
instructions,
so
we
can
get
started
on
that
and
then
we'll
do
some
hands-on
stuff.
What
time
do
we
have
to
stop?
Okay,.
A
D
D
F
D
The
slide
deck
is
in
there,
which
you
could
copy
and
paste
from
so
yeah,
so
I'll
leave
that
up
there
for
a
second
and
then
once
everybody
feels
kind
of
comfortable
having
downloaded
it.
You
don't
actually
need
need
any
of
this
stuff
to
follow
along.
If
you
don't
mind
typing
a
little
bit
and
I
promise,
there
are
no
multi-line
commands
at
all
about.
Some
of
those
lines
are
very
long.
D
You
know
I,
don't
know
like
how
you
want
to
it's
probably
easier
to
break
it
up
into
little
groups
of
three
or
four
or
something
like
that.
But
if
you
want
to
do
it
on
your
own,
that's
fine
too,
and
then
all
we
need
is
the
go
textile
binary
command
line
tool
that
you've
already
downloaded.
There
are
some
other
things
in
the
workshop
folder
that
we
could
play
around
with
at
the
end,
if
there's
some
time,
but
we
probably
won't
run
out
of
time,
so
you
know
get
the
latest
release
download
the
binary
install
it.
D
And
then
yeah,
okay,
so
cool
that
everybody
has
the
infrastructure
needed
to
do
this.
Hopefully
now,
let's
see
if
the
internet
works
so
first
things
first
open
up
a
terminal
command
line
whatever
you
want
to
call
it
bash
session,
you
know
whatever
and
you
can
type
or
copy
and
paste
text
out
while
it
create
and
you
will
create
a
textile
wall
and
you
should
get
some
output.
D
A
D
Okay,
so
all
this
is
doing,
is
it's
not
saving
or
writing
anything
anywhere?
It's
just
printing
something
on
to
the
out
onto
the
screen
right,
because,
basically
all
a
wallet
is
is
the
month
from
the
monitor
and
so
there'll
be
a
bunch
of
words
up
here.
So,
if
you're
a
developer,
you
would
then
provide
some
way
for
your
user,
maybe
to
copy
that
or
back
that
up
somewhere.
But
since
we're
just
kind
of
fiddling
on
the
command
line,
I
know
you
can
copy
and
paste
it
somewhere
else
or
we're
just
gonna
use
the
first
account.
D
D
So
that's
the
sort
of
long
string
that
started
with
an
S
that
you
just
printed
in
the
last
command
and
what
this
is
going
to
do
is
it's
going
to
provision
in
a
new
textile
peer
which
has
an
account
address
and
associated
secret
key.
It's
going
to
also
provision
an
IP
FS
appear
automatically
and
like
that
ipfs
repo
and
blah
blah
blah
all
that
stuff.
D
You
can
control
the
ipfs
repo
and
pretty
much
all
the
same
ways
that
you
could
control
a
normal
ipfs
repo
we've
added
a
few
things
too,
like
you'll,
automatically
bootstrap
off
of
peers
that
we
control,
but
you
can
change
that.
Obviously
we
use
the
default
IP
FS
ports,
you
can
change
those
blah
blah
and,
of
course
it's
just
a
it's
a
vanilla
ipfs
peer,
so
you
can
also
edit
the
ipfs
config
any
way
that
you
see
fit
as
well.
D
D
O
D
I've
played
around
with
that
and
it
kind
of
does
work,
but
there's
a
few
assumptions
that
we
make
about
how
the
repo
is
configured
that
you
would
have
to
satisfy
and
like
by
default.
We
turn
off
access
to
the
to
the
ipfs
api
from
outside
of
textile.
So
there's
a
few
things
like
that,
but
yes
in
theory,
you
could
use
different
we're
almost
out
of
time,
so
we'll
skip
that,
and
what
we
will
do
is
we're.
Just
gonna
make
a
very
simple
default
thread
using
our
account.
D
Okay,
so
is
everybody
in
initialize
an
account
okay
cool,
so
threads
can
have
these
schemas.
The
most
simplest
schema
that
we
have
is
a
blob
schema,
and
this
is
the
entire
definition
of
the
blob.
His
name
is
blob.
You
could
call
that
whatever
you
want,
you're
gonna
pin
everything
and
you're
just
going
to
like
send
the
data
through
untouched
as
a
like
binary
blob-
it's
probably
the
least
useful
schema,
because
it's
making
no
assumptions
about
structure
or
what
the
dag
structures
is
just
putting
the
blocks
of
data
on
type
EFS.
D
D
D
You
can
give
it
a
like
a
unique
key
if
you're
an
app
developer
and
you're
developing
multiple
different
apps,
and
you
want
to
be
able
to
interact
with
threads
between
those
you
might
give
it
a
special
key
so
that
you
could
reference
it
and
then
what
that
will
do
is
blast
out
a
bunch
of
JSON
which
describes
the
metadata
for
that
threat.
Yeah
and
it'll
look
something
kind
of
like
this,
but
of
course,
it'll
have
a
unique.
A
unique
ID.
D
Everybody's
ID
will
be
different
because
it's
a
unique
private
key
public
key
pair
and
there
you
go
so
now.
You've
created
a
thread,
so
you
might
as
well
start
to
add
some
data
to
it.
So
in
this
case,
I'm
just
gonna
echo
mm
bytes
to
the
terminal
and
type
that
into
your
thread.
So
now
what
you
you
know
just
for
fun.
You
can
copy
the
thread
ID
of
the
thread
that
you
just
created
and
you
can
type
bytes
into
the
thread
as
some
data.
So
in
that
case
you
just
type
the
text
style
files.
D
Add
you
copy
and
paste
the
thread
ID
hit
enter,
and
it
will
just
pipe
some
string
into
there
untouched
and
not
that
not
that
exciting
and
then
what
you
get
back
is
the
block
update.
So
this
is
the
sort
of
like
JSON
representation
of
the
block
that
was
added
to
the
hash
tree
and
you
get
like
the
block
ID
its
target,
which
would
probably
be
the
same
thing
when
it
was
added
the
user
that
so
the
peer
ID
that
actually
added
that
data
plus
a
bunch
of
other
information
about
the
file
structure.
D
And
so
in
this
case
we
use
the
blob.
So
it's
just
going
to
create
a
single
file
dag
with
some
metadata,
including
which
mill
it
was
used
to
process
it,
a
checksum
of
the
files
to
help
with
deduplication
when
you're
indexing
things
and
a
bunch
of
other
useful
metadata,
and
that's
about
it.
And
but
you
know
what
you'll
notice
is
at
the
bottom:
there's
there's
some
empty
arrays
for
comments
likes
and
the
threads
that
it's
a
part
of.
D
So
what
you
can
actually
do
is
you
can
actually
add
this
file
to
multiple
threads
and
it
would
just
D
duplicate.
It
would
just
add
a
reference.
The
same
reference
to
the
file
to
multiple
threads,
so
you're,
not
adding
more
data
to
the
database,
and
you
can
actually
like
comment
and
like
on
individual
thread.
Files
and
comments,
are
really
just
like
messages
that
point
at
a
particular
there's.
H
F
What's
also
nifty
here
is
this
metadata
is
its
own
IP,
FS
content
and
then
the
data
that
were
actually
storing
this
in
biases,
it's
also
its
own
IP
FS
content.
So
it's
useful
put
deduplication
here.
If
what
we're
also
encrypting
things,
so
the
metadata
isn't
going
to
change
their
hash
of
the
content
right.
D
J
J
H
So
there's
actually
a
totally
arbitrary
metadata
entry,
so
you
have
the
data
of
the
file
and
then
you
are
sorry
of
the
content
to
the
file
there.
And
then
you
have
the
metadata
of
the
file,
and
so
that's
yours
to
do
whatever
you
want.
We
have
these
high-level
ones
for
just
some
very
top
generic
things.
Tags
like
whatever
oh
yeah.
Your
metadata
is
yours.
Yeah,
sorry,
wasn't.
D
B
Q
R
H
D
R
D
Okay,
so
what
you
could
do
is
you
can
invite
your
literal
neighbor
to
a
thread
if
you'd
like,
like
actually
the
person
sitting
next
to
you
and
you
can
I,
don't
know
you
could
create
a
peer
pad
normally
as
an
application
developer,
you
have
an
alternative
channel
to
transfer
your
IDs
yeah,
but
you
could
invite
your
neighbor
or
you
can
invite
me
and
then
you
I
would
be
your
neighbor
and
you
can
just
copy
and
paste.
That's
this
Mac
right
here.
That's
the
peer
I
know
you
can
invite
me
to
a
thread.