►
From YouTube: 🙌 IPFS Weekly Call 📡 💫 2019-09-23
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
So
probably
none
just
put
it
in
the
chat
and
then
P
von
Hardenberg
from
you
can
switch,
is
going
to
tell
us
all
about
the
cool
stuff
that
that
they're
building
in
the
sort
of
art,
science,
thinking
and
yeah,
using
what's
the
future
tech
distributed
web
technology
cool
so
can
I
get
a
note-taker.
Please.
B
Lightning
speeds
I
ran
out
of
time
for
anyone
who's
going
to
be
me
in
Japan
for
Def
Con,
that's
on
October
7th
we're
having
an
IP
FS
community
meetup,
hosted
by
the
Japan
protocol
chapter
in
Osaka
and
on
the
12th,
which
is
a
Saturday.
We
are
going
to
have
a
meet-up
in
Tokyo
for
anyone
who's
there
and
so
actually,
whether
or
not
you're
in
town,
if
you're
in.
B
C
Pardon
me
so
yeah
thanks
for
inviting
me.
My
name
is
Peter
van
Hardenberg
I'm,
a
principal
investigator
with
the
Incans
witch
research
labs,
we're
an
industrial
research
lab
motivated
by
the
idea
that
computers
in
computing
are
failing
thinkers
and
creators,
and
that
we
have
moved
to
a
consumptive
mode
of
computing.
I'm,
not
going
to
say
too
much
about
that,
because
this
is
perhaps
a
little
farther
afield
from
the
interest
of
most
of
the
people
on
the
IVFs
call.
C
But,
put
briefly
it's
telling
that
the
MacBook
Pro
no
longer
has
an
escape
key,
which
is,
of
course
vital
to
you
know
a
great
many
professional
software
developers
who
use
VI
the
iPad,
which
originally
kind
of
had
this
promise
of
being
this
incredible
creative
environment.
For
me
and
for
most
people,
I
think
you'll
find
the
iPad
is,
is
most
frequently
used
as
a
Netflix
device.
C
And
we
see,
of
course,
that
you
know
all
of
our
computing
platforms,
including
the
computing
platform
we
spend
most
of
our
time
with
the
phone
are
sort
of
organized
around
an
attentional
metaphor
that
that
the
value
of
a
software
that
software
authors
can
create
is
tied
to
how
much
of
your
time
they
can
get
you
to
spend
looking
at
that
device,
and
so
we
have
these
kind
of
perverse
incentives
in
our
technology.
Stack
that
cause
us
to
spend
our
time
being
distracted
and
being
consumptive
instead
of
being
concentrated
and
focused
and
creative,
and
so
throughout.
C
All
of
the
different
sort
of
acts
of
research
at
the
lab,
we've
been
exploring
these
problems
from
a
sort
of
technical
but
also
philosophical
perspective,
and
trying
to
understand
what
we
can
do
to
to
change
that
so
I'm
going
to
talk
a
little
bit
about
one
of
those
tracks.
That
is,
we
call
local
first
software
you
may
have
heard
of
offline
first
software.
C
The
idea
behind
offline
for
a
software
is
that
your
software
work
offline
first
and
we
kind
of
we
think
that's
very,
very
reasonable,
but
we
kind
of
extended
it
a
little
bit
further
and
added
a
few
more
requirements
and
begin
by
kind
of
asking
a
question.
You
know
who
owns
your
data
now
it's
it's
very
popular
today
to
pick
on
big
cloud
vendors
like
Google,
for
owning
your
data
right
and
if
they
can,
you
know,
shut
down
a
service
and
take
it
away.
C
Was
it
really
yours,
but
it's
more
than
more
than
just
you
know,
sort
of
privacy
or
sort
of
corporate
surveillance
paranoia,
which
I
think
are
perfectly
reasonable,
but
you
know,
if
you
own
your
data,
do
you
have
it
on
your
device?
Do
you
worry
about?
You
know
the
startup
who
makes
the
software
going
out
of
business?
If
it's
your
data,
can
you
choose
what
programs
it
works
with?
Do
you
decide
how
it
gets
shared
if
it's
shared
with
advertisers
and
so
on?
C
These
are
all
different
kind
of
pressures
on
it,
and
you
know
the
the
number
one
thing
that
kind
of
motivated
me
to
worry
about.
This
was
I,
got
really
tired
of
all
the
incredible
journeys
that
my
data
was
going
on.
Without
me,
you
know
we
keep
having
these
sort
of
blog
posts
about
what
an
incredible
journey
it's
been
to
build
some
startup
or
some
product,
but
now
that
journey
has
come
to
an
end
and
with
it
so
has
my
use
of
the
software.
C
Meanwhile,
George
Martin,
who
writes
The
Game
of
Thrones
novels,
continues
to
peck
out
the
latest
Game
of
Thrones
novel
on
an
ancient
IBM
PC
running
word:
star
4.0
under
ms-dos.
You
know
that
that
ownership,
that
deep
longevity
is
not
something
that's
available
to
us
today.
So
gonna
outline
seven
kind
of
principles
of
local
first
software
and
then
I'll
talk
a
little
bit
about
how
how
we
build
local
for
software
at
the
lab.
So
first
and
I
think
it's
important
that
we
put
this
first.
C
These
kinds
of
things
make
huge
huge
differences
to
the
lived
experience
of
consuming
software,
and
you
know
fundamentally,
we
believe
that
local
first
software
has
the
ability
to
be
faster
than
any
other
kind
of
software,
because
if
the
data
is
already
there
on
your
computer,
you
don't
have
to
wait
for
it
to
go
to
Ashburn
Virginia,
you
know
to
fetch
packets
over
the
network
before
you
can
start
showing
results.
You
know
you
know
next
frame
or
your
money
back
has
been
sort
of
a
rallying
cry
for
us,
but
it's
quite
difficult
to
achieve
today.
C
Another
question
you
know
about
local
for
software,
is
you
know,
can
you
actually
use
the
software
on
all
your
devices?
Is
this
software
trapped
inside
you
know
a
single
computer?
Is
your
data
trapped
in
a
computer?
Is
it
stuck
on
your
phone?
Is
it
you
know,
obviously,
for
software
to
be
useful,
your
data
has
to
be
available
where
you
are,
and
that
means
being
available
on
all
your
devices.
C
We
believe
that
humans
are
a
collaborative
species
and
that
software,
which
doesn't
support
collaboration
where
appropriate,
is
just
kind
of
broken
out
of
the
box.
We
talked
a
little
bit
about
the
incredible
journey
problem.
You
know,
will
this
software
have
longevity?
Will
it
live
a
long
time?
Are
you
kind
of
you
know?
Can
you
trust
the
software
to
do
your
most
important,
creative
work
of
your
life?
You
know
if
you
begin
writing
a
novel.
C
Obviously
privacy
and
security
are
concerns
everywhere,
but
particularly
when
we're
talking
about
our
creative
work,
it's
just
not
comfortable
to
feel
that
strangers
or
other
people
might
be
accessing
your
work
without
your
knowledge
and
last
sort
of
talking
about
data
control
and
ownership,
this
little
bit
of
a
umbrella
concept.
But
if
someone
else
can
delete
the
data,
it's
not
your
data.
If
you
can't
choose
where
it
is
or
how
works
or
whether
you
write
to
it,
it's
not
your
data.
You
know
a
concrete
example
here
that
we
talked
about
a
lot.
C
Is
this
idea
of
you
know
people
keep
trying
to
invent
sort
of
right,
protection
for
decentralized
systems
and
I
think
that's
sort
of
fundamentally
misguided,
because
if
the
data
is
on
my
computer
and
I
can't
write
to
it.
Then
it's
not
my
data.
It's
somebody
else's
data.
You
know
if
someone
else
can
revoke
my
access
to
the
data.
It's
not
my
data
and
we
believe
very
strongly
that
that
the
things
on
your
computer
should
be
yours,
and
then
it's
disempowering
and
destructive
of
user
agency
to
to
take
that
away.
C
Okay,
so
that's
you
know
a
brief
philosophical
tour.
I'll
happily
answer
questions
about
it
towards
the
end,
but
I
want
to
talk
about
some
of
our
experiments
in
actually
building
local
for
software.
Briefly,
so,
first,
a
caveat
browsers
are
not
local.
First
I
know:
that's
probably
not
a
surprise
to
anyone
on
the
call,
but
it's
really
amazing
just
how
hostile
browsers
are
to
the
idea
of
not
having
a
network
connection
and
that's
despite
really
good
work
from
people
like
Frances
and
Alex
Russell
to
you
know,
work
on
PW,
A's
and
so
on.
D
C
To
open
up
something
that
I
had
a
PWA,
I
hadn't
used
in
a
few
months,
and
it
just
wasn't
there
anymore,
I
relied
on
that
I
trusted
it
and
I
went
to
load
it
and
it
was
gone
because
I,
don't
know
why
browsers
just
don't
don't
keep
data
locally
they're
not
built
that
way,
as,
of
course
everybody
on
this
call
knows
browsers,
don't
support
all
the
things
that
we
need
to
do.
Peer-To-Peer
networking
and
you
know
fundamentally,
you
just
can't
use
your
browser
in
an
airplane.
C
I
can't
tell
you
the
number
of
times
I've
sort
of
tabbed
to
something
in
my
browser
and
then
you
know,
I
see
it
for
like
two
frames
and
then
the
browser
goes
to
refresh
and
pull
the
data.
It's
gone
super
frustrating,
but
maybe
in
a
place
where
I
would
sort
of
leave
from
the
ipfs
position.
I
also
think
that
the
Dayman
solution
is
is
not
viable.
Asking
a
user
to
install
a
daemon
on
their
computer.
Is
you
know
one
just
sort
of
practically
I?
C
All
you
want
make
that
as
nice
as
you
like,
but
it's
it's
fundamentally
now
you
have
two
things,
and
one
of
them
is
this
weird
mysterious
thing
that
requires
all
this
explanation:
I
just
want
to
open
the
software
and
have
the
software,
and
yes,
of
course,
I've
talked
to
ipfs
people
about
this
before
and
they
say
oh
well,
in
the
beautiful
future.
You
know
every
OS
will
have
ipfs
built
into
it.
That's
nice,
but
you
don't
get
to
live
in
that
future.
C
If
that
you
can't
solve
problems
today
and
I,
don't
really
see
how
that
path
converges
with
the
current
course
and
speed.
Okay,
so
well,
Bowser's
out
what
are
we
gonna
do
yeah
it's
electron,
I
hate
electron
as
much
as
anyone
else
who
uses
an
electron
on
a
daily
basis.
However,
I
had
written
a
lot
of
software
in
a
lot
of
ways
and
at
this
point,
I'm
just
used
to
it.
Electron
is
a
pretty
great
solution
for
building
a
cross-platform
software
and
not
only
that
it
allows
you
to
access
the
wealth
of
skills
and
creative
innovation.
C
That's
going
on
in
the
browser
development
space,
but
without
tying
yourself
to
the
network.
So
oK
you've
suffered
long
enough
through
me
just
sort
of
yammering
on
about
philosophical
principles.
Let's
look
at
some
screenshots
and
talk
about
actual
projects.
We've
done
this
first
project
I'm
showing
here
was
one
of
our
early
projects.
It's
called
pixel
pusher,
so
pixel
pusher
was
an
experiment
in
basically
taking
some
of
our
local
first
principles
and
bringing
them
to
life
by
modifying
an
existing
react.
App
I'll
have
a
link
to
the
blog
posts
of
some
of
these
things.
C
At
the
end,
so
you
can
check
it
out
in
more
detail,
but
what
you
see
here
is
we
took
somebody's
basic
pixel
art
editor
built
with
react,
and
we
bolted
a
sort
of
a
distribution
system
underneath
it
based
on
C,
R
DT,
we've
more
working
on
Clutton
called
Auto
March,
and
so
what
you
see
on
the
right
here
is
a
little
map
of
different
versions
of
this
software.
You
can
see
this
one
maybe
has
some
shading
on
the
pixels
a
little
differing.
This
is
kind
of
chunky.
C
Yes,
maybe
a
little
too
small
fine
details
of
sometimes
a
different
gray
background,
and
what
happens
is
that
you
can
create
Forks
and
then
merge
them
back
up.
So
you
can
basically
sort
of
dynamically
collaborate
with
people
in
this
case
is
only
a
single
user
working
on
each
of
these
that's
the
sort
of
green
rectangle,
but
you
can
imagine-
and
indeed
when
we
were
working
on
the
project,
we
would
create
all
these
sort
of
wild
variations
of
images.
C
And
then
you
can
mix
and
match
anything
and
merge
anything
together
with
anything
else,
and
because
we've
built
around
a
causally
ordered
CR,
dt
conflict-free,
replicated
data
type.
We
can
detect
anytime
to
users
that
edited
the
same
pixel
and
provide
really
intelligent
conflict
resolution
a
later
project.
We
worked
on.
Here's
pushpin.
This
is
an
earlier
version
of
pushpin.
I
can
show
life.
People
are
interested
later.
What
looks
like
today,
but
pushpin
is
sort
of
cards
on
a
canvas.
There's
a
number
of
products
based
around
these
ideas.
C
But
again
the
idea
here
was
exploring
what
does
collaboration
look
like
in
a
more
user
friendly
kind
of
way,
and
so,
while,
yes,
you
can
see
the
sort
of
cards
on
a
canvas
here,
a
lot
of
the
magic
is
in
the
title
bar
at
the
top.
Where
we
were
exploring
questions
about
you
know,
what
does
it
mean
to
meet
another
user?
How
do
you
track
identity
and
presence?
C
And
so
you
can
see,
for
example,
here
there's
a
little
green
ring
around
Adams
avatar,
and
that
means
that
he's
online
and
he's
broadcasting
on
a
pubsub
channel
a
little
sort
of
heartbeat
so
because
I
know
him.
I
can
see
that
he's
online.
If
he
selected
some
of
these
cards,
I
would
see
his
selection
state
more.
That
later,
we've
done
a
number
of
other
projects,
including
capstone,
which
we
wrote
pretty
extensively
about
published,
which
was
built
as
a
Google
app
Google
apps
are
a
bit
like
electron,
apps
I'm,
currently
calling
you
from
a
pixel
book.
C
So
that
was
ultimately
my
advice
is
don't
pick
Google
Apps,
not
that
Google
would
tell
you
to
for
your
projects,
and
then
we
also
built
one
called
farm
which
I
don't
have
any
screenshots
of.
Sadly,
but
it
was
a
really
interesting
experiment
where
we
basically
paired
a
CR
DT
document
that
could
change
over
time
collaboratively
to
code
for
a
web
component
written
in
the
elm
programming
language.
That
was
also
itself
OCR
DT.
D
C
Using
the
software
together,
that's
a
lot
of
fun,
but
ultimately
quite
challenging
to
sort
of
rationalize
for
the
user.
So
I
want
to
talk
a
little
bit
briefly
now,
having
built
we've
been
at
this
almost
three
years:
building
various
research
projects
and
experiments
I
want
to
talk
about
the
things
that
I
see
as
working
in
the
things
that
I
see
is
not
working,
so
things
that
are
working
really
well
include
because
I
think
this
notion
of
standalone
software
is
something
that
I
would
like
to
see.
C
More
people
internalized,
it's
amazing,
to
work
on
a
piece
of
software
and
that's
it
to
sound
silly.
But
you
know
having
been
a
web
person
for
a
long
time.
You
kind
of
have
this
like
tripartite
world,
where
there's
always
a
data
stack,
an
API
stack
and
then
it
front-end
stack,
and
then
you
have
to
deploy
it
afterwards
and
it's
just
so
incredible
and
empowering
to
you
know,
have
a
piece
of
software
and
to
work
on
it
and
to
use
it
and
it
works
and
you're
done.
C
You
know
if
it
works
on
your
machine,
that's
literally
it
that
somebody
else's
machine
is
probably
going
to
have
the
same
behavior.
There's
no,
you
know
separate
deploy,
step.
There's
no
separate,
you
know
platform,
that's
different!
You
don't
have
a
migration
to
run
and
prod.
You
know
your
computer
is
where
the
software's
kalypso,
if
it
works
it
works.
We've
been
very
pleasantly
surprised
by
just
how
well
CRD
t's
work
in
terms
of
ordering
and
collaborating
on
data.
C
Specifically
the
CR
dt
we
work
on
is
something
called
Auto
merge,
there's
lots
of
stuff
written
about
it
out
there
Americans
always
out
talking
about
it,
but
Auto.
Merge
is
a
sort
of
a
JSON
like
CR
DT,
which
is
to
say
it's
a
series
of
lists
and
maps
that
can
nest
together,
sort
of
arbitrarily
with
values
in
them
and
that
models
a
lot
of
data
use
cases
really
well
so
I.
C
That's
surprisingly
good,
we
were
really
worried
about
sort
of
conflict
resolution
and
the
challenges
of
like
making
you
know
dealing
with
things
arriving
in
different
orders,
from
different
users
and
people
creating
problems
and
in
pixel
pusher.
We
did
a
bunch
of
work
around
you
eyes
for
that,
but
really,
surprisingly,
for
us
working
on
later
projects,
we
discovered
that
for
the
most
part
while
conflicts
can
occur,
humans
seem
to
have
relatively
strong
innate
collaboration
sort
of
intuitions
and
so
don't
create
problems
for
each
other.
C
That
was
a
big
surprise
positively
and
also
the
sort
of
functional
reactive
programming
model
that
react.
The
Elm
kind
of
model
is
a
really
good
fit
for
decentralized
systems,
because
you
have
a
very
clear
separation
between
the
data,
the
transform
function,
hardening
the
data,
the
transformation
of
the
data
to
a
UI,
and
then
events
coming
back
from
that
UI
into
the
data
which
maps
really
well
on
to
an
environment
where
your
data
could
be
updated
either
locally
or
by
any
remote
user.
C
So
that's
all
good
things
that
suck
basically
NAT
traversal
is
a
super
big
problem.
This
is
no
surprise
to
anyone
here,
but
we'll
talk
more
about,
particularly
where
my
worry
is.
Their
mobile
support
is
quite
dire
and
it
worries
me
that
I
don't
see
much
recognition
of
how
bad
it
is
doing.
A
good
job
of
mobile
support
is
not
like
getting
this
stuff
working
on
react.
C
You
need
to
worry
about
not
draining
the
battery
by
doing
things
in
the
background,
there's
so
much
subtlety
and
important
research
that
needs
to
be
done
there
and
I
don't
see
it
happening,
and
if
anybody
is
doing
it
out
there
I
don't
mean
any
insult
by
it.
It's
possible
I,
don't
I,
haven't
seen
your
work.
C
C
I
think
that
if
you
attract
people
chasing
that
you
will
not
get
the
best
developers
or
the
best
work
I
think
that
ultimately,
every
sort
of
generation
of
software
needs
to
find
a
viable
business
model,
and
but
the
trap
that
needs
to
be
avoided
here
is
what
I
would
call
kind
of
like
the
open
source
consumer
software
problem
like
OpenOffice
sucks,
the
UI
is
terrible.
It
was
never
competitive
with
what's
best
in
the
and
I
think.
C
A
lot
of
that
is
because
the
best
designers
and
people
from
that
community
were
always
alienated
by
open-source
software
and
open-source
culture,
and
so
we
never
really
got
great
UI
is
built
in
the
open
source.
World
I
hope
that
this
world
can
someday
be
the
best
way
not
just
to
make
software,
but
also
the
best
way
to
make
a
living
and
because
you
don't
give
up
control
over
your
creations,
and
you
don't
need
a
giant
team
to
get
things
done.
So
hopefully
that
can
be
the
case.
C
Also
just
broadly
performance
is
a
huge
issue
in
the
web
stack
running
things
at
60
frames.
A
second
which
we
talked
about
the
importance
of
earlier
is
really
really
hard.
Borderline
impossible
and
I've
had
lots
of
deep
conversations
like
chrome
team
people
about
this
stuff
and
they're.
Basically
like
yeah,
it's
it's
hard
and
in
our
particular
case,
I
think.
A
lot
of
the
focus
in
the
community
early
was
around
like
anti
censorship
or
sharing
a
scientific
data.
C
These
kinds
of
things,
so
there
hasn't
been
a
lot
of
you-
can
do
privacy
sure
you
can
encrypt
your
blobs
before
you
share
them
with
them.
That
creates
new
problems,
they're
just
talking
briefly
about
the
net
reversal
issue.
This
is
kind
of
the
worst
case
from
that
traversal,
which
is
that
you
are
at
a
coffee
shop
with
your
collaborator.
A
very
common
case
in
a
coffee
shop
is
that
the
router
will
be
configured
with
sort
of
guest
network
access,
which
means
that
mdns
or
all
local
kind
of
an
you
to
me
traffic
is
blocked.
C
So
of
course,
then
you
go
out,
and
you
say:
okay
well,
we'll
do
a
sort
of
loopback
natura
tour.
So
we'll
do
this.
You
know
I'll
connect
up
through
the
internet
and
back,
but
the
router
sees
that
traffic
and
goes
this.
Is
this
isn't
right?
Why
would
I
want
to
make
the
loopback
NAT
traversal
to
myself?
That's
crazy,
so
it
drops
that
and
the
result
is
that
there's
just
no
way
for
you
and
me
to
connect
if
we're
in
the
same
room
on
the
same
Wi-Fi.
C
If
one
of
us
jumps
onto
our
phone
connection,
everything's
fine,
but
unfortunately
it's
not
just
in
coffee
shops
that
this
happens.
It's
also
in
air
B&B,
x',
it's
at
universities
and
it's
in
company
networks
and
so
I,
don't
see
anyone
with
a
solution
to
this
problem.
I
think
broadly,
the
most
credible
solution,
I've
seen
is,
is
something
like
stun
return.
You
know
kind
of
having
proxy
nodes
out
in
the
network,
but
that's
really
fragile.
C
That
kind
of
fails
the
longevity
test,
which
is
that,
if
you
know
all
of
this
traffic
has
to
be
routed
by
like
a
benevolent
corporate
benefactor,
that's
operating
a
service
in
the
hope
of
maintaining
the
reliability
of
the
network.
Then
that
only
works
as
long
as
they
feel
like
paying
to
do
that
and
that's
not
sustainable,
so
I
hope
somebody
will
work
on
that.
C
We've
built
all
our
stuff.
On
top
of
that,
that
is
a
lot
like
ipfs.
If
you're
not
familiar
with
it,
it's
a
another
peer-to-peer
data
sharing
stack
and
with
that,
rather
than
having
the
addresses
of
content
being
the
hash
of
the
content,
the
address
of
content
is
a
public
key
that
signs
the
content
and
then
each
block
in
the
content
is
signed
with
the
hash
of
the
previous
content.
So
you
can
create
a
nice
consistent
depend
on
the
log
system
with
sort
of
the
robust
self
checking
which
is
quite
cool.
C
I
know
there
are
supposed
to
be
ways
to
emulate
this
using
IP,
NS
and
I
feel
T,
but
the
performance
of
doing
all
of
those
lookups.
It
makes
it
completely
impossible
for
the
kind
of
real-time
collaboration
that
we
do.
I'd
be
interested
in.
Looking
more
at
that,
and
my
last
kind
of
point
for
the
IP
ifs
project
is
that
I
think
pinning
is
like
totally
the
wrong
frame
to
think
about
data
through
I.
C
C
I,
think
that
should
be
the
default
and
we
could
consider
sort
of
ways
to
relieve
pressure
if
that
was
a
problem,
but
it's
kind
of
the
wrong
metaphor
and
I
think
it's
created
so
much
churn
in
terms
of
like
people
doing
all
kinds
of
complicated
incorrect
things
to
try
and
solve
these
problems,
both
at
the
user
experience
level,
but
also
at
the
technical
level
to
try
and
work
around
this
and
last
very
briefly,
I
think
I'm
well
over
time
here.
So
I'll
speak
quite
shortly
about
this
think.
C
You
know,
as
we
move
up
the
stack
into
end
user
experiences,
we're
encountering
a
whole
new
universe
of
user
experience
challenges.
So
it's
one
thing
to
say:
oh
this
person
is
present
or
not,
but
why
am
I
not
able
to
connect
to
you?
Are
you
seeing
what
I'm
seeing
you
know?
Are
we
in
sync?
Are
we
out
of
sync?
How
can
I
tell
do
I
have
a
connection
to
you
locally
on
our
local
Wi-Fi
that
we're
in
an
airplane
at
30,000
feet,
but
not
beyond
there?
C
C
Person
that
offline
camp,
but
that's
not
really
something
that
we
have
the
mental
framework
or
the
user
sort
of
experiences
to
communicate
or
talk
about
so
I-
think
there's
a
lot
of
really
interesting.
Ux
work
further
up
the
stack
that
needs
doing
and
we've
been
exploring
that
Thanks
I
could
talk
for
a
long
time
about
the
stuff.
I
talk
properly
for
a
little
tooth
already,
but
you
can
read
a
lot
more
we've
written
a
lot
more
and
we
have
lots
more
that
we
have
done
and
not
written
about
so
feel
free
to
reach
out.
C
C
A
C
Well,
we
have
a
number
of
projects
going
on
right
now
at
the
moment.
There's
a
team
working
on
pushpin
we're
interested
in
taking
it
from
a
research
prototype
to
something
that
users
can
really
use.
We
think
that
the
next
sort
of
step
in
the
maturation
of
this
space
is
actually
putting
something
into
end-user
hands.
There's
a
lot
of
work
to
do,
but
we're
sort
of
making
progress
on
that
synchronization
status
is
something
that
we're
working
on
this
week,
which
is
ok
grades.
C
You
know,
we've
shared
data
we're
connected,
but
like
can
I
see
what
you
see.
How
do
I
know
if
you're
offline,
how
do
I
know
where
you
were
last,
if
I
have
the
same
program
on
my
desktop
and
my
laptop,
you
know
am
I
caught
up
in
my
head.
Am
I
behind
how?
How
do
you
think
about
all
of
this?
How
do
you
communicate
all
of
this,
and
how
do
you
do
it
without
creating
like
a
giant
spreadsheet,
of
vector
flocks,
so
those
are
UI.
Problems
were
working
on
today,
literally
yeah.
A
C
A
C
Our
CRT
T's
are
built
out
of
long
chains
of
individual
operations
by
actors,
so
my
machine
I'm
calling
you
from
might
be
one.
My
other
laptop
might
be
one.
Your
laptop
might
be
one,
and
each
node
produces
a
chain
of
work
that
then
you
need
to
sort
of
you
feed
all
that
into
a
box.
You
shake
it
and
then
a
document
pops
out.
C
This
is
not
rocket
science,
but
because
each
operation
refers
to
all
the
previous
operations
that
all
need
to
be
resolved
before
you
can
render
the
document
it's
extremely
tedious
and
expensive
to
walk
all
the
way
back
through,
like
an
IPSS
chain,
goes
Allah
by
the
way
has
been
looking
at
some
of
this,
so
you
may
have
heard
some
of
these
things
from
him.
He's
been
looking
at
out
on
urgent
our
work
for
awhile,
so
it's
possible.
C
You've
already
got
some
of
these
versions
of
it,
but
the
extra
challenge
is
that
I
also
would
like
to
be
able
to
have
storage
nodes
that
I,
don't
trust
with
the
contents
of
the
data.
I,
don't
want
to
have
to
upload
unencrypted
versions
of
my
data
in
order
for
this
sort
of
traversal
to
work,
which
means
that
there
needs
to
be
some
kind
of
structure
around
this,
but
even
more.
C
Concerning
Lee,
you
can
learn
all
awful
lot
about
a
person
and
what
they're
doing,
even
just
by
watching
the
structure
in
the
stream
of
this
traffic
and
so
I
have
I'm
not
sure
what
the
answer
here
is
in
terms
of
how
to
distribute
these
kind
of
flows
of
data
without
creating
these,
like
really
privacy
violating
side
channels,
I.
Think
the
scuttlebutt
approach
of
building
sort
of
like
fat
logs
that
have
a
lot
of
data
in
them
and
then
sort
of
D
mixing
them
in
clients
is
interesting.
But
that
has
all
kinds
of
performance
problems.
C
So
I
think
there's
a
lot
of
like
we
can
make
small
improvements
on
the
technical
problem
and
that's
good
and
necessary.
Just
the
ability
to
query
like
a
whole
linked
list
and
a
single
query
would
be
nice,
but
I.
Think
that
there's
quite
a
bit
more
work
to
do
past
that
madam
I'm
not
sure
what
the
state
of
the
research
is.
There
yeah.
D
Let
me
quickly
quickly
as
say
that
we
have
a
new
thing
called
and
I
peeled
these
selectors,
which
is
exactly
this,
so
you
can
basically
then
query
yeah
chains
of
things
or
complete
trees
and
it's
currently
in
mostly
in
the
spec
repository,
but
there's
a
JavaScript
implementation
for
it
these
days.
No,
no!
D
C
D
I
will
I
will
post
a
link,
I
have
to
find
it
myself,
okay
and
then
there's
also.
What
we
are
also
truly
work
on
is
IP
LD
schemas
and
this
kind
of
is
related
to
you
can
kind
of
define
the
structure
of
your
data
in
the
schema,
but
it
would
then
be
kind
of
independent
of
your
blocks,
so
you
can
kind
of
have
for
your
application.
You
would
still
have
the
kind
of
like
link
stuff
and
blocks,
but
what
do
expose
might
be
I
squash.
It
into
a
single
block,
for
example.