►
Description
This talk was given at IPFS Camp 2022 in Lisbon, Portugal.
A
A
So
quiet
is
a
slack
alternative
for
desktop
and
for
mobile.
That's
built
on
ipfs
orbit,
DB
and
Tor
that
uses
tour.
Onion
servers
in
store,
onion
Services.
Instead
of
servers,
we
don't
use
servers
at
all
other
than
the
Tor
Network.
So
the
thing
that
makes
quiet
unique
is
that
we're
doing
private
lip,
P2P
and
ipfs
networks
over
tour.
A
It
also
lets
us
do
peer-to-peer
on
Android
and
iOS.
We
have
full
peer-to-peer
working
on
Android
and
iOS
with
JS
ipfs
running
in
node.js
and
while
the
iOS
version
doesn't
run
in
the
background,
because
Apple
doesn't
allow
that
Apple
sort
of
sucks
and
and
limits
a
lot
about
what
developers
can
do
with
peer-to-peer
on
mobile
Android
is
always
on
and
runs
as
a
full
peer-to-peer.
Ios,
node
and
I
actually
have
it
running
here
and
I'm
going
to
show
it
to
you
as
part
of
my
demo.
A
So
so
also
from
the
user's
perspective,
just
joining
a
quiet
community
is
easier,
I
think
than
starting
and
joining
a
slack.
They
don't
need
to
enter
an
email
address
or
go
through
a
signup
process.
That's
as
complicated
as
slack.
They
just
downloaded
an
app
paste
in
an
invite
code
and
and
I
think.
The
promise
for
users
is
that
they
can
control
all
of
their
own
data
without
running
any
of
their
own
infrastructure.
A
The
way
they
would
have
to
with
something
like
a
matrix
or
matter
most
you
kind
of
have
to
have
to
choose
between
okay.
Do
I
really
want
to
set
up
my
own
Matrix
Service
and
maintain
that,
and
is
that
even
really
more
secure
than
Google
quiet
lets
people
not
have
to
face
that
dilemma,
so
here's
I'm
just
going
to
run
through
how
it
works
and
then
I'll
do
a
demo.
A
The
basics
of
how
it
works
is
that
each
team
has
its
own
totally
private,
ipfs
Network,
that's
based
on
each
member,
knowing
each
other's
onion
addresses
and
just
connecting
to
peers
that
they
know
over
tour.
They
connect
with
Torah
and
live
P2P.
We
use
a
modified
version
of
the
lib
P2P
websockets
transport,
just
kind
of
match
that
up
with
Tor
it's
very
unsophisticated
and
we
would
love
like
a
first
class
tour
transport.
But
it's
working
for
us
and
each
connection
is
authenticated
with
a
certificate
from
the
community
owner.
A
So
peers,
don't
accept
incoming
connections
for
peers,
they
don't
know,
and
we
use
orbit
DB
for
messaging
the
way
sending
a
message
works.
Is
you
add
a
you
give
a
message
to
orbit2b.
It
adds
it
to
the
local
state.
It
calculates
the
hash
and
gossips
that
over
Pub
sub
and
then
Pierce
fetch
that
with
bit
Swap
and
that
all
happens
within
the
private
ipfs
Network,
it's
not
happening
on
the
global
ipfs
Network
at
all.
A
So
you
get
really
great
privacy
properties
for
users,
like
my
former
activism
organization,
and
so
how
sending
files
works.
Is
the
sender
pins?
The
file
puts
the
Cid
in
a
message
like
any
other
message:
everybody
fetches
and
pins
all
files
under
a
certain
threshold
and
over
a
certain
threshold
we
fetch
files
just
with
user
intervention
and
at
some
point
soon
we
haven't.
We
haven't
done
this
yet,
but
in
order
to
make
this
like
sustainable
and
also
more
private,
we're
going
to
add
retention
limits
on
messages.
A
So
you
don't
just
like
fill
up
every
user's
device
with
all
of
the
messages
that
have
ever
been
sent,
and
also
so
that
people
who
have
privacy
or
people
who
are
using
the
app
for
its
privacy
properties
can
have
stronger
attention
limits
because
those
are
really
fundamental
for
anybody
doing
real
real
world
private,
sensitive
communication.
You
need
to
be
able
to
know
that
things
will
be
deleted.
After
a
certain
amount
of
time,
so
Auto
deletion
is
is
a
feature
not
a
bug
for
people
who
care
about
privacy.
A
Then
I
would
sync
to
orbitb
and
pull
down
the
list
of
all
the
other
peers
and
I
would
be
a
full-fledged
member
of
the
network.
Oh
and
meanwhile,
the
owner
would
broadcast
my
information
to
all
the
other
peers,
so
they
would
know
how
to
connect
to
me
in
the
future
and
that
user
table
is
synced
just
within
ipfsbase
crtc,
like
all
the
messages.
A
It
also
sells
Nat
traversal,
because
Tor
is
making
an
outgoing
connection
from
your
device
to
the
world.
It's
not
like.
You
don't
need
to
actually
receive
an
incoming
connection,
even
though
in
you're
receiving
an
incoming
connection
without
having
to
have
that
happen
under
the
hood.
So
we
don't
have
to
worry
about
firewalls
and
it
provides
some
basic
end-to-end
encryption
and
metadata
protection
and
I.
Think
from
the
user's
standpoint.
A
Tour
is
great
because
without
something
like
Tor
or
a
mixed
net,
peer-to-peer
networks
are
kind
of
sketchy
for
privacy,
like
you're,
leaking
a
lot
of
data
by
gossiping
all
the
time
about
what
you're,
looking
for
and
and
who
you're
connected
with,
and
also
I.
Think
Tor
for
people
in
the
security
Community
is
and
for
users
themselves
to
some
degree.
It's
a
known
and
trusted
thing.
People
basically
have
some
familiarity,
familiarity
with
how
it
works
as
a
starting
point.
A
A
So
yeah
private
networks
gives
us
a
clear
privacy
story
for
users,
but
it
also
gives
us
better
performance
like
on
mobile.
If
we
were
connecting
to
the
the
global
ipfs
network,
it
would
kill
our
battery
in
a
second
as
it
is.
We
have
a
totally
unoptimized
version
of
our
desktop
peer-to-peer
stack
working
on
mobile
that
we
haven't
even
yeah.
A
We
haven't
done
any
optimizations
yet
and
it
uses
maybe
10
or
20
of
the
battery
in
a
day
when
it's
just
like
in
the
background
which
isn't
good,
but
we
should
be
able
to
reduce
that
a
lot
and
it's
not
that
bad,
so
yeah
we
can
have
full
p2pinos
running
on
Android
yeah,
it's
cool,
and
so
oh
whoops
I
will
give
a
demo
now
I'm
going
to
switch
to
or
I
guess.
I
can
talk
about
this
slide.
This
is
pretty
much
our
wish
list
now.
A
A
There
isn't
anything
that
does
that,
yet
so
we're
going
to
have
to
hack
our
own
so
for
the
one
big
reliability
issue
we
have
right
now
is,
is
that
Tor
has
a
known
bug
where
onion
addresses
are
taking
a
very
long
time
to
connect
once
they're
connected
it's
fast,
but
the
initial
connection
can
take
some
time.
This
shows
up
mostly
when
someone
is
first
joining
the
network.
A
It
can
take
like
many
minutes
to
connect
and
it's
super
annoying,
but
once
someone
is
already
a
part
of
the
network,
we
find
it's
fairly
Fairly
reliable
and
we
have
a
a
test
Suite
pretty
much
all
of
the
the
peer-to-peer
back
end
up
to
State
Management.
We,
we
can
kind
of
run
it
in
headless
mode
and
spin
up
many
of
them
and
test
to
see
how
it
behaves
and
we've
tested
it
with
up
to
250
users,
and
it
behaves
well
like
our
own
front.
B
A
Okay
and
it
so
what
we
could
do
well,
you
can
delete
entire
like
DBS.
We
could
just
drop
an
entire
table,
so
we
could
hack
deletionable
messages
by
saying.
Okay,
every
every
channel
is
a
set
of
of
like
chunks,
maybe
divided
by
week,
say,
and
then
we
could
drop
weeks
once
they
pass
by
a
certain
time
threshold.
Does
that
make
sense,
or
you
could
do
that
for
days,
so
we
could
set
some
time
interval
and
break
everything
all
the
messages
up
by
that
time,
interval
for
a
channel
and
then
drop
old
intervals.
A
A
Thank
you,
yeah,
and
so
so
I
think,
like
the
way
scrdt
would
support
deletion
would
be
to
put
the
in
what
we
could
hack
on
top
of
orbit
DB,
but
it'd
be
better.
If
the
crdt
did,
it
would
be
to
put
the
put
a
CID
pointing
to
the
contents
of
the
message
in
the
log
rather
than
putting
the
contents
of
the
message
in
the
log
and
then
you
would
be
able
to
to
ask
everyone
to
unpin
that
message
in
order
to
delete
it.
A
C
Two
questions
first
question
is:
what's
the
threat
model
of
your
users,
who
would
prefer
this
compared
to
like
a
signal?
Group
second
question
is
more
more
technical
since
you're
running
every
PR
as
a
tour
hidden
service?
Does
that
mean
that
the
pier
has
to
be
always
online
to
receive
messages
and
what
happens
if
I'm
offline,
which
happens
quite
frequently
when
I'm
running
it
on
my
phone
right.
A
Of
course
yeah,
so
I'll
answer
the
second
question.
First.
The
second
question
is
the
reason
why
we
use
a
crdt,
so
using
a
crdt
means
that
if
you
go
offline
momentarily
when
you
return
online,
you'll
exchange
ads
with
other
with
one
of
the
other
peers
in
the
network
and
if
their
heads
differ
from
yours,
you'll
know
that
there
are
messages
you're,
not
aware
of
and
you'll
start
fetching
those
messages,
and
that
happens
very
fast.
A
So
you
it
it's
not
the
IRC
thing
where,
when
you're
offline,
you
miss
messages,
it's
the
slack
thing
where
you
go
offline,
you
come
back.
You
see
what
happened
while
you're
gone,
provided
that
there's
continuous
liveness
between
peers,
like
every
peer
kind
of
has
to
stay
alive,
long
enough
to
sort
of
pass
the
Baton
of
latest
messages
to
the
next
peer,
provided
you
have
that
continuous
liveness
you're
good,
and
if
there
isn't
that
liveness,
it
will
sort
of
partition
and
you'll
get
some
messages
coming
in
a
bit
later.
A
When
that
part
of
the
network
connects
to
your
part
of
the
network
which
isn't
great
but
we've,
we
actually
thought
that
would
be
more
annoying
than
it
actually
is.
We
found
that
since
most
people,
you
know
you're
working
at
the
same
time
as
other
people,
it's
usually
not
an
issue,
okay.
So
to
answer
your
first
question,
the
threat
model
that
we're
building
for
is
is
similar
to
signals.
I
would
say,
like
people
want
confidentiality
and
that's
the
main
thing
that
that
we
we
feel
people
want
the
one
thing
we
offer
now.
A
That
signal
doesn't
yet,
but
will
in
the
future.
Is
you
don't
need
to
link
it
to
your
phone
number?
So,
for
example,
if
a
phone
is
seized
right
now
a
signal,
the
authorities
that
seized
it,
get
your
your
number
and
all
or
get
your
entire
social
graph,
because
they
can
see
all
the
contacts
that
you
communicate
with
in
the
groups
that
you're
active
in
if
they
unlock
your
phone,
whereas
with
quiet
they
would
not
be
able
to
do.
A
That
signal
will
fix
that
at
some
point,
but
I
think
the
main
value
add
for
users
is
that
there
isn't
really
a
signal
for
teams
yet
or
there
isn't
a
clear
winner
there
you
have
Matrix
and
matter
most
and
wire,
and
most
of
these
depend
on
some
type
of
centralization.
Trusting
some
type
of
central
service
or
running
your
own
and
quiet
gives
you
the
team
chat
ux
without
requiring
the
people,
trust
a
central
service
or
run
their
own
stuff.
D
A
Currently,
in
like
the
prototyping
State
we're
in
now,
it's
the
latter
I
just
have
like
an
account
for
my
phone
called
H's
phone
and
an
account
on
my
computer
called
homes,
but
that's
obviously
not
what
we're
shooting
for.
So
that's
one
of
the
things
we
plan
to
implement
is
Multi-Device
support,
and
you
know
it'll
be
something
like
sync:
a
QR
code
appears
and
you
use
that
to
sync
keys
and
it
will
function
under
the
hood,
something
similarly
to
a
private
group.
A
Like
that,
we
we
haven't
done
that
yet
and
on
try
quiet.org,
there's
a
list
of
what
we've
implemented
and
what
we
plan
to
implement.
That
is
not
yet
even
in
the
list
of
things
we
plan
to
implement,
but
it
is
a
it
is
a
cool
feature,
but
but
that
wouldn't
be.
You
know
that
reference
wouldn't
be
usable
outside
of
the
community,
of
course,
because
it's
not
it's
not.
E
Yeah,
thank
you
for
the
talk.
You
said
that
the
user
is
owner
of
the
data,
so
I
was
wondering
if
there
is
any
solution
like
for
plus
deniability
or
if
the
user
is
crossing
the
border.
So
how?
How
do
you
fix
this?
This
problem,
I
mean
they
delete
the
application
and
then
they
can
download
the
data
yeah.
A
Or
not
yeah,
we
haven't,
we
haven't
tackled
account
recovery,
yet
I.
Think
honestly,
like
account,
recovery
is
probably
the
hardest
like
problem
in
all
of
like
web3
usability
right
now,
I
would
say,
and
our
starting
point
will
just
be
everyone
else's,
which
is
you
can
make
a
paper
backup
or
back
up
your
keys
somewhere
else
and
in
the
crossing
the
border
case.
A
You
would
be
able
to
send
your
keys
in
some
way
securely
across
the
board
or
separate
from
you,
delete
everything
from
your
device
and
then
recover
once
you
arrived
at
your
destination,
we're
also
planning
on
making
it
so
that,
because
this
is
like
a
team
chat
structure
and
not
an
individual
chat
structure
like
signal,
we
can
give
the
team
owner
a
lot
of
power
to
help
people
restore
their
accounts.
We
don't
want
to
let
them
impersonate
users,
but
we
we
can.
F
A
Yeah
I
mean
that's,
that's
a
limitation
of
this
approach.
I
I
think
well.
First
of
all,
if
it's
just
text
messages
we're
talking
about
and
the
team
is
small,
you
can
retain
messages
for
quite
a
while.
You
know
you
could
retain
messages
for
months
or
a
year
without
filling
up
a
device.
If
the
team
is
big
and
the
channel
is
very
active,
you'd
fill
up
a
device
quickly.
A
The
I
guess
I
should
step
back
and
say
the
reason
why
I
think
this
approach
is
worth
pursuing,
even
if
there
are
drawbacks,
and
it's
that
I
think
open
source
software
really
hit
a
wall
with
the
cloud
where,
once
we
started
depending
on
servers
controlled
by
other
people,
we
lost
a
lot
of
the
privacy
and
freedom
guarantees
that
are
free
and
open
source.
Software
was
built
to
give
us,
and
we
have
not
solved
that
problem
yet,
and
crypto
and
blockchain
and
decentralized
Tech
exist
to
solve
that
problem.
A
But
we
have
not
solved
it
yet
for
end
user
apps
to
solve
it
for
end
user,
apps
I
think
we
need
to
build
apps
that
can
run
autonomously
on
people's
own
phones
and
give
them
as
much
functionality
as
we
possibly
can
before.
We
make
them
turn
to
a
server,
because
as
soon
as
they
turn
to
a
server,
they
lose
the
privacy
and
freedom
guarantees
that
free
software
gives
them
and
we're
back
in
the
web.
A
2
hellscape,
so
I
think
I
think
it's
worth
pursuing
this
in
trying
to
find
product
Market
fit
with
a
product
that
has
these
limitations.
Even
if
we
know
that
some
users
out
there
want
to
back
up
all
their
messages
forever
and
ever
and
ever
also
I
think
there's
a
ton
of
organizations
out
there
that
are
back
keeping
their
messages
forever.
That
are
foot
gunning
themselves
by
doing
that,
because
as
soon
as
you
get
as
soon
as
you're
in
a
lawsuit
as
soon
as
you
know,
it
could
be
an
HR
thing.
A
It
could
be
something
about
copyright
or
the
government,
or
you
know,
for
web3
and
crypto
companies,
the
SEC,
or
something
like
that
as
soon
as
there's
any
legal
risk.
All
that
stuff
is
going
into
Discovery
and
massively
increases
your
exposure
as
soon
as,
if
you're
doing
any
type
of
sensitive
work.
All
that
stuff
could
get
Spilled,
Out
and
create
months
of
headaches.
A
If
it's
like
showing
up
in
the
Press
that
happened
to
my
organization,
we
we
were
attacked
by
a
mercenary
hacker
for
hire
group
that
was
paid
for
by
some
of
our
adversaries,
we're
not
sure
exactly
who.
But
we
knew
who
the
group
was
eventually
that
attacked
us
and
yeah
they're
looking
for
internal
comms,
that
they
can
spill
out
on
the
internet
in
order
to
try
to
discredit
us
and
every
organization
has
some
Indiscreet
conversations
in
their
slack
and
every
manager
knows
that.