►
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
So
this
talk
is
not
really
diving
deep
into
any
kind
of
approach
or
technical
direction.
It's
just
a
summary
of
general
thoughts.
I've
been
having,
while
you
know
doing
all
this,
having
these
discussions
with
the
group
of
people
that
have
talked
so
far,
basically
with
florian
earlier
elizabeth
giam
and
others
in
here.
So
okay,
the
motivation
is
pretty
clear.
Privacy,
I
believe,
is
one
of
the
reasons
why
people
come
to
web
3,
but
only
to
find
out
that
things
are
not
too
much
better.
A
They
are
a
little
bit
better
right
now,
because
thing
like
applications
are
not
you
know
developed
as
much
in
order
to
you
know,
gather
users,
data
and
monetize
out
of
that.
But
if
we
leave
the
ship
like
going,
perhaps
that's
there,
there
are
going
to
be
applications
that,
even
in
the
web,
3
space
start
doing
the
same
thing,
which
is
something
we
should
not
get
into.
Others
have
dive
deeper
into
that.
A
What
I
wanted
to
do
is
actually
highlight
the
fact
that
there
are
lots
of
dimensions
into
what
we
want
to
do
and
the
place
is
vast,
like
we
know,
pitbury
networks,
they
have
been
a
big
thing
like
10
15
years
ago.
20,
maybe,
and
there
have
been
papers-
and
you
know-
techniques
for
privacy
as
well,
so
it's
not
a
brand
new
space
and-
and
there
has
been
a
lot
of
work
put
into
it.
A
The
important
thing
here
is-
and
at
least
for
me
it
was
that
I
was
kind
of
getting
lost
into
all
the
different
directions
that
we
wanted
to
investigate
things
that
we
wanted
to
brainstorm
on
and
so
on.
So
I
think
a
very
good
exercise
is,
as
we
go
on,
try
to
identify
the
different
dimensions
that
we
have,
because
we
have
different
actors
like
the
publisher,
privacy
and
client
privacy,
reader
writer
privacy.
As
we
as
we
call
it,
then
we
have
all
these
different
content
routing
systems
in
the
ipfs
stack.
A
So
it
was
a
whole
session
yesterday,
but
the
dhd
is
very
different
to
bitswap.
Bitswap
is
very
different
to
the
indexer
nodes
and
so
on.
Then
you
have
other
versions
like
js
versions
of
jsonpfs
and
lip22p.
A
So
all
these
need
to
be
taken
into
account
and
you
know
basically,
when
we
design
or
when
we
look
into
some
privacy,
preserving
kind
of
technique
or
protocol
enhancement,
we
need
to
place
it
there
and
have
a
map
so
that
you
know
if
you
try
to
improve
privacy
on
the
dht,
but
you
don't
do
on
bitswap,
as
marco
just
mentioned,
then
you're
back
to
square
one.
A
Basically,
so
we
need
to
be
very
clear
about
where,
where
we
want
to
go,
then
you
have
different
layers
right,
so
you
might
be
anonymous
on
the
overlay.
But
what
happens
if
you
leak
information
about
your
multi
address
at
the
network
layer?
And
someone
wants
to
go
after
that,
and
you
know,
although
your
peer
id
is
rotating
or
doing
whatever
and
you
stay
anonymous
there.
If
you
go
underneath
and
you
have
your
ip
address
exposed
all
of
the
time,
then
you
didn't
achieve
much.
Basically,
someone
can
find
out
everything
about
you.
A
Then
there
are
different
dimensions
which
actually
this
is
kind
of
what
I'm
going
to
talk
about
today:
different
dimensions,
even
for
all
categories
of
techniques
that
we
can
look
into,
and
I
would
like
to
focus
for
five
minutes
on
those.
So
you
have
content-based
approaches
and
improvements,
so
one
of
them
is
what
guillain
just
mentioned.
You
can
ask
for
the
double
hash
of
a
cid
or
you
can
ask
for
a
part
of
the
cid
and
so
on.
A
The
private
sector,
intersection
that
we
heard
about
earlier
today
is
again
part
of
that.
It
doesn't
touch
too
much
the
the
routing,
the
routing
subsystem
so
as
to
speak,
obfuscating
with
more
traffic
and
mixnets,
and
so
on
probably
also
fall
into
this.
This
category,
then
you
have
rooting
based.
We
had
about
onion
routing
we
investigated
in
the
past
bit
swap
and
having
a
kind
of
ttl
for
bit
swap
so
right
now,
bitswap
is
asking
the
first
kind
of
immediately
connected
neighbors.
A
What
if
that,
could
go
two
hops
or
three
hops
further
away,
whether
that
would
be
useful.
Performance-Wise
is
a
different
discussion,
but
you
could
say
that
you
know
the
first
order.
Your
first
or
neighbor,
yes,
they
are
going
to
listen
to
what
you're
asking
for,
but
then
from
then
on.
They
won't
know,
and
perhaps
if
there
is
some
randomization
there,
even
the
first
hope
will
not
know
if
you're
the
one
asking
or,
if
you're
the
one
relaying
someone
else's
request.
A
So
again
you
cannot
guarantee
a
hundred
percent
privacy,
but
it
makes
things
a
little
bit
more
difficult
to
to
figure
out.
Then
you
have
okay
content
addressing
there
are
different
approaches:
yeah
no
before
alterative
versus
recursive,
so
the
apfsdht
is
using
recursive
up.
Alternative
has
been
discussed
in
the
past,
but
it
was
rejected
because
of
reflection,
attacks
and
several
other
kind
of
downsides,
but
it
could
be
something
that
people
could
have
a
second
thought
into
and
reconsider.
A
You
know
things
have
changed,
maybe
maybe
the
the
the
attack
surface.
That
was
there,
then
is
not
there
anymore
or
if
you
know
there
are
some
easy
mitigation
strategies
is
something
to
investigate,
because
you
know
the
iterative
lookup
is
clearly
better
in
terms
of
in
terms
of
privacy.
A
Then
we
have
content
addressing
and
yes
it's.
There
has
been
a
big
line
of
work
in
the
academic
sphere
about
contents,
addressed
networks
and
content-centric
networks,
and
there
is
actually
I
have
a
pile
of
papers
that
like
talk
about
that,
and
it
would
be
interesting
to
workshop
around
them
and
like
read
through
what
this
is
saying.
A
There
are
pros
and
cons
there.
If
you
have
content
addressing
you,
have
something
or
content
name
or
address,
or
a
hash
or
cid
whatever
it
is.
We
have
to
understand
that
this
is
out
in
the
clear
if
you
have
it,
if
you're
asking
something
by
name
everyone
in
the
network,
unless
you
encrypt
the
cid
itself
in
a
way,
everyone
knows
what
you're
after
and
that's
even
the
case
for
approaches
that
try
to
put
that
at
the
network
layer
directly.
So
not
as
an
overlay.
A
The
routers
would
understand
and
be
able
to
root
based
on
network
names,
but
then
the
routers
themselves
now
know
what
they're
doing
right
now,
the
internet,
because
it's
blind
and
location
based
they
they
just
forward
to
an
iep
address.
So
unless
the
router
has
a
deep
bucket
inspection,
it
doesn't
know
what
he's
doing
he's
just
blindly
forwarding
data
here
and
there
with
content
addressing
even
not
on
the
overlay
in
the
kind
of
network
layer.
A
Things
are
much
more
in
the
open,
so
that
is
something
that
has
to
be
taken
into
account
and
perhaps
be
kind
of
complemented
with
a
content-based
approach.
Where
you
know
there
is
some
obfuscation
there
or
something
like
that,
so
that
the
cid
or
the
name
or
whatever
the
content
addressing
scheme
is
like
is,
is
more
hidden
and
not
so
much
in
the
open.
A
Then
there
are
a
female
like
well
female
could
be
in
parentheses,
but
id
based
approaches
so
yeah.
It
has
been
discussed
even
with
part
of
this
group
a
few
months
ago,
that
you
know
nodes
could
rotate
their
peer
id
every
so
often
say
every
24
hours
or
every
48
hours
or
whatever.
So
you
kind
of
have
snapshots
of
the
dht,
but
nodes
rotate
their
pid,
so
there
you
cannot
really
find
them
after
a
while,
you
know
with
the
same
period
of
course.
The
next
question
is
what
happens
with
the
multi
address.
A
So
if
you're
in
the
same
ip
address-
and
you
change
your
peer
id,
then
probably
people
can
locate
you,
okay,
you
know
ip
addresses
change
as
well,
because
nodes
move
and
so
on,
but
someone
could
link
now
if
we
kind
of
put
that
together
with
nodes
and
blending
their
cid
with
some
randomness
like
encrypting
or
like
obfuscating,
somehow
the
cid,
then
you
can.
A
You
could
potentially
arrive
in
a
situation
where,
when
you
want
to
go
back
to
yesterday
or
last
month
or
last
year
and
see
what
these
peer
particularly
asked
for,
you
don't
have.
You
have
broken
the
linkability
between
both
the
peer
id
and
the
content,
address
the
cid
or
the
content
that
the
peers
asked
for.
So
in
that
case
you
know
it's.
A
It
becomes
basically
exponentially
more
difficult
to
try
and
get
a
snapshot
of
the
network
back
then,
where
you
have
either
the
cid
or
you
can
link
between
different
peer
ids
and
you
end
up,
like
figuring
out
peer
did
yeah.
So
I
I
think
that
pretty
much
concludes
what
I
wanted
to
bring
to
the
table
some
facts.
We
cl.
We
need
to
think
a
clearly
defined
threat
model
because
you
know
all
of
the
different
approach,
all
of
the
different
dimensions
that
I
brought
here.
A
Each
one
of
them
could
have
a
different
threat
model
and
we
need
to
know
what
we're
attacking
what
we're
trying
to
solve
here.
It's
definitely,
I
would
say
impossible
to
you,
know,
find
one
size
fits
all
solution,
so
yeah
juan's,
write
up
today
in
the
hackmd
document,
seemed
like
a
good
start
there,
but,
but
still
it's
a
long
list,
so
we
need
to
have
a
threat
model
for
each
one
of
them,
perhaps
also
a
different
solution
for
each
one
of
them.
A
Performance
will
always
get
hit.
We
know
that,
but
it's
always,
I
think,
good,
to
remind
ourselves
and
our
users
yeah
and
that's
it.
Basically.
I
think
we
need
to
do
an
exercise
of
putting
all
these
in
some
kind
of
spectrum,
these
different
dimensions
and
then
place
the
solutions
according
to
where
they
are
just
so
that
we
know
which
part
we
are
we're
targeting
yeah.
That's
it.
A
What
what
does
the
like?
Dram
blending?
Look
like,
I
don't
know,
that's
that's
very
brainstorming
thing
we're
having
a
discussion
in
some
discord
channel
the
other
day
about
being
able
to
have
it
as
a
feature
where,
in
order
to
create
your
peer
id,
you
get
randomness
from
dirhand
or
some
other
randomness
generator
during
this
good,
because
you
can
verify
whether
someone
did
it
or
not
and
then
not
for
privacy
reasons.
It
was
for
a
different
reason,
but
if
you
want
to
obfuscate,
perhaps
you
know
what
your
cid
looks
like
you
can
get.
A
I
don't
know
a
deer
on
randomness
value
and
hash
it
together,
but
knowing
which
rounds
which
epoch
of
different
this
happen.
So
you
can
go
back
actually
and
kind
of
it's.
It's
not
it's
like
an
encoding
step,
perhaps
which
yeah
everyone
would
have
access
in
the
future,
but
yeah.
Perhaps
it
would
make
it
more
difficult
to
you
know
it
would
bring
break
link
ability
at
some
point.
A
Can
you
explain
the
iterative
phd
lookup
thing
so
so
what
was
the
reflection
yeah?
So
this
is
a
big
well,
there
are
some
issues,
hence
I'm
not
really
even
an
expert.
I
can't
remember
exactly
the
details,
but
the
the
base
thing
is
that,
instead
of
like
asking
someone
and
getting
back
the
request,
the
response
and
then
asking
again
basically
you
delegate,
you
ask
your
first
hop
node
and
then
they
ask
for
you
right.
A
A
Obviously,
because
you're
going
to
be
shot
back,
but
if
not,
then
you
can
just
send
out
requests
you're
over
overloading
other
nodes
and
you
basically
don't
care
because
you
might
at
some
point
receive
the
responses
only,
but
you
know
nodes
might
be
dead
by
then,
but
certainly
because
on
only
the
first
node
you're
asking
knows
like
who
you
are,
then
the
rest
is
kind
of
hidden.
So
in
that,
in
that
sense
you
know
it
improves
privacy.
In
a
sense,
but
of
course
again
it
depends
what
the
way
back
looks
like.
A
If
the
way
back
looks
like
you
know,
your
multi-address
or
pid
is
carried
over
and
the
final
source
of
content
is
just
connecting
to
you
and
sending
you
content.
Then
you
haven't
achieved
anything.
The
trick
would
be
to
send
the
content
all
the
way
back
through
those
nodes,
so
that
every
intermediate
step
don't
know
what
they're
doing
they're
just
forwarding
content,
and
only
the
last
one,
which
has
been
your
first
knows
who
you
are
and
what
you
have
asked
for.