►
Description
This talk will describe the journey followed from research to implementation of a distributed clone of Vineāthe GIF sharing app. It will touch on the p2p aspects of the app, the nature of distributed apps, and how a blockchain layer is optional when building distributed apps. Then it will continue explaining the high-level plan for the app and the goals that were set.
Finally, it will touch on the implementation details, the dragons, the groundwork, the how-tos and gotchas of using a shared data structure (CRTD) between peers, and a demo of the gif-sharing app.
A
Thank
you
very
much
again
Daniel.
Thank
you
very
much
all
for
attending.
Let
me
tell
you
a
story
about
a
buying
clone
and
in
order
to
do
that,
I'll
spend
just
a
minute
telling
you
how
I
work
at
gather
on
a
daily
basis.
If
any
of
you
are
interested
on
phone
solution
for
remote
work,
I
invite
you
to
check
it
out,
I'm,
a
side
experimenter
guy
by
night.
This
is
where
most
of
the
stuff
comes.
A
Com
comes
from
and
soon
to
be
a
full-time
father,
I'm
gonna
take
a
page
out
of
minters
book
and
I'm
gonna
do
a
product
product
demo.
First
then
I'm
gonna
discuss
the
architectures
of
the
ticket
app
talk
about
the
usage
of
crdts
for
the
multiplayer
async
operations.
A
This
is
not
going
to
be
in
depth
as
Hugo
stock
or
how
Alex
described
crdts
so
highly.
Advise
that
you
go
for
them
for
the
specifics.
This
is
just
going
to
be
a
showcase
for
a
proof
of
concept.
Then
I'm
just
gonna
talk
about
the
takeaways
and
if
there's
any
room,
we'll
go
over
some
q,
a
so
product
first
but
I'm
gonna
show
you
in
a
second
is
a
video
of
Thicket.
A
The
idea
behind
ticket
is
that
you
get
communities
you're
part
of
communities,
because
this
was
built
five
years
ago
there
were
an
associate
research
project.
There
were
a
bunch
of
difficult
things
that
had
to
be
put
in
place
in
order
for
it
to
work.
So
we
had
to
take
out
I
had
to
take
out
some
of
the
harder
stuff
in
retrospective
I
I
wished,
you
can
was
available
back
then
definitely
makes
or
should
make
things
easier
for
the
builders
nowadays,
because
of
that
identity
was
not
built
into
this
dap.
A
The
approach
took
the
idea
of
having
unguessable
URLs
that
would
be
shared
among
Spears
so
that
they
would
all
be
part
of
a
community.
The
again
the
idea,
I'm
gonna
record
you'll,
see
how
a
gif
is
recorded.
We're
gonna,
post
that
gift
to
the
community.
The
link
to
the
community
is
going
to
be
shared
among
Spears
and
then,
whenever
other
peers
visit,
that
link,
they're
gonna
be
syncing
and
you
know
fun
and
frolics
when
you
get
to
share
gifts.
A
So
here's
the
ticket
UI,
basically
I,
created
a
community
then
recorded
a
gif
gifs
are
fun.
I
highly
suggest
that
you
take
a
moment
to
do
that
and
enjoy.
This
spear
is
adding
some
metadata
to
this
GIF
and
then
it's
posting
the
gift
to
the
community.
Then
what
I'm
doing
here
is
copying
the
link
opening
and
incognito
window,
which
triggers
a
different
peer.
This
beer,
syncs
with
the
community,
the
most
up-to-date
state,
goes
into
the
GIF
and
updates
the
metadata
Associated
to
that
gif.
A
A
I'm
gonna
take
that
beer
offline,
bring
in
fire
folks
make
sure
that
Firefox
sinks,
then
I'm
gonna,
post
a
gif
using
this
other
client
and
then
after
that,
you're
gonna,
see
Firefox
is
going
to
do
some
updates
to
the
existing
gifs
and
then
I'm
gonna,
take
Firefox
offline,
bring
back
the
original,
pier
and
you'll
see
how
the
original
peer
gets
the
most
up-to-date
state-
and
this
is
happening
because
of
the
magic
of
crdts
as
a
consideration.
A
We
also
post
the
size
each
community
community
takes
up
on
on
your
computer
so
that
you
know
how
many
resources
you're
giving
back
to
the
community.
That
was
a
whole
idea
behind
calling
these
communities
how
there
there
were
different
layers
put
in
place,
the
not
the
simplest
but
that
layer
I'm
not
going
to
touch
on
is
the
UI
building
uis
building
buttons.
A
Definitely
fun
definitely
suggest
that
you
do
that,
but
the
thing
I'm
gonna
be
focusing
mostly
here
is
the
other
two
layers,
a
ledger
which
I
never
understood
as
a
vacant,
but
there
was
this
misinterpretation
or
misconception
of
decentralized
meaning,
no
back
end.
That's
not
that
case.
If
anything
earlier
today,
I
was
referring
to
ipfs
as
a
distributed
or
share
file
system.
Thank
you
very
much
Daniel
for
correcting
me.
That's
not
the
case
ipfs,
and
this
would
be
one
of
the
key
takeaways
for
me.
A
Whilst
building
a
Dap
on
top
of
ipfs,
it's
more
of
it's
a
Content
addressable
transfer
protocol,
I
I've
already
proposed
that
name
change,
but
no
traction
so
far,
and
so
in
reality
the
the
DAP
connects
to
this
node,
which
would
be
that
back-end
layer
and
then
Bia
that
pops
up
mechanisms
that
come
with
ipfs.
We
get
the
multiplayer
effect
in
a
diagram
type
of
way.
What
ticket
does
you
get
a
swarm
of
peers
connected
to
each
other
which
are
posting
via
the
pops
up
mechanism
to
everybody
connected
on
the
same
topic?
A
And
then
we
get
the
most
up-to-date
state
in
your
store
via
the
magic
of
this
flux
pattern
you
get
the
rendered
state
in
your
UI
and
just
as
a
small
description
of
what
the
ticket
state
looks
like
there
is
a
list
of
Publications.
Each
publication
has
a
metadata
Associated
to
it.
Each
Community
has
a
metadata
Associated
to
it,
and
then
you
each
peer
can
also
have
nicknames
yeah.
A
What
does
what
does
do?
Crdts
do
for
Thicket,
because
we
have
multiplayers.
We
have
asynchronous
operations
happening
at
different
times.
We
need
a
way
to
make
sure
that
every
peer
when
they
connect,
has
the
same
data
structure
and
is
up
to
date
with
all
of
the
operations
that
have
have
happened
within
this
data
structure
and
the
crdd.
This
is
the
magic
that
crdt
did
for
Ticket.
It
normalized
all
of
this
data.
Whenever
this
operation
happened
at
asynchronous
times.
A
I'm
just
gonna
go
over
very
quickly
over
this,
the
most
important
pieces
of
code.
Here
you
definitely
need
an
instance
of
ipfs
ticket
five
years
ago.
What
I
was
doing.
I
was
running
a
full
brow,
full
node
in
the
browser
highly
discouraged
that
you
do
that
way
better.
If
you
connect
to
your
local
node
or
some
node
that
you
that
you
can
offer,
this
was
done
using
the
experimental,
Pub
sub
flag
and
I
try
to
keep
it
very
lean.
A
This
is
a
code
that,
in
Easy
ipfs
instance,
I'll
be
using
that
throughout
the
rest
of
the
code
and
then
for
crdts
I
was
using
a
library
called
Yas
very
kind
utility
works
almost
out
of
the
box
with
ipfs
the
way
you
use
Yas,
you
extended,
extend
it
depending
the
different
resources
that
you're
interested
in
and
whenever
you
instance,
whenever
you
need
an
instance
of
Yas,
you
have
to
send
over
your
pass
a
parameter
of
the
your
ipfs
node
and
several
other
parameters.
A
The
decision
was
made
for
a
ticket
that
each
Community
would
get
its
own
independent
pops
up
room
so
that
you
would
get
not
nor
you
wouldn't
get
noise
in
the
in
the
boss
and
then
crowd
operations.
The
the
the
way
that
we
the
way
that
ticket
posts
images
to
the
node
is
using
the
existing
API
for
adding
files.
Whenever
you
get
the
response
from
that,
you
grab
the
hash,
and
then
you
publish
that
via
your
shared
instance,
in
your.
A
Why
be
at
your
shared
state
in
your
y
instance
and
because
there's
metadata
Associated
to
each
cache,
you
also
publish
that
when
you're
reading
information
you
need
to
get
a
hold
of
the
hash
or
hashes.
You
enumerate
that
by
using
your
say,
the
shared
data
structure.
Whenever
you
have
the
hash,
you
can
get
the
metadata
and
then
you
can
cut
the
the
images
data
directly
from
your
node
instance.
We
perform
I
perform
a
small
transformation
so
that
we
could.
This
could
be
used
in
an
in
image
element
update
operations.
A
Basically,
what
we're
dealing
here
is
a
JavaScript
map
object,
so
you're
doing
set
and
get
operations.
So,
whenever
you
update
this
was
making
sure
that
the
rest
of
the
information
was
there
and
you
just
updated
a
piece
of
information
that
you
needed
and
delete
operations
once
you
have
the
get
hold
of
the
hash,
you
delete
the
Publications
and
as
a
side
effect,
you
delete
the
metadata,
and
this
is
where
the
magic
is
happening.
Every
shared
data
structure
within
the
Y
instance
is
something
that
you
can
observe
that
you
subscribe
to.
Whenever.
A
A
Similarly,
you
you
listen
in
to
Bia
via
the,
why
instance,
to
whenever
users
join,
and
you
have
to
wait
for
this
specific
event
when
synced
to
know
when
to
perform
your
operations
like
hey
this
other
note
came
online,
their
operations
have
been
synced
now,
I
need
to
perform
side
effects
like
updating,
nicknames
or,
if
you're,
if
you
ever,
if
you're
already
subscribed,
your
changes
should
be
propagated
to
your
store,
which
then
should
propagate
to
your
UI.
A
It
was
fun,
I,
hope,
I
haven't
lost,
you
guys
key
discoveries,
whilst
building
ticket
five
years
ago,
I
remember
the
jsipfs
readme
had
a
legend
Beware
of
the
Dragons.
There
were
dragons,
we've
been
joking
around
that.
Maybe
some
of
those
dragons
have
not
been
slain,
but
maybe
they
left
the
premises.
Who
knows
back
then
we
we
ran
into
a
very,
very
weird
situations.
There
was
a
aegir
build
process
which
was
an
in-house
thing
which
wasn't
playing
nice
with
the
create
react
app.
A
So
we
we
had
to
figure
out
a
bunch
of
ways
to
put
everything
together
when
we
were
able
to
build
something
and
put
it
online,
the
things
weren't
working,
and
so
that's
that's
when
we
started
looking
I
started
looking
at.
Why
aren't
nose
connecting
to
each
other
and
that's
when
I
realized,
hey
we're
trying
to
connect
using
these
bootstrap
nodes
given
to
us
by
ipfs
what
happens
if,
instead
of
relying
on
those
because
they
do
not
seem
reliable
enough,
I
use
my
own
note.
A
This
was
mostly
a
proof
of
concept
to
make
to
to
see
if
we
could
have
a
social,
give
social
sharing,
social
sharing
application
for
gifts
using
ipfs,
which
was
successful
and
was
very
fun.
There
was
a
bunch
of
documentation
done
back
then
that
I
published,
if
you're
interested,
not
sure
if
these
slides
are
going
to
be
made
public.
If
not
a
common
come
and
find
me,
I
can
share
link
with
them
to
you
all
if
you're
interested
and
yeah.
If
there
are
any
questions
that
was
it.