►
A
Hi
everyone
welcome
to
the
ipfs
core
implementations
weekly
sync
for
monday,
the
2nd
of
october
2020..
I
am
aching
brain.
I
am,
will
be
your
host
we're
going
to
go
through
our
high
power
initiatives.
Other
initiatives
parking
lot
q,
a
all
that
good
stuff.
It's
gonna
be
a
great
one.
I'm
not
sure
it's
gonna
be
as
good
as
last
week.
No,
it's
gonna
be
better.
It's
gonna
be
amazing.
Let's
get
on
with
it.
Okay
upcoming
and
shipped
releases.
Wait
hang
on.
We
need
a
note
taker.
A
I
forgot
that's
terrible,
isn't
it
lied
all
done
you're
in
the
left
of
my
screen?
Bad
luck!
Good
luck!
I
mean
it's
all
relative.
Thank
you
very
much
for
volunteering
yourself
like
that
cool.
So,
let's
move
on
anyway,
so
hybrid
high
priority
initiatives.
The
first
thing
is
upcoming
and
ship
releases,
so
just
quickly
shipped
jsipfs51
a
few
days
ago.
It's
great
it
has
types.
It
has
types
omg
mega
lols
that
has
types
I
think
they
work.
They
work
it's
great.
It's
amazing!
A
B
Yes
yeah,
so
there
will
maybe
be
a
release
this
week.
I
need
to
see
there's
a
couple
things
that
need
to
get
added
the
picking
service
work.
We'll
talk
about
in
a
second
is
looking
pretty
good.
Data
store
works,
looking
good
for
that
as
well.
There's
a
quick
upgrade.
We
need
to
do,
and
then
there
are
some
there's
some
go,
live
bdp
work,
they're,
working
on
improving
the
streaming,
there's
some
stream
closures
and,
all
goodness,
with
the
interface
so
they're
going
to
work
on.
A
C
C
I
think
we're
going
to
do
a
final
review
on
all
of
that,
but
as
far
as
it
working
it's
great,
I've
got
the
migrations
as
well,
and
I
will
check
that
should
be
able
to
check
those
in
the
day
they
look
great
both
for
forward
and
backward
migrations
and
other
than
that,
I
don't
know,
there's
anything
less
left
unless
we
want
to
run
it
on
some
actual
customer
data
or
something
like
that
that
we
want.
You
know
to
verify
it.
C
Otherwise
it
looks
like
it
should
be
ready
to
go
this
week
pending
any
any
review,
any
issues
that
come
up
so
not
anticipating
anything,
anything
any
major
changes,
if
any
at
all
so
green
light.
If
there's
any
questions
on
that
nope,
then
we're
moving
forward
with
that.
As
far
as
from
the
next
release.
D
Yeah,
just
a
quick
psa
from
the
pinning
service
api
spec
front.
There
was
a
small
patch
release
which
does
not
change
the
require
format
but
flips
the
way
we
do
search
based
on
pin
names.
So
by
default
it's
now
fast
exact
name,
search
as
a
default,
and
if
you
want
case
insensitive
partial,
then
you
need
to
pass
match
parameter.
D
So
eventually,
please
switch,
I
think,
go
ipfs
client
already
switched
to
the
latest
version.
If
not
it's
it's
not
a
blocker.
It's
kind
of
like
softly
backwards,
compatible
change,
but
we
flipped
us.
We
flip
the
the
default
to
more
performant
thing
as
a
part
of
broader
refinement
of
our
defaults.
In
things
like
listing
pins
or
resolving
stuff,
we
are
switching
to
the
most
performant
default
because
people
often
don't
know,
there's
a
parameter
which
makes
things
faster,
so
we
are
making
the
default
thing
fastest.
D
B
B
A
A
If
there
are
complaints,
they
could
send
them
to
a
pre-designated
pub
sub
channel,
which
of
course
they
won't
be
able
to
because
they
won't
have
psycho.
I
don't
have
noise
enabled
so
that
the
hydro
nodes
they
basically
like
didn't
so
we
hardened
the
network
against
civil
attacks
earlier
in
the
year,
and
the
hydrogens
are
basically
a
civil
attack
on
our
own
network.
Do
they
still
work.
B
So
the
hydras
are
sybils,
but
they're,
not
they're,
not
an
attack.
So
if
you
look
at
like
the
hydras
work,
the
main
thing
what
they
do
is
they
you
get
better
coverage
on
the
network,
so
we've
we've
basically
done
the
calculation
to
get
pure,
solid
peer
id
distribution.
So
if
you
look
at
your
routing
table
over
time,
you'll
have
some
hydro
nodes
in
there,
but
they're
not
overwhelming
your
node
right,
like
the
whole
point
of
the
dht
hardening
like
the
blog
post,
that
we
posted
last
week.
B
This
is,
I
connect
to
your
node
and
then
I
take
over
your
entire
routing
table.
This
is
not
what
the
hydrogenates
do.
It's
a
it's,
a
sybil
for
good,
but
yeah
public
nodes
are
innately.
Public
networks
are
innately
susceptible
to
to
attacks.
We've
just
made
that
very
expensive
to
do,
and
we
are
not
going
to
spend
the
money
to
attack
ourselves,
because
that
would
be
silly.
E
E
With
that,
I
also
implemented
a
custom
dial
address
sorter,
and
the
goal
of
this
is
to
is
allowing
for,
for
example,
we
start
by
dialing,
known
public
addresses
and
only
trying
private
addresses
if
we
cannot
dial
the
problem
so
in
in
the
outer
relay
area.
I
worked
on
this
then
in
the
in
the
rendezvous
side
of
things
I
I
got
back
to
it.
E
It's
still
not
using
the
discovery
api,
but
I
have
a
pr
with
the
rendezvous,
integrated
android
test
and
everything
it's
ready
for
an
initial
review,
as
well
as
the
the
rendezvous
implementation
itself,
and
then
I
basically
started
working
on
some
examples.
We
started
with
the
auto
relay
I've
mostly
done
the
the
example
for
it,
but
I
will
also
leverage
this
opportunity
to
create
tests
for
this
example,
which
is
the
thing
that
we
have
been
delaying
for
a
long
time
in
liberty.
E
A
Cool
adding
test,
your
examples
is
a
good
idea,
just
saying
so
saves
so
much
time,
so
I
have
added
in
a
new
item
in
there,
which
is
bi-directional
streaming
and
streaming
errors
in
the
browser.
In
brief,
what
this
is
is
due
to
the
limitations
of
current
browser
technology.
We
cannot
stream
things
backwards
and
forwards.
A
At
the
same
time,
you
have
to
create
a
form
data
object
before
you
can
like
upload
a
directory
for
the
files,
for
example,
which
requires
consuming
the
entire
stream
before
you
start
sending
it,
which
is
really
boring,
because
you
can't
start
receiving
data
until
you've
sent
all
the
data
so
the
solution.
So
the
other
problem
is
the
streaming
errors
that
the
existing
http
api,
what
it
does
is.
It
puts
all
the
errors
in
http
trailers,
which
is
fab
except
for
no
browser
supports
http
trailers.
A
So
if
you're
streaming
a
whole
bunch
of
stuff
to
the
server
and
there's
an
error,
it
gets
put
into
the
trailer
it
never
arrives,
or
at
least
it
never
gets
processed
by
the
browser.
The
stream
effectively
just
stops,
and
you
think
cool
beans,
I'm
done
except
you're,
not
done.
There
was
an
error
and
you
never
saw
it.
So
it's
not
not
great.
So
the
solution
to
this
kind
of
stuff
is
doing
some
kind
of
rpc
over
a
medium.
A
You
can
stream
bi-directionally
and
you
can
wrap
errors
and
that
kind
of
thing
so
like
websockets,
is
the
obvious
one
to
use
so
look
at
looking.
I
was
looking
into
grpc
today
works
in
node.
It's
great.
It
doesn't
work
in
the
browser
because
it
goes
over
http
in
node.
It
uses
http
2,
which
is
not
doesn't
seem
to
be
supported
in
any
browsers,
so
that's
kind
of
problematic.
A
Now
you
can
just
use
http
too
it's
like,
oh
no.
I
can't
I
can't
use
it
so
you
might
not
be
able
to
use
grpc,
which
is
a
shame,
because
you
know
it's
quite
well
understood
and
the
pro
bottom
nice
and
that
kind
of
thing,
but
yeah
anyway.
So
looking
into
that
just
started
knocking
around
without
today
so
more
updates
next
week,
but
that
will
be
rad
and
will
solve
lots
of
problems
for
us
any
questions.
A
I
mean
I'd
like
to
use
grpc
if
it's,
if
it's,
if
we
can
do
over
web
sockets,
that
would
be
rad,
but
if
it
ends
up
being
a
whole
ton
of
work,
I'm
just
going
to
use
something
else,
because
I
don't
particularly
want
to
be
maintaining
like
the
infrastructure
around
the
thing.
I
just
want
to
use
the
thing
and
get
it
shipped.
F
C
As
far
as
badger,
two
there's
not
really
been
any
movement,
we're
still
waiting
to
see
if
they're
going
to
come
out
with
another
major
release.
That
has
the
features
we
need
in
it,
but
other
than
that,
there's
no.
There
hasn't
been
any
updates
and
no
changes.
We're
ready
to
go
on
our
end,
but
you
know
what
is
it?
We
need
our
actual
release
from
badger
to
move
forward
with
those
features.
A
B
Yeah
we've
got
a
very
long
work
stream
coming
up
moving
it
here
for
now
likely
we'll
move
it
up
with
the
priority
list,
but
we're
still
working
on
the
work
plan
here,
there's
a
bunch
of
things
that
potentially
need
to
get
done
for
this
to
land,
we're
just
figuring
out
exactly
what
that.
What
that
work
plan
is
because
we
need
to
deal
with
things
like
simultaneous
connect,
which
has
implications
on
multi-stream
and
all
kinds
of
stuff.
So
we
are
working
on
figuring
that
all
out.
A
F
A
Like
I
can't,
I
can't
see
a
good
reason
to
have
both
http
and
a
websocket
api
apart
from
fullback
like
the
atg
api,
isn't
going
anywhere
like
there
is,
you
know,
there's
too
much
stuff
built
on
top
of
it.
It's
like
it's
just
a
case
of
like.
Do
you
want
to
pile
more
stuff
onto
that?
Or
do
you
want
to
have
something
else?
A
D
D
Docs.Ipfsio.Ipns.Localhost
the
problem
is
like
on
localhost:
it's
fine
because
there's
no
tls,
the
problem
is,
if
you
want
to
load
it
from
a
public
gateway
and
it's
not
the
original
gateway.
That
is
backing
that
domain
name.
Let's
say
you
want
to
load
it
from
the
web
link
or
maybe
cloudflare's
subdomain
gateway
right
now.
D
D
Domain
names
have
dots
which
split
into
more
than
one
dns
label,
and
that
means
it's
impossible,
given
both
like
technically
maybe
possible,
but
due
to
terms
of
service,
it's
impossible
to
easily
mine
that
type
of
certificate
on
the
fly
and
there's
no
multi-level
wildcard
available.
So
the
idea
is,
there
are
like
different
ideas
and
pros
and
cons
listed
on
the
issue,
but
I
think
the
most
promising
one
is
to
come
up
with
some
simple
encoding.
Where
we
remove
dots
fit
in
the
single
label.
Limit
is
63
characters,
but
I
think
for
most
of
websites.