►
Description
IPLD on gateways, and with URLs - presented by @RangerMauve at IPFS þing 2022 - Data and IPFS: Models - https://2022.ipfs-thing.io
A
This
is
the
ipld
gateway.
Spec
talk,
so
today
we're
going
to
be
looking
at
some
ideas.
I've
been
kind
of
floating
around
gently
forcefully
in
people's
face
about
how
we
can
have
high
level
apis
over
ipld
that
can
be
exposed
in
things
like
gateways,
but
also
relating
to
places
like
ipld
protocol
handlers,
and
so
this
is
going
to
be
a
bit
of
an
interactive
talk,
so
I'm
probably
going
to
be
pausing
every
now
and
then
to
get
people's
feedback,
which
I
hope
to
write
down
in
the
chat
or
in
a
document
yeah.
A
A
A
So
also.
I
want
to
have
a
clear
path
for
new
developers
coming
into
the
ecosystem,
to
think
about
how
they
can
integrate
adls
and
schemas
with
all
of
this
stuff,
as
well
like
reading.
Ipld
data
isn't
enough,
and
I
just
got
out
of
the
writable
gateways
talk.
So
it
seems
some
folks
might
be
missing
context
from
there.
But
rideable
gateways
are
a
thing
and
they're
happening
and
totally
being
standardized,
it'd
be
cool
if
we
could
read
ipl
data,
but
also
write
it
out
so
as
well.
A
One
of
the
goals
of
just
doing
this
talk
here
is
it'd,
be
cool
to
get
some
ideas
going
and
find
folks
that
would
want
to
use
this
or
have
opinions
on
it
existing.
So
one
example
is
the
light
clients
examples
for
like
how
to
frame
these
ideas
so
like
web
browsers
with
custom
protocol
handlers
like
brave
or
aggregor
or
say
we
have
environments
where
getting
an
ipld
library
is
just
not
realistic.
Like
say
we
have
a
php
developer
and
they
really
want
to
do
ipld,
but
it's
a
huge
pain.
A
So
in
http
land
we
have
the
accept
header
which
tells
the
server
hey.
I
want
the
thing
at
this
path,
but
I
want
it
in
a
particular
format
which
doesn't
get
used
that
often,
but
we
can
use
it
with
ipld
to
hint
at
which
encoding
we
want
back
because
oftentimes,
you
know
json
might
be
easier
for
a
web
application
to
parse
than
dag
cbor,
but
the
data
itself
might
be
stored
in
dag
c
bore.
A
So
with
the
accept
header,
we
can
tell
it
that
we
want
to
accept
json
or
we
could
give
it
one
of
the
custom
mime
types
that
I
don't
know
if
these
are
standardized
at
all
for
they're,
totally
standardized
yeah.
So
we
can
kind
of
leverage
ipld's
way
of
converting
between
different
formats
to
make
it
easier
for
applications
to
deal
with
data.
A
Similarly,
if
we
want
to
download
data,
but
we
don't
care
about
too
much-
we
probably
just
want
the
gateway
to
give
us
whatever
the
encoding
is,
so
that
there's
no
extra
work
being
done
and
in
the
response
it'll
tell
us
what
the
encoding
is
with
the
content.
Type
response-
header,
that's
kind,
this
stuff
is
kind
of
similar
to
what
can
already
be
done
in
the
ipfs
gateway.
A
However,
it
kind
of
extends
it
with
features
that
would
be
really
kludgy
like
right
now,
there's
the
format
flag
for
getting
stuff
out
as
a
raw
block,
but
this
kind
of
centers,
the
strengths
of
ipld,
which
is
the
universal
data
model
and
the
way
of
converting
between
things.
But
ipld
isn't
just
about
the
raw
data
model.
We
also
have
useful
lenses
for
viewing
data.
So
could
we
expose
that
in
the
path
itself?
A
A
So
alternately
this
might
make
sense
to
put
in
the
query
string,
but
this
is
stuff
that
could
be
discussed
more,
so
the
syntax
is
pretty
much
the
same
format
as
query
strings
but
shoved
in
between
square
brackets
inside
the
path
segments.
So
in
order
to
make
this
work
and
account
for
new
data
types,
I
also
propose
standardizing
how
data
gets
escaped
so
already
in
the
ipld
space.
A
We
have
problems
where
we
sometimes
have
path
segments
that
are
not
utf
data
that
are
like
some
weird
binary
format,
which
just
like,
doesn't
translate
well
to
a
string
and
right
now.
The
answer
to
that
has
pretty
much
been
like.
You
know,
use
go
and
maybe
it'll
work
or
it
doesn't
work,
whereas
with
this
we
can
have
a
standard
way
of
encoding
data
in
the
in
the
url
scheme.
So
outside
of
that
it'd
be
cool.
A
If
we
could
specify
you
know
the
custom
parameters
that
we
want
to
the
traversal,
and
so
this
could
integrate
with
the
rest
of
the
ecosystem,
and
we
can
have
serializers
and
deserializers
from
this
url
format,
just
out
of
the
box
in
different
languages,
which
would
probably
be
easier
to
implement
than
you
know
everything
else.
In
fact,
I
have
a
javascript
implementation
that
literally
just
uses
the
built-in
url
parser
and
just
adds
an
extra
little
bit
for
getting
data
out
of
segments.
A
A
Should
we
be
linking
to
schemas
using
raw
json
or
should
be
linking
to
it
using
a
url?
Is
there
even
a
good
way
to
serialize
selectors,
because
at
the
moment
it's
like
a
deeply
nested
ipld
object,
which
is
not
too
bad
to
generate
with
code
and
validate
with
code,
but
it
can
be
very
verbose.
So
this
is
like
an
active
thing
to
figure
out
which
maybe
we
could
talk
about
more
at
the
end,
but
like
what
are
the
things
that
are
useful
for
signaling.
A
So
the
most
straightforward
thing
is:
if
you
want
to
post
some
data
to
the
ipld
endpoint,
and
so
that
data
can
be
encoded
in
whatever
encoding
you
want
and
then
it'll
process
that
parse
it
out
and
then
spit
back
a
new
cid,
so
that
encoding
could
be
json.
It
could
be
dag
cbore
protocol
buffers.
You
know
whatever
and
similar
to
the
way
we
can
accept
different
encodings.
A
A
A
A
It
is
a
list
of
operations
where
you
have
the
type
of
operation.
You
have
the
path
where
you're
doing
the
operation
and
potentially
a
value
that
you're
putting
there
or
replacing
so
http
actually
has
a
standard
method
called
patch
for
patching
data,
and
we
now
have
a
patch
wow.
I
think
it's
a
match
made
in
heaven.
A
It
would
be
really
cool
if
working
with
ipld
data
sets
as
an
application
creator,
I
could
just
submit
a
patch
set
with
the
data
that
I
want
to
change
and
then
the
gateway
can
handle
all
of
the
nitty
gritty,
traversal
stuff.
So
from
an
application
developer
perspective.
This
simplifies
everything.
You
need
a
lot
less
code
to
do
potentially
complex
operations
and
having
deterministic
change
sets
are
useful
because
you
can
re-share
them
verify
them
more
easily
and
kind
of
it's
just
great
in
every
way.
A
So
I
think
that
all
of
these
metaphors
can
also
relate
to
libraries
for
languages
for
working
with
ipld
at
the
moment.
If
I
want
to
use
ipld,
there's
this
huge
swath
of
tools
and
specs
that
I
could
learn
to
use
it
or
I
could
use
the
built-in
go
or
sorry
kubo
ipld
apis
that
are
kind
of
cool.
If
you
want
to
just
get
raw
nodes,
but
it's
kind
of
hard
for
advanced
use
cases
and
personally
from
working
with
trying
to
work
with
trees
of
data,
it
just
hasn't
been
enough.
A
Whereas
now,
if
we
have
someone,
that's
coming
to
ipld
and
they're,
just
like
getting
into
the
space
they're
like
okay,
I
want
to
put
some
data
out
there.
I
want
to
get
some
data
out
and
I
maybe
want
to
patch
some
or
make
changes
to
a
tree
of
data
without
having
to
like
manually,
do
all
of
those
get
input
operations.
A
A
So
next
I
was
wondering
if
we
could
talk
about
some
stuff
like
are
there
any
other
use
cases
that
I
didn't
mention
or
that
struck
out
to
you
that
we
could
talk
about
for
doing
this
stuff?
Is
there
anything
that
I
mentioned
here?
That
should
be?
You
know
watched
out
for,
or
is
there
like,
glaring
things
missing?
There
are
applications
you
can.
Think
of
that
could
be
worked
on.
A
Also,
like
is
anyone
here
interested
in
using
these
specs
or
helping
make
them
because
I'm
down
to
spec
it
out,
but
it'd
be
nice.
If
people
wanted
it
also
do
we
have
buy-in
from
gateway
maintainers,
because
I
mean
I
know
probably
one
gateway
maintainer
that
I
could
convince
with
enough
time,
but
it'd
be
useful
to
like
do
a
bit
of
you
know
asking
around
yeah.
So
that's
what
I
got,
but
I
was
wondering
if
we
could
do
a
bit
of
question
comments
time.
Yes,.
B
A
Yeah,
so
the
question
was:
is
the
gateway
storing
the
block
that
we're
writing?
Is
it
like
local
to
the
gateway,
and
I
think
some
of
the
subs
text
there?
If
I'm
hearing
correctly
is,
is
it
like
pinning
the
data
locally
forever
or
is
it
gonna
disappear?
After
a
while-
and
I
don't
know-
that's
probably
something
that
we
should
spec
out
because
at
the
very
least
it's
going
to
have
the
data
on
there,
and
maybe
we
need
some
contract
that
says
like
it
either.
A
If
it's
like
a
local
node
like
akin
to
the
ipfs
daemon
running
locally,
maybe
we
could
just
assume
that
it'll
keep
it
forever
or
maybe
we
need
to
think
about
how
pinning
services
can
work
with
ipl
d
data,
where
we
can
say
okay,
I
uploaded
the
data,
but
now,
if
you
want
it
to
persist,
upload
it
to
web3
storage
or
give
the
cid
to
web3
storage.
So
that's
a
good
question.
That's
probably
something
that
should
be
covered
by
the
spec
or
an
explainer
dock.
C
C
A
A
A
It
assumes
that
managing
that
block
is
now
on
the
client
side,
which
means
the
client
side
needs
all
of
the
libraries
for
knowing
what
how
to
assemble
a
block,
how
to
disassemble
it
how
to
upload
the
individual
ones.
So
it
adds
complexity
which
gateway
that
supports
ipld
out
of
the
box
can
kind
of
gloss
over
adeen.
Did
you
have
a
comment?
A
C
A
A
The
other
thing
was
how
http
verbs
like
put
and
patch
probably
don't
expect
semantically
to
create
new
entities,
and
it
seems
in
this
case
new
entities
would
be
created.
So
regarding
the
creation
of
new
entities,
you
know
best,
we
could
do
in
the
ipfs
case,
so
what
the
writable
gateway
currently
does
is,
if
I
put
or
post
some
data
to
ipfs
it'll
return
a
201
status
code
which
says
that
the
entity
was
created
and
it'll
have
a
location
header
in
the
response
which
says
where
it
was
created.
A
A
A
A
C
C
A
You
know
whatever
our
new
codec
of
the
day.
Well,
I
mean
speaking
of
gateway.
Specs,
I
think
lido
has
a
great
example
of
specs
supporting
formats
explicitly
in
that
in
the
format
header
that
got
introduced.
It
explicitly
says
which
formats
are
currently
supported,
which
I
don't
know.
If
the
wording
there
says
that
there
may
be
others
or
if
there
may
be
others
that
are
explicitly
done
in
a
spec.
Do
you
think
you
could
talk
to
that
vital.
D
D
For
special
use
cases
and
purposes,
they
should
support
more.
If
someone
uses
that
wholesale
they
could
support
it.
We
omitted
that
on
purpose,
because
the
codec
table
does
not
fit
on
the
entire
screen.
That's
one
reason
and
another
one
is
way
when
I
was
writing
a
gateway
specs.
It
was
the
minimum
description
of
current
state
and
also
signaling
possibilities,
but
without
being
too
prescriptive.
C
D
C
D
A
So
if
I
could
summarize
what
you
said,
it
seems
like
existing
spec
work
might
mention
some
specific
formats
that
will
probably
be
supported,
but
ultimately
the
gateway
might
air
out,
and
your
code
should
probably
account
for
that,
and
also
it's
good
to
start
minimal
and
then
kind
of
like
see
about
expanding
from
there.
That
makes
sense.
D
D
People
have
very
good.
The
problem
is
now
I'm
when
I'm
mostly
wearing
the
specs.
Is
that
every
little
thing
you
add
it
suddenly
adds
a
burden
to
the
person
that
will
implement
it.
So
one
if
we
add
new
things,
we
should
really
double
check.
If
we
how
we
are
then
today
put
into
many
new
dependencies
and
if
we
agreed
to
add
something
new,
probably
should
be
like
a
separate
spec
or
a
thing
that
people
can.
B
A
A
D
A
Okay,
cool
well
yeah.
Thank
you
all
very
much
for
the
discussion
and
for
listening.
Hopefully
we
can
resume
this
tomorrow,
and
hopefully
this
can
start
getting
you
thinking
about
like
other
ways
we
can
interact
with
ipld
and
how
we
can
make
it
more
centered
easier
to
use
and
expose
all
of
the
goodies
to
everyone
yeah.
Thank
you
very
much.