►
Description
Meeting description here: https://github.com/ipfs/team-mgmt/issues/992#issuecomment-640668300
For more information on IPFS
- visit the project website: https://ipfs.io
- or follow IPFS on Twitter: https://twitter.com/IPFS
Sign up to get IPFS news, including releases, ecosystem updates, and community announcements in your inbox, each Tuesday: http://eepurl.com/gL2Pi5
A
Hello
welcome
everyone
to
the
IVFs
Wheatley
core
implementation.
Sync
I
am
ipfs
zoom
number
two
I
will
be
your
host.
We
are
going
to
go
around
the
room
and
talk
about
important
initiatives
and
then
less
important
initiatives.
They're
all
important
and
then
question
sponsors
parking
lot.
That
kind
of
thing
so
without
further
ado
on
to
the
high
priority
initiatives
upcoming
and
ship
releases
are
someone
snuck
in
in
front
of
Joyce
idea.
First
new
p2p
talk
to
me
us
the
world
tell
us
yeah.
B
So
about
28
shipped
last
week
on
Friday
we're
gonna
put
a
official
announcement
today
or
tomorrow
I'll
be
tomorrow,
that
includes
Pierce
or
updates
and
post
or
persistence,
and
that
also
includes
pure
info
deprecation,
so
we'll
be
getting
getting
rid
of
that
and
that's
that's
mostly
it,
but
there's
more
a
little
bit
more
there.
If
you
want
to
look
at
it,
the
ability
to
listen
and
announce
certain
addresses
no
announce.
That's
all
in
there.
So
take
a
look.
Let
us
know
if
you
have
issues.
A
Incredible
very
excited
about
that
really
I
think
it's
gonna
get
much
smaller
and
faster
right.
It's
there.
It's
kind
of
great
chaos
ipfs
shipped
on
friday,
so
we
shipped
version
no
point
46.
The
haggling
feature
of
that
was
go
okay,
fess
than
0.5
compatibility,
so
they
were
the
a
bunch
of
changes
to
the
api's
and
that
kind
of
thing
and
those
have
all
been
pulled
across
to
JYP
FS
and
the
HTTP
client
as
well.
So
everything
is
100%
compatible,
there's
also
a
bug
in
the
pub/sub
implementation,
which
meant
you
ever
sowed
into
conditions.
A
C
Well,
it's
gonna
come
out
later
today,
it's
most
of
earlier,
just
Friday
got
a
last-minute
bug
where
we
kick,
someone
disconnect,
reconnect
and
then
forget
all
their
dresses,
and
then
we
just
second
try
reconnect
again.
People
feel
to
it
yeah.
D
Yep
so
base
56
supports
lunge
18,
go
IP,
first
master,
I
believe
and
after
discussing
stuff
with
Steven
last
week
we
said
it
to
reevaluate
our
splitting
figs
for
supporting
long
see
IDs
on
subdomain
gateways,
so,
namely
I've
been
running
that
for
a
while
and
two
significant
downsides,
which
I
believe
defeat
the
purpose
of
actually
doing
that
on
a
subdomain
gateway.
So
due
to
the
fact
that
it
split
into
multiple
labels,
there
it's
impossible
to
get
a
TL
TL
s
cert.
D
So
publix
of
the
main
gateways
want
to
be
able
to
provide
that
content
to
people,
and
by
that
I
mean
if
someone
tries
to
open
it
in
regular
user
agent
in
a
web
browser,
they
will
always
get
this
teyla's
error.
So
it's
like
subdomain
gateways
were
created
to
improve
security
in
the
browser
context
by
bringing
origin.
D
So
that
being
said
to
encourage
the
discussion,
we
decided
to
like
postpone
this
just
to
be
clear.
This
is
like
this.
This
is
not
a
problem
with
existing
defaults,
but
we
may
run
into
that
problem.
If
people
try
start
using
hash
functions
which
produce
longer
booty,
hashes
and
in
result
that
will
result
in
no
longer
see
IDs
so
I
closed.
D
The
content
is
more
important
in
that
context,
then,
having
like
this
specific
CID,
because
if
you
are
using
a
public,
HCP
gateway,
you
actually
need
to
trust
the
Gateway
to
send
you
the
content.
You
are
not
actually
taking
advantage
of
Khan
addressing.
You
are
not
like
verifying
the
payload.
You
delegate
that
trust
at
work
to
the
public
gateway.
So
if
you
are
not
able,
so
the
only
purpose
of
subdomain
gateway
at
that
point
is
to
give
you
access
to
the
content
and
that's
not
possible
without
TLS.
D
D
Yes,
it's
effectively
defeating
the
purpose
of
longer
see
IDs,
but
in
this
context
of
someone
accessing
a
public
HTTP
gateway,
they
don't
have
any
security
guarantees
provided
by
a
BFS
anyway,
and
the
point
here
would
be
to
at
least
provide
access
to
people
and
I
will
encourage
everyone
interested
in
this
on
having
a
strong
opinions
to
comment
on
the
PRI
link.
There.
Is
this
a
trail
of
worth
doing
or
do
we
simply
say
on
subdomain
gateways
we
don't
support
C
IDs
longer
than
63,
because
I
don't
believe
at
this
point.
Splitting
brings
any
benefit.
D
It
actually
may
even
confuse
people
because
the
dns
would
resolve,
and
then
people
see
TLS
error.
So
that's
where
we
are
I'm,
not
sure.
If
there
should
be
like
a
separate
design
discussion,
we
probably
could
bounce
some
ideas
a
synchronously
on
that
issue.
I
just
wanted
to
highlight
that's
happening
here.
A
E
A
G
We
just
landed
cat
support
for
the
end
points
and
via
the
UNIX
FS
implementation
that
we're
doing
yet
is
next
and
due
to
some
substrate
grant
work
that
we're
doing
we're
going
to
get
ad
as
well,
so
that
should
sort
of
complete
the
trifecta
of
UNIX
FS
stuff
and
the
sort
of
like
baseline
endpoints
that
the
user
would
do
so.
Things
are
looking
really
good,
I
put
in
the
notes.
The
cat,
PR
and
I'm
also
quickly
adding
a
link
to
an
issue
that
I
would
like
to
invite.
G
All
of
you
to
that's
just
sort
of
brainstorming
future
work
initiative
there
just
to
get
some
input
on
the
directions
we
might
go.
We
got
some
input
from
Steven
already
by
email
and
there's
stuff
that
we're
obviously
sort
of
chewing
on
and
thinking
about
ourselves,
but
just
feel
free
to
come
and
share
your
thoughts.
G
H
I
So,
as
Jacob
said,
28
its
shipped,
it
basically
comes
with
all
the
improvements
that
we
were
planning
on
doing
for
this
first
iteration,
and
this
was
also
already
integrated
in
jessup
FS
today,
and
it
will
be
available
for
a
BFS
users
in
the
next
release.
So
yeah
I
think
we
can
finally
close
this
initiative.
A
Amazing
talking
of
initiatives
that
can
be
closed,
I
think
yeah
I
think
you
can
come
close.
The
council
will
request
one
as
well
paying
the
person
accountable
and
yeah
here.
Any
kind
of
interesting
thing
was
takings
here.
These
are
the
one
less
than
that
shipped
in
45,
so
no
update
on
the
council,
requests
and
I
think
it
can
come
out
of
the
notes
for
the
next
meeting.
I
Yes,
so
basically
I
started
working
on
the
protocol
because
we
have
experienced
some
people
having
issues
related
to
a
new
versions
of
ipfs,
and
will
it
be
in
the
browser.
This
was
basically
a
consequence
of
the
deprecation
of,
and
so
basically
the
goal
is
for
us
from
from
the
next
room.
Hopefully,
the
next
recipe
to
basically
just
use
the
render
for
protocol
and
the
service
relay
and
after
that
starts,
getting
rid
of
the
need
for
the
start.
A
A
A
Okay,
pending
system
revamp,
is
the
same
still
working
on
the
migration
tool,
had
a
super
tedious
thing
with
index
DP
closing
transactions
and
when
my
current
task
queue
is
empty
and
things
that
look
like
they
should
work
that
won't
working,
but
I
have
made
some
progress
on
that,
so
that
should
actually
start
moving,
which
is
great
shed
I
give
us
no.
It's
goes
on
up.
H
However,
I
run
into
certain
roadblocks,
one
of
them
being
how
the
doc
PB
is
implemented.
I
worked
on
implementing
changes,
sent,
said
sort
of
tries
to
bridge
between
where
IPL
the
team
is
going
in
the
future
and
where
we
are
today,
it's
in
the
PR,
it's
been
verified
that
it
passes
all
the
tests
at
worser
and
all
the
years
activists
are
also
encompassing
and
seem
to
see
no
difference.
So
if
we
can
land,
those
and
I
will
be
able
to
make
even
more
progress.
A
J
J
J
J
C
J
F
D
F
D
F
D
No
I
totally
agree.
That's
the
significant
trade
of
both
cost
of
republishing
and
changing
the
MU
T
hush
it's
the
price.
We
would
have
to
pay
to
have
TLS
working
on
some
time,
and
so
that's
just
a
decision
to
make
and
it
unless
there's
a
more
like
concerns,
we
did
not
see
that's
why
I
laugh
more
and
more
eyes
on
that
before
we
make
a
decision.
J
D
Then
well,
if
we,
if
we
are
talking
about
ipfs
URI
right,
if
we
talk
about
that,
then
the
URI
is
just
like
protocol
colon,
slash,
slash,
CID,
whatever
type
of
CID
you
put,
because
you
are
no
longer
limited
by
the
DNS
spec
at
that
point,
when
you
have
your
own
protocol
handler
so
subdomains
only
matter
when
you
use
HTTP
for
interrupt
because
then
you
hit
DNS
and
you
also
hit
public
key
infrastructure
for
serves
when
we
use
our
own
protocol
handler.
That's
not
an
issue
and
I.
Don't
believe.
D
F
Think
here,
that
kind
of
surfaced
recently
is
that
you
are
eyes
not
URLs,
but
you
arise
are
somewhat
infected
by
the
DNS
limitation
in
parcels
in
general.
So,
even
though
you
are
eyes
are
not
genus
bound.
A
lot
of
parsers
like,
for
example,
slack
or
you
know
what
whatever
there
is
a
highlight
for
ánotá,
pastes
and
so
on
and
so
forth
how
to
recognize
a
URI
they,
even
though
they
have
nothing
to
do
with
DNS
they're,
still
limited
to
63
characters
between
dots.
So
that's
something
that
we
need
to.