►
From YouTube: OCTO Speaker Series #7 Peter van Hardenberg
Description
Local-first Computing
We were promised "bicycles for the mind", but the vision of computers as tools for thought remains elusive. In our pursuit of this ideal, we have identified design principles we call "local-first software" that can help our software run faster, last longer, and cost less to build. We'll start by talking about the ideas that motivate our research, then look at some real-world prototypes and the technologies behind them, and finally talk about the challenges still outstanding.
Peter van Hardenberg has worked as an Arctic oceanographer, a game developer, wrangled a (literal) million Postgres databases, and is now Executive Director of Ink & Switch where he plots the future of tools for thought.
twitter: @pvh
GitHub: pvh
web: https://inkandswitch.com/
A
Hi
everyone
welcome
to
the
seventh
episode
of
the
octo
speaker
series.
My
name
is
idan
and
I
run
the
developer
experiences
research
team
in
github's
office
of
the
cto.
Today
our
guest
is
peter
van
hardenberg.
I've
had
the
pleasure
of
working
with
peter
previously
at
heroku,
where
he
formed
a
data
team
that
operated
something
on
the
order
of
a
hundred
thousand
databases
per
engineer,
but
it's
his
latter
day.
A
Work
running
inc
and
switch
that
I
think
most
about
in
my
work
here
at
octo
tools
for
thought
is
the
banner
that
hangs
over
a
lot
of
the
research
at
ink
and
switch.
How
can
we
use
these
amazing
little
rectangles
in
our
pockets
and
on
our
desks
to
help
our
brains
reason
about
more
complex
things?
What
will
arrange
information
so
that
it's
easier
for
us
to
spot
patterns
and
understand
behaviors?
A
A
A
One
final
note
before
peter
comes
on
we'll
be
taking
questions
in
the
github
discussions
thread.
The
url
is
down
here
on
the
screen.
I'll
also
try
to
keep
an
eye
out
for
questions
and
twist
chat.
Please
keep
things
positive
and
welcoming
to
everyone.
We've
got
a
code
of
conduct
in
the
repo
that
the
discussions
thread
is
on
and
it's
important
to
us
that
everybody
abide
by
that.
So
without
further
ado.
B
B
B
This
is
an
image
of
the
eniac
main
control
panel.
Eniac
was
the
first
programmable
computer.
The
year
was
1946..
The
war
had
just
been
won
by
the
americans.
If
you
believe
american
popular
history
and
this
first
computer
was
used.
Predictably,
because
it
was
built
by
the
military
to
serve
military
aims,
it
was
built
to
calculate
field
artillery
firing
sheets,
or
rather
it
was
built
to
prove
a
point,
but
its
first
application
was
to
calculate
these
tables
quickly
and
efficiently.
B
The
effort
to
build
eniac
was
undermined
and
thwarted
by
the
man
we
see
depicted
here,
promoting
the
first
google
glass
van
of
our
bush
venevar
bush
was
the
leader
of
the
u.s
science
and
research
effort
and
helped
organize
the
manhattan
project
and
was
not
actually
much
of
a
fan
of
computers.
He
didn't
feel
that
they
would
be
built
in
time
to
help
win
the
war,
which
was
his
his
mandate
to
his
credit
or
perhaps
because
of
his
undermining.
B
In
fact,
eniac
wasn't
completed
until
1946
and
so
did
not
actually
help
the
allies
win
the
war,
but
even
at
this
time,
venevar
was
interested
in
what
came
later
to
be
known
as
intelligence
amplification,
which
was
to
say
what.
If
we
had
machines
that
went
beyond
helping
us
work
that
gave
us
mechanical
advantage
and
started
to
consider
machines.
That
would
give
us
intellectual
advantage.
B
This
is
the
memex
it
was
published
in
1946
in
the
atlantic
again,
the
sort
of
just
before
the
interregnum
between
wars
at
the
end
of
world
war
ii
and
before
the
cold
war
really
started
to
ignite.
And
you
know
he
proposed
a
complex
mechanical
system,
which
many
people
have
tried
for
decades
since
to
rebuild
either
in
spirit
or
in
in
actual
form.
B
You
know
the
mind,
discovered
computers
in
the
I
guess:
late,
50s,
early
60s
and
wrote
this
paper
man-computer
symbiosis,
which
proposed
that
you
know
computers
could
make
people
smarter,
not
just
the
sort
of
modern
idea
that
oh
computers
will
replace
intelligence,
but
the
computers
could
enhance
intelligence.
This
came
to
the
attention
of
of
leaders
in
the
new
arpa
institution
and
led
to
his
involvement
as
a
human
factors.
B
B
If
you
watch
the
video
or
read
the
paper
today,
as
you
can
see,
you
know,
sketchpad
occupied
an
entire
wall.
It
used.
You
know
very
rudimentary
images,
but
it
allowed
for
direct
manipulation
of
drawings
and
basically
gave
birth
to
cad,
and
what
I'm
drawing
here
is
perhaps
not
the
most
in
any
way,
the
most
comprehensive,
or
indeed
even
like
usefully
accurate
history
of
human
factors
in
computer
science.
B
But
what
I'm
trying
to
do
is
basically
create
a
thread
that
stretches
back
from
these
early
1930s
systems
to
today
and
sutherland
was
brought
in
by
lick
to
actually
work
on
these
systems
and
sutherland,
of
course,
inspired.
Engelbart
engelbart,
famously
the
the
man
behind
the
mother
of
all
demos,
or
at
least
credited
with
the
mother
of
all
demos.
B
All
of
this
was
around
again
this
idea
of
amplifying
the
mind
that
we
could
use
computers,
not
just
to
you
know,
compute,
to
calculate
to
you
know,
estimate,
but
to
actually
symbiose
with
human
mind
and
extend
it
and
empower
it
right.
Much
like
you
know,
a
sound
amplifier
can
take
a
quiet
noise
and
make
it
louder.
We
wanted
a
mind
amplifier.
B
I
love
this
metaphor
by
the
way
of
the
bicycle
for
the
mind,
as
so
many
people
do,
because
a
bicycle
gives
you
mechanical
advantage,
but
it's
designed
to
be
nimble.
You
know
it's
not
a
battleship,
it's
not!
You
know
it's
not
a
tank.
Its
purpose
is
not
to
dominate
or
destroy.
It's
to.
You
know
to
give
you
advantage
to
make
you
more
agile
and
to
get
you
places
you
couldn't
get
on
your
own.
B
B
But
the
sort
of
general
principle
here
is
of
symbiosis
of
extension,
of
partnership
between
a
person
and
a
computer,
and
I
think
this
is
an
important
concept
to
internalize
the
strongest
chess
player
in
the
world
is
not
a
person.
You
know
deep
blue,
beat
kasparov
and
took
the
title
for
computers
decades
ago.
B
Now
it's
also
not
a
computer
program,
though
the
strongest
chess
player
in
the
world
is
a
centaur
and
there's
a
form
of
chess
competition
called
centaur
chess,
where
human
players
paired
with
software
compete
against
each
other
and
at
least
today
that's
still
the
strongest
way
to
to
play
chess,
and
so
this
concept
of
a
centaur
of
a
person.
You
know
made
stronger
made
more
capable
by
by
the
computer
systems
that
they
employ
it's
something
we
see
in
a
lot
of
domains.
B
B
In
fact,
we've
seen
a
lot
of
retrograde
action
around
computers
as
tools
for
thinking
in
the
last
couple
of
decades,
and
a
lot
of
that
has
to
do
with
changes
in
the
platforms
that
we
use
to
do
our
our
to
engage
in
our
computing
lives,
and
you
know
push
notifications
is
a
lot
of
talk
about
the
attention
economy
and
push
notifications
and
distraction.
And
of
course,
that's
a
huge
feature.
B
B
The
basic
set
of
tools,
a
woodworker,
uses,
a
chisel,
a
saw,
you
know,
they've
been
electrified
and
even
computerized.
But
fundamentally
you
know
there's
a
set
of
composable
tools
that
could
produce
almost
anything
made
of
wood
and,
in
fact,
in
the
wood
shop.
Four
different
artists
and
artisans
share
the
space
and
the
tools
to
both
have
the
camaraderie,
but
also
to
you
know,
because
their
tools
are
interchangeable.
B
It's
remarkable
how
poor
compatibility
is
in
the
thought,
work
space
between
tools,
let's
take
a
moment
and
consider
what
the
tools
of
a
thought
worker
look
like
by
going
to
the
workshop
of
a
thought
worker.
This
is
john
conway
famous
for
the
game
of
life
and
and
all
kinds
of
other
mathematical
breakthroughs
at
his
office
in
princeton.
Of
course,
we
see
a
computer
on
his
desk,
but
we
also
see
him
surrounded
by
well
mess.
Yes,
but
also
inspiration,
other
ideas,
books
papers,
things
that
he
needs
to
read.
B
You
know
a
phone
for
reaching
out
and
contacting
people.
You
know
his
workshop
is
a
rich
environment,
and
so,
if
we
think
about
kind
of
you
know
the
process
of
building
a
chair,
you
know
you
get
wood,
you
plane
it
you
thickness
it
you
cut
it
to
length,
you
fasten
it.
You
finish
it
well,
we
could
look
at
the
same
kind
of
process
or
what
science
looks
like.
B
So
here's
a
very
simplified
and
idealized
model
of
that
you
take
a
bunch
of
old
ideas,
you
get
some
new
data
and
then
you
know
you
drink
coffee.
You
have
a
lot
of
long
baths
and
procrastinate
and
then
somehow,
after
a
little
while
a
peer-reviewed
journal
pops
out
now
that
middle
stage
actually
has
a
lot
of
articulation.
B
That,
I
think,
would
be
irresponsible
of
me
to
try
and
squeeze
into
a
talk
today
this
sort
of
rumination
and
there's
drafting
and
there's
you
know
active
reading
and
there's
a
lot
of
tools
and
techniques
people
use
to
get
through
that
and
honestly,
that's
where
a
lot
of
this
kind
of
thought
tools
operate,
but
I
want
to
sort
of
zoom
back
from
the
construct
construction
of
a
single
idea
to
note
that,
in
fact,
scientists
and
researchers
generally
have
many
ideas
on
the
go.
It's
not
like
you
sort
of
sit
down
and
you're
like.
B
So
if
we
come
back
to
the
question
of
what
are
these
tools
for
thought
workers?
Well,
then
we
should
ask
ourselves
what
what
are
the
properties
of
a
good
tool.
This
is
a
john
economaki
hp9
thickness
plane.
John
aconimacki
was
a
woodworker
who
developed
a
wood
dust.
Allergy
became
unable
to
to
do
his
favorite
work,
and
so
he
got
into
tool
making
for
woodworkers.
Instead,
I
mentioned
him
to
a
woodworking
professional,
woodworking
friend
of
mine,
and
he
laughed
and
said:
oh
no
one
who
actually
works
in
woodworking
uses
those
tools.
B
I
think,
first
and
foremost,
if
we're
thinking
about
the
challenge
of
thought,
work
in
the
modern
era
we
need
to
talk
about
focus.
Attention
is
a
limited
quantity
that
we
need
to
preserve.
We
have
a
you
know
the
hardest
thing
in
the
world.
Is
these
days
to
shut
out
everything
else
and
to
focus
in
on
the
problem
at
hand,
tools
for
thought
that
don't
prioritize
that
are
going
to
be
worse
than
tools
that
do
our
tools
for
thinking
also
should
be
incredibly
responsive.
We
want
them
to
feel
effortless
frictionless.
B
B
It's
really
important
that
our
tools
are
reliable.
In
particular,
this
is
an
area
that
we
struggle
today,
which
is
that
these
tools
that
that
we
rely
on
we
want
them
to
be
available
to
us
anywhere
and
anytime.
We
want
them
to
work,
you
know
in
our
kitchens
and
on
our
front
steps,
and
we
want
them
to
work
in
10
years
and
we
want
them
to.
B
You
know
come
with
us
in
airplanes,
and
you
know
there's
very
few
tools
that
are
better
for
this
than
a
notebook
right
like
an
actual
physical
piece
of
paper
and
a
pen
passes
all
these
tests.
It's
got
no
push
notifications,
you
know
you
can
never
unzip
a
battery.
You
know
you
can
stick
it
on
your
shelf
and
come
back
to
it.
Five
years
later,
it's
still
gonna
work.
You're
not
gonna,
have
to
run
any
system
updates.
B
First,
you
know.
We
believe
that
your
tools
should
have
no
spinners.
Your
work
should
always
be
at
your
fingertips.
You
should
never
have
to
wait
for
things
to
download
or
sync
and
if
you're
australian,
you
know,
the
entire
internet
is
always
about
a
second
and
a
half
away
from
you
and
I'm
going
to
move
fairly
quickly
through
these.
We
can
talk
about
any
of
them
later.
If
you
have
questions
about
anything,
go
into
more
depth,
it's
vital
that
your
work
is
not
trapped
in
one
device.
B
You
know
there's
nothing
more
frustrating
than
when
you're
sort
of
taking
notes
on
your
desktop,
and
then
you
get
you
know
to
the
coffee
shop
and
you
pull
out
your
phone
and
it's
not
there
right,
like
you,
you
wanna!
You
wanna
have
all
of
your
ideas.
Your
content
needs
to
be
available
to
you,
or
else
you
have
this
friction
between
you
and
what
you're
doing
it's
important
that
the
network
is
optional.
You
know
when
I
joined
the
lab.
B
I
remember
having
this
conversation
with
adam
wiggins,
the
past
lab
director
about,
like,
oh
sure,
you
know
this
stuff's
all
good,
but
it
doesn't
really
matter
the
internet
is,
is
everywhere
and
it's
just
getting
better
and
he
sort
of
laughed
and
said.
Like
is
that
true,
you
know:
do
you
have
the
internet
on
your
front
doorstep
and
in
fact,
this
spot
this
picture
here
is
my
kitchen.
B
Now,
of
course,
collaboration
is
table
stakes
now
for
any
kind
of
useful
software.
You
know
we,
we
can't
imagine
going
back
to
an
era
where
you
know.
Collaboration
is
not
built
in
to
everything
we
do,
but
at
the
same
time
we
want
to
build
for
the
long
now.
These
cuneiform
tablets
have
lasted
thousands
of
years
and
remained
legible,
but
you
know
it's
so
common
for
the
software
we
rely
on
today
to
go
on
sort
of
an
incredible
journey,
which
is
to
say
you
know
you
build
something:
people
love
it.
B
B
And
so
you
know,
you
need
to
trust
in
your
tools
and
you
need
to
choose
software
that
is
for
a
longer
time
frame
than
people
today,
often
think
through
again,
if
you're
building
for
creative
thinking,
it's
important
that
you,
you
know
you,
you
trust
that
the
work
that
you
do
is
kept
secure
and
private.
I
think
that,
from
an
emotional
perspective,
this
is
particularly
important.
B
I
mean
yeah,
the
gdpr
and
data
privacy
and
data
security
is
important,
but
this
isn't
just
about
sort
of
you
know,
paranoid
thinking,
but
it's
also
about
the
kind
of
emotional
security
that
you
have
in
doing
your
work
when
you
know
that
no
one's
peering
over
your
shoulder
before
you're
ready
right
like
if
you're
working
on
a
work
project,
you
might
not
be
ready
to
show
it
to
your
boss
until
you've
thought
it
through.
You
don't
want
to
embarrass
yourself.
B
You
want
to
have
that
that
space,
where
you
can
work
quietly
apart
from
other
people
until
you're,
ready
to
share
things
more
broadly,
and
you
know
ultimately
kind
of
all
of
this-
boils
down
to
the
question
of
who
who
owns
and
controls
the
tool
that
you
have.
If
I
buy
a
chisel,
I
take
it
home
and
it's
mine.
If
I
want
to
put
a
new
handle
on
it,
I
can.
B
This
is
an
image
of
word
star.
Four
george
martin
is
writing.
Ostensibly
the
game
of
thrones
song
of
fire
and
ice
novels.
Call
it
what
you
will
on
an
old
ibm,
pc,
running
ms-dos
and
using
word
star
four
he's
doing
that
now
still
today,
allegedly
because
that's
the
software
that
he
started
the
series
in-
and
I
just
think
that's
so
remarkable
that
you
know
and
almost
unthinkable
like
he
must
know
those
tools
so
well.
B
B
It's
it's
not
your
workshop,
it's
theirs,
and
so
it's
not
to
say
that
I'm
in
any
way
opposed
to
progress
or
improvement
or
consistency,
but
just
that
those
things
should
happen
under
your
terms
when
you're
ready
and
when
they
serve
your
needs,
not
the
needs
of
a
product
manager
or
corporate
entity.
That
provides
those
tools
to
you.
B
So
those
are
the
seven
ideals
of
local
first
software,
and
we
think
that
these
things
connect
back
to
building
great
tools
for
thought,
and
I
I
think,
since
we're
here
talking
to
github
it'd,
be
good
to
sort
of
comment
on
from
the
paper
we
we
sort
of
scored
github
on
these
seven
marks.
You
know
between
git
and
github
as
a
combined
system,
and
we
think
git
is
obviously
very
fast.
It
works
offline,
you
know
git
and
now
github
has
enough
sort
of
track
record.
We'll
give
you
some
marks
for
longevity.
B
We
believe
that
it
does
get
in
particular
empower
users,
but
you
know,
git
is
only
barely
available
across
multiple
devices
and
you
have
to
manually
synchronize
things
all
the
time
if
you
want
to
get
anything
done.
If
you
put
your
data
up
on
github,
it
is
only
private
through
the
herculean
efforts
of
github's
security
and
privacy
teams
by
default.
B
B
You
know
I
I
think
github
has
pioneered
something
really
magical
with
the
pull
request,
but
a
lot
of
github
is
only
semi-collaborative
and
requires
sort
of
manual,
refreshing,
there's,
no,
real-time
collaboration
in
a
lot
of
github,
that's
kind
of
a
legacy
of
the
tooling
and
infrastructure
from
the
era
that
it
was
born.
Out
of
you
know
the
the
rails
app
predates,
which
started
github
started
as
a
rails
app
and
that
predates
kind
of
modern
conceptions
about
real-time
collaboration
and
modern
expectations
about
what
that
looks
like
so
not
to
pick
on
github.
B
We
all
have
a
long
way
to
go.
That's
why
we're
doing
this
research,
so
I
want
to
turn
my
attention
now
from
kind
of
vague
philosophical
thoughts
to
talking
about
some
of
the
built
systems
that
we've
explored
at
incan
switch,
and
if
we
have
time
maybe
later,
we
can
even
look
at
one
of
them
live
that
I've
got
running
on
my
machine
here,
but
we'll
start
with
sort
of
a
a
tour.
So
our
first
project
working
in
this
space
was
a
little
trello
clone.
We
call
trellis.
B
You
know
this
was
our
first
attempt
to
build
a
piece
of
local
first
software.
It's
an
electron
app
because
browsers
are
not
very
good
at
storing
data,
and
you
know
pwas
are
fine,
but
we
found
we
just
couldn't
trust
that
the
pwa
would
be
there
when
you
came
back,
so
we
wanted
to
build
an
app
that
somebody
could
download
and
really
have
and
really
feel
that
feeling
that,
like
this
is
the
thing
on
my
computer
and
electron
is
great
for
that.
B
What
you
can
see
here
in
the
image
on
the
right
is
sort
of
two
views
of
the
same
data,
the
main
view
sort
of
our
our
quasi
trello
and
then
on
the
right.
You
have
a
change
log
and
those
are
two
representations
of
the
same
information
and
in
fact,
in
trellis
you
can
click
back
through
time
and
you
can
see
each
change.
You
know
like
popping
off
the
stack,
so
you
can
go
back
and
look
at
how
things
used
to
be
so
you
can
say
you
know
what
did
this
look
like
yesterday
morning?
B
How
does
it
change
and
who
made
those
changes
and
that's
built
into
the
tech
stack
that
we
built?
We
built
this
system
on
top
of
webrtc
webrtc.
Is
a
technology
built
into
browsers?
That's
designed
to
allow
peer-to-peer,
video
and
audio
chat?
It's
probably
how
this
stream
yard
tool
we're
using
today
works.
B
B
But
before
we
get
into
that,
I
want
to
talk
just
briefly
about
crdts
in
auto.
Merge
a
crdt
put
simply
is
a
mergeable
data
structure.
If
you
think
about
git
right
in
git,
you
have
files
which
are
made
up
of
lines.
You
can
remove
lines
and
you
can
add
lines
and
if
two
people
edit
the
same
line,
then
that's
a
conflict.
B
Auto
merge
is
essentially
a
similar
process.
It
does
a
similar
task,
but
instead
of
working
on
an
array
of
lines,
auto
merge
works
on
something
more
like
the
fields
of
a
json
data
structure.
So,
instead
of
having
to
add
or
remove
a
line-
and
then
you
know,
if
we
both
add
an
element
to
an
array,
is
that
a
conflict
or
not
in
auto
merge?
B
You
have
operations
like
insert
element
in
array
or
change
value
of
this
field,
and
so,
when
you
get
a
whole
bunch
of
edits
from
a
whole
bunch
of
people,
you
know
you
can
sort
of
build
up
a
to-do
list
and
then
you
can
exchange
those
changes
as
they're
recorded
into
logs
over
the
network
and
then
produce
documents.
The
promise
of
a
crdt
is
that,
given
the
same
data,
everyone
will
see
the
same
thing
and
you
could
do
that
trivially
by
just
throwing
away
all
the
data.
B
We
were
excited
about
our
experience
with
with
crdts
and
we
had
you
know.
We
contacted
martin
klepman,
who
wrote
the
json
crdt
paper
and
teamed
up
with
him
to
build
the
first
version
of
auto
merge,
and
it
worked
very
surprisingly,
so
we
thought
okay.
Well,
that
was
probably
just
a
fluke.
So
what
we
wanted
to
do
was
to
find
somebody
else's
software
and
try
and
add
collaboration
to
it,
based
on
these
crdts
and
so
for
this
project.
B
B
A
dat
data
is
built
on
something
called
a
hypercore,
which
is
an
append
only
log.
It
works
quite
a
bit
like
git,
where
each
new
thing
that
gets
written
into
the
log
refers
to
the
thing
before
it,
and
so
you
can
just
request
the
head
and
it
will
give
you
the
full
history
of
that
thing.
You
know
each
one
signed
with
the
previous
commit
hash.
B
Basically,
so
you
can
guarantee
integrity
and
then
it
uses
some
cool
peer-to-peer
distribution
tricks
sort
of
inspired
by
bittorrent
to
allow
you
to
use
one
of
these
kind
of
opaque
tokens
at
the
top.
Here,
these,
like
ugly
crypto
hashes,
to
to
discover
other
people
who
have
that
file
and
then
share
it,
and
so
pixel
pusher
was
was
you
know
one
just
like
a
really
fun
way
to
experiment
with
these
technologies?
B
We
spend
a
lot
of
time,
I
think
unsuccessfully,
sadly
exploring
how
you
could
hybridize
the
google
docs,
real-time
collaboration
with
suggestions,
model
and
github's,
wonderful,
but
incredibly
baroque
and
hostile
to
non-technical
users,
pull
request
model
into
sort
of
a
real-time
hybrid.
I
think
there's
a
lot
more
work
to
do
there.
We
haven't
had
time
to
return
to
it
yet,
but
there's
I
think
it's
an
important
problem
to
solve.
We
also
built
a
simple
conflict
resolution
system.
B
You
can
see
in
the
blog
post
linked
there
on
the
slide
a
little
bit
more
on
that,
but
essentially
we
could
detect
if
more
than
one
person
and
edited
the
same
pixel
and
then
merge
it,
give
you
a
merge
interface,
a
little
hover,
icon
and
so
on.
More
than
anything,
pixel
pusher
is
great.
It's
really
fun
to
play
with
you
know.
B
I
would
encourage
you
to
like,
if
you're
interested
in
this
stuff
grab
a
copy
of
pixel
pusher,
try
and
get
it
working
with
a
couple
of
friends
and
then
you
know
start
drawing
something
together
and
we
would
in
our
testing
sessions.
We
would
like
literally
just
build
some
pictures
for
fun
as
part
of
our
system
and
see
if
we
could
break
it
or
how
the
performance
evolved
so
yeah,
it's
a
rare
treat
to
get
to
build
pixel
art
during
a
work
meeting.
B
It's
an
interesting
challenge
once
you
start
to
really
pull
the
user
experience
thread
of
what
local
first
software
means
and
looks
like
you
get
into
really
cool
questions
about.
You
know
in
the
traditional
you
know,
github
model,
for
example
of
collaboration.
You
either
can
reach
github
or
you
can't
you're
online
or
you're
not.
But
if
you
have
a
really
peer-to-peer
system,
you
start
to
have
questions
about
like
well
who's
online.
Am
I
online?
Are
you
online?
B
Pushpin
again,
it
works.
We've
written
a
lot
about
our
experiences
in
a
paper
that
we
published
last
year
at
the
pap
pac,
it's
again
linked
at
the
bottom.
Here
we
talk
a
lot
about
the
challenges
of
like
peer-to-peer,
nat
traversal
and
how
much
we
like
this
sort
of
functional
reactive
programming
model.
B
The
basic
idea,
and
in
a
little
more
detail
how
that
works.
You
know
we
use
the
crdt
depicted
here
to
ensure
that
everybody
sees
the
same
data
document
and
then
because
react
guarantees,
convergence
from
if
you
start
with
the
same
data.
That
means
that
everybody
sort
of
out
at
the
edges
of
the
system
has
these
nice
little
loops
where
their
building
changes
the
data.
So
you
know
just
react.
B
You
kind
of
you
send
a
message,
and
then
that
causes
an
update
function
and
then
that
goes
back
to
the
render
function
and
that's
the
nice
little
loop
and
then
all
we
do
to
make
that
collaborative.
Is
we
basically
tap
into
that
react
state?
And
then
we
share
that
over
the
network
with
other
peers,
and
so,
if
you're
working
offline,
you
just
batch
up
your
changes
until
you're
ready
to
share
them.
When
you
come
back
online,
you
flush
all
that
log
of
changes
out
and
it
merges
with
everybody
else's.
B
B
B
There
are
meetings
to
be
had
right,
and
so
we
decided
we
would
build
sort
of
a
github
issues,
style
experiment
and
our
goal
was
to
allow
every
version
of
that
program
to
interact,
live
in
real
time
with
every
other
version
of
the
program.
By
translating
the
schema
of
the
data
on
demand
between
different
versions
and
by
storing
those
schemas
in
the
data
itself,
so
that
we
could
fetch
them.
B
I'm
going
to
show
an
example
of
what
that
looks
like
here,
so
you
can
see.
Oh
gee,
that's
really
flickering
for
me.
I
hope
it's
okay
for
you,
but
on
the
right
you
can
see
we
have
to
do
doing
done.
These
are
like
flags
for
a
ticket
and
on
the
left,
we
have
tickets
that
just
have
run
that
again
on
the
left.
We
have
just
you
know.
Each
item
is
either
done
or
not
done
and
on
sorry
on
the
left,
it's
done
or
not
done,
and
on
the
right.
B
We
have
an
enum
of
different
values,
and
so
what
we've
done
is
created
a
lens,
a
bi-directional
function
that
translates
between
the
two
and
so
you
can
compose
these
lenses
to
build
more
complicated
migrations.
But
this
shows
a
simple
example
of
how
you
can
have
interoperability
between
the
two.
We
handle
you're,
going
from
a
single
value
to
multiple
values
and
changing
field
types
and
renaming
fields,
and
all
these
kinds
of
things,
and
so
you
can
build
up
these
like
migration
networks
and
then
be
able
to.
B
B
So
okay
enough
of
these
examples,
I
want
to
talk
a
little
bit
about
what
what
this
all
adds
up
to
you
know.
We've
got
these
these
tools
for
thought
that
you
know
everybody
since
van
over
bush
have
wanted,
and
yet
the
computing
environment
we
live
in
today
is
somewhat
hostile
to
actually
thinking
and
doing
focused
work.
That
takes
a
long
time.
So
we've
outlined
these
seven
principles,
which
you
know
following
these
principles,
will
not
build
a
tool
for
thought,
but
it
will,
if
you
follow
these
principles,
build
better
tools
for
thought
than.
B
If
you
don't
right,
you
could
also
build
social
media
networks.
This
way-
and
I
think
they'd
be
better
too,
but
in
particular,
I
think,
when
you're
dealing
with
tools
that
people
are
going
to
rely
on
for
a
long
time
and
put
important
information
into,
I
think
that's
where
these
principles
are
really
important,
but
we
have
a
lot
of
problems
right
cloud.
Software
is
fragile,
expensive
and
high
latency.
B
You
know
it
there's
one
instance
of
it.
There's
an
ops
team
that
has
to
keep
it
online
and
you
know
sas
software
is
routinely
destroyed
by
market
forces.
The
company
gets
acquired,
the
founders
run
out
of
money.
You
know
it's
just
they
have
an
outage.
You
move
to
a
country
where
it's
no
longer
available,
etc.
B
The
only
real
universal
cross-platform
system
we
have
is
the
browser.
If
you
want
to
have
your
data
on
all
your
devices
and
browser's
kind
of
bad,
it's
like
storing
data,
it's
called
a
browser,
not
a
keeper,
as
I
like
to
say,
and
not
only
that
but
browsers
are
also
really
slow.
If
you
really
want
to
have
these
like
frictionless
tools
that
feel
like
an
extension
of
yourself,
you
know
you
can't
be
running
them
at
10
frames,
a
second
and
waiting
200
milliseconds
to
get
responses
back
from
from
some
web
server.
B
B
B
So
there's
a
lot
more
to
do.
There's
a
lot
more
going
on.
I
hope
that
you'll
take
on
some
of
these
challenges
and
and
join
us
in
doing
that,
and
that's
what
I
came
here
to
share
with
you.
We
have
essays
online
there's
code
online.
You
can
contact
me
by
email.
You
can
find
me
on
twitter
and
github
and
thanks
all
for
coming
on
this
journey
with
me
and
yeah
I'd
love
to
take
your
questions.
A
Fantastic
peter,
thank
you
so
much
that
was
excellent.
A
quick
note
will
the
slides
be
shared
and
or
recording
these
be
available?
Yes,
it
will
be
on
github's
youtube
in
a
day
or
two
after
I
managed
to
turn
the
cranks
and
operate
all
the
post-processing
things
peter
there's
so
much
stuff
in
this,
and
it
was,
as
has
forecasted
a
look
at
the
future
through
the
lens
of
of
history,
but
the
the
sort
of
the
the
first
questions
that
jump
out
at
me.
A
B
The
the
raskin
family,
jeff
and
later
aza
have
been
writing
about
humane
computing
for
years.
You
know,
brett
victor
likes
to
talk
about
how
you
know
we
have
these
bodies,
but
all
we
ever
do
is
like
hold
up
little
like
black
rectangles
in
front
of
our
faces
and
paw
at
glass.
No,
that's
no
good!
We
need
computers
that
embody
physical
space.
B
Dynamic
land
has
been
exploring
a
lot
of
like
how
we
can
expand
computers
beyond
the
bounds
of
these
little
glass,
rectangles
they're,
not
the
only
ones
we
think
stylist
computing
is
really
important.
We
think
alternative
input
methods
are
really
important.
We
think
that
you
know
tactile.
Interfaces
are
really
important.
One
of
the
things
that's
really
cool
with
the
muse
app,
which
spun
off
of
a
bunch
of
our
work
at
the
lab
is
that
it
sort
of
spatializes
your
thought
and
then
it's
designed
for
people
with
hands.
B
You
know
not
for
people
with
cursors,
so
you
can
use
the
pen
and
simultaneously
use
your
hand
to
move
things
around
on
the
canvas
or
you
can
move
several
things
at
once.
If
you
touch
several
things
at
once,
it's
it's
not
kind
of
oriented
to
this.
Like
you
know,
oh
you
know,
sketch
pad
literally
had
a
light
pen
and
ever
since
then,
we've
been
following
that
exact
input.
Paradigm,
there's
one
you
know,
xy
coordinate
and
if
you
want
more,
what's
your
problem
so
yeah,
that's
that's
a
couple
of
the
areas.
B
Another
big
one
is,
you
know
we
talk
about
amplification
of
the
mind.
A
big
part
of
that
is,
you
know,
computational
thinking
excel
is
always
held
up
as
kind
of
the
gold
standard
here,
which
is
that
it
exposes
computation
to
a
broader
audience
of
non-computers,
I'm
very
skeptical
of
the
low
code,
no
code
movement
generally,
because
I
think
you
know
it's
like
focused
in
the
wrong
place,
which
is
like
programming
is
not
the
problem.
Thinking
is,
and
so
we
need
to
root
ourselves
in
like
what
are
the
tasks
that
scientists,
journalists,
authors.
A
It
could
be
that
that
you
know
the
the
true
low
code.
No
code
is
actually
just
a
synonym
for
for
excel,
and
maybe
we
need
a
corollary
to
at
wood's
law.
You
know,
instead
of
anything
that
can
be
written
in
javascript
will
be
written
in
javascript.
Anything
that
can
be
written
as
like
an
excel
function
eventually
will
be
written
as.
B
Code
is
I
mean
excel?
Is
a
coding
environment
right,
it's
just
the
word
code
is
this
like,
and
the
word
programming
have
taken
on
this
pejorative
tone.
I
think
you
know
there's
a
literacy
issue
here,
which
is,
I
think,
that
we
need
better
languages
and
better
tools,
but
also
symbolic.
Manipulation
of
concepts
is
sort
of
the
point.
That's
modeling
right.
The
map
is
not
the
territory,
you
build
a
model
of
an
environment
of
a
problem,
and
then
you
interact
with
it.
A
That
the
overzealous
bot
that
I
don't
know
how
to
like
reign
in
is
destroying
faster
than
that.
I
can
flag
a
flag
in
another
thing
that
you
you
touched
on.
That
I
think
was
really
interesting.
Is
you
talked
about
real-time
collaboration
around
software
and
specifically
around
the
the
creative
act,
and
I
can
think
of
of
of
exactly
one
real-time
collaboration
paradigm,
which
is
the
the
google
docs
or
vs
code
live
share
like
I
have
multiple
insertion
points
and
that's
that's
definitely
real
time
and
it's
definitely
collaborative
yeah.
A
Yeah
exactly
it's
highly
efficient
writing
of
of
of
bugs,
but
what
are
some
other
paradigms
that
you
think
might
represent
collaborative
creation
in
the
in
the
concept
of
coding
I
mean,
maybe
maybe
this
also
ties
into
the
the
previous
question
of
you
know
what
is
low
code
no
code?
What
is
actually
the
boundary
there?
Is
it
like?
You
know,
as
soon
as
you
know,
what
a
variable
is.
That's
it
it's
code
like.
B
So
I
think
that
the
fundamental
problem
with
our
programming
systems
and
why
many
of
these
designs
are
failures-
is
that
they're
built
on
the
wrong
abstraction
git
operates
on
the
in
in
the
1970s
multix
was
face
planting
you
know,
its
uptime
was
measured
in
milliseconds
using
an
oscilloscope,
and
so
the
unix
project
was
born
as
a
pun
on
multix.
I
think
actually
multics
was
sutherland
in
fact
going
back
to
our
history
lesson
here.
B
If
anyone
in
the
chat
remembers
better
than
me,
they
can
correct
me,
I'm
sorry,
I'm
speaking
out
of
school
here,
but
unix
thompson
and
and
and
kernigan
and
richie,
and
that
crew
they
were
so
frustrated
by
this
experience
that
they
were
like.
Oh
we're,
gonna
do
something
really
simple
and
the
unix
mentality.
Everything
is
a
file.
Well,
what's
a
file,
a
file
is
an
array
data
structure.
It
is
newline
delimited,
arrays
of
lines
and
the
lines
are.
B
The
type
of
the
data
in
those
lines
is
characters
which,
as
we've
learned
over
the
years,
is
a
very
complicated
thing
that
involves
a
lot
of
different
unicode
code
points
and
and
formats
and
so
on.
Anyway.
The
unix
mindset
is
that
okay
well
everything's,
just
these
arrays
of
strings
cool,
fine,
we'll
build
tools
that
operate
on
that
data
structure
and
git
operates
on
that
data
structure.
But
your
code
is
not
an
array
of
strings.
B
It's
a
it's
a
tree
structure.
It's
a
graph
structure!
It
you
have
call
points,
you
can't
rename
a
function
and
have
something
else
follow
that,
and
so
I
think
there
are
a
number
of
people
doing
really
interesting
work
in
this
space.
Ravi
choose
lab
and
sketch
and
sketch
at
the
university
of
chicago
are
exploring
different
kinds
of
editors
and
representations.
B
The
dark
programming
language
is
looking
at
like
just
a
whole
different
paradigm.
For
what
software
looks
like
it's,
it's
very
sas,
but
it's
also,
you
know,
exploring
a
lot
of
these
things.
If
you
represent
the
code,
not
as
these
like
linear
ordered
bytes,
you
know
the
array
of
strings,
but
in
a
more
rich
way,
then
you
can
do
a
lot
more.
You
can
see
that,
like
I
could
program
in
english
and
you
could
program
in
french
and
we
would
just
have
translation
tables
that
could
be
the
same.
B
You
want
behind
the
scenes
and
then
do
like
scatter
gather
algorithms,
and
if
those
nodes
go
to
call
a
function,
they
don't
have
them.
They
can
fetch
them.
There's
something
really
really
fascinating
happening
there,
and
you
know
I
feel
bad
because
I
know
there
are
so
many
exciting
projects
working
on
this
stuff
and-
and
these
are
just
a
few-
but
that's
maybe
a
little
color
of
some
of
the
interesting
stuff
out
there.
A
Conway's
law,
that's
that's
the
one
I
never.
I
always
get
that
mixed
up
with
the
other
one.
That's
like
you
know
how
quickly
conversations
devolve
into
whatever
I
don't
know
the
godwin's
law.
You
know
the
yeah
all
the
laws
that
software
right
now
as
you
as
you,
as
you
touched
on
there,
is,
is
kind
of
about
the
manipulation
of
files
with
with
with
text
inside
them
as
the
as
the
sort
of
the
unit
and
that's
the
reason
why
we
have
well.
B
That's
eunuch
science,
that's
dead.
Basically,
I
think
the
modern
paradigm
is
actually
the
we
have
factories
which
hold
giant
expensive.
You
know
software
objects
right.
There
are
these.
These
distant
humming
racks
of
of
chrome-plated
servers
in
some.
You
know
warehouse
in
ashburn
virginia
and
the
software
lives
there
and
then
there's
a
cadre
of
like
miserable
workers
who
who
toil
at
their
desks
every
day
to
keep
those
servers
from
catching
fire
and
falling
over.
B
When
you
know
beyonce
tweets
or
something,
and
then
that's
the
software
there's
only
one
of
those
and
you
can't
touch
it,
and
you
know
a
product
manager
decides
that
the
star
is
now
a
heart,
because
that
increases
engagement,
metrics
and
so
your
star
is
now
a
heart
that
what
you
have
on
your
computer
is
also
not
the
software.
It's
it's
just
like
it's
the
skin
left
behind
by
the
snake
as
it
grows.
B
It's
it's
it's
a
dead
thing
that
comes
to
you,
and
so
that's
the
thing
that
we
have
and
that
thing
talks
to
the
real
software.
But
it
is,
it
is
of
it
it.
It
is
not
the
software
and
I
think,
that's
really
unfortunate.
One
of
the
things
I
really
like
about
local
for
software
is
that
you
have
the
whole
enchilada,
it's
self-contained
right,
and
so,
if
you
don't
like
how
it
works,
you
can
change
it.
And
if
you
want
something
better
you
can
you
can
move
forward.
B
A
Yeah,
it's
all
good,
where
we
can
run
a
little
bit
over
so
jay
garing
gehring
asked
that
a
significant
feature
of
collaborative
cloud-based
software
is
the
ability
to
define
fine-grained
access
roles
and
permissions
for
who
can
read
and
write
data
and
he's
asking
here
about
what
does
this
look
like
in
a
world
of
local
first
software?
How
do
you
achieve
the
same
level
of
of
granularity
and
permissions
while
still
remaining
safe
and
secure?
Maybe
it's
actually
easier
in
this
in
this
sort
of
paradigm,
I'm
not
not
sure
how
to
drive.
B
Yeah,
so
so
that
we
face
a
wave
particle
duality
with
data
right,
so
data
data
is
both
a
thing
and
a
place
and
a
google
doc
is
a
place
right.
You
can,
you
can
go
and
you
can
visit
it
and
then
someone
can
can
close
the
door
and
lock
it
and
you
can't
come
in.
You
can
send
someone
a
url
and
they
can
reach
it,
but
a
google
doc
isn't
the
place
because
I
can
download
it
and
keep
it
on
my
ipad.
So
it's
a
thing.
B
So
it's
a
thing
and
a
place,
and
there's
like
this
weird
if
you've
ever
received
an
email
from
a
business
that
uses
outlook
no
offense
to
your
corporate
overlords
and
you
get
like
an
email
recovery
ticket
or
the
system
is
like.
Oh
no
unsend
that
email
well
now
you're,
definitely
going
to
read
that
email
right,
the
cat
is
out
of
the
bag.
B
So
the
the
point
I'm
making
here
is
that
fundamentally,
information
is
is
not
something
you
can
take
away
from
people,
it's
something
you
can
share,
and
so
one
of
the
core
tenets
of
local
first
software
is
that
you
should
have
agency
over
the
data.
So
once
you
have
data
on
your
computer,
well,
it
doesn't
really
it's
not
really
coherent
to
say
that
you
can't
edit
it.
Maybe
you
shouldn't
edit
it,
but
the
real
question
is
not.
Do
you
have
permission
to
edit
it?
The
question
is:
does
anybody
care
if
you
edit
it?
B
B
A
Yeah
so
bj
titus
said
that
he's
heard
jason
freed
of
base
camp
marry
your
thoughts
about
keeping
old
versions
available
to
avoid
messing
up
the
the
workshops
or
workflows
of
users,
and,
given
that
all
the
different
you
know,
app
stores
only
make
the
latest
version
available.
What
do
you
think
about
the
shipping
of
multiple
versions
of
software
like
muse,
without
dramatically
increasing
complexities?
Cambria
is
like
you
know.
Obviously,
one
part
of
that.
B
B
You're,
like
you
know
what
gang
we're
just
not
going
to
do
that:
data
migration
or
we're
going
to
email
everybody
and
be
like
you
need
to
upgrade
to
the
new
api
because
we're
turning
off
the
old
one
and
then
you
turn
it
off
and
it
starts
500,
and
then
they
complain
until
you
turn
it
back
on
for
a
while,
and
then
you
turn
it
off
next
week
after
four
more
meetings.
But
anyway,
you
can't
do
that
in
a
decentralized
world
right
and
on
some
level.
B
The
fact
that
you
can't
do
that
in
a
decentralized
world,
moxie
marlin
spike
wrote
an
issue
wrote
an
essay
about
how
this
basically
makes
decentralized
software
evolution
impossible,
because
your
protocols
ossify
as
soon
as
you
have
success,
but
that's
not
necessarily
true.
It's
just
that.
We
lack
the
infrastructure,
we
don't
have
the
right
tools
and
so
what
the
cambria
project
we
did
last
summer
was
about.
Was
we
kept
running
into
these
problems?
Where,
like
you
know,
it's
really
it's
bad
in
in,
like
the
sort
of
old
school,
like
downloaded
software
case,
where
it's
like?
B
Oh
I'm,
on
the
old
version,
so
I
can't
open
the
new
file.
Okay,
fine
upgrade,
but
when
you
have
people
doing
live
collaboration
on
a
document
from
different
versions
of
the
software
and
they've
changed
the
format
they
speak.
It
leads
to
some
very
annoying
and
some
extremely
upsetting
bugs,
where,
like
both
versions,
are
constantly
trying
to
write
the
data
they
expect
and
remove
each
other's
data
from
the
file.
So
you
don't
want
that.
So
you
know
this
is
no
less
a
problem
in
centralized
systems
right.
So
in
github.
B
But
the
old
response
was
never
changed
because
people
were
relying
on
it,
and
so
why
is
it
this
way
right?
It
doesn't
have
to
be
so.
The
idea,
fundamentally
behind
the
cambrio
research
was
to
say
like
well.
What
we
need
is
a
tool
right.
Much
like
version
control
systems,
gave
us
the
ability
to
like
change.
The
you
know,
code
over
time
with
confidence
and
packaging
systems
gave
us
the
ability
to
rely
on
very
specific
versions
of
dependencies
and
pull
a
lot
of
other
code
in
in,
let's
just
say,
relatively
safe
ways.
B
Well,
first,
you
do
this,
then
you
do
this,
then
you
do
that
and
then
you
do
that
and
that
gets
you
back
to
a
version
one
file
and
then,
when
they
edit,
they
write
the
writes
in
their
native
format
and
then
the
other
clients
upgrade
them
at
the
other
end.
That
works
pretty
well
now,
as
to
muse,
I
want
to
say
muse
is
fantastic
software.
It
lives
in
the
apple's
ecosystem,
and
so
it's
constrained
by
the
way
apple
thinks
about
software
apple
is
notorious
for
abandoning
the
past.
B
I
have
lots
of
apps
on
my
ipad
that,
like
old
games
I
bought
years
ago,
I
go
to
play
them
and
they
don't
work
anymore.
That
just
makes
me
so
sad,
but
it's
the
nature
of
it's
the
nature
of
the
ecosystem
and
you
have
to
play
within
the
constraints
of
the
ecosystem
you're,
given
what
we
want
is
a
better
ecosystem.
A
Right,
yeah,
I
mean
muse,
is
one
of
those
one
of
those
pieces
of
software
that
that
has
tempted
me
repeatedly
to
actually
get
an
ipad
and
a
pencil,
because
it
looks
so
fun
just
also
purely
on
the
zoomable
user
interface
aspect,
but
also
the
bringing
in
of
the
like
you
know.
Two-Handed
tablet
computing,
which
I
think
is
is
is
rare
and
interesting.
A
A
I
mean
you've
talked
about
about
the
collaboration
on
the
writing
of
software
and
even
cambria,
I
think,
sort
of
the
central
conceit
there
is
really
about
merging
right,
because
if
I'm
collaborating
with
other
people
through
git
on
software,
so
long
as
we
don't
have
conflicts
in
principle,
I
don't
really
need
git,
it's
just
I
I
push
you
push
and
so
long
as
like
we're
not
touching
the
same
files.
It's
okay,
it's
really
only
comes
into
play
or
sort
of.
A
B
I
would
take
it
a
little
different
direction,
so
we
have
a
real
paucity
of
tools
and,
and
it's
sort
of
funny,
you
know
I
have
a
lot
of
love
and
appreciation
for
rome
and
notion,
and
you
know
all
the
folks
building.
You
know
air
table
and
tools
like
that.
I
think
they're
good
but
they're.
They
occupy
like
a
relatively
narrow
slice
of
the
total
knowledge
production
space,
and
you
know
I
use
those
products
all
the
time
I
use
github
all
the
time,
but
none
of
them
actually
really
fulfill
these
requirements.
B
I
I
see,
but
in
terms
of
where
there's
opportunity,
I
think,
there's
opportunity
at
every
point
from
a
knowledge
repository
building,
which
is
to
say,
like
good
ideas,
come
from
other
good
ideas,
so
you
need
to
have
great
access
to
the
all
of
the
ideas
that
are
the
raw
material
of
thought.
So
we
need
better
tools
for
collecting
thought
you
can't
save
web
pages.
It
doesn't
work.
Pdfs
are
these
terrible,
opaque
format?
You
know,
scholarly
journals
are
locked
behind
paywalls,
the
apps
like
zotero,
and
so
on
that
manage
these
things.
B
B
It's
like
something
happens
right
between
you
got
a
bunch
of
ideas
and
data
and
then
at
the
end,
there's
a
journal
paper
and
you
gotta
like
write
latex,
but
that
center
space
has
a
lot
of
like
rumination
and
contemplation
and
conversation
and
collaboration
and
synthesis,
and
so
muse
is
designed
to
work
in
that
place
and
to
support
that
kind
of
ideation.
But
I
think
there's
a
lot
of
opportunity
to
improve
data
exploration,
idea
connection.
B
All
that
kind
of
stuff
and
part
of
the
problem
is
like
a
lot
of
these
tools
operate
as
silos,
so
they're
quite
closed
and
don't
allow
like
collaboration
with
other
tools
and
outside
sources.
So
I
think
that's
part
of
the
issue
and
then
the
final
process,
which
is
actually
like
getting
data
out
into
the
world
and
like
talking
about
it
and
sharing
it,
you
know,
we've
got
you
know.
B
Google,
slides
and
we've
got
latex
and
and
overleaf
and
all
these
kinds
of
things,
but
they're
all
again,
there's
huge
opportunity
both
for
improvement
in
integration
and
collaboration
and
durability
and
performance
and
user
experience.
So
I
think
you
could
pick
almost
any
point
in
this
process
whether
it's
tools
for
musicians
or
artists
or
journalists
right
like
the
new
york
times,
needs
better
text
editors
to
do
a
better
job
of
their
journalism.
D3
is
pretty
good,
but,
like
you
know,
there's
a
lot
of
improvement
opportunity
in
how
we
visualize
data
for
communication
of
it.
A
B
You
can't
so
two
things:
one
is
people
will
do
the
easy
thing.
I
use
google
slides,
not
some
weird
local
first
thing.
I
guess
I
could
use
keynote,
but
I'm
on
a
windows
machine
these
days.
Keynote
is
actually
a
good
example
of,
like
a
pretty
darn,
credible,
local
first
application,
where
it
has
like
a
strong
client.
It
has
a
good
web
application
and
it
does
data
sync
across
all
your
devices
kudos
to
apple
for
that
one.
B
But
so
I
think
the
short
answer
is
like
we
need
better,
tooling
and
infrastructure.
So
a
lot
of
what
we
think
about
at
the
lab
is
like
unblocking
this
work
and
in
a
big
way.
I
think
if
we
get
it
right,
it
will
happen
automatically
because
and
by
we
I
don't
mean
assetting
can
switch.
I
mean
you
who
are
watching.
It
will
happen
automatically
because
you
know
like
ruby
on
rails,
spawned
literally
millions
of
new
kinds
of
applications.
You
know
from
like
toys
and
games
to
like
election
monitoring.
B
You
know
software.
All
of
that
came
out
of
this,
like
empowerment,
that
came
with
these
libraries
but
the
problem
with
web
applications.
Is
they
don't
scale?
You
know
people
like.
Oh
it
scales
to
millions
of
users,
it
only
scales
to
millions
of
users,
because
somebody
is
spending
a
lot
of
money
and
staying
up
late
at
night
right
word:
star.
Everybody
on
the
planet
can
install
an
old,
ms-dos
simulator
and
run
that
old
copy
of
word
star
and
no
one
is
gonna.
No
one's
gonna
get
woke
up
at
three
in
the
morning
because
of
it.
B
Well,
actually,
somebody's
gonna
get
woke
up
because
they'd
be
like.
Why
is
they
ever
doing
a
word
style?
This
is
weird
they're
gonna
lie
awake,
think
about
it,
but
like
technically,
no
one's
getting,
there's
no
ops
burden
to
this
and
local
first
software
can
eliminate
ops
burden,
which
means
that
if
you
want
to
make
software,
you
can
make
one
piece
of
software
and
everyone
can
use
it
and
it
won't
wake
you
up
and
it
won't
cost
you
a
dime,
think.
B
You
could
build
a
business
used
by
billions
without
spending
a
dime
in
ops
costs
and
without
getting
woken
up
at
three
in
the
morning
by
like
an
outage.
So
I
think
that
that's
like
a
very
compelling
economic
argument,
and
so
you
know
people
do
things
when
they're
easier
and
when
they're
cheaper
when
they're
better.
So
that's
part
of
it.
B
B
But
but
my
point
is
that
you
know
these:
the
the
model
today
is
like
sas
subscription
businesses
and
subscription
business
is
a
really
good
way
to
run
your
company,
but
like
paying
every
month
is
not
a
great
way
to
consume
software,
that
sucks
for
the
user,
and
so
I
think,
we're
going
to
need
to
find
new
models
that
make
it
economically
compelling
to
build
great
software.
This
way,
I
think,
that's
not
you
know,
people
will
just
start
charging
money
and
once
you
figure
it
out
will
get
rich.
B
A
B
A
Right
but
I
mean
I
can't
I
can't
actually
do
a
local
first
app
in
in
in
apple's
like
wild
garden,
because
they'll
be
like
show
me
the
app
and
you're
like
no
it's.
It
depends
and
there's
multiple
versions,
and
they
might
want
to
talk
to
one
another
like
you
still
need
to
to
live
with
their
approval
of
your
software.
B
I
think
a
robust
local
first
solution
will
be
not
it
will.
It
has
to
fuse
the
benefits
of
both.
I
think
there's
a
lot
of
great
things
about
the
web.
Right,
like
it's
global
distribution.
It's
you
know
it's
accessible.
The
old
sort
of
geocities
web
is
closer
where,
like
more
of
the
code,
was
in
the
thing
that
you
downloaded,
I
think
that
stuff
is
important.
I
think
browsers
could
really
improve
pwas
and
local
storage
support
and
file
support.
B
That
would
be
huge
just
across
the
board
in
terms
of
unblocking
this,
but
also
browsers,
are
just
slow.
It
takes
forever
to
render
a
web
page.
I
mean
you
know
this.
You
done
you
look
at
a
performance
profile
on
a
web
application.
It's
awful
run
in
60
frames.
A
second
you
know
like
if
you
can't
run
60.
B
A
Fantastic
peter,
thank
you
so
much.
This
has
been
a
fantastic
discussion.
I
really
appreciate
you
coming
over
and
and
giving
us
both
the
history
lesson
and
the
the
forward-looking
thing.
Oh,
what
is
the
minimum
software
requirements
around
this?
I'm
going
to
copy
and
paste
that
question
into
the
thread,
because
we
are
all
already
quite
overdue
to
hand
it
over
to
b
dougie
who's
going
to
be
up
next
on
on
twitch
tv,
slash,
github,
thanks
so
much
for
coming
everyone.