►
From YouTube: Agregore `fetch()`, a multi-protocol abstraction - @RangerMauve - Browsers and the Web Platform
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello,
so
my
name
is
moef,
my
pronouns:
are
they
them?
And
today
I'm
going
to
be
talking
about
peer-to-peer
urls
and
how
we
use
them
in
the
agricore
browser,
so
yeah
you
can
find
me
online
at
ranger
move.
A
I
work
for
more
mo
software
inc,
but
that's
just
me-
and
I
guess
I
also
work
for
protocol
labs
indirectly,
but
I'm
like
really
obsessed
with
peer-to-peer
protocols
just
from
like
my
career
as
a
developer
kind
of
learned
that
there's
a
lot
of
pain,
points
that
peer-to-peer
protocols
kind
of
just
sidestep
entirely,
like
I
really
don't
like
having
to
hoard
user
data.
Just
leads
to
all
of
these.
It's
weird
dynamics
where
everything's
centralized
in
one
place
it's
easier
to
abuse
and
it
takes
a
lot
more
time
to
scale.
A
I
like
things
that
are
a
little
bit
more
person
to
person
where
I'm
sharing
data
with
people
that
I
actually
want
to
be
sharing
it
with
directly
or
I
don't
have
to
worry
about
aws
going
down
and
then
suddenly
like
nothing
working
at
all,
and
I
want
my
applications
to
work
on
any
network
because
you
know
like
say
we're
here
at
the
hotel.
Wi-Fi
and
maybe
some
websites
don't
load
or
say
we
have
a
spotty
internet
connection
and
suddenly
our
chat
apps
don't
work
and
we
can't
communicate
so.
A
The
default
cloud
environment
makes
it
really
hard
to
avoid
these
problems
it's
possible,
but
with
peer-to-peer
protocols
it's
the
default
so
obviously
ipfs.
I
really
love
it
because
the
content
addressability
really
takes
advantage
of
this.
So
rather
than
having
data
always
pulled
from
the
cloud,
we
can
pull
it
from
local
caches,
if
necessary,
local
peers
and
all
of
that
and
it's
useful
in
that
it
can
kind
of
detect
data
across
different
peers,
even
if
they
don't
have
the
entire
data
set,
which
is
different
from
things
like
bittorrent.
A
However,
it
also
means
that
it
can
be
a
little
heavy.
However,
combined
with
some
other
protocols
on
the
web,
we
can
kind
of
take
trade-offs
and
kind
of
use
the
best
tool
for
the
job,
which
I
think
eventually
might
just
be
ipfs.
A
A
So
as
dietrich
and
little
hinted
earlier,
urls
are
kind
of
like
the
bread
and
butter
of
the
web
right
now,
where
you
have
some
sort
of
scheme,
usually
http
or
https,
some
sort
of
origin,
you're
loading
stuff
from
the
path
to
the
whatever
specific
file
you
want
to
load
and
some
extra
search
parameters
for
stuff.
What's
cool
is
that
we
can
apply
that
similar
concept
to
a
whole
bunch
of
different
protocols.
So
obviously,
we've
seen
some
ipfs
urls,
where
we
have
the
content
id
in
the
origin
section.
A
But
what
if
we
could
do
the
same
thing
with
bittorrent,
where
we
have
an
infohash
or
a
hypercore
protocol
or
ipns
or
literally
whatever
else?
What's
cool?
Is
that
urls
give
us
this
like
base
building
block
that
a
lot
of
people
already
understand
and
that
we
can
map
to
a
lot
of
data
very
easily,
so
the
sort
of
stuff
that
we
can
load
from
these
urls
is
stuff
like
web
pages,
for
just
like
the
raw
html
for
a
page
you're
having
iframes
that
embed
sub
content.
A
You
know
we
have
media,
like
images,
audio
video,
all
this
stuff,
our
styles
and
this
could
be
wroting
loading
scripts
directly
from
your
local
network
and,
what's
more,
is
this
isn't
just
like
raw
urls?
We
can
start
taking
advantage
of
this
with
javascript
apis
for
more
dynamic
uses.
Like
say,
we
want
to
load
from
larger
data
set.
We
can
use
the
browser's
built-in
fetch
api,
which
typically
requires
a
server,
but
we
can
ditch
the
server
and
just
focus
on
the
content.
A
Similarly,
there's
apis
like
event
source
that
come
just
packaged
in
with
javascript
that
lets
us
subscribe
on
changes
over
time,
for
instance,
for
lib
p2p,
pub
sub
and
so
outside
of
just
urls
for
loading
stuff,
there's
a
little
bit
more
functionality
under
the
hood
with
the
way
http
work
works.
So,
as
a
lot
of
folks
know,
it's
based
on
a
request
response
cycle
where
a
client
will
send
a
request,
then
a
server
will
get
back
a
response.
A
The
request
usually
contains
some
sort
of
method
for
what
you
want
to
do,
a
url
for
what
you
want
to
do
it
to
some
headers
for
extra
little
configurations
that
aren't
in
the
url,
and
sometimes
you
might
be
sending
a
request
body
to
the
server
being
like
hey.
I
want
to
do
this
thing
and
here's
what
you
can
do
it
with.
A
A
So
this
is
also
very
similar
to
what
gateways
do
and
the
stuff
that
lydle
talked
about
where
gateways
rather
than
a
url.
They
have
a
sub
path
or
a
subdomain
which
takes
that
ipnsd
id
and
with
ingestible
data
gateways.
As
lionel
said,
we
could
also
start
thinking
about
how
we
can
post
or
put
some
data
over
top
of
an
existing
data
set
or
something
fresh
and
get
back
on
ucid.
A
So
this
is
the
sort
of
stuff
that
I've
been
experimenting
in
the
aggregor
browser.
So
agrigore
is
a
minimalist
web
browser
that
I
created
to
explore.
What
it'd
be
like
to
mix
these
protocols
together
under
this
http
like
interface,
so
it
aims
to
have
as
few
assumptions
as
possible
as
few
like
fancy
features
as
possible
and
focus
more
on
centering
the
protocols
and
using
web
extensions
to
add
extra
functionality
that
I
then
think
of
doing
initially
so
right
now,
we
actually
have
support
for
a
whole
bunch
of
protocols
and
are
actively
working
on
supporting
more.
A
So
obviously,
we
have
ipfs,
but
we
also
so
have
support
for
ipns
stuff
in
ways
that
you
might
not
even
think
are
there
yet,
which
I
might
go
into
later.
We
also
support
lib
p2p
pub
sub
secretly,
which
I
don't
think,
there's
any
spec
for
it
out
there
or
documentation,
but
lets
us
kind
of
do
the
ephemeral
peer-to-peer
stuff
through
a
protocol
handler.
A
Lastly,
also
we
have
ipld,
but
then
outside
of
the
ipfs
ecosystem,
we're
looking
at
other
peer-to-peer
protocols
that
have
their
own
trade-offs
like
the
hypercore
protocol
ecosystem
bittorrent,
where
we
have
kind
of
like
a
new
url
scheme
which
doesn't
really
exist
but
almost
existed
like
20
years
ago
and
also
regular
magnet
magnet
links.
Then
we
also
support
the
gun,
db,
peer-to-peer
api
and
secure
scuttlebutt
for
loading
social
data.
A
Also,
we
support
gemiini,
which
is
kind
of
like
gopher,
but
with
mark
down
and
more
simple,
so
like
just
weird,
obscure
things
and
obviously
like
anyone
seeing
this
remotely
like.
If
you
want
your
protocol
in
there,
just
like
open
an
issue
or
dm
me
yeah,
but
like
I'm,
just
going
to
jump
right
into
it
and
show
you
what
this
looks
like
in
practice.
How
do
I
actually
use
these
protocol
handlers?
So
I
am
going
to
tempt
fate
and
do
a
live
demo.
A
So,
as
I
mentioned
before,
we
can
put
some
data
over
an
existing
ipfs
directory
to
your
data
set,
and
there
is
this
really
cool
standard
for
cids
called.
I
think
it
was
like
inline
or
raw
cids
or
something,
but
basically
what
it
lets
you
do
is
skip
the
network
set,
skip
actually
having
a
block
and
just
have
data
in
line
in
the
cid,
and
I
use
that
to
have
a
cid
representing
no
data,
just
an
empty
directory.
A
A
A
fetch
request,
which
will
pass
in
that
url
and
it'll,
pass
in
a
method
saying
that
I
want
to
put
some
data
in
there
and
then
for
the
body.
I'm
going
to
have
just
some
inline
markdown
ips
thing:
wow!
Does
this
real
work
and
a
cool
emoji
for
the
style?
So
I'm
going
to
send
that
off
it's
going
to
take
a
few
seconds
and
bam.
It
sent
the
the
request
to
the
built-in
protocol
handler
in
agrigore,
and
it
gave
me
back
a
response
now
to
get
the
new
url.
A
I'm
going
to
look
in
the
response
headers
and
I'm
going
to
get
the
location
header,
which
tells
me
the
location
of
the
url
that
just
got
created.
So
here
we
have
an
actual
cid,
which
is
a
lot
less
legible
and
harder
to
pronounce,
but
this
will
actually
load
it
from
the
network.
So
if
someone
manages
to
copy
that
manually,
hopefully
they'll
actually
load
it.
But
I
instantly
regret
saying
that.
A
So
what
I
can
do
is,
I
can
tell
the
page
to
navigate
to
it
and
bam
there
you
go.
So
that's
how
I
can
create
a
website
pretty
much
in
like
one
or
two
requests
and
what's
cool
is
that
if
I
want
to
update
a
website
with
new
content,
all
I
gotta
do
is
just
put
another
file
or
update
an
existing
piece
of
data,
and
I
can
just
get
back
these
urls.
A
So
this
means
that
for
developers
trying
to
make
local
first
apps
remote
moves
a
huge
amount
of
dependencies
and
tooling,
and
all
that
that
might
take
a
lot
more
time
to
learn,
whereas
here
they
can
take
pretty
much
just
the
the
lowest
level
like
simplest
javascript,
that
they
can
like
copy
paste
from
stack
overflow
and
just
change
the
fetch
to
instead
use
ipfs
so
yeah.
So
the
goal
here
is
really
to
simplify
it,
while
still
giving
us
most
of
the
power
of
the
ipfs
stack
so
yeah.
A
That
was
that
so
it's
great
it
works.
It's
so
easy.
It's
amazing,
but
it's
not
perfect,
and
so
as
part
of
developing
some
actual
web
apps.
Using
these
protocol
handlers
that
work
on
mobile
and
on
desktop,
we
actually
came
across
some
pain
points
that
I
think
are
kind
of
making
it
more
difficult
and
are
areas
where
we
can
like
gain.
A
A
lot
of
improvements
like,
namely
ipns,
is
the
only
way
to
really
have
mutable
data
in
ipfs
that
is
like
standardish
and
doesn't
require
extra
servers
or
extra
like
complex
ad
hoc
things
like
you
could
do,
ipf
or
lib
p2p
stuff,
cut
yourself
or
have
a
blockchain
or
whatever
else,
but
like
a
lot
of
these
methods,
aren't
really
local.
First,
they
don't
work
on
your
local
network
and
spread
out,
and
you
know
like
ipns
is
right.
There
like
it's
built
in.
A
It
should
be
faster
and
easier
to
use,
and
I
think
we're
slowly
making
progress
there
as
well
with
mutability
there's,
currently
no
obvious
way
to
pin
mutable
data
where
we
have.
This
awesome
pinning
api,
where
we
can
tell
a
service
to
pin
some
data
and
keep
it
online
for
us
for
when
we're
offline,
but
we
can't
tell
it
to
keep
data
that
updates
over
time
online
for
us.
A
So
that's
like
another
thing:
that's
being
actively
worked
on
and
another
thing
that
we
found
a
lot
is
that
actually
sending
data
over
the
peer-to-peer
network
between
say
two
home
networks
is
still
a
little
bit
iffy,
because,
even
though
we
have
this
cool
new
hole,
punching
feature
that
is
out
in
the
latest
kubo,
it's
not
everywhere,
and
it
doesn't
work
for
everything
yet
and
it's
still
kind
of
new.
A
So
one
of
the
useful
things
from
trying
to
mix
these
protocols
on
the
web
and
kind
of
simplifying
it
down
is
that
we
can
find
all
of
these
new
areas
to
improve
the
protocol
and
make
it
better
and
faster
and
easier
to
use
so
like.
Why
do
I
bother
with
all
of
this
stuff
like?
A
Why
does
agrigore
even
exist,
and
I
think
a
really
important
thing
for
me
is
to
make
local
first
software
possible
and
that's
software,
which
contains
user
owned
data
where,
rather
than
a
third
party,
having
you
know
final
say
on
what
my
data
is.
It's
me
it's
about
software
that
can
work
offline
by
defaults
and
doesn't
rely
on
you
connecting
to
a
third-party
service
in
order
to
do
anything,
it's
stuff
that
can
work
on
your
local
area
network.
A
If
you
have
like
an
ad
hoc
wi-fi
thing,
set
up
or
like
a
router
attached
to
a
battery
in
the
woods,
but
it
can
also
scale
over
the
internet
and
do
all
of
those
fancy
things
that
we're
used
to
things
doing
like
sending
an
email.
I
think
another
place
where
this
local
first
software
and
peer-to-peer
protocol
stuff
really
mixes
in
well,
is
in
community
mesh
networks.
A
Where
now
we
can
think
not
only
about
decentralizing
our
data
but
also
decentralizing
our
infrastructure,
and
this
is
also
very
important
for
cases
where
communities
are
just
not
served
by
the
current
cloud
infrastructure,
where
they
might
have
a
lot
of
outages
which
this
period
of
your
stuff
is
resilient
to
or
they
might
have.
You
know,
limitations
on
how
much
data
they
can
exchange
or
how
expensive
it
is,
which
we
can
just
totally
sidestep
by
not
needing
to
touch
the
internet
and
as
well.
A
A
really
important
thing
is
how
to
actually
distribute
applications
on
these
networks,
where
you
know,
I'm
sure
a
lot
of
the
folks
in
this
room
are
really
used
to
like
having
our
fancy
linux
and
mac
machines
with
like
super
beefy,
cpus
and
like
know
all
of
the
fancy
tooling
and
know
how
to
download
it
and
use
it,
and
all
of
that,
but
like
building
apps
that
you
can
distribute
across
platforms
that
are
local
first,
is
really
hard
and
takes
a
lot
of
really
like
specialized
engineering
knowledge,
and
I
believe
that
with
peer-to-peer
and
web
technology
together,
we
can
sidestep
a
lot
of
that
and
package
resilient
apps
and
distribute
them
the
same
way.
A
We
would
any
other
information
yeah,
so
that's
kind
of
agrigore
and
peer-to-peer
urls
and
the
stuff
that
I'm
focused
on
and
why?
Hopefully,
this
will
be
interesting
to
folks
and
yeah
I'm
around
for
questions.
If
there
are
any.
B
Is
that
something
that
you
like
I'd,
love
to
hear
more?
How
you
envision
that
happening?
And
if
that's
essentially
something
like
a
service
or
or
a
way
to
re-provide
ipns
records?
Or
is
that
independent
of
that.
A
Yeah
so
I
mean,
I
think,
there's
different
levels
at
the
highest
level
for
someone
actually
using
the
system
is
what,
if
I
can
send
an
ipns
url
rather
than
an
ipfs
cid
through
the
pinning
service,
spec
and
so
right.
Now,
there's
a
dev
grant
that
I
think
just
got
approved
like
a
few
weeks
ago
for
the
person
working
on
the
fiero
pinning
service,
where
they're
actually
gonna
standardize
how
to
do
mutability
over
time.
A
But,
like
the
other
details
of
like,
is
this
pinning
service
gonna
be
able
to
republish
my
ipns
record
indefinitely.
That's
like
a
really
big
question,
because
ipns
as
it
is
now
just
isn't
really
geared
towards
the
originator
of
the
record
going
offline
for
more
than
like.
You
know,
I
think
a
day,
and
so
this
means
that
even
if
we
republish
those
records
on
the
pinning
service,
it
wouldn't
work.
A
So
there's
actually
a
lot
of
area
for
research
on
increasing
that
timeout
or
figuring
out
how
we
can
delegate
permission
to
the
pinning
service
to
generate
fresh
records
on
our
behalf,
which
we
can
revoke
with
something
like
ucans
or
I
mean
in
the
short
term.
We
might
just
be
sending
our
private
keys
to
a
service.
We
trust
if
we
trust
them,
which
is
awful
for
security,
but
it'll
get
the
job
done
while
we
figure
out
the
fanciest
fancier
stuff,
so
yeah.
So
to
answer
your
question
it
it's
still
very
fresh.
We
don't
know
everything.
C
I
love
your
focus
on
local
first
software.
That's
super
fantastic!
Thank
you.
I
think
these
sorts
of
like
yeah,
but
what
if
we
could
actually
do
it
like
this
is
really
really
important.
It
reminds
me
we
started
basically
saying
what,
if
no
servers
ever.
B
C
That
guided
a
lot
of
our
design.
People
are
adding
servers
to
the
stuff
that
we're
doing,
but
that
is
in
fact
a
lot
easier
than
putting
that
which
I
love.
I've
generally
made
the
decision
to
include
dns.
B
C
A
Yeah,
it's
really
complicated
because,
like
I
think,
right
now,
dns
and
ds
nest
link
is
just
the
most
reliable
form
of
mutability
for
ipfs
data.
If
you're
connected
to
the
internet
can
afford
a
registrar
trust.
Your
registrar,
with
your
link
and
also
like,
have
apis
to
make
updating
that
dns
record
very
easy.
These
are,
like
very
big
ifs,
that
kind
of
limit
who
can
reliably
do
it.
A
I
guess
the
next
level
from
that
is
all
of
the
blockchain-based
dns
things
which
are
kind
of
getting
popular
now,
where
it
kind
of
like
makes
the
apis
a
bit
more
open,
or
in
some
cases
it
might
be
like
more
trustless
and
decentralized
or,
like
you
know,
maybe
some
of
them
will
like
cache
more
of
your
records
locally
or
pre-download
them,
but
at
the
end
of
the
day
it
all
depends
on
the
internet,
which
doesn't
really
fit
with
the
local
first
context.
So
I
don't
think
there's
anything
out
there
right
now.
A
A
I
say
this
is
like
move.com
and
you
say
like
yeah,
it's
move.com
because
you
say
it
is
so
like
lots
of
challenges
there,
obviously
not
perfect,
but
yeah
tldr,
dns
kind
of
works
if
you're
technical,
not
really
local,
first
at
all,
local
first
stuff
might
exist
if
we're
lucky,
like
probably
not
anytime,
soon,
yeah,
just
like
with
zuko's
triangle,
the
whole
like
global
uniqueness,
human,
readable
and
trustlessness
thing.
I
just
kind
of
go
with
global
uniqueness
and
trustlessness
and
then
say
just
share
qr
codes
or
links
directly
between
people.
A
You
trust
yeah,
I
think,
there's
a
question
back
there
as
well,
for
after.
D
Michael's
first,
okay
I'll
ask
my
ninja
people.
So
in
your
fetch
demo
and
like
here,
you
had
like
get
http
url
post,
hp
url
but
at
least
in
my
mental
model,
usually
like
they
get
in
poster
defined
by
http.
So
when
you're
like
get
or
post
or
put
like
ipfs
colon,
you
know
scheme
url.
D
D
Invocations
as
sort
of
being
like
that,
where
we
have
capability
method
names,
sort
of
over
like
rel,
almost
arbitrary
uris
or
at
least
did
uris
and
anyway,
that's
like
potentially
one
answer,
but
I'm
more
just
curious.
If
you
thought
about
okay,
the
protocol
of
that
or
something
methods
plus
arbitrary
uris,
not
just
http.
A
Well,
I
mean
I,
like,
I
just
say,
http,
like
things
or
I
I
say
more,
like
I'm,
taking
these
protocols
and
applying
the
http
like
metaphor
onto
them.
One
like
really
tricky
thing.
There
is
the
method
name,
actually
matters
a
lot
in
terms
of
which
clients
support,
which
methods
which,
like
technically
with
the
spec
you
can
use
like
whatever
the
name
you
want
like.
A
I
can
make
the
method
like
name,
publish
and
the
spec
will
support
it,
but,
like
most
clients
will
not
like
node.js,
won't
do
engine
like
a
bunch
of
other
things
because
for
optimization's
sake
and
maybe
security,
they
just
like
don't
acknowledge
things
existing
so
pretty
much
like
if
we
want
to
use
this
http
like
interface,
which
I
think
is
valuable,
we're
kind
of
stuck
with
like
limiting
ourselves
to
http
like
concepts
yeah,
but
yeah
hd.
If
you
like,.
E
Thank
you
move.
I
really
appreciate
the
demo.
I
think
the
work
is
really
important,
given
that
this
is
a
proof
of
concept.
E
What
do
you
think
is
the
most
constructive
way
of
taking
your
proof
of
concept
to
something
that
becomes
more
ubiquitous,
and
I
would
be
looking
for
something
more
like
very
specifics
or,
like
very
specific
implementations
that
you
think
are
reasonable
to
approach
like
I
would
see
ultimately
to
have.
I
think
you
called
it
agrigore
to
be
something
baked
into
the
operating
system
of
your
local
device,
for
example,
or
maybe
part
of
its
networking
stack,
and
if
that
were
the
vision,
I'm
not
saying
that
it
is.
How
would
you
get
from
here
to
there.
A
This
is
one
is
if
we
can
standardize
some
of
this
ingestible
gateway
concepts
or
writable
gateways,
and
if
we
could
get
them
in
something
like
brave,
because
once
we
can
get
the
ability
to
post
data
to
any
other,
like
you
know,
real
web
browser
with
actual
users
rather
than
like
you
know
the
dozen
or
so
people
that
actively
use
this
thing,
then
we
can
start
like
building
applications
that
are
like
gonna
work
for
the
general
populace,
more
the
other
thing,
speaking
of
applications.
A
You
know
we
have
these
cool
protocols.
We
have
the
ipfs
stuff
working
on
mobile
android,
pretty
well
now's
the
time
to
start
making
little
demos
in
little
apps
to
kind
of
teach
people
how
to
use
these
concepts
by
looking
at
existing
things
and
to
actually
just
show
that
it
it
works
and
is
useful
in
terms
of
operating
systems.
I
have
a
an
evil
scheme,
that's
like
very
low
key.
A
Where
thinking,
maybe
I
can
just
fork,
chrome
os
and
then
just
slap,
the
ipfs
stuff
that
we
already
did
in
there
and
suddenly
we
have
a
peer-to-peer
operating
system,
that's
kind
of
like
a
cappy
loom,
but
more
googled
yeah,
like
I
think,
outside
of
that
for
operating
system.
Integration.
A
Daemons
just
are
kind
of
the
easiest
way
to
integrate
where
I've
integrated
some
of
these
protocol
handlers
as
http
daemons
in
other
program
gramming
languages
in
other
applications
that
are
outside
of
aggregor,
and
since
we
still
have
pretty
much
the
same
metaphor
between
protocol
handlers
and
http
requests.
It's
really
easy
to
make
reusable
code
and
modules
between
those
different
environments.