►
From YouTube: Closing Keynote - Juan Benet
Description
In this May 2022 IPFS implementations workshop, we heard a number of first-hand accounts from builders & thinkers working on and with IPFS, taking stock of the current implementation story, and imagining what’s possible through shared effort on a protocol with such broad applicability.
A
Crazy
everyone-
this
has
been
a
really
awesome
workshop.
I've
been
super
excited
to
see
that
we've
basically
converged
on
a
lot
of
the
same
ideas
across
the
ecosystem
and
so
huge
kudos
to
just
everyone
here,
and
you
know
many
other
people
out
there
that
see
where
we
are
see
the
gaps,
see
the
needs
and
so
on,
and
we're
kind
of
rallying
to
solve
the
problem.
A
So
my
original
intention,
when
setting
up
this
initial
talk,
was
to
like
talk
a
lot
about
the
same
things
that
has
have
been
said
in
the
talk
already,
which
is
which
is
great,
like
I
don't
have
to
say
those
things
anymore.
Everybody
else
already
said
them,
maybe
it's
good
to
like
acknowledge
them
in
terms
of
common
knowledge.
A
A
Walk
through,
you
know,
kind
of
a
set
of
ideas
of
what
may
be
viable
and
then
talk
about
how
as
a
community,
we
will
make
this
happen,
meaning
I
think,
there's
a
lot
of
interest
here
to
fix
a
bunch
of
these
problems.
But
the
kind
of
like
trajectory
or
path
from
here
to
the
future
is
a
bit
unclear.
A
So
what
I'm
gonna
do
is,
is
I'm
gonna
kind
of
like
suggest
a
few,
a
bunch
of
ideas
here
and
kind
of
have
this
as
a
call
to
you
know
kind
of
think
about
these
possibilities
and
think
of
writing
these
new
types
of
implementations
and
then
then,
I'm
gonna
kind
of,
like
finish
with
a
with
a
call
to
like,
come
together
at
ipfs
camp
to
then
as
a
community,
make
a
bunch
of
decisions
of
where
to
go,
meaning.
What
should
the
protocol
be,
and
so
on?
A
A
A
So
when
the
web,
as
we
have
evolved,
you
can
see
here
this
chart
that
shows
kind
of
the
distribution
of
different
websites
using
different
types
of
servers,
and
you
can
see
kind
of
even
by
1995.
There
were
a
few
different
implementations,
apache
being
one
of
the
really
key
ones.
A
That
kind
of
helped
open
up
the
landscape
of
and
help
a
lot
of
people
write
new
implementations
and
then
it
took
a
while
until
we
got
like
the
the
later
explosion
of
the
web
and
kind
of
what
I
mean
by
that
is
that
it
took
a
while
to
mix
the
client
server
model
of
hdb
with
the
computation
that
we
know
and
love
today.
A
In
terms
of
these
massive
scale,
web
services
that
can
blend
the
http
protocol
and
the
whole
html
js,
css
stack
with
pages
and
apis
and
so
on.
And
you
know
another
way
of
like
looking
at
the
story
is
like
this.
In
in
the
in
the
beginning,
there
was
kind
of
httpd
and
a
lot
of
people
ran
http.
A
Then
people
started
kind
of
like
creating
patches
of
http,
so
people
started
creating
their
own
forks
and
their
own
versions
and
sort
of
kind
of
writing
different
implementations
and
it's
kind
of
confusing
which
http
version
you
were.
You
were
running
and
so
on
and
then,
after
that,
people
started
creating
crafting
these
different
implementations
and
naming
them
something
else
like
apache,
2
and
iis
and
and
so
on,
and
that
naming
change
really
helped.
A
Everybody
talk
about
what
implementation
that
we're
actually
running
and
that
there
could
be
trade-offs
between
between
a
lot
of
these
implementations.
There
are
a
number
of
other
implementations
that
got
written
around
this
time
that
were
super
usually
useful.
A
Around
the
same
time,
people
started
blending
computation
in
with
http,
mostly
through
external
means,
mostly
by
calling
it
using
an
http
server
to
then
call
out
to
some
other
process
through
you
know:
cgi
bin
and
similar
kind
of
kind
of
systems,
but
the
and
then
that
kind
of
seated
the
ground
for
a
whole
bunch
of
other
frameworks
and
and
web
tools
that
then
flex
out
the
the
explosion
that
came
later
and
that
that
was
when
people
stopped
treating
the
the
web
server
as
a
thing
kind
of
on
it
on
its
own.
A
Of
course,
this
is
still
how
tons
of
web
systems
run
at
scale,
but
there's
a
huge
transition
when
people
started
writing
applications
by
embedding
the
http
server
or
client
as
a
as
a
library
in
their
application.
A
And
so
you
know
things
like
the
early
java
work,
that
kind
of
accumulated
a
ton
of
like
really
good
ideas
to,
I
think,
whiskey
and
and
a
bunch
of
other
and
other
different
kinds
of
interfaces
that
enabled
translation
of
this
sort
of
stuff
to
then
you
know
things
like
django
and
php,
and
many
other
frameworks
and
tools
that
enabled
blending
the
computation,
along
with
with
the
generation
of
the
page
and
that
eventually,
ultimately
leading
to
you
know
things
like
flask
and
and
many
other
frameworks.
A
You
know
there
are
probably
hundreds
of
different
tools
and
things
like
node.
Eventually
that
kind
of
really
took
this
to
the
extreme,
where
you
suddenly
had
you
were
sort
of
composing,
the
entire
construction
of
the
of
the
page
and
application
as
as
a
as
a
runtime
and
and
that's
really
when
the
massive
explosion
of
web
adoption
and
web
application
development.
I
think
really
happened
like
and
and
going
back
to
this
graph,
a
lot
of
this
adoption
and
so
on
has
kind
of
gone
down
in
terms
of
these
big
name
servers.
A
A
So
let's
go,
you
know,
think
about
this
for
a
moment.
So
in
the
beginning
we
were
sort
of
going
across
and
just
typed
with
us
and
the
goal.
There
was
to
kind
of
create
this
landscape,
where
you
could
have
kind
of
the
the
larger
scale,
disturbance,
oriented
implementation
with
you
and
so
on,
and
then
you
could
have
like
a
a
web
native
implementation
that
could
just
run
in
directly
in
the
browser
over
time.
A
So
things
like
companion
and
desktop
and
go
mobile
and
ips
lite,
and
so
on,
and
a
ton
of
other
tools
that
have
kind
of
either
used
parts
of
these
implementations
as
a
library
or
embedded
one
of
them
entirely
or
or
something
like
that
and
kind
of,
but
they
were
still
sort
of
constrained
by
garba,
fest
geosapps
and
the
infamous,
like
spec,
that
is,
that
is
floating
around.
A
I
think,
what's
happened
since
then
is
that
people
have
taken
the
really
useful
parts
of
the
of
the
systems
and
sort
of
exploded
ipfs
into
a
larger
scale
network
of
systems.
That's
basically
about
ipld
data.
Moving
around
some
transport-
I
could
be
literally
it
could
be
just
http.
It
could
be
a
bunch
of
other
things
and
really
kind
of
starting
to
build
applications
on
top
of
the
ipld
data
directly-
and
I
think
one
of
the
key
things
that
we
need
to
do
in
this
moment
is
to
actually
rename
go.
A
Ipfs
and
jstype
with
us,
and
you
know
been
kind
of
pushing
hard
for
this,
because
right
now,
people
are
still
equating
ivfs
with
the
tool
that
you
run
in
your
command
line.
A
That
is
called
ipfs,
that
you're
installing
your
computer
and
it's
called
ipfs
and
so
on,
and
so
we're
kind
of
being
held
back
by
the
fact
that
we're
at
this
stage-
and
we
still
have
the
the
tool
named
ipfs,
like
kind
of
the
web
sort
of
did
away
with
that
earlier,
and
I
think
we
we
kind
of
have
to
do
that
so
that
we
start
recognizing
all
these
other
systems
as
full-on
implementations
of
ipfs
and
full-on,
like
systems
that
have
their
own
trade-offs
and
their
own
design
decisions
and
so
on.
A
But
they
can
really
like
kind
of
treat
all
of
these
different
kinds
of
implementations
as
far
as
class,
and
when
people
are
thinking
about
what
what
ipfs
should
do
or
or
how
to
reason
about
content,
ivfs
and
so
on.
The
the
question
becomes
a
lot
more
nuance,
depending
on
the
specific
implementation
of
the
specific
service
or
the
specific
deployment
that
you're
talking
about.
And
so
I
think,
like
one
of
the.
A
The
big
shifts
that
we
have
to
do
is
like
open
up
the
landscape
of
implementation
and
just
make
it
look
much
easier
for
everybody
to
kind
of
treat.
All
of
these
other
systems,
as
as
full-on
iphone's
implementations,
and
they
might
not
all
interrupt
and
that's
one
of
the
hard
questions
that
we're
going
to
have
to
figure
out.
Hopefully
this
at
our
custom.
A
Soon
it's
like
how
do
we
reason
about
data
moving
between
all
these
different
kinds
of
implementations
in
many
cases,
it'll
be
difficult
for
some
of
these
systems
to
to
interact.
A
A
Yet
it's
just
difficult
to
move
around
the
data
and
whatnot,
but
I
think
one
of
the
big
wins
that
we've
seen
over
the
last
few
few
months
and
a
couple
years,
I
guess,
is
a
lot
of
services
just
moving
around
data
directly
through
car
files,
through
other
other
formats,
and
learning
to
kind
of
read
and
write
directly
to
those
kind
of
intermediate
bundles
and
then
building
iphone
systems.
A
Out
of
that
now,
I
think,
like
what's
going
to
generate
the
big
explosion
here
and
we're
sort
of
like
kind
of
like
about
to
encounter
is
advertising
awesome
and
there's
one
like
I've.
Many
regrets
in
like
one
of
them,
which
is
a
really
big
one,
is
that
early
in
the
ips
paper
way
back
when
I
was
writing
it.
A
I
was
strongly
considering
putting
va
directly
into
ffs
and
just
shipping
it,
because
the
first
version
natively
with
the
vm
and
I
was
worried
about
the
security
applications
very
naturally,
but
I
think
in
retrospect
that
was
insane.
I
think
that
if
I
profess
nba
had
shipped
together
from
the
get-go
kind
of
what
did
the
whole
kind
of
history
here
would
have
been
very
different,
because
ipod
and
all
the
data
structures
would
have
just
been
written
directly
and
then
run
on
v8.
A
As
a
different
system
that
you're
going
to
run
and
so
on,
but
really
it's
a
way
of
programming,
your
application
and
your
system
by
using
a
lot
of
these
components
as
libraries
and
really
push
a
lot
of
the
complexity
of
the
network,
stack
and
a
lot
of
the
protocols.
So
things
like
bitswap
and
the
transports
and
baseball
crafting
and
many
other
transports,
and
a
lot
of
the
complexity
of
and
power
really
of
ipod
and
the
adls
and
so
on
into
into
wasm.
A
And
so
I
think,
like
the
the
big
one
of
the
big
things
that
I
think
is
going
to
matter
here,
is
to
get
to
a
point
where
we
can
start
embedding
wasn't
programs
with
a
lot
of
the
different
kinds
of
iphone
implementations,
and
so
this
is
what
I
think
where
we're
headed
sort
of
this
year.
I
think
it
would
be
great
as
a
community
to
kind
of
talk
about
all
this
sort
of
stuff
in
in
in
that
bit
of
scan.
A
Now
I
want
to
kind
of
like
touch
on
a
few
things
that
I
think
are
going
to
be
really
important
to
people
writing
hypothesis,
implementations
today
and
people
potentially
starting
new
ones,
because
there's
a
lot
of
people
today,
we've
heard
about
tons
of
different
implementations,
which
is
super
hey.
We
should
kind
of
like
support
all
those
groups
and
b.
We
should
help
make
it
way
easier
to
do
all
of
that
work
and
all
that
development,
and
so
we
should
kind
of
like
I.
A
I
think
it
would
be
great
if
what
I've
been
posting
we
can,
or
even
before
we
can
look
back
and
kind
of
like
make
problems
easier
by
dismissing
a
lot
of
requirements
or
constraints
to
kind
of
like
be
a
full-on,
you
know
kind
of
ibm's
implementation
or
to
have
an
ibfs
deployment
or
an
ips
system.
The
kind
of
like
litmus
sets
that
I've
been
using
lately
is
like
hey.
A
If
you
have
a
program
that
represents
ipld
data
with
ideas
and
so
on
and
you're,
and
it
just
moves
around
with
netcap
to
some
other
program
somewhere
else
like
is
that
an
ipad
system-
and
I
think
it
probably
is-
I
think
that
there's
one
key
constraint
here
that
I
think
our
community
is
gonna-
have
to
figure
out,
and
I
have
a
strong
opinion
on
this.
But
I
don't
really
have
a
good
answer.
A
It's
like
whether
or
not
you
know
content
should
be
find
it
more
unreadable
and
that
will
really
matter
I'll
pop
into
kind
of
thinking
about
networks
in
a
moment
and
thinking
about
primitives
and
kind
of
what
are
the
things
that
have
that
I
think
are
going
to
stay
on
the
test
of
time,
but
before
I
get
to
that
in
terms
of
making
it
easy.
A
I
think
one
of
the
key
things
that
our
community
needs
to
do
is
to
have
a
strong
focus
on
optimizing
performance,
and
one
of
the
pieces
here
is
like
if
you
look
at
large-scale
systems
like
the
web,
that
we
use
today,
all
browsers
all
large-scale
deployments
of
complex
software
and
so
on.
A
They
have
extensive
testing
frameworks,
and
here
one
of
the
principles
that
all
that
is
based
on
is
at
the
end
of
the
day,
like
you
really
get,
what
you
measure
and,
if
you're,
not
measuring
something
you're,
not
going
to
get
a
good,
a
good
signal
and
you're
not
going
to
get
the
outcome
that
you
that
you're
expecting
so
in
terms
of
like
really
building
it's
kind
of
leveling
up
the
success
of
the
implementations
everywhere,
we
need
to
change
a
mode
where
we're
learning
from
the
best
in
class
large
distributed
system
communities
and
get
to
a
point
where
we
can
really
optimize
and
and
measure
the
perform
measure,
the
performance
of
all
of
these
different
kind
of
implementations
and
get
a
point
where
we
can
start
optimizing
all
of
them,
and
this
is
like
a
huge
undertaking
to
kind
of
build
the
tooling
and
the
and
the
structures
to
be
able
to
support
this.
A
We
already
have
a
lot
of
this
kind
of
stuff.
In
the
past,
like
we
built
out
things
like
test
ground
placement,
it
really
enables
a
lot
of
this
kind
of
testing
and
tons
of
improvements
that
come
out
of
this.
We've
done
a
lot
of
r
d
to
to
find
problems
and
kind
of
turn
into
like
measurable
outcomes.
A
Kind
of
fix
problems
like
there's
a
really
great
talk
from
pro
lab
talking
about
a
bunch
of
different
questions
and
in
you
know,
discuss
who
can
solve
problems
and
whatnot,
but
I
think,
basically,
like
we
have
to
level
up
the
community-oriented
infrastructure
to
get
to
something
like
this,
where,
like
it's
super,
easy
to
write,
performance-oriented
benchmarks,
that,
then,
can
you
can
kind
of
tie
to
an
implementation,
and
you
can
see
the
changes
that
you're
going
to
make
and
how
they're
going
to
ripple
through
kind
of
like
all
our
users.
A
I
think,
because
we're
lacking
something
like
this,
a
lot
of
problems
sneak
in
and
it's
difficult
to
kind
of
evolve.
The
software
when
you
think
about
systems
like
you
know,
most
of
the
programming
languages
that
we
use
or
browsers
and
so
on.
We
have
cases
of
thousands
or
tens
of
thousands
of
people
working
daily
on
improving
those
systems
and
the
only
way
that
you
can
manage
a
system,
a
software
system
at
that
scale
and
keep
good
performance.
A
A
We
have
this
kind
of
large-scale
testing
and
tooling,
and-
and
so
this
is
like
a
a
a
key
component,
I
wanna
kind
of
like
talk
for
a
moment
about
like
important
primitives,
so
I
think
something
that
I
that
I
think
has
stood
the
test
of
time
like
really
well
with
cids.
I
think
this
turned
out
to
be
really
useful
in
a
ton
of
ways.
I've
seen
them
even
absorb
into
systems
that
don't
use
equality
or
any
fully
and
so
by
nature,
they're
sort
of
like
bringing
in
ipld.
A
But
the
point
is
like
they.
It
turned
out
to
be
like
a
pretty
pretty
useful,
useful
component,
primitive
and
some
things
tools
that
kind
of
use
cids,
I
think,
will
will
very
much
stay
on
the
test
of
time.
A
I
think
getting
right
now
today
we
all
understand
the
power
and
utility
of
being
able
to
manipulate
these
dags
directly,
but
today
it's
still
like
very
difficult
to
write
your
own
data
structures
and
it's
very
difficult
to
kind
of
evolve
them
and
make
them
work
across
systems,
and
a
big
part
of
that
is
that
we
don't
have
a
good
language
for
expressing
these
in
a
language
and
runtime
independent
way.
A
So,
for
example,
if
you
write
some
complex
data
structure,
you
have
to
go
and
implement
it
in
a
bunch
of
different
languages,
for
it
to
be
to
be
used
or
you're.
Gonna
have
to
like
have
a
bunch
of
systems
that
don't
know
how
to
deal
with
it.
Okay
and
it
can't
like
do
translation
in
the
gateway
or
anything
like
that.
A
So
I
think
one
of
the
key
things
here
is
to
shift
a
mode
where
we
can
properly
program
all
of
these
kinds
of
infrastructures,
in
a
way
that
all
programs,
all
ipfs
capable
systems
can
interpret,
and
I
think
that
one
of
the
key
to
that
is
ipod.
Sorry,
sorry,
the
key
to
that
is
awesome,
is
bringing
in
wasm
into
into
the
equation
to
then
be
able
to
have
a
link
all
of
the
link,
all
the
codecs
and
so
on,
to
be
able
to
kind
of
interpret
the
all
of
these
data
structures.
A
I
think
another
really
great
thing
that
that's
just
kind
of
like
helped
ease
the
the
problem.
Is
these
car
files
and
they've
all
evolved
quite
a
bit,
and
I
think
they're
gonna
continue
evolving,
but
just
this
idea
that
you
can
like
take
a
bunch
of
data,
bundle
them
into
a
car
file
and
then
move
that
around
has
just
been
super
useful.
A
And
so
I
would
expect
to
see
a
lot
more
implementations
over
time
just
using
car
files
directly,
and
this
is
a
pretty
good
format
to
bet
on
because
of
it's
kind
of
like
broad,
broad
flexibility.
You
can
think
of
having
implementations
that
don't
have
a
repo,
they
just
kind
of
point
to
a
car
file
or
they
point
to
you
know
some
other
tool
written
around
or
on
top
of
multiple
car
files
and
whatnot
there's
also
what's
going
to
enable
kind
of
swapping.
A
A
So
I
think,
like
this,
is
it's
a
pretty
good
format
to
bet
on
and
especially
because
there's,
like
good
thought,
put
into
the
upgrades
to
that
this
format,
so
as
more
and
more
more
features
emerge
so
like
the
new
carb,
v2
and
rp3,
and
so
on
that
might
come
down
the
pipeline
they're
built
with
very
much
backwards
compatibility
in
mind
so
that
you
can
kind
of
reason
about
them.
A
One
of
the
things
I
think
is
key
for
for
folks
to
to
remember
remember:
is
that
there's
any
kind
of
like
a
much
better
diagram
of
this,
because
this
is
like
super
updated
this
from
like
many
years
ago,
is
that
the
broader
ipfs
network
is
a
very
large
scale
thing
spanning
the
internet
and
potentially
disconnected
so.
A
You
have
many
different
kinds
of
systems:
loading
and
using
data
in
disconnected
environments
that
may
or
may
not
be
using
the
dhc
may
or
may
not
be
using
the
new
network
indexers
and
the
content
may
not
be
like
directly
readable
or
findable,
but
you
want
to
be
able
to
like
write
tools
and
systems
to
be
able
to
move
around
a
lot
of
this
data
across
these.
A
These
kinds
of
networks,
so
kind
of
like
have
this
picture
in
mind
where
you
know,
if
your,
if
your
tool
is
putting
an
assumption
that
some
service
is
going
to
be
around,
then
maybe
it
only
works
in
in
you
know
a
subset
of
the
subset
of
the
network.
A
I
remember
probably
two
three
years
ago
about
three
years
ago,
there
was
a
large
effort
around
package
managers
and
putting
in
a
lot
of
data
for
package
managers
using
ypfs
and
so
on,
and
at
the
time
like
we
were
having
trouble
with,
like
you
know,
one
terabyte
of
content
and
just
loading
one
single
terabyte
into
integrated
professor
dealing
with,
like
a
repo
of
that
size,
was
kind
of
difficult
and
it's
kind
of
complex
to
deal
with,
like
that
kind
of
that
kind
of
sets
of
static
acids
and
whatnot
and,
and
today
like
we
are
just
kind
of
like
in
it
in
a
totally
different
world.
A
Let
me
show
you
like
a
thing
of
the
sense
of
scale.
You
know.
One
of
the
largest
advertised
deployments
is
the
popcorn
network
and
just
as
a
sense
like
the
network,
is
onboarding.
A
There's,
like,
I
think,
about
80
petabytes
of
data
total.
It's
like
this,
an
insane
level
of
scale
compared
to
where
we
were
two
years
ago
or
three
years
ago.
A
So,
for
example,
just
how
we,
how
we
think
about
absorbing
some
large-scale
data
set,
that's
maybe
stored
in
a
ton
of
drives,
and
then
we
have
to
process
it
to
turn
it
all
into
ipld
data,
and
that
right
now
today
requires
like
reading
all
that
data,
copying
it
and
splitting
it
up
into
into
a
number
of
card
files.
A
All
these
different
like
little
graphs,
and
we
can't
really
like,
have
a
way
of
kind
of
mapping
onto
the
drive
as
it
is
now
and
kind
of
being
able
to
sort
of
like
ingest
the
drive
and
construct
like
a
set
of
companion
indices
or
something
that
can
point
to
the
data
like
we're
dealing
with
the
scale
of
like
of
data
ingestion.
A
Now
where
it
is
really
questioning
a
lot
of
the
assumptions
that
that
a
lot
of
the
iphone
suiting
built
over
the
last
three
four
years
kind
of
had-
and
so
I
think
like
use
this
as
a
massive
opportunity
to
say
hey.
Could
we
like
rethink
how
data
onboarding
into
a
content
address
network
should
work
like?
A
Could
we
do
a
thing
where,
like
you
can
run
a
pro,
you
can
take
a
drive
with
like
terabytes
worth
of
stuff,
and
you
know
remember
that,
like
the
storage
density
is
gonna,
keep
increasing
like
we're
gonna
we
have
like,
I
think,
eight
10
terabyte
drives
now.
16
terabyte
drives
it's
going
to
push
into
20
and
more
in
the
future,
and
so
a
lot
of
the
data
in
the
world
is
going
to
be.
A
Like
already
stored
in
a
specific
set
of
formats,
can
we
lean
into
that
and
write
tools
that
can
just
index
the
data
on
the
drive
as
they
are
on
whatever
native
file
system
format?
That
drive
is
in
and
then
add
a
content
addressing
layer
on
top
of
it,
so
you
can
just
kind
of
use
the
drive
as
it
is,
and
and
just
plug
it
into
a
set
of
ipfs
nodes
or
ipvs
systems
that
can
like
read
the
data
and
use
that
data.
A
So
I
think,
like
you,
know,
some
implementations
looking
at
this
problem
scale
and
being
able
to
tune
their
tooling,
for
this,
I
think,
will
be,
will
be
super
helpful.
One
other
thing
that
this
brings
up
is
that
all
of
that
data
right
now,
a
lot
of
it
is
just
standard
unix,
fs
data
imported
into
into
into
the
network.
It's
not
kind
of
like
ipld
fight
in
any
kind
of
special
way.
A
A
So
you
could
have
a
lot
of
stuff
added
already
as
standard
unix
files,
usbs
files
in
the
unixfs
tag,
and
you
can
construct
another
dac
that
points
to
the
objects
in
that
dag
and
interprets
it
differently
and
one
of
the
key
things
that
enables
that
is
all
the
equity
data,
layouts
and
so
on.
But
again
for
that
we
we're
going
to
need
to
make
the
entire
thing
programmable.
So
we're
going
to
need
wasm
what
wasn't
everywhere
so
yeah.
I
think
I'm
I
reaching
the
the
end
of
the
the
talk.
A
So
when
I
kind
of
finish
up
talking
about
like
two
things,
one
is
we're
gonna.
A
What
we're
talking
about
here
today,
through
through
pointing
out
different
possibilities
and
different
implementations
and
so
on,
is
a
huge
amount
of
work
and
part
of
that
requires
helping
create
and
build
and
and
support
a
lot
of
these
these
implementations.
So
one
of
the
things
that
I've
been
talking
to
a
number
of
people
about
is
actually
creating
a
fund
to
support
people
writing
new
iphone
implementations.
A
So
one
of
the
things
that
I'm
working
on
in
the
in
with
some
folks
is
creating
a
set
of
like,
like
a
large
scale,
thunder
of
a
bunch
of
different
implementations
and
I'll
have,
I
hope,
to
have
more
news
about
this
in
the
in
the
weeks
leading
up
to
ips
camp,
but
the
goal
would
be
to
kind
of
like
be
able
to
support
a
number
of
teams.
Writing
different
kinds
of
ivf's
implementations
and
different
kinds
of
fps
tooling
to
them
go
and
tackle
a
lot
of
these
large-scale
problems.
A
So
that's
one
of
the
things
there
is
trying
to
kind
of
leverage
a
lot
of
the
community-oriented
funding
structures
that
have
emerged
in
the
in
the
web,
3
community
to
then
allocate
funding
to
teams
building
a
bunch
of
the
ceiling.
A
lot
of
these
implementations,
without
kind
of
like
inserting
a
whole
other
talk
in
this
one
about
kind
of
like
what's
been
going
on
there
I'll
just
kind
of
like
leave
it
at
that
and
say
more,
maybe
at
active
camp.
A
The
the
second
thing
is
about
iphone
scan.
I
think
the
a
lot
of
us
kind
of
like
see
the
need
for
this
happening
relatively
soon,
and
I
think
we're
kind
of
now
at
the
point
where
we
have
a
very
large
scale
community.
That
kind
of
wants
this
to
happen
soon
kind
of
like
the
original
kind
of
a
goal
for
this
was
to
kind
of
bring
together
a
subsidiary
community
in
july,
there's
all
kinds
of
like
requirements,
and
so
on
that
are
shifting
that
over
to
september.
A
So,
as
I
said
on
chat,
I
think
it'd
be
great
to
get
input
from
the
people
in
this
room,
because
kind
of
what
we
want
to
do
is
like
gather
together
the
set
of
people
that
are
here
now
to
talk
about
this.
So
I
would
love
to
kind
of
like
so
so,
if
you're
here
in
this
call
just
kind
of
if
you
want
to
get
together
and
talk
about
all
this,
this
sort
of
stuff,
soon
like
in
kind
of
like
a
july
time
frame.
A
A
Do
this
like
this
would
be
really
useful
data
for
me
and
separate
if,
if
you
want
to
kind
of
hey
now,
actually
it'd
be
much
more
much
better
for
us
to
kind
of
push
out
to
to
september
and
kind
of
like
work
towards
that
and
work
towards
like
having
that
that
a
much
larger
community
gathering
at
that
point
also,
let
me
know
that
so,
like
just
quick
pull
to
the
people
hearing
this,
what
do
do
you
feel
the
same
kind
of
urgency
that
a
lot
of
the
people
in
this
call
have
to
get
together,
define
a
lot
of
these
things
and
kind
of
do
this
work
sooner
or
would
now
having
heard
this
and
having
adjusted?