►
From YouTube: IPFS Weekly Call 2019-03-11 🙌🏽📞
Description
IPFS Newsletter: https://tinyletter.com/ipfsnewsletter
A
Hello
and
welcome
to
the
ipfs
weekly
call
where
we
get
to
learn
about
all
the
exciting
projects
that
are
happening
in
the
ipfs
community.
Before
we
begin
I
have
a
few
housekeeping
notes.
One
please
add
your
name
to
the
agenda,
notes
that
Terri
helpfully
put
in
a
chat
and
sticking
it
sorry,
Thank
You
Terri
for
taking
notes
for
today.
Terri
is
our
hero
and
second
announcement.
A
So
in
North
America
you
guys
already
had
daylight
savings
time,
so
the
ipfs
weekly
call,
if
you're
in
north
america
it'll
still
be
the
same
time.
But
if
you
are
in
Europe,
then
the
time
will
be
an
hour
earlier,
so
UTC
time
will
be
4:16
p.m.
and
like
CET
would
be
17
p.m.
or
5:00
p.m.
and
I
will
only
be
for
two
weeks
as
of
I.
B
A
C
B
C
C
C
C
C
Was
our
original
programmer
for
the
software,
doing
everything,
and
now,
unfortunately,
for
me
and
for
the
people
that
are
actually
good
programmers,
that's
not
the
case
as
much,
but
my
background
was
government
and
consulting
doing
encrypted
messaging
and
identity
management,
and
things
like
that
for
the
Department
of
Defense
classified
agencies.
Things
like
that.
C
You
got
a
little
bit
of
an
overview
of
what
open.
Bazaar
was
just
there
in
my
introduction,
but
it's
essentially
an
open
source
project
started
in
2014,
we're
working
on
building
a
protocol
and
software
for
e-commerce.
That
is
as
decentralized
as
possible
and
it
uses
crypto
currencies
as
the
only
medium
of
exchange.
I
mean
originated
out
of
a
hackathon
idea
called
dark
market,
which
was
a
basically
an
idea
to
figure
out
how
to
build
a
decentralized
Silk
Road
to
create
a
free
and
open
marketplace
for
the
world.
C
Just
a
quick
overview
of
kind
of
where
open
Bazaar
is
today
yeah.
You
know
it's
it's
it's
a
DAP,
technically,
not
a
theory,
em
DAP,
but
it's
a
DAP
in
our
minds,
and
you
know
even
before
that
you,
you
know
the
term
DAP
existed.
We
currently
get
about
400
to
600
new,
open
Bazaar
nodes
on
our
network
daily
we've
had
almost
a
hundred
and
sixty
thousand
nodes
created
on
the
network.
C
C
So
here's
a
quick
timeline
of
open
Bazaar.
We
started
back
in
2014,
wasn't
based
on
anything
close
to
FS
at
that
time
actually
started
out
as
a
couple
0
mq
nodes
talking
to
each
other
and
was
not
very
scalable,
and
we
quickly
changed
that
network
created
a
1.0
but
we're
ipfs
enters
the
the
conversation
was
probably
late
2016
when
we
decided
to
rewrite
the
entire
thing
on
top
of
Lib,
p2p
and
ipfs,
and
we
launched
that
towards
the
end
of
2017
and
there's
a
couple
of
other
notable
things
on
here.
C
The
open,
Bazaar,
calm,
went,
live
early.
Last
year,
which
you
know
pretty
much
just
is
a
read-only
version
of
our
network.
It
just
uses
our
gateway,
our
ipfs
gateway,
to
serve
up
content
so
that
people
can
search
and
and
browse
the
marketplace
without
downloading
the
software,
and
then,
if
they
want
to
purchase
something
they
can
download
our
app
and
and
do
a
so
in
the
app
and
on
the
horizon.
C
We
have
something
called
Haven,
which
is
our
mobile
version
of
Oakland,
bizarre
and
and
then
later
we're
going
to
be
moving
towards
a
web-based
open
Bazaar,
which
is
kind
of
our
holy
grail.
That
we'd
like
to
use
JSI
PFS
for
at
some
point,
so
hoping
was
our
version
one
we
built
it
in
Python,
we
rolled
our
own
peer-to-peer
protocol,
so
it
was
a
very,
very
basic,
udp-based
network
that
we
we
built.
We
extended
it
to
be
reliable
UDP
so
that
we
could
punch
through
firewalls
and
get
to
home
routers.
C
C
So
that
was
obviously
something
we
wanted
to
fixed
and
and
then
we
also
had
a
lot
of
requests
for
implementing
an
anonymity
services,
either
ITP
or
tor,
and
the
way
that
our
network
was
so
homegrown
it
just
it
wasn't
conducive
to
us
integrating
any
kind
of
tour.
So
that
was
like
a
big
knock
on
what
we
were
doing
as
well.
C
So
we
decided
to
scrap
that
after
looking
at
some
alternatives
and
coming
across
idea,
fest
so
version
2,
we,
you
know
we
were
looking
a
couple
alternatives
to
our
own
peer-to-peer
network,
keen
things
like
mainline
DHT
and
using
the
BitTorrent
Network
and
some
others
made
safe
and
a
few
others.
But
ultimately
we
wanted
to
use
btcd,
which
was
a
Bitcoin
wallet
stack.
It
was
written
and
go,
ipfs
was
written
and
go.
C
We
felt
like
that
was
a
pretty
strong
language
for
building
cross-platform
software,
and
so
we
just
decided
to
make
the
jump
from
Python
to
go
and
adopt
ipfs.
It
made
sense,
so
we
ended
up
rewriting
all
of
the
marketplace
logic
and
go
and
incorporating
ipfs
and
the
p2p
for
our
data
storage,
layer
and
networking.
C
We
actually
created
our
own
onion
transport
and
contribute
that
back
to
you
guys,
so
that
people
could
use
that
as
one
of
the
transport
options
for
the
PGP
and
then
we
built
something
kind
of
clever
on
top
of
ipfs
using
an
offline
messaging
layer.
So
that
allowed
us
to
do
two
things
for
open,
Bazaar
one.
C
They
could
do
that
in
an
offline
way,
so
that
the
recipients
didn't
need
to
be
online
all
the
time
when
they
came
back
online,
they
would
retrieve
all
the
messages
they
had
missed
from
from
my
PFS
and
and
keep
going,
and
then
we
also
adopted
IP
NS
for
our
naming
system
so
prior
to
that
we
kind
of
had
peer
IDs
or
our
version
of
peer
IDs,
and
we
mapped
them
to
like
block
stack,
IDs
and
a
couple
other
things.
In
our
first
version.
C
So
what
makes
our
network
a
little
bit
different
than
the
standard
ipfs
network?
Well,
for
one
thing,
we
use
a
fork
of
the
ipfs
network
so
early
on,
when
we
were
looking
at
ipfs
and
we
wanted
to
implement
the
offline
storage
concept,
we
knew
that
one
day
was
probably
not
going
to
cut
it
in
terms
of
storing
things.
Therefore,
for
offline
support.
C
That
meant
that
you
know.
Obviously,
this
stuff
was
going
to
get
expunged
quicker
than
we
wanted,
and
so
that
was
one
of
the
main
impetus
is
for
for
modifying
the
the
standard.
Ipfs
Network
I
have
actually
spoken
to
several
other
people
that
are
looking
to
build
an
IP
FS
that
have
different
needs
in
that
respect,
so
I
know,
I
I
spoke
with
one
when
I
was
in
Germany
last
week
and
we
discussed
the
ability
to
maybe
flexibly
be
able
to
change
that.
That
would
be
great.
C
We
also
wanted
to
make
sure
that
our
network
was
super
reliable
and
quickly
accessed.
So
we
built
some
custom
indexers
that
crawl
the
entire
network.
We
can
actually
crawl
our
entire
Bazaar
network
in
a
couple
minutes,
and
we
do
so
and-
and
we
put
it
into
elasticsearch
and
you
build
a
search
engine
off
of
that
which
allows
us
to
do
all
kinds
of
different
manipulation
of
that
data
and
query,
what's
available
on
the
network
at
any
given
time
and
provide
caching.
So
we
have
a
search
endpoint.
C
Then
you
can
search
for
listings
search
for
users,
search
for
all
kinds
of
different
stuff,
and
we
also
just
recently.
We
we
also
create
IP
NS
indexes
so
that
you
don't
have
to
make
ipfs
crawls.
If
you
don't
want
to
to
to
get
IP,
NS
records
resolved
and-
and
that's
that's
something
we
built
in
particular
for
our
mobile
app,
which
we're
okay
with
being
slightly
more
centralized
than
our
open,
Bazaar
desktop
nodes.
C
And
then
we
have
gateways
which
we've
kind
of
modified
to
be
our
super
nodes.
And
so
what
we
do
is
we
make
sure
that
our
nodes,
when
they
publish
any
kind
of
data
to
ipfs,
that
we
automatically
send
it
to
our
super
nodes
as
well,
so
that
they
will
be
seeding.
The
content
from
the
from
the
get-go,
so
that's
something
that
we
we
maintain
to
make
sure
that
all
the
content
is
available.
C
This
is
kind
of
a
very
high
level
diagram
of
what's
kind
of
occurring
in
our
architecture,
so
we
have
on
the
left
side
of
the
line.
I
can't
point
to
it
for
you,
but
you
can
see
it.
You
know
we
have
users
using
an
open,
Bazaar
and
they're
there
talking
through
a
front-end
client,
whether
that's
the
mobile
app
or
the
desktop
app,
and
then
we
have
a
whole
architecture
over
there
that
that
talks
to
the
swarm.
We
have
our
seed
nodes.
We
have
our
indexers,
we
have
our
search.
C
C
You
know
how
are
we
using
IP
FS
with
an
app
like
what
are
users
experiencing
so
on
this
screen?
What
you're
seeing
is
are
kind
of
our
profile
view
or
storefront
view
for
users
within
the
desktop
app
people
address
access
their
storefronts
through
an
OB
address,
which
is
basically,
if
you
look
closely,
you
can
see
it's
a
ob,
:,
/
/
and
then
the
the
IP
NS
name
/,
a
path
that
we've
created
as
custom
for
open
Bazaar,
that's
how
they
get
to
their
stores.
C
C
So
what
will
happen
is
when
you
access
the
store,
you'll
pull
down
their
profile,
JSON
from
my
ipfs
and
within
that
egg
has
a
bunch
of
hashes
of
different
content
for
the
images
and
all
that
stuff,
and
it
goes
out
retrieves
that
in
real
time
and
pulls
that
into
the
view,
we've
kind
of
bastardized
ipfs
data
directory
a
little
bit.
If
you
look
at
a
normal,
I,
Pfister
ipfs
directory,
you
only
see
about
I
think
maybe
six
of
those
items
in
there.
For
us
we
had
we've
added
logging.
C
We
have
a
an
out
box
folder,
which
is
where
we
we
store
offline
messaging.
That
I
spoke
about
earlier.
If
they're
using
tor,
then
we
set
up
a
hidden
service
for
them
and
keep
their
keys
in
there,
and
we
also
have
to
keep
track
of
which
version
of
open
Bazaar
they're
on
so
that
we
can
migrate
them
up
and
down
when
they
upgrade
and
and
then
also
in
the
root
folder
that
we
we
pin
to
to
ipfs.
C
C
C
It
basically
sends
them
in
at
a
command
a
special
command
and
those
gateways
that
are
programmed
to
understand
that
and
know
that
they
need
to
request
the
data
back
from
from
the
publishing
node,
and
then
they
seed
it.
That
way,
so
we
kind
of
force
them
to
access
our
content
on
demand,
and
then
they
become
cedars
of
our
content,
and
then
we
move
on
to
publish
to
IPs
and
and
then
eventually,
since
it's
an
IP
NS
our
gateways
index
that
content
and
make
it
accessible
there.
C
So
a
couple
things
to
note
things
that
we've
observed
is
that
one
RI
PMS
publishers
are
pretty
slow,
and
this
is
something
we
struggle
with
a
lot
and
I.
Don't
I,
don't
know
if
this
is
really
an
anomaly.
I
think
it's
just
kind
of
the
nature
of
the
beast
here
right
now,
but
our
publishers
actually
take
between
one
six
minutes,
mostly
between
one
and
two
minutes.
Retrieving
ipfs
content,
though,
is
super
fast
and
we're
actually
looking
to
implement
something
within
our
app
to
do
smart.
So
so
I
mentioned
earlier
in
the
presentation
that
we've
got.
C
We
now
have
our
crawler
indexing,
the
IP
NS
publishing
in
it
it
does
that
so
that
we
don't
have
to
make
IP
n
s,
calls
all
the
time
for
certain
content,
and
so
we
have
a
we
request:
the
data
via
IP
FS
first,
and
then
we
go
in
the
background.
We
kind
of
look
at
I
P
NS,
to
see
if
that
content
is
needs
to
be
refreshed,
and
then
we
we
do
that
if
it
does
need
to
be
updated.
C
We
kind
of
refresh
the
view
later
so
that
the
UX
is
much
better
and
then
we're
also
looking
at
alternative,
tiered
routing
options
so
that
we're
not
completely
reliant
on
the
DHT.
We
might.
We
want
to
have
another
option
to
maybe
have
like
a
HTTP
in
HTTP
into
point
where
we
can
request
data
quicker
than
go
into
the
DHT,
something
we're
currently
building
some
more
of
our
future
plans.
We
really
would
like
to
get
off
of
a
fork
every
time
I
PFS
updates.
C
We
have
to
go
through
a
real,
lengthy,
rebase
and
testing
process
so
that
we
can
get
all
the
goodies
from
the
new
version,
and
we
have
an
issue
on
github
that
we've
shared
with
the
team
with
your
team
to
track
what
we
need
to
do
to
get
off
that
fork
and
it's
kind
of
in
the
weeds.
I
won't
really
go
into
that
right
now.
But
if
you're
interested
I'd
be
glad
to
share
that
link.
C
But
that
would
allow
us
to
you
know,
upgrade
much
more
quickly.
I
think
we
were
on
in
point.
Oh
point:
4.15,
like
four
I
mean
we've
been
on
that
until
like,
maybe
no
actually
we
haven't
even
up.
We
haven't
even
released
0.4
0.8
een,
which
is
what
we're
rebasing
right
now.
So
it's
been
a
long
long
time
and
19
is
already
out,
so
it's
getting
more
difficult.
C
So
one
new
thing
that
I
thought
I'd
be
interesting
to
share
with
you
guys
is
this.
This
app
is
not
out
yet
we're
in
the
final
stages
of
getting
this
done,
and
so
we
get
it
released.
Is
our
mobile
app
called
Haven
and
it
actually
runs
the
exact
same
code
as
the
desktop
on
the
device.
So
it's
a
complete
full
ipfs
node
on
mobile
device.
C
We
cross-compile
ipfs
and
open
bazaar
into
a
armed
binary
and
we
run
it
on
the
device
just
like
we
do
on
the
desktop,
and
so
there's
no
need
for
having
you
know
it's
not
talking
to
a
centralized
server
or
anything
it's
actually
connecting
to
the
peer-to-peer
network
directly
through
mobile.
And
you
know
these
are
kind
of
the
four
pivotal
areas
that
we
want
to
accomplish
with
the
mobile
app,
which
is
like
we're
a
lot
of
people
to
shop
to
do
secure,
Hinda
in
encrypted
chat.
C
They
have
a
multi
currency
wallet
and
then
the
now
I'll
have
social
post.
So
it's
like
a
social
network
built
on
top
of
IP
FS,
so
you
can
like
and
and
post
and
and
start
conversation
threads
on
the
content.
Just
it's
basically
like
a
decentralized
Twitter
built
into
the
app
uses,
IP
FS,
behind
the
scenes
for
that.
C
C
So
that
you
know
notes
can
connect
to
each
other
right
now.
What
happens
is
like
every
communication
is
like
an
offline
message,
so
we
have
to
like.
We
can't
connect
to
a
node
because
they're,
like
they
don't
take
inbound
connections,
and
then
we
have
to
publish
to
the
DHT
as
an
offline
message
and
then
that
other
node
has
to
pull
from.
You
know
the
the
DHT
to
find
out
if
it
has
a
message.
So
if
you're
chatting
with
somebody,
it's
like
very
high
latency,
it's
not
good
circuit
relay
with
our
testing
of
the
rebase.
C
C
We
think
it'll
be
much
more
efficient,
so
I,
don't
really
have
anything
else.
To
talk
about
I
mean
there's,
probably
a
lot
of
questions
you
may
be
have
or
there's
probably
a
lot
more
to
talk
about,
but
I
want
to
like
talk
for
an
hour
here,
for
you
guys
just
thought.
I'd
give
you
some
some
initial
thoughts
of
our
experience
with
it
and
we've
been
working
with
it
for
years
now.
A
C
C
B
A
C
C
We
we
were
very
heavily
reliant
on
I,
pianists
and
DHT,
and
that's
something
that's
been
pretty
new
to
the
Jos
ipfs
I
think
it
just
recently
got
merged,
and
so
we're
trying
to
test
that
out.
We've
had
some
challenges
with
it,
getting
it
to
work,
at
least
in
the
context
that
we're
using
it.
And
but
you
know
it's
a
very
fluid
thing.
We
like
really
just
started
heavily
working
on
it.
A
C
One
of
the
issues
that
we've
had
with
pub/sub
is
that
you
have
to
be
subscribed
to
it
to
get
the
to
get
the
calls
in
the
way
that
our
users
use.
Ip
NS
is
they're
accessing
a
lot
of
nodes
that
they'd
never
known
about,
so
that
first
contact
is
always
slow,
no
matter
what,
but
then
the
subsequent
I
pianist
publishes
or,
like
real-time
so
I
mean
imagine
you're
browsing
through
the
store
like
every
every
storefront
you're
clicking
to
look
at
is
a
new
IP
NS
resolution
and
that's
just
slow.
B
So,
for
instance,
I
just
searched
for
Scotch,
though
so
there's
a
25
year
old,
Macallan
Scotch.
That
actually
looks
really
good
on
open
Bazaar.
But
the
challenge
is
like:
are
you
helping
or
aiding
any
of
the
software
for
the
certifying
the
authenticity
into
those,
or
are
you
relying
totally
on
the
vendors
to.
C
Be
on
yes,
so
so
so
we
are
relying
on
the
vendors.
We
have
implemented
a
program
called
the
verified
moderators
program.
So
in
this
case,
what
happens
is
you
know
in
opens,
or
in
general
the
way
it
works
is
there's
like
it.
There's
three
parties,
there's
the
buyer
and
the
seller,
and
then
there's
a
dispute
resolution
person
called
a
moderator,
so
we
use
like
an
escrow
account.
C
So
if
you
buy
something
for
someone,
you
put
your
cryptocurrency
into
the
escrow
account
and
then
the
merchant
ships
to
the
good
and
when
you're
happy
and
satisfied,
you
release
the
funds
to
the
merchant
in
their
hat.
You
know,
that's
it.
If
there's
a
problem,
a
third
person
can
step
in
and
help
you
know
deal
with
the
dispute.
C
So
in
terms
of
like
authenticity,
the
likelihood
would
be
that
you
would
get
the
Scotch
and
you'd
be
like
this
is
this
is
not
right
and
you
would
file
a
dispute
and
then
you
guys
would
have
to
hash
it
out
now.
The
question
that
arises
from
that
is
like:
okay:
now
can
you
drink?
Can
you
trust
the
moderator?
C
Those
disputes,
if
possible,
but
only
for
a
small
amount
of
the
moderators
and
you're,
not
forced
to
use
that
it's
just
the
added
value
program,
but
we
generally
try
to
stay
away
from
the
from
the
you
know,
hand-holding
in
any
of
the
transactions,
because
it's
open-
and
you
know
we
just
don't-
want
to
expose
ourselves
to
legal
liability
at
this
point
but
yeah.
It's
it's
a
challenge
and
it's
still
not
a
perfect
path,
and
we
have
a
lot
of
the
similar
issues
that
existing
marketplaces
have.
A
C
C
We
we
haven't,
we
haven't
not
that
one
in
particular,
we
we've
got
like
a
library
that
we
did
where
you
can
publish
to
the
dns,
so
you
could
use
DNS
names
to
resolve
your
storefront
you're
like
if
you
have
Brian
store
comm
already.
You
can
put
a
txt
record
in
your
DNS
and
you
can
use
that.
We
also
still
support
block
stack,
IDs
and
ENS,
but
we
haven't
looked
into
D
ID
I'm,
not
not
familiar
with
that
ones.
A
C
Other
than
the
onion
transport
No,
so
basically,
if
you're
running
tor
browser
when
you
fire
up
open
visit
aria,
will
detect
that
and
ask
you
if
you
want
to
route
through
tor
before
you
connect
to
the
network,
and
if
you
do,
then
it
just
relics
that
do
that
onion
transport,
but
we
don't
do
anything
above
and
beyond
that
for
privacy,
so
I
mean
just
just
to
be
clear.
We
haven't
done
a
security
audit
on
open
Bazaar
either,
so
we
don't
promise
that
that
there
aren't
leaks.
In
fact,
we
probably
have
an
Open
DNS
leak.