►
Description
HTTP gateways are a key onramp for IPFS usage not only by browsers, but tools, APIs and more. Learn about the state of the IPFS HTTP gateway implementation in Kubo today, and new features and changes coming soon.
A
Working
at
protocol
Labs
app
on
things
like
gateways,
and
this
is
a
status
update
of
where
we
are
with
the
Gateway
as
a
part
of
the
stack
as
a
part
of
showing
up
in
places
that
described
being
part
of
the
told
tool
set
that
developers
can
use-
and
this
is
designed
to
be
a
short
lightning
talk.
So
first
how
to
think
about
gateways.
We
will
not
go
too
deep,
but
kind
of
setting
up
the
mental
model.
What
are
the
two
modes
of
operation
that
are
available
this
year?
A
What
are
recent
improvements
that
landed
since
we've
talked
about
gateways
in
Iceland
and
what
is
the
ongoing
work
and
what's
the
future
holds
in
just
a
quick
refresher?
The
Gateway
follows
the
Mantra
that
no
API
is
the
best
API.
We
don't
have
any
special
schemas.
You
have
a
simple
path,
which
is
the
same
as
content
path,
request,
CID
get
data
back,
and
it's
designed
to
be
a
vendor
agnostic,
generic
HTTP
interface
for
ipfs.
You
may
have
seen
API
v0
endpoints.
A
A
So
if
you
are
interested
in
implementing
ipfs-
and
you
don't
want
to
implement
hundreds
of
commands
present
in
existing
implementations-
and
you
want
something
very
simple-
I
think
providing
the
Gateway
interface
is
a
good
place
to
start
playing
with
ipfs
ecosystem,
because
you
can
now
provide
a
drop
in
replacement
for
existing
integration
points,
and
there
are
two
modes
of
operation
right
now,
which
I
would
like
to
go
over
the
default.
One
that
has
been
around
for
multiple
years
is
requesting
for
a
specific
CID
or
a
path
and
getting
the
serial
lace.
A
The
serialized
user
data
back.
So
when
you
make
a
request
to
the
Gateway,
the
the
end
user,
the
user
agent
is
in
control.
How
much
trust
and
work
is
delegated
to
the
HTTP
Gateway.
Historically,
there
was
only
one
option:
you
delegate
everything
to
the
Gateway.
It
does
all
ipfs
things
and
all
the
content
addressing
things.
But
this
year
we
have
a
ability
to
choose
and
user
agent
is
able
to
opt
in
to
get
a
verifiable
retrieval
from
Gateway
to
either
HTTP
header,
with
a
content
type
which
is
registered
at
Diana
or
a
query
parameter.
A
Excuse
me,
and
just
to
maybe
like
illustrate
the
difference,
the
difference
is
where
the
serialization
of
a
duck
happens
so
that
the
old
default,
if
it
happens
on
Gateway,
that
means
all
the
hashes
are
verified
on
the
Gateway.
So
that's
no
work
for
the
client,
maybe
better
for
your
battery,
but
at
the
same
time
you
delegate
all
the
trust
to
the
Gateway
that
the
Gateway
return,
the
bits
that
you
requested
to
a
CID.
It's
fine!
A
If
it's
a
node,
you
trust
it's
fine
if
it's
not
only
a
local
machine
or
machine
under
your
control,
but
at
the
same
time
now
there
is
a
choice
to
the
serialized
DAC
on
the
client,
and
that
means
less
work
for
a
gateway
may
be
less
expensive
to
run.
A
Gateway
like
that.
That's
more
work
on
a
client,
but
there's
a
huge
win
that
enables
use
of
gateways
are
kind
of
like
a
dump
pipes,
so
you
are
able
to
use
them
without
having
to
trust
them.
A
You
can
use
third-party
gateways
which
are
outside
of
your
control
without
risking
many
in
the
middle,
because
the
harsh
verification
happens
on
the
client
and
for
that
distinction
we
have
a
user
user
documentation
how
to
use
Gateway.
With
that
in
mind,
so
there's
a
the
trust
model
for
both
the
full
delegation
and
partial
delegation
to
Gateway
is
described
there
fetching
blocks
and
cars
examples
so
I'll
just
leave
it
at
that
and
move
to
recent
improvements
around
the
gateways.
A
The
main
one
trustless
verifiable,
retrieval
it
shipped
a
while
ago
in
cup
of
13,
but
I've
put
it
here
because
we
see
finally
see
the
rollout
on
the
public
gateways
reaching
the
point.
When
light
clients
have
multiple
choices:
that
dream,
that
being
able
to
use
random
public
Gateway
to
retrieve
content,
address
data
and
verify
hashes
locally
I
believe
is
finally
reaching
a
point
of
practicality.
A
We
have
specs
for
this
and
we
are
planning
to
do
similar,
trustless
verifiable,
retrieval
of
ipns
namespace,
being
able
to
fetch
IPS
record
and
verify
it
on
the
client
and
that
will
close
the
gap
right
now.
You
can
do
you
can
fetch
immutable
data,
but
soon
it
will
be
also
possible
for
mutable
cryptographic
identifiers-
and
this
is
a
current
state
from
yesterday.
I
believe
public
gateways
are
more
and
more
public
gateways
are
providing
support
for
block
and
car
responses,
which
is
really
good
and
shows
that
people
eventually
update
their
software.
A
Very
cool
thing
that
we
landed
this
year
was
Landing
a
redirects
file
support.
So
this
one
is
a
feature
of
web
gateways
which
are
a
subset
of
gateways
which
do
full
the
serialization,
and
you
can
think
about
them
as
a
way
of
using
ipfs
as
a
part
of
your
web
2
infrastructure,
but
still
get
ripping
some
benefits
or
from
content
addressing
for
data
portability.
So
this
feature
shipped
in
Kubo
16.
There
are
specifications
and
there
are
user
document,
there's
a
user
documentation,
but
it's
a
well-known
format
of
specifying
redirects.
A
But
the
cool
thing
is
this
feature
enables
makes
website
hosting
switching
website
hosting
to
ipfs
a
bit
easier,
because
now
you
are
able
to
host
single
page
applications
without
any
additional
nginx
rules
in
front
of
your
ipfs
gateway.
You
are
able
to
migrate
websites
to
ipfs
and
keep
all
the
links
working
correctly
and
you
can
specify
custom
error
Pages
for
a
situation
when
a
page
got
removed
and
it's
a
and
it's
a
good
demonstration
how
ipip
interplanetary
Improvement
proposal
process
works
for
improving
Gateway
specifications.
A
The
ipip
document
also
includes
test
fixtures.
So
if
you
are
curious,
how
what's
the
full
functionality
examples
are
there?
And
finally,
what's
the
what's
the
near
future,
so
we
have
ongoing
work,
which
I
think
it's
very
important
for
unlocking
additional
use
cases.
So
the
first
one
is
a
small
one.
It's
just
closing
ux
Gap,
it's
possible
right
now.
A
But
the
second
one
is
really
really
important
because
it's
adding
support
four
codecs
other
than
Unix
FS
to
the
Gateway,
and
that
means
adding
support
for
data
structures,
Beyond
files
and
directories
being
able
to
load
DAC,
Json
or
daxibo
data
structures.
It's
not
possible
right
now.
You
can
Traverse
to
the
taxable
document,
but
if
the
taxiboard
CID
is
the
last
one
on
your
path,
the
Gateway
will
refuse,
because
it's
not
a
file.
A
We
register
content
type
at
INR
for
taxable
and
Json
earlier
this
month,
I
believe
they
got
accepted
and
we
will
be
shipping
support
for
that
Json
and
XC
board.
On
gateways
in
a
deserialized
form
somewhere
between
Cooper,
17
and
18,
and
that
will
enable
web
application
developers
to
consume
content
addressed
data
in
a
form
that
allows
linking
documents
and
traversing
links
between
documents.
A
A
We
need
to
improve
performance
of
our
responses,
namely
removing
the
need
for
a
light
client
to
keep
a
Blog
store
to
keep
all
the
blocks
in
memory,
because
you
don't
know,
maybe
the
single
block
is
used
multiple
times,
adding
a
special
refining.
The
way
we
return
car
streams
will
make
it
easier
and
less
expensive
to
implement
those
clients.
We
also
want
to
add
the
ability
to
fetch
a
sub
resource
of
a
web
web
page
without
going
multiple
round
trips
for
each
element
on
above
right.
A
Now
you
need
to
fetch
all
the
parents,
and
then
you
request
the
final
file
as
a
single
car
request.
We
could
include
those
additional
blocks.
Adding
ipld
support
is
ongoing.json
taxiboard.
We
also
are
discussing
adding
a
separate
ipld
namespace
for
more
advanced
things
like
data
layouts
and
custom
schemas
and
in
general,
going
Beyond
just
retrieval.
A
If
we
want
gateway
to
be
vendor
agnostic
data
onboarding
API,
then
we
need
to
agree
on
specification
around
post
and
put,
and
if
we
have
that
we
could
go
even
further
and
have
a
very
efficient
Doug
Edition,
the
dag
edits
using
ipld
path,
spec,
which
is
we
have
a
specification
for
this.
It's
just
a
matter
of
figuring
out
a
way
that
would
make
sense
for
exposing
this
on
Gateway,
and
that's
it.
That's
a
very
brief
update
on
the
Gateway
status
for
this
quarter.
A
We
have
dogs
for
end
users
who
want
to
talk
to
Gateway
for
developers
who
want
to
integrate
Gateway
within
their
stack,
and
we
have
specifications
for
people
who
would
like
who
are
ipfs
implementation,
implementers
developers,
or
would
you
maybe
like
people
who
want
to
go
deeper
and
understand
the
full
scope
that
goes
into
implementing
Gateway?
But
that's
it.
Thank
you.