►
Description
Browsers 3000 is a six-week virtual event to explore and accelerate the development of web3 in the browser through experimentation and challenge prizes of up to $20,000 worth of Filecoin (FIL). Learn more at https://events.protocol.ai/2021/browsers3000.
Like all IPFS Community events, Browsers 3000 expects all speakers and participants to follow the IPFS Community Code of Conduct (https://github.com/ipfs/community/blob/master/code-of-conduct.md).
A
Okay,
so
I'm
brian
cardell,
I'm
a
developer
advocate
at
a
galleo.
This
is
my
domain.
If
you
want
to
learn
more
about
me
and
I'm
going
to
talk
about
decentralization
and
not
just
the
distributed
web,
but
also
this
other
kind
of
centralization,
which
is
that,
like
everyone
relies
on
the
web,
there
are
thousands
of
organizations
built
on
these
foundational
web
standards.
There
are
hundreds
of
orgs
that
participate
in
standards,
bodies
that
make
them,
but
then
there
are,
you
know,
historically
even
fewer,
that
make
a
browser
and
even
fewer
still
that
make
a
browser
engine.
A
They
have
different
departments
with
different
managers
and
skills
people
with
different
skill
sets,
and
you
know
everyone
is
trying
to
manage
them
independently
and
it's
only
ultimately
a
standard
if
everyone
makes
it
through
all
of
the
gauntlets
and
so
things
get
really
backed
up
and
vendors
are,
you
know,
less
likely
to
take
the
time
to
diverge
from
working
the
current
backlogger
things
that
they
already
think
are
important
to
discuss
new
things,
especially
big
things.
That
would
you
know,
involve
hard
problems
like
decentralizing
the
web
itself.
A
So
you
know
we
all
wait
and
we
all
hope
that
they
do
it.
We
lobby
them
to
do
it,
but
ultimately
this
is
also
a
feedback
loop,
and
you
know
things
just
get
worse,
so
even
small
things
can
wind
up
lingering
without
a
final
implementation
which
costs
us
all,
which
really
kind
of
sucks
that
we've
created
this.
You
know
sort
of
centralized
choke
point
of
where
we
can
progress.
So
I'm
super
grateful
that
we
have
gotten
this
far
with
that
model,
but
just
imagine
that
we
could
fix
this
and
prove
it
well.
A
We
can,
and
the
reason
that
we
can
is
because
things
have
gotten
progressively
more
open
over
the
course
of
the
lifetime
of
the
web.
We've
gotten
to
the
point
where
all
of
the
standards
implementations
are
now
open
and
to
illustrate
why
I
think
this
is
important.
I
don't
know
if
you
are
familiar
with
css
grid
when
it
landed
in
2017,
everyone
was
like
wow,
everybody
did
it
and
it's
magic
and
it's
our
favorite
thing
ever
people
still
talk
about
it
in
my
timeline
on
twitter
every
day,
but
this
has
origins
going
back
to
1996..
A
There
were
failed
attempts
along
the
way,
but
this
time
it
worked.
What
was
different
well
in
fairness,
multiple
variables,
but
really
one
core
critical
one
is
that
things
are
open
and
so
other
people
can
contribute,
and
that
is
what
we
did.
Igalia
did
the
work
to
contribute
to
implementations
of
css
grid.
We
did
that
with
funding
from
bloomberg
tech.
So
thank
you
for
that.
A
But
what
I'm
trying
to
point
out
here
is
that
a
lot
of
things
aren't
sort
of
stuck
over
politics
or
these
big
strategic
gyrations
that
we
imagine
it's
just
there's
way
more
practical
things
that
they
just
can't
get
prioritized.
There's
very
mundane
sorts
of
things
about
prioritization
that
hold
us
back
a
lot
and
that's
what
a
galia
does.
A
A
The
one
on
the
left
shows
our
contributions
to
webkit,
where
the
orange
the
light
blue
is
apple.
You
can
see
what
a
big
slice
of
the
pie
that
is
on
the
right
are
the
last
two
years
of
commits
these
do
not
include
google
in
chromium,
but
they
do
include
everybody
who
isn't
google,
and
you
can
see
that
the
blue
is
a
gallia
and
the
red
is
microsoft.
A
Now
microsoft
will
probably
pass
us
up,
but
just
to
give
you
an
idea
of
the
level
of
commitment
that
we're
playing
in
multiple
browsers,
all
of
the
browsers
really.
So
it's
it's
pretty
significant.
We
work
on
all
the
standards
bodies
and
we
help
bring
priority
to
things
that
browser
vendors
can't
prioritize
themselves.
A
A
A
Everybody's
really
excited
including
us
about
miriam
suzanne's
work
with
google,
but
you
know
our
proposals
and
prioritization
helped
push
that
from
the
outside
a
little
bit
and
in
fact
we
demonstrated
a
working
prototype
in
chromium
the
same
week
that
they
announced
taking
up
the
better
proposal
so
also
has
which
is
like
parent
or
ancestor
selectors
have
been
in
and
out
of
css
selector
specifications
since
the
late
90s.
A
Nobody
has
been
willing
to
touch
that
because
it
seems
like
impossibly
hard,
but
a
gallery
has
a
working
prototype
in
chromium
that
was
funded
by
work
by
io.
So
we
think
that's
like
fantastic
we're
excited
about
that.
So
what
I'm
trying
to
say
here
is
like
this
is
a
really
good
thing.
We
can
accomplish
great
things
if
we
work
together
and
that's
great,
because
we
all
move
forward
together.
A
So
it
is
kind
of
a
commons
that
we
should
all
try
to
play
some
kind
of
role
in
and
we
don't
know
what
kind
of
roles
we
can
play
until
we
talk
about
them.
So
I
have
a
lot
of
thoughts
on
this.
In
fact,
I
have
a
podcast
at
gallia,
chats
where
we
have
an
entire
series
on
improving
the
health
of
the
web
ecosystem.
A
So
one
way
that
we're
able
to
do
that
is.
We
are
the
maintainers
of
wpe,
which
is
the
webkit
port
for
embedded.
So
if
you
go
to
webkit.org,
download
you'll
see
it
there
and
it
powers
like
billions
of
embedded
devices
so
well.
Why
does
this
matter?
Well,
another
example.
So
if
you
don't
know
sarah
drasner,
she
is
an
svg
guru,
enthusiast
expert
and
she
has
long
been
a
proponent
asking
for
hardware
accelerated
svg.
A
Well,
not
exactly
just
cooking
machines
but
all
embedded
systems.
So
this
is
the
thermal
mix
tmz
six
by
four
work
and
that
little
screen
on
there
is
an
embedded
webkit.
A
All
of
these
things
in
you
know,
car
infotainment
systems
and
video
games
and
televisions-
and
you
know,
appliances
and
digital
signage
and
point
of
sale.
They're
all
using
the
web
to
make
their
interfaces
and
what's
interesting
about
embedded
is
that
it
is
actually,
of
course,
important
to
have
hardware
accelerated
svgs
there,
because
these
devices
are
less
powered.
A
They
all
have
a
gpu
for
the
most
part
and
the
kinds
of
interfaces
that
you
frequently
want
on.
These
are
more
svgs,
so
that's
really
important
and
we're
able
to
help
bring
new
investment
that
will
benefit
everyone.
I
think
that's
great,
but
also
just
why
do
we
even
have
the
model
that
we
do
like
why?
Why
should
even
a
single
organization
have
to
fund
the
development
of
a
standard?
Maybe
that
doesn't
always
have
to
be
the
case.
A
So
we
also
ran
this
experiment
last
year
that
we'll
probably
continue
called
open
prioritization,
which
is
a
partnership
with
open
collective
in
which
we
collected
funding
from
from
many
sources
to
fund
some
work.
So
I
think
that's
really
interesting
and
we
hope
that
that
helps
sort
of
decentralize,
the
ecosystem
of
investment
and
our
ability
to
get
things
done
so,
okay,
but
decentralizing
the
web
itself.
A
It's
a
big
challenge,
it's
the
kind
of
challenge
that
we
like
it's
a
big
challenge
for
a
lot
of
reasons,
and
all
these
reasons
you
know
pile
up
and
each
one
independently
is
subject
to
all
of
these
prioritization
filters
and
budget
constraints
and
things,
and
so
the
investment
from
you
know
the
main
browser
vendors
might
not
be
as
great
as
everybody
would
like,
but
that's
okay,
because
we
can
supplement
that,
and
so
that's
what
we've
been
doing.
A
We've
been
working
with
protocol
labs
protocol
labs
has
funded
a
bunch
of
work
in
this
area
from
gallia.
A
We
have
worked
on
improving
register
protocol
handler
the
html
specification,
neither
matched
implementations
nor
allowed
for
some
usefully
workable
definitions,
and
so
we
sent
patches
for
things
like
making
sure
urls
are
well
specified
and
that
they
work
then
implementations
in
chromium.
For
like
how
do
we
define
like
what
are
the
safe
urls
that
you
can
register
what
are
the
safe
protocols,
so
we're
still
sorting
that
out.
A
We
landed
this
poll
in
chromium
that
adds
the
distributed
web
protocols
and
we
have
an
open
pr
for
html
for
that
along
the
way
we
have
done
just
tons
of
fixes
of
things
like
service
workers
and
url,
encoding
and
parsing
for
how
these
interplay
and
protocol
handlers,
but
also
there's
just
these
bigger
ideas
like
secure
context
and
potentially
trustworthy.
Word
like
the
specs
are
built.
You
know,
reasoning
about
the
web
that
we
had,
and
so
sometimes
things
need
a
better
definition.
A
So
we've
done
a
lot
of
work
to
fix
those
things
in
chrome
and
define
you
know
what
is
a
trustworthy,
potentially
trustworthy,
url
and
one
of
the
big
improvements
here
has
to
do
with
local
loopbacks,
and
they
you
know,
can
you
trust
them,
so
you
can
in
firefox
and
now
you
can
in
chromium,
and
we
also
have
done
an
experiment
in
gtk
and
wpe,
which
are
two
ports
of
webkit,
that
a
gallery
maintains
and
we're
opening
discussions
based
on
those
prototypes
with
apple
we've,
also
added
extension,
specific
features,
because
the
register
protocol
handler
approaches.
A
You
know
one
aspect
of
it,
but
there
are,
you
know
different
concerns
when
it
comes
to
extensions
and
while
they're
getting
more
standard
their
differences.
So
this
is
a
lot
better.
Now
in
chrome,
this
list
would
be
really
really
long.
I'm
just
going
to
show
you
a
bunch
of
links
and
say
that
each
one
of
these
things
represents.
A
You
know
a
discussion,
a
pull
request,
an
issue
where
in
in
many
cases,
there's
you
know
a
lot
there
to
each
one
of
these
links,
and
this
is
only
a
partial
list,
but
each
step
along
the
way
gets
us
closer.
So
there's
a
lot
left
to
do
right.
So
I'm
going
to
talk
to
you
about
like
a
couple
of
things
that
we're
looking
forward
to
doing
challenges
that
we're
looking
forward
to
solving.
So
one
of
them
is
the
chromium
architecture.
A
Chromium
architecture
has
these
sort
of
two
layers:
the
chrome
layer
and
the
content
layer.
The
chrome
layer
is
sort
of
the
browser
around
and
the
content
is
the
stuff
inside
and
they
communicate
via
ipc,
and
you
know,
there's
different
kind
of
calls
in
and
out,
but
this
creates
some
real
interesting
challenges
because
currently
all
of
the
you
know
the
check
to
find
out
if
something
is
safe.
A
Is
that
one
layer,
but
then
the
actual
handling,
the
handling
of
the
protocol
and
the
the
registration
of
it
and
everything
is
left
at
the
chrome
layer
today,
and
this
creates
a
just
a
bunch
of
interesting
problems,
how
it
integrates
ux
permissions
and
things
is
not
really
great
for
like
supporting
lots
of
things
in
even
web
platform
tests.
We.
It
raises
interesting
new
questions
in
web
platform
tests,
for
example,
you
only
are
dealing
with
the
content
piece,
and
so
you
don't
even
have
these,
so
this
is
also
really
problematic
for
downstream
variation.
A
So
if
you're
downstream
chromium-
and
you
wanted
to
support
things,
everything
is
currently
at
the
chromium
level.
So
you
have
to
you
know,
have
your
you
have
to
bring
all
of
your
own
stuff
for
that.
If
you
want
to
have
it
in
the
first
place
to
have
it
actually
work,
and
then
you
have
to
deal
with.
You
know
your
fork
and
rebasing
and
constant
breakage
and
things.
So
we
would
like
to
move
this
and
you
know
change
where
different
bits
live
and
allow
even
the
shipping
of
default
handlers
at
both
levels.
A
So
that
is
what
we
have
been
working
on
and
some
of
the
things
we're
looking
forward
to.
There
are
plenty
more
things,
but
if
you
have
questions
or
comments
or
you
want
to
talk,
people
from
mongalia
will
be
around
you
can
reach
out
to
me.
Thank
you.